Influxdata
/
docs-v2
mirror of https://github.com/influxdata/docs-v2.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

resolved merge conflicts

pull/2001/head
Scott Anderson 2020-12-23 13:56:20 -07:00
parent bad6817bf4 793d5f5dce
commit 312c55d7ad
84 changed files with 6474 additions and 600 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
CONTRIBUTING.md
View File

@ -431,6 +431,20 @@ The following parameters are available:
{{< keybind mac="⇧⌘P" linux="Ctrl+Shift+P" win="Ctrl+Shift+Alt+P" >}}
```
### Diagrams
Use the `{{< diagram >}}` shortcode to dynamically build diagrams.
The shortcode uses [mermaid.js](https://github.com/mermaid-js/mermaid) to convert
simple text into SVG diagrams.
For information about the syntax, see the [mermaid.js documentation](https://mermaid-js.github.io/mermaid/#/).
```md
{{< diagram >}}
flowchart TB
This --> That
That --> There
{{< /diagram >}}
```
### High-resolution images
In many cases, screenshots included in the docs are taken from high-resolution (retina) screens.
Because of this, the actual pixel dimension is 2x larger than it needs to be and is rendered 2x bigger than it should be.

1
assets/styles/layouts/_article.scss
View File

@ -102,6 +102,7 @@
"article/children",
"article/code",
"article/cloud",
"article/diagrams",
"article/enterprise",
"article/expand",
"article/feedback",

44
assets/styles/layouts/article/_diagrams.scss Normal file
View File

@ -0,0 +1,44 @@
.mermaid {
opacity: 0;
color: $article-bg;
margin: 3rem 0;
transition: opacity .5s;
.arrowheadPath, .arrowMarkerPath { fill: $diagram-arrow !important; }
.edgePath .path, .flowchart-link { stroke: $diagram-arrow !important; }
.label { color: $article-text !important; }
.cluster-label .nodeLabel {
color: $article-code !important;
}
.edgeLabel {
color: $article-text !important;
background: $article-code-bg !important;
font-size: .85em;
font-weight: $medium;
}
.node {
rect,
circle,
ellipse,
polygon,
path {
fill: $article-bg !important;
stroke: $diagram-arrow !important;
stroke-width: 2px !important;
}
.label { color: $article-text !important; }
}
.cluster {
rect,
circle,
ellipse,
polygon,
path {
fill: $article-code-bg !important;
stroke: none !important;
}
}
}

3
assets/styles/themes/_theme-dark.scss
View File

@ -209,6 +209,9 @@ $svg-geo-s2-cell: $b-dodger;
$svg-geo-region: $p-comet;
$svg-geo-point: $br-chartreuse;
// Diagram colors
$diagram-arrow: $g6-smoke;
@import "dark/telegraf",
"dark/chronograf",
"dark/kapacitor";

3
assets/styles/themes/_theme-light.scss
View File

@ -209,6 +209,9 @@ $svg-geo-s2-cell: $b-hydrogen !default;
$svg-geo-region: $br-galaxy !default;
$svg-geo-point: $p-potassium !default;
// Diagram colors
$diagram-arrow: $g14-chromium !default;
@import "light/telegraf",
"light/chronograf",
"light/kapacitor";

34
content/enterprise_influxdb/v1.5/concepts/clustering.md
View File

@ -15,30 +15,16 @@ This document describes in detail how clustering works in InfluxEnterprise. It s
An InfluxEnterprise installation consists of three separate software processes: Data nodes, Meta nodes, and the Enterprise Web server. To run an InfluxDB cluster, only the meta and data nodes are required. Communication within a cluster looks like this:
```text
┌───────┐ ┌───────┐
│ │ │ │
│ Meta1 │◀───▶│ Meta2 │
│ │ │ │
└───────┘ └───────┘
▲ ▲
│ │
│ ┌───────┐ │
│ │ │ │
└─▶│ Meta3 │◀─┘
│ │
└───────┘
─────────────────────────────────
╲│╱ ╲│╱
┌────┘ └──────┐
│ │
┌───────┐ ┌───────┐
│ │ │ │
│ Data1 │◀────────▶│ Data2 │
│ │ │ │
└───────┘ └───────┘
```
{{< diagram >}}
flowchart TB
subgraph meta[Meta Nodes]
Meta1 <-- TCP :8089 --> Meta2 <-- TCP :8089 --> Meta3
end
meta <-- HTTP :8091 --> data
subgraph data[Data Nodes]
Data1 <-- TCP :8088 --> Data2
end
{{< /diagram >}}
The meta nodes communicate with each other via a TCP protocol and the Raft consensus protocol that all use port `8089` by default. This port must be reachable between the meta nodes. The meta nodes also expose an HTTP API bound to port `8091` by default that the `influxd-ctl` command uses.

34
content/enterprise_influxdb/v1.6/concepts/clustering.md
View File

@ -15,30 +15,16 @@ This document describes in detail how clustering works in InfluxDB Enterprise. I
An InfluxDB Enterprise installation consists of three separate software processes: Data nodes, Meta nodes, and the Enterprise Web server. To run an InfluxDB cluster, only the meta and data nodes are required. Communication within a cluster looks like this:
```text
┌───────┐ ┌───────┐
│ │ │ │
│ Meta1 │◀───▶│ Meta2 │
│ │ │ │
└───────┘ └───────┘
▲ ▲
│ │
│ ┌───────┐ │
│ │ │ │
└─▶│ Meta3 │◀─┘
│ │
└───────┘
─────────────────────────────────
╲│╱ ╲│╱
┌────┘ └──────┐
│ │
┌───────┐ ┌───────┐
│ │ │ │
│ Data1 │◀────────▶│ Data2 │
│ │ │ │
└───────┘ └───────┘
```
{{< diagram >}}
flowchart TB
subgraph meta[Meta Nodes]
Meta1 <-- TCP :8089 --> Meta2 <-- TCP :8089 --> Meta3
end
meta <-- HTTP :8091 --> data
subgraph data[Data Nodes]
Data1 <-- TCP :8088 --> Data2
end
{{< /diagram >}}
The meta nodes communicate with each other via a TCP protocol and the Raft consensus protocol that all use port `8089` by default. This port must be reachable between the meta nodes. The meta nodes also expose an HTTP API bound to port `8091` by default that the `influxd-ctl` command uses.

34
content/enterprise_influxdb/v1.7/concepts/clustering.md
View File

@ -15,30 +15,16 @@ This document describes in detail how clustering works in InfluxDB Enterprise. I
An InfluxDB Enterprise installation consists of three separate software processes: data nodes, meta nodes, and the Enterprise web server. To run an InfluxDB cluster, only the meta and data nodes are required. Communication within a cluster looks like this:
```text
┌───────┐ ┌───────┐
│ │ │ │
│ Meta1 │◀───▶│ Meta2 │
│ │ │ │
└───────┘ └───────┘
▲ ▲
│ │
│ ┌───────┐ │
│ │ │ │
└─▶│ Meta3 │◀─┘
│ │
└───────┘
─────────────────────────────────
╲│╱ ╲│╱
┌────┘ └──────┐
│ │
┌───────┐ ┌───────┐
│ │ │ │
│ Data1 │◀────────▶│ Data2 │
│ │ │ │
└───────┘ └───────┘
```
{{< diagram >}}
flowchart TB
subgraph meta[Meta Nodes]
Meta1 <-- TCP :8089 --> Meta2 <-- TCP :8089 --> Meta3
end
meta <-- HTTP :8091 --> data
subgraph data[Data Nodes]
Data1 <-- TCP :8088 --> Data2
end
{{< /diagram >}}
The meta nodes communicate with each other via a TCP protocol and the Raft consensus protocol that all use port `8089` by default. This port must be reachable between the meta nodes. The meta nodes also expose an HTTP API bound to port `8091` by default that the `influxd-ctl` command uses.

40
content/enterprise_influxdb/v1.8/administration/ports.md
View File

@ -8,23 +8,53 @@ menu:
parent: Administration
---
![InfluxDB Enterprise network diagram](/img/enterprise/1-8-network-diagram.png)
## Enabled ports
![](/img/enterprise/1-8-network-diagram.png)
### 8086
### `8086`
The default port that runs the InfluxDB HTTP service.
It is used for the primary public write and query API.
Clients include the CLI, Chronograf, InfluxDB client libraries, Grafana, curl, or anything that wants to write and read time series data to and from InfluxDB.
[Configure this port](/enterprise_influxdb/v1.8/administration/config-data-nodes/#bind-address-8088)
in the data node configuration file.
**Resources** [API Reference](/influxdb/v1.8/tools/api/)
_See also: [API Reference](/influxdb/v1.8/tools/api/)._
### 8088
The default port used for RPC calls used for inter-node communication and by the CLI for backup and restore operations (`influxdb backup` and `influxd restore`).
Data nodes listen on this port.
Primarily used by other data nodes to handle distributed reads and writes at runtime.
Used to control a data node (e.g., tell it to write to a specific shard or execute a query).
It's also used by meta nodes for cluster-type operations (e.g., tell a data node to join or leave the cluster).
This is the default port used for RPC calls used for inter-node communication and by the CLI for backup and restore operations
(`influxdb backup` and `influxd restore`).
[Configure this port](/influxdb/v1.8/administration/config#bind-address-127-0-0-1-8088)
in the configuration file.
**Resources** [Backup and Restore](/influxdb/v1.8/administration/backup_and_restore/)
This port should not be exposed outside the cluster.
_See also: [Backup and Restore](/influxdb/v1.8/administration/backup_and_restore/)._
### 8089
Used for communcation between meta nodes.
It is used by the Raft consensus protocol.
The only clients using `8089` should be the other meta nodes in the cluster.
This port should not be exposed outside the cluster.
### 8091
Meta nodes listen on this port.
It is used for the meta service API.
Primarily used by data nodes to stay in sync about databases, retention policies, shards, users, privileges, etc.
Used by meta nodes to receive incoming connections by data nodes and Chronograf.
Clients also include the `influxd-ctl` command line tool and Chronograph,
This port should not be exposed outside the cluster.
## Disabled ports

33
content/enterprise_influxdb/v1.8/concepts/clustering.md
View File

@ -17,30 +17,17 @@ This document describes in detail how clustering works in InfluxDB Enterprise. I
An InfluxDB Enterprise installation consists of three separate software processes: data nodes, meta nodes, and the Enterprise web server. To run an InfluxDB cluster, only the meta and data nodes are required. Communication within a cluster looks like this:
```text
┌───────┐ ┌───────┐
│ │ │ │
│ Meta1 │◀───▶│ Meta2 │
│ │ │ │
└───────┘ └───────┘
▲ ▲
│ │
│ ┌───────┐ │
│ │ │ │
└─▶│ Meta3 │◀─┘
│ │
└───────┘
{{< diagram >}}
flowchart TB
subgraph meta[Meta Nodes]
Meta1 <-- TCP :8089 --> Meta2 <-- TCP :8089 --> Meta3
end
meta <-- HTTP :8091 --> data
subgraph data[Data Nodes]
Data1 <-- TCP :8088 --> Data2
end
{{< /diagram >}}
─────────────────────────────────
╲│╱ ╲│╱
┌────┘ └──────┐
│ │
┌───────┐ ┌───────┐
│ │ │ │
│ Data1 │◀────────▶│ Data2 │
│ │ │ │
└───────┘ └───────┘
```
The meta nodes communicate with each other via a TCP protocol and the Raft consensus protocol that all use port `8089` by default. This port must be reachable between the meta nodes. The meta nodes also expose an HTTP API bound to port `8091` by default that the `influxd-ctl` command uses.

1
content/influxdb/cloud/query-data/influxql.md
View File

@ -147,6 +147,7 @@ To learn more about InfluxQL, see [Influx Query Language (InfluxQL)](/{{< latest
- `DELETE`*
- `DROP MEASUREMENT`*
- `EXPLAIN ANALYZE`
- `SELECT` _(read-only)_
- `SHOW DATABASES`
- `SHOW MEASUREMENTS`

39
content/influxdb/cloud/reference/flux/stdlib/built-in/transformations/stream-table/_index.md
View File

@ -17,41 +17,4 @@ related:
- /influxdb/cloud/query-data/flux/scalar-values/
---
Use stream and table functions to extract a table from a stream of tables and access its
columns and records.
{{< children type="functions" >}}
### Example stream and table functions
##### Recommended usage
```js
data = from(bucket:"example-bucket")
|> range(start: -5m)
|> filter(fn:(r) => r._measurement == "cpu")
// Extract the "_value" column from the table
data
|> findColumn(fn: (key) => key._field == "usage_idle", column: "_value")
// Extract the first record from the table
data
|> findRecord(fn: (key) => key._field == "usage_idle", idx: 0)
```
##### Alternate usage
```js
data = from(bucket:"example-bucket")
|> range(start: -5m)
|> filter(fn:(r) => r._measurement == "cpu")
// Extract the first available table for which "_field" is equal to "usage_idle"
t = data |> tableFind(fn: (key) => key._field == "usage_idle")
// Extract the "_value" column from the table
values = t |> getColumn(column: "_value")
// Extract the first record from the table
r0 = t |> getRecord(idx: 0)
```
{{< duplicate-oss >}}

41
content/influxdb/cloud/reference/flux/stdlib/built-in/transformations/stream-table/findcolumn.md
View File

@ -12,43 +12,4 @@ related:
- /influxdb/cloud/query-data/flux/scalar-values/
---
The `findColumn()` function returns an array of values in a specified column from the
first table in a stream of tables where the group key values match the specified predicate.
The function returns an empty array if no table is found or if the column label
is not present in the set of columns.
_**Function type:** Stream and table_
```js
findColumn(
fn: (key) => key._field == "fieldName")
column: "_value"
)
```
## Parameters
### fn
A predicate function for matching keys in a table's group key.
Expects a `key` argument that represents a group key in the input stream.
_**Data type:** Function_
### column
Name of the column to extract.
_**Data type:** String_
## Example
```js
vs = from(bucket:"example-bucket")
|> range(start: -5m)
|> filter(fn:(r) => r._measurement == "cpu")
|> findColumn(
fn: (key) => key._field == "usage_idle",
column: "_value"
)
// Use column values
x = vs[0] + vs[1]
```
{{< duplicate-oss >}}

2
content/influxdb/cloud/reference/flux/stdlib/built-in/transformations/stream-table/findrecord.md
View File

@ -20,7 +20,7 @@ _**Function type:** Stream and table_
```js
findRecord(
fn: (key) => key._field == "fieldName",
fn: (key) => key._field == "fieldName"),
idx: 0
)
```

35
content/influxdb/cloud/reference/flux/stdlib/built-in/transformations/stream-table/getcolumn.md
View File

@ -14,37 +14,4 @@ related:
- /influxdb/cloud/query-data/flux/scalar-values/
---
The `getColumn()` function extracts a column from a table given its label.
If the label is not present in the set of columns, the function errors.
_**Function type:** Stream and table_
```js
getColumn(column: "_value")
```
{{% note %}}
#### Use tableFind() to extract a single table
`getColumn()` requires a single table as input.
Use [`tableFind()`](/influxdb/cloud/reference/flux/stdlib/built-in/transformations/stream-table/tablefind/)
to extract a single table from a stream of tables.
{{% /note %}}
## Parameters
### column
Name of the column to extract.
_**Data type:** String_
## Example
```js
vs = from(bucket:"example-bucket")
|> range(start: -5m)
|> filter(fn:(r) => r._measurement == "cpu")
|> tableFind(fn: (key) => key._field == "usage_idle")
|> getColumn(column: "_value")
// Use column values
x = vs[0] + vs[1]
```
{{< duplicate-oss >}}

35
content/influxdb/cloud/reference/flux/stdlib/built-in/transformations/stream-table/getrecord.md
View File

@ -14,37 +14,4 @@ related:
- /influxdb/cloud/query-data/flux/scalar-values/
---
The `getRecord()` function extracts a record from a table given the record's index.
If the index is out of bounds, the function errors.
_**Function type:** Stream and table_
```js
getRecord(idx: 0)
```
{{% note %}}
#### Use tableFind() to extract a single table
`getRecord()` requires a single table as input.
Use [`tableFind()`](/influxdb/cloud/reference/flux/stdlib/built-in/transformations/stream-table/tablefind/)
to extract a single table from a stream of tables.
{{% /note %}}
## Parameters
### idx
Index of the record to extract.
_**Data type:** Integer_
## Example
```js
r0 = from(bucket:"example-bucket")
|> range(start: -5m)
|> filter(fn:(r) => r._measurement == "cpu")
|> tableFind(fn: (key) => key._field == "usage_idle")
|> getRecord(idx: 0)
// Use record values
x = r0._field + "--" + r0._measurement
```
{{< duplicate-oss >}}

47
content/influxdb/cloud/reference/flux/stdlib/built-in/transformations/stream-table/tablefind.md
View File

@ -14,49 +14,4 @@ related:
- /influxdb/cloud/query-data/flux/scalar-values/
---
The `tableFind()` function extracts the first table in a stream of tables whose
group key values match a predicate. If no table is found, the function errors.
_**Function type:** Stream and table_
```js
tableFind(fn: (key) => key._field == "fieldName")
```
## Parameters
{{% note %}}
Make sure `fn` parameter names match each specified parameter.
To learn why, see [Match parameter names](/influxdb/cloud/reference/flux/language/data-model/#match-parameter-names).
{{% /note %}}
### fn
A predicate function for matching keys in a table's group key.
`tableFind` returns the first table that resolves as `true`.
Expects a `key` argument that represents a group key in the input stream.
_**Data type:** Function_
##### Example fn function
```js
(key) => key._field == "fieldName"
```
## Example
```js
t = from(bucket:"example-bucket")
|> range(start: -5m)
|> filter(fn:(r) => r._measurement == "cpu")
|> tableFind(fn: (key) => key._field == "usage_idle")
// t represents the first table in a stream whose group key
// contains "_field" with a value of "usage_idle".
```
{{% note %}}
You can use `t` from the example above as input for [`getColumn()`](/influxdb/cloud/reference/flux/stdlib/built-in/transformations/stream-table/getcolumn/)
and [`getRecord()`](/influxdb/cloud/reference/flux/stdlib/built-in/transformations/stream-table/getrecord/).
{{% /note %}}
{{< duplicate-oss >}}

12
content/influxdb/cloud/tools/grafana.md
View File

@ -86,15 +86,15 @@ configure your InfluxDB connection:
2. Under **Auth**, enable **Basic Auth**.
3. Under **Basic Auth Details**, provide your InfluxDB authentication credentials:
- **username**: InfluxDB username
- **password**: InfluxDB [authentication token](/influxdb/cloud/security/tokens/)
- **User**: InfluxDB username
- **Password**: InfluxDB [authentication token](/influxdb/cloud/security/tokens/)
4. Under **InfluxDB details**, set the following:
4. Under **InfluxDB Details**, do the following:
- **Database**: The database to use when querying InfluxDB.
_See [Database and retention policy mapping](/influxdb/cloud/reference/api/influxdb-1x/dbrp/)._
- **Database**: Enter the ID of the bucket to query in InfluxDB Cloud. To retrieve your bucket ID, see how to [view buckets](/influxdb/cloud/organizations/buckets/view-buckets/).
- **User**: Enter the username to sign into InfluxDB.
- **Password**: Enter the token used to query the bucket above. To retrieve your token, see how to [view tokens](/influxdb/cloud/security/tokens/view-tokens/).
- **HTTP Method**: Select **GET**.
- **Min time interval**: The [Grafana minimum time interval](https://grafana.com/docs/grafana/latest/features/datasources/influxdb/#min-time-interval).
{{< img-hd src="/img/influxdb/2-0-visualize-grafana-influxql.png" />}}

39
content/influxdb/v1.8/concepts/key_concepts.md
View File

@ -9,34 +9,21 @@ menu:
v2: /influxdb/v2.0/reference/key-concepts/
---
Before diving into InfluxDB it's good to get acquainted with some of the key concepts of the database.
This document provides a gentle introduction to those concepts and common InfluxDB terminology.
We've provided a list below of all the terms we'll cover, but we recommend reading this document from start to finish to gain a more general understanding of our favorite time series database.
Before diving into InfluxDB, it's good to get acquainted with some key concepts of the database. This document introduces key InfluxDB concepts and elements. To introduce the key concepts, we’ll cover how the following elements work together in InfluxDB:
<table style="width:100%">
<tr>
<td><a href="#database">database</a></td>
<td><a href="#field-key">field key</a></td>
<td><a href="#field-set">field set</a></td>
</tr>
<tr>
<td><a href="#field-value">field value</a></td>
<td><a href="#measurement">measurement</a></td>
<td><a href="#point">point</a></td>
</tr>
<tr>
<td><a href="#retention-policy">retention policy</a></td>
<td><a href="#series">series</a></td>
<td><a href="#tag-key">tag key</a></td>
</tr>
<tr>
<td><a href="#tag-set">tag set</a></td>
<td><a href="#tag-value">tag value</a></td>
<td><a href="#timestamp">timestamp</a></td>
</tr>
</table>
- [database](/influxdb/v1.8/concepts/glossary/#database)
- [field key](/influxdb/v1.8/concepts/glossary/#field-key)
- [field set](/influxdb/v1.8/concepts/glossary/#field-set)
- [field value](/influxdb/v1.8/concepts/glossary/#field-value)
- [measurement](/influxdb/v1.8/concepts/glossary/#measurement)
- [point](/influxdb/v1.8/concepts/glossary/#point)
- [retention policy](/influxdb/v1.8/concepts/glossary/#retention-policy-rp)
- [series](/influxdb/v1.8/concepts/glossary/#series)
- [tag key](/influxdb/v1.8/concepts/glossary/#tag-key)
- [tag set](/influxdb/v1.8/concepts/glossary/#tag-set)
- [tag value](/influxdb/v1.8/concepts/glossary/#tag-value)
- [timestamp](/influxdb/v1.8/concepts/glossary/#timestamp)
Check out the [glossary](/influxdb/v1.8/concepts/glossary/) if you prefer the cold, hard facts.
### Sample data

10
content/influxdb/v2.0/get-started.md
View File

@ -32,7 +32,7 @@ _See [Differences between InfluxDB Cloud and InfluxDB OSS](#differences-between-
Download InfluxDB v2.0 for macOS.
<a class="btn download" href="https://dl.influxdata.com/influxdb/releases/influxdb-2.0.3_darwin_amd64.tar.gz" download>InfluxDB v2.0 (macOS)</a>
<a class="btn download" href="https://dl.influxdata.com/influxdb/releases/influxdb2-2.0.3_darwin_amd64.tar.gz" download>InfluxDB v2.0 (macOS)</a>
### (Optional) Verify the authenticity of downloaded binary
@ -50,7 +50,7 @@ If `gpg` is not available, see the [GnuPG homepage](https://gnupg.org/download/)
For example:
```
wget https://dl.influxdata.com/influxdb/releases/influxdb-2.0.3_darwin_amd64.tar.gz.asc
wget https://dl.influxdata.com/influxdb/releases/influxdb2-2.0.3_darwin_amd64.tar.gz.asc
```
3. Verify the signature with `gpg --verify`:
@ -177,7 +177,7 @@ If `gpg` is not available, see the [GnuPG homepage](https://gnupg.org/download/)
3. Verify the signature with `gpg --verify`:
```
gpg --verify influxdb-2.0.3_linux_amd64.tar.gz.asc influxdb-2.0.3_linux_amd64.tar.gz
gpg --verify influxdb2-2.0.3_linux_amd64.tar.gz.asc influxdb2-2.0.3_linux_amd64.tar.gz
```
The output from this command should include the following:
@ -194,10 +194,10 @@ _**Note:** The following commands are examples. Adjust the file names, paths, an
```sh
# Unpackage contents to the current working directory
tar xvzf path/to/influxdb-2.0.3_linux_amd64.tar.gz
tar xvzf path/to/influxdb2-2.0.3_linux_amd64.tar.gz
# Copy the influx and influxd binary to your $PATH
sudo cp influxdb-2.0.3_linux_amd64/{influx,influxd} /usr/local/bin/
sudo cp influxdb2-2.0.3_linux_amd64/{influx,influxd} /usr/local/bin/
```
{{% note %}}

1
content/influxdb/v2.0/query-data/influxql.md
View File

@ -218,6 +218,7 @@ To learn more about InfluxQL, see [Influx Query Language (InfluxQL)](/{{< latest
- `DELETE`*
- `DROP MEASUREMENT`*
- `EXPLAIN ANALYZE`
- `SELECT` _(read-only)_
- `SHOW DATABASES`
- `SHOW MEASUREMENTS`

2
content/influxdb/v2.0/reference/flux/stdlib/built-in/transformations/stream-table/findcolumn.md
View File

@ -21,7 +21,7 @@ _**Function type:** Stream and table_
```js
findColumn(
fn: (key) => key._field == "fieldName")
fn: (key) => key._field == "fieldName",
column: "_value"
)
```

2
content/influxdb/v2.0/reference/flux/stdlib/built-in/transformations/stream-table/findrecord.md
View File

@ -20,7 +20,7 @@ _**Function type:** Stream and table_
```js
findRecord(
fn: (key) => key._field == "fieldName",
fn: (key) => key._field == "fieldName"),
idx: 0
)
```

2
content/influxdb/v2.0/tools/client-libraries/go.md
View File

@ -26,7 +26,7 @@ If just getting started, see [Get started with InfluxDB](/influxdb/v2.0/get-star
```sh
# Add InfluxDB Go client package to your project go.mod
go get github.com/influxdata/influxdb-client-go/v2
go get github.com/influxdata/influxdb-client-go
```
3. Ensure that InfluxDB is running and you can connect to it.
For information about what URL to use to connect to InfluxDB OSS or InfluxDB Cloud, see [InfluxDB URLs](/influxdb/v2.0/reference/urls/).

12
content/influxdb/v2.0/tools/grafana.md
View File

@ -84,15 +84,15 @@ configure your InfluxDB connection:
2. Under **Auth**, enable **Basic Auth**.
3. Under **Basic Auth Details**, provide your InfluxDB authentication credentials:
- **username**: InfluxDB username
- **password**: InfluxDB [authentication token](/influxdb/v2.0/security/tokens/)
- **User**: InfluxDB username
- **Password**: InfluxDB [authentication token](/influxdb/v2.0/security/tokens/)
4. Under **InfluxDB details**, set the following:
4. Under **InfluxDB Details**, do the following:
- **Database**: The database to use when querying InfluxDB 2.0.
_See [Database and retention policy mapping](/influxdb/v2.0/reference/api/influxdb-1x/dbrp/)._
- **Database**: Enter the ID of the bucket to query in InfluxDB 2.0. To retrieve your bucket ID, see how to [view buckets](/influxdb/v2.0/organizations/buckets/view-buckets/).
- **User**: Enter the username to sign into InfluxDB.
- **Password**: Enter the token used to query the bucket above. To retrieve your token, see how to [view tokens](/influxdb/v2.0/security/tokens/view-tokens/).
- **HTTP Method**: Select **GET**.
- **Min time interval**: The [Grafana minimum time interval](https://grafana.com/docs/grafana/latest/features/datasources/influxdb/#min-time-interval).
{{< img-hd src="/img/influxdb/2-0-visualize-grafana-influxql.png" />}}

1
content/kapacitor/v1.5/introduction/getting-started.md
View File

@ -1,5 +1,6 @@
---
title: Get started with Kapacitor
description: Get started with Kapacitor to process your time series data.
weight: 20
menu:
kapacitor_1_5:

2
content/kapacitor/v1.5/introduction/installation.md
View File

@ -1,6 +1,6 @@
---
title: Install Kapacitor
Description: Download, install, and configure Kapacitor on your operating system of choice.
Description: Install, start, and configure Kapacitor on your operating system of choice.
weight: 10
menu:
kapacitor_1_5:

49
content/telegraf/v1.10/concepts/aggregator_processor_plugins.md
View File

@ -10,37 +10,24 @@ menu:
Besides the input plugins and output plugins, Telegraf includes aggregator and processor plugins, which are used to aggregate and process metrics as they pass through Telegraf.
```
┌───────────┐
│ │
│ CPU │───┐
│ │ │
└───────────┘ │
│
┌───────────┐ │ ┌───────────┐
│ │ │ │ │
│ Memory │───┤ ┌──▶│ InfluxDB │
│ │ │ │ │ │
└───────────┘ │ ┌─────────────┐ ┌─────────────┐ │ └───────────┘
│ │ │ │Aggregate │ │
┌───────────┐ │ │Process │ │ - mean │ │ ┌───────────┐
│ │ │ │ - transform │ │ - quantiles │ │ │ │
│ MySQL │───┼──▶ │ - decorate │────▶│ - min/max │───┼──▶│ File │
│ │ │ │ - filter │ │ - count │ │ │ │
└───────────┘ │ │ │ │ │ │ └───────────┘
│ └─────────────┘ └─────────────┘ │
┌───────────┐ │ │ ┌───────────┐
│ │ │ │ │ │
│ SNMP │───┤ └──▶│ Kafka │
│ │ │ │ │
└───────────┘ │ └───────────┘
│
┌───────────┐ │
│ │ │
│ Docker │───┘
│ │
└───────────┘
```
{{< diagram >}}
graph TD
Process[Process<br/> - transform<br/> - decorate<br/> - filter]
Aggregate[Aggregate<br/> - transform<br/> - decorate<br/> - filter]
CPU --> Process
Memory --> Process
MySQL --> Process
SNMP --> Process
Docker --> Process
Process --> Aggregate
Aggregate --> InfluxDB
Aggregate --> File
Aggregate --> Kafka
style Process text-align:left
style Aggregate text-align:left
{{< /diagram >}}
**Processor plugins** process metrics as they pass through and immediately emit
results based on the values they process. For example, this could be printing

49
content/telegraf/v1.11/concepts/aggregator_processor_plugins.md
View File

@ -10,37 +10,24 @@ menu:
Besides the input plugins and output plugins, Telegraf includes aggregator and processor plugins, which are used to aggregate and process metrics as they pass through Telegraf.
```
┌───────────┐
│ │
│ CPU │───┐
│ │ │
└───────────┘ │
│
┌───────────┐ │ ┌───────────┐
│ │ │ │ │
│ Memory │───┤ ┌──▶│ InfluxDB │
│ │ │ │ │ │
└───────────┘ │ ┌─────────────┐ ┌─────────────┐ │ └───────────┘
│ │ │ │Aggregate │ │
┌───────────┐ │ │Process │ │ - mean │ │ ┌───────────┐
│ │ │ │ - transform │ │ - quantiles │ │ │ │
│ MySQL │───┼──▶ │ - decorate │────▶│ - min/max │───┼──▶│ File │
│ │ │ │ - filter │ │ - count │ │ │ │
└───────────┘ │ │ │ │ │ │ └───────────┘
│ └─────────────┘ └─────────────┘ │
┌───────────┐ │ │ ┌───────────┐
│ │ │ │ │ │
│ SNMP │───┤ └──▶│ Kafka │
│ │ │ │ │
└───────────┘ │ └───────────┘
│
┌───────────┐ │
│ │ │
│ Docker │───┘
│ │
└───────────┘
```
{{< diagram >}}
graph TD
Process[Process<br/> - transform<br/> - decorate<br/> - filter]
Aggregate[Aggregate<br/> - transform<br/> - decorate<br/> - filter]
CPU --> Process
Memory --> Process
MySQL --> Process
SNMP --> Process
Docker --> Process
Process --> Aggregate
Aggregate --> InfluxDB
Aggregate --> File
Aggregate --> Kafka
style Process text-align:left
style Aggregate text-align:left
{{< /diagram >}}
**Processor plugins** process metrics as they pass through and immediately emit
results based on the values they process. For example, this could be printing

49
content/telegraf/v1.12/concepts/aggregator_processor_plugins.md
View File

@ -10,37 +10,24 @@ menu:
Besides the input plugins and output plugins, Telegraf includes aggregator and processor plugins, which are used to aggregate and process metrics as they pass through Telegraf.
```
┌───────────┐
│ │
│ CPU │───┐
│ │ │
└───────────┘ │
│
┌───────────┐ │ ┌───────────┐
│ │ │ │ │
│ Memory │───┤ ┌──▶│ InfluxDB │
│ │ │ │ │ │
└───────────┘ │ ┌─────────────┐ ┌─────────────┐ │ └───────────┘
│ │ │ │Aggregate │ │
┌───────────┐ │ │Process │ │ - mean │ │ ┌───────────┐
│ │ │ │ - transform │ │ - quantiles │ │ │ │
│ MySQL │───┼──▶ │ - decorate │────▶│ - min/max │───┼──▶│ File │
│ │ │ │ - filter │ │ - count │ │ │ │
└───────────┘ │ │ │ │ │ │ └───────────┘
│ └─────────────┘ └─────────────┘ │
┌───────────┐ │ │ ┌───────────┐
│ │ │ │ │ │
│ SNMP │───┤ └──▶│ Kafka │
│ │ │ │ │
└───────────┘ │ └───────────┘
│
┌───────────┐ │
│ │ │
│ Docker │───┘
│ │
└───────────┘
```
{{< diagram >}}
graph TD
Process[Process<br/> - transform<br/> - decorate<br/> - filter]
Aggregate[Aggregate<br/> - transform<br/> - decorate<br/> - filter]
CPU --> Process
Memory --> Process
MySQL --> Process
SNMP --> Process
Docker --> Process
Process --> Aggregate
Aggregate --> InfluxDB
Aggregate --> File
Aggregate --> Kafka
style Process text-align:left
style Aggregate text-align:left
{{< /diagram >}}
**Processor plugins** process metrics as they pass through and immediately emit
results based on the values they process. For example, this could be printing

49
content/telegraf/v1.13/concepts/aggregator_processor_plugins.md
View File

@ -10,37 +10,24 @@ menu:
Besides the input plugins and output plugins, Telegraf includes aggregator and processor plugins, which are used to aggregate and process metrics as they pass through Telegraf.
```
┌───────────┐
│ │
│ CPU │───┐
│ │ │
└───────────┘ │
│
┌───────────┐ │ ┌───────────┐
│ │ │ │ │
│ Memory │───┤ ┌──▶│ InfluxDB │
│ │ │ │ │ │
└───────────┘ │ ┌─────────────┐ ┌─────────────┐ │ └───────────┘
│ │ │ │Aggregate │ │
┌───────────┐ │ │Process │ │ - mean │ │ ┌───────────┐
│ │ │ │ - transform │ │ - quantiles │ │ │ │
│ MySQL │───┼──▶ │ - decorate │────▶│ - min/max │───┼──▶│ File │
│ │ │ │ - filter │ │ - count │ │ │ │
└───────────┘ │ │ │ │ │ │ └───────────┘
│ └─────────────┘ └─────────────┘ │
┌───────────┐ │ │ ┌───────────┐
│ │ │ │ │ │
│ SNMP │───┤ └──▶│ Kafka │
│ │ │ │ │
└───────────┘ │ └───────────┘
│
┌───────────┐ │
│ │ │
│ Docker │───┘
│ │
└───────────┘
```
{{< diagram >}}
graph TD
Process[Process<br/> - transform<br/> - decorate<br/> - filter]
Aggregate[Aggregate<br/> - transform<br/> - decorate<br/> - filter]
CPU --> Process
Memory --> Process
MySQL --> Process
SNMP --> Process
Docker --> Process
Process --> Aggregate
Aggregate --> InfluxDB
Aggregate --> File
Aggregate --> Kafka
style Process text-align:left
style Aggregate text-align:left
{{< /diagram >}}
**Processor plugins** process metrics as they pass through and immediately emit
results based on the values they process. For example, this could be printing

49
content/telegraf/v1.14/concepts/aggregator_processor_plugins.md
View File

@ -10,37 +10,24 @@ menu:
Besides the input plugins and output plugins, Telegraf includes aggregator and processor plugins, which are used to aggregate and process metrics as they pass through Telegraf.
```
┌───────────┐
│ │
│ CPU │───┐
│ │ │
└───────────┘ │
│
┌───────────┐ │ ┌───────────┐
│ │ │ │ │
│ Memory │───┤ ┌──▶│ InfluxDB │
│ │ │ │ │ │
└───────────┘ │ ┌─────────────┐ ┌─────────────┐ │ └───────────┘
│ │ │ │Aggregate │ │
┌───────────┐ │ │Process │ │ - mean │ │ ┌───────────┐
│ │ │ │ - transform │ │ - quantiles │ │ │ │
│ MySQL │───┼──▶ │ - decorate │────▶│ - min/max │───┼──▶│ File │
│ │ │ │ - filter │ │ - count │ │ │ │
└───────────┘ │ │ │ │ │ │ └───────────┘
│ └─────────────┘ └─────────────┘ │
┌───────────┐ │ │ ┌───────────┐
│ │ │ │ │ │
│ SNMP │───┤ └──▶│ Kafka │
│ │ │ │ │
└───────────┘ │ └───────────┘
│
┌───────────┐ │
│ │ │
│ Docker │───┘
│ │
└───────────┘
```
{{< diagram >}}
graph TD
Process[Process<br/> - transform<br/> - decorate<br/> - filter]
Aggregate[Aggregate<br/> - transform<br/> - decorate<br/> - filter]
CPU --> Process
Memory --> Process
MySQL --> Process
SNMP --> Process
Docker --> Process
Process --> Aggregate
Aggregate --> InfluxDB
Aggregate --> File
Aggregate --> Kafka
style Process text-align:left
style Aggregate text-align:left
{{< /diagram >}}
**Processor plugins** process metrics as they pass through and immediately emit
results based on the values they process. For example, this could be printing

49
content/telegraf/v1.15/concepts/aggregator_processor_plugins.md
View File

@ -10,37 +10,24 @@ menu:
Besides the input plugins and output plugins, Telegraf includes aggregator and processor plugins, which are used to aggregate and process metrics as they pass through Telegraf.
```
┌───────────┐
│ │
│ CPU │───┐
│ │ │
└───────────┘ │
│
┌───────────┐ │ ┌───────────┐
│ │ │ │ │
│ Memory │───┤ ┌──▶│ InfluxDB │
│ │ │ │ │ │
└───────────┘ │ ┌─────────────┐ ┌─────────────┐ │ └───────────┘
│ │ │ │Aggregate │ │
┌───────────┐ │ │Process │ │ - mean │ │ ┌───────────┐
│ │ │ │ - transform │ │ - quantiles │ │ │ │
│ MySQL │───┼──▶ │ - decorate │────▶│ - min/max │───┼──▶│ File │
│ │ │ │ - filter │ │ - count │ │ │ │
└───────────┘ │ │ │ │ │ │ └───────────┘
│ └─────────────┘ └─────────────┘ │
┌───────────┐ │ │ ┌───────────┐
│ │ │ │ │ │
│ SNMP │───┤ └──▶│ Kafka │
│ │ │ │ │
└───────────┘ │ └───────────┘
│
┌───────────┐ │
│ │ │
│ Docker │───┘
│ │
└───────────┘
```
{{< diagram >}}
graph TD
Process[Process<br/> - transform<br/> - decorate<br/> - filter]
Aggregate[Aggregate<br/> - transform<br/> - decorate<br/> - filter]
CPU --> Process
Memory --> Process
MySQL --> Process
SNMP --> Process
Docker --> Process
Process --> Aggregate
Aggregate --> InfluxDB
Aggregate --> File
Aggregate --> Kafka
style Process text-align:left
style Aggregate text-align:left
{{< /diagram >}}
**Processor plugins** process metrics as they pass through and immediately emit
results based on the values they process. For example, this could be printing

49
content/telegraf/v1.16/concepts/aggregator_processor_plugins.md
View File

@ -10,37 +10,24 @@ menu:
Besides the input plugins and output plugins, Telegraf includes aggregator and processor plugins, which are used to aggregate and process metrics as they pass through Telegraf.
```
┌───────────┐
│ │
│ CPU │───┐
│ │ │
└───────────┘ │
│
┌───────────┐ │ ┌───────────┐
│ │ │ │ │
│ Memory │───┤ ┌──▶│ InfluxDB │
│ │ │ │ │ │
└───────────┘ │ ┌─────────────┐ ┌─────────────┐ │ └───────────┘
│ │ │ │Aggregate │ │
┌───────────┐ │ │Process │ │ - mean │ │ ┌───────────┐
│ │ │ │ - transform │ │ - quantiles │ │ │ │
│ MySQL │───┼──▶ │ - decorate │────▶│ - min/max │───┼──▶│ File │
│ │ │ │ - filter │ │ - count │ │ │ │
└───────────┘ │ │ │ │ │ │ └───────────┘
│ └─────────────┘ └─────────────┘ │
┌───────────┐ │ │ ┌───────────┐
│ │ │ │ │ │
│ SNMP │───┤ └──▶│ Kafka │
│ │ │ │ │
└───────────┘ │ └───────────┘
│
┌───────────┐ │
│ │ │
│ Docker │───┘
│ │
└───────────┘
```
{{< diagram >}}
graph TD
Process[Process<br/> - transform<br/> - decorate<br/> - filter]
Aggregate[Aggregate<br/> - transform<br/> - decorate<br/> - filter]
CPU --> Process
Memory --> Process
MySQL --> Process
SNMP --> Process
Docker --> Process
Process --> Aggregate
Aggregate --> InfluxDB
Aggregate --> File
Aggregate --> Kafka
style Process text-align:left
style Aggregate text-align:left
{{< /diagram >}}
**Processor plugins** process metrics as they pass through and immediately emit
results based on the values they process. For example, this could be printing

25
content/telegraf/v1.17/_index.md Normal file
View File

@ -0,0 +1,25 @@
---
title: Telegraf 1.17 documentation
description: >
Documentation for Telegraf, the plugin-driven server agent of the InfluxData
time series platform, used to collect and report metrics. Telegraf supports four categories of plugins -- input, output, aggregator, and processor.
menu:
telegraf_1_17:
name: Telegraf v1.17
weight: 1
---
Telegraf is a plugin-driven server agent for collecting & reporting metrics,
and is the first piece of the [TICK stack](https://influxdata.com/time-series-platform/).
Telegraf has plugins to source a variety of metrics directly from the system it's running on, pull metrics from third party APIs, or even listen for metrics via a statsd and Kafka consumer services.
It also has output plugins to send metrics to a variety of other datastores, services, and message queues, including InfluxDB, Graphite, OpenTSDB, Datadog, Librato, Kafka, MQTT, NSQ, and many others.
## Key features
Here are some of the features that Telegraf currently supports that make it a great choice for metrics collection.
* Written entirely in Go.
It compiles into a single binary with no external dependencies.
* Minimal memory footprint.
* Plugin system allows new inputs and outputs to be easily added.
* A wide number of plugins for many popular services already exist for well known services and APIs.

27
content/telegraf/v1.17/about_the_project/_index.md Normal file
View File

@ -0,0 +1,27 @@
---
title: About the Telegraf project
description: Release notes, contribution guidelines, CLA, and license for the Telegraf project.
menu:
telegraf_1_17:
name: About the project
weight: 10
---
## Telegraf release notes
View the [Telegraf release notes](/telegraf/v1.17/about_the_project/release-notes-changelog/)
for important information about new versions of Telegraf.
## Contributions and licenses
- [Contribute to Telegraf](https://github.com/influxdata/telegraf/blob/master/CONTRIBUTING.md)
- [Contributor License Agreement (CLA)](https://influxdata.com/community/cla/)
- [License](https://github.com/influxdata/telegraf/blob/master/LICENSE)
## Third party software
InfluxData products contain third party software, which means the copyrighted, patented, or otherwise legally protected
software of third parties that is incorporated in InfluxData products.
Third party suppliers make no representation nor warranty with respect to such third party software or any portion thereof.
Third party suppliers assume no liability for any claim that might arise with respect to such third party software, nor for a
customer’s use of or inability to use the third party software.
The [list of third party software components, including references to associated licenses and other materials](https://github.com/influxdata/telegraf/blob/release-1.15/docs/LICENSE_OF_DEPENDENCIES.md), is maintained on a version by version basis.

10
content/telegraf/v1.17/about_the_project/cla.md Normal file
View File

@ -0,0 +1,10 @@
---
title: InfluxData Contributor License Agreement (CLA)
menu:
telegraf_1_17:
name: Contributor License Agreement (CLA)
parent: About the project
weight: 30
url: https://influxdata.com/community/cla/
---

10
content/telegraf/v1.17/about_the_project/contributing.md Normal file
View File

@ -0,0 +1,10 @@
---
title: Contributing to Telegraf
menu:
telegraf_1_17:
name: Contributing
parent: About the project
weight: 20
url: https://github.com/influxdata/telegraf/blob/master/CONTRIBUTING.md
---

10
content/telegraf/v1.17/about_the_project/license.md Normal file
View File

@ -0,0 +1,10 @@
---
title: License
menu:
telegraf_1_17:
name: License
parent: About the project
weight: 40
url: https://github.com/influxdata/telegraf/blob/master/LICENSE
---

2729
content/telegraf/v1.17/about_the_project/release-notes-changelog.md Normal file
View File

File diff suppressed because it is too large Load Diff

11
content/telegraf/v1.17/administration/_index.md Normal file
View File

@ -0,0 +1,11 @@
---
title: Administering Telegraf
menu:
telegraf_1_17:
name: Administration
weight: 60
---
{{< children >}}

423
content/telegraf/v1.17/administration/configuration.md Normal file
View File

@ -0,0 +1,423 @@
---
title: Configuring Telegraf
description: Overview of the Telegraf configuration file, enabling plugins, and setting environment variables.
menu:
telegraf_1_17:
name: Configuring
weight: 20
parent: Administration
---
The Telegraf configuration file (`telegraf.conf`) lists all available Telegraf plugins. See the current version here: [telegraf.conf](https://github.com/influxdata/telegraf/blob/master/etc/telegraf.conf).
## Generate a configuration file
A default Telegraf configuration file can be auto-generated by Telegraf:
```
telegraf config > telegraf.conf
```
To generate a configuration file with specific inputs and outputs, you can use the
`--input-filter` and `--output-filter` flags:
```
telegraf --input-filter cpu:mem:net:swap --output-filter influxdb:kafka config
```
## Configuration file locations
Use the `--config` flag to specify the configuration file location:
- Filename and path, for example: `--config /etc/default/telegraf`
- Remote URL endpoint, for example: `--config "http://remote-URL-endpoint"`
Use the `--config-directory` flag to include files ending with `.conf` in the specified directory in the Telegraf
configuration.
On most systems, the default locations are `/etc/telegraf/telegraf.conf` for
the main configuration file and `/etc/telegraf/telegraf.d` for the directory of
configuration files.
## Set environment variables
Add environment variables anywhere in the configuration file by prepending them with `$`.
For strings, variables must be in quotes (for example, `"$STR_VAR"`).
For numbers and Booleans, variables must be unquoted (for example, `$INT_VAR`, `$BOOL_VAR`).
You can also set environment variables using the Linux `export` command: `export password=mypassword`
> **Note:** We recommend using environment variables for sensitive information.
### Example: Telegraf environment variables
In the Telegraf environment variables file (`/etc/default/telegraf`):
```sh
USER="alice"
INFLUX_URL="http://localhost:8086"
INFLUX_SKIP_DATABASE_CREATION="true"
INFLUX_PASSWORD="monkey123"
```
In the Telegraf configuration file (`/etc/telegraf.conf`):
```sh
[global_tags]
user = "${USER}"
[[inputs.mem]]
[[outputs.influxdb]]
urls = ["${INFLUX_URL}"]
skip_database_creation = ${INFLUX_SKIP_DATABASE_CREATION}
password = "${INFLUX_PASSWORD}"
```
The environment variables above add the following configuration settings to Telegraf:
```sh
[global_tags]
user = "alice"
[[outputs.influxdb]]
urls = "http://localhost:8086"
skip_database_creation = true
password = "monkey123"
```
# Global tags
Global tags can be specified in the `[global_tags]` section of the config file
in `key="value"` format. All metrics being gathered on this host will be tagged
with the tags specified here.
## Agent configuration
Telegraf has a few options you can configure under the `[agent]` section of the
config.
* **interval**: Default data collection interval for all inputs
* **round_interval**: Rounds collection interval to `interval`.
For example, if `interval` is set to 10s then always collect on :00, :10, :20, etc.
* **metric_batch_size**: Telegraf will send metrics to output in batch of at
most `metric_batch_size` metrics.
* **metric_buffer_limit**: Telegraf will cache `metric_buffer_limit` metrics
for each output, and will flush this buffer on a successful write.
This should be a multiple of `metric_batch_size` and could not be less
than 2 times `metric_batch_size`.
* **collection_jitter**: Collection jitter is used to jitter
the collection by a random amount.
Each plugin will sleep for a random time within jitter before collecting.
This can be used to avoid many plugins querying things like sysfs at the
same time, which can have a measurable effect on the system.
* **flush_interval**: Default data flushing interval for all outputs.
You should not set this below `interval`.
Maximum `flush_interval` will be `flush_interval` + `flush_jitter`
* **flush_jitter**: Jitter the flush interval by a random amount.
This is primarily to avoid
large write spikes for users running a large number of Telegraf instances.
For example, a `flush_jitter` of 5s and `flush_interval` of 10s means flushes will happen every 10-15s.
* **precision**: By default, precision will be set to the same timestamp order
as the collection interval, with the maximum being 1s. Precision will NOT
be used for service inputs, such as `logparser` and `statsd`. Valid values are
`ns`, `us` (or `µs`), `ms`, and `s`.
* **logfile**: Specify the log file name. The empty string means to log to `stderr`.
* **debug**: Run Telegraf in debug mode.
* **quiet**: Run Telegraf in quiet mode (error messages only).
* **hostname**: Override default hostname, if empty use `os.Hostname()`.
* **omit_hostname**: If true, do no set the `host` tag in the Telegraf agent.
## Input configuration
The following config parameters are available for all inputs:
* **interval**: How often to gather this metric. Normal plugins use a single
global interval, but if one particular input should be run less or more often,
you can configure that here.
* **name_override**: Override the base name of the measurement.
(Default is the name of the input).
* **name_prefix**: Specifies a prefix to attach to the measurement name.
* **name_suffix**: Specifies a suffix to attach to the measurement name.
* **tags**: A map of tags to apply to a specific input's measurements.
## Output configuration
There are no generic configuration options available for all outputs.
## Aggregator configuration
The following config parameters are available for all aggregators:
* **period**: The period on which to flush & clear each aggregator. All metrics
that are sent with timestamps outside of this period will be ignored by the
aggregator.
* **delay**: The delay before each aggregator is flushed. This is to control
how long for aggregators to wait before receiving metrics from input plugins,
in the case that aggregators are flushing and inputs are gathering on the
same interval.
* **drop_original**: If true, the original metric will be dropped by the
aggregator and will not get sent to the output plugins.
* **name_override**: Override the base name of the measurement.
(Default is the name of the input).
* **name_prefix**: Specifies a prefix to attach to the measurement name.
* **name_suffix**: Specifies a suffix to attach to the measurement name.
* **tags**: A map of tags to apply to a specific input's measurements.
## Processor configuration
The following config parameters are available for all processors:
* **order**: This is the order in which processors are executed. If this
is not specified, then processor execution order will be random.
#### Measurement filtering
Filters can be configured per input, output, processor, or aggregator,
see below for examples.
* **namepass**:
An array of glob pattern strings. Only points whose measurement name matches
a pattern in this list are emitted.
* **namedrop**:
The inverse of `namepass`. If a match is found the point is discarded. This
is tested on points after they have passed the `namepass` test.
* **fieldpass**:
An array of glob pattern strings. Only fields whose field key matches a
pattern in this list are emitted.
* **fielddrop**:
The inverse of `fieldpass`. Fields with a field key matching one of the
patterns will be discarded from the point.
* **tagpass**:
A table mapping tag keys to arrays of glob pattern strings. Only points
that contain a tag key in the table and a tag value matching one of its
patterns is emitted.
* **tagdrop**:
The inverse of `tagpass`. If a match is found the point is discarded. This
is tested on points after they have passed the `tagpass` test.
* **taginclude**:
An array of glob pattern strings. Only tags with a tag key matching one of
the patterns are emitted. In contrast to `tagpass`, which will pass an entire
point based on its tag, `taginclude` removes all non matching tags from the
point. This filter can be used on both inputs & outputs, but it is
_recommended_ to be used on inputs, as it is more efficient to filter out tags
at the ingestion point.
* **tagexclude**:
The inverse of `taginclude`. Tags with a tag key matching one of the patterns
will be discarded from the point.
**NOTE** Due to the way TOML is parsed, `tagpass` and `tagdrop` parameters
must be defined at the _end_ of the plugin definition, otherwise subsequent
plugin config options will be interpreted as part of the tagpass/tagdrop
tables.
#### Input configuration examples
This is a full working config that will output CPU data to an InfluxDB instance
at `192.168.59.103:8086`, tagging measurements with `dc="denver-1"`. It will output
measurements at a 10s interval and will collect per-cpu data, dropping any
fields which begin with `time_`.
```toml
[global_tags]
dc = "denver-1"
[agent]
interval = "10s"
# OUTPUTS
[[outputs.influxdb]]
url = "http://192.168.59.103:8086" # required.
database = "telegraf" # required.
precision = "s"
# INPUTS
[[inputs.cpu]]
percpu = true
totalcpu = false
# filter all fields beginning with 'time_'
fielddrop = ["time_*"]
```
#### Input Config: `tagpass` and `tagdrop`
**NOTE** `tagpass` and `tagdrop` parameters must be defined at the _end_ of
the plugin definition, otherwise subsequent plugin config options will be
interpreted as part of the tagpass/tagdrop map.
```toml
[[inputs.cpu]]
percpu = true
totalcpu = false
fielddrop = ["cpu_time"]
# Don't collect CPU data for cpu6 & cpu7
[inputs.cpu.tagdrop]
cpu = [ "cpu6", "cpu7" ]
[[inputs.disk]]
[inputs.disk.tagpass]
# tagpass conditions are OR, not AND.
# If the (filesystem is ext4 or xfs) OR (the path is /opt or /home)
# then the metric passes
fstype = [ "ext4", "xfs" ]
# Globs can also be used on the tag values
path = [ "/opt", "/home*" ]
```
#### Input Config: `fieldpass` and `fielddrop`
```toml
# Drop all metrics for guest & steal CPU usage
[[inputs.cpu]]
percpu = false
totalcpu = true
fielddrop = ["usage_guest", "usage_steal"]
# Only store inode related metrics for disks
[[inputs.disk]]
fieldpass = ["inodes*"]
```
#### Input Config: `namepass` and `namedrop`
```toml
# Drop all metrics about containers for kubelet
[[inputs.prometheus]]
urls = ["http://kube-node-1:4194/metrics"]
namedrop = ["container_*"]
# Only store rest client related metrics for kubelet
[[inputs.prometheus]]
urls = ["http://kube-node-1:4194/metrics"]
namepass = ["rest_client_*"]
```
#### Input Config: `taginclude` and `tagexclude`
```toml
# Only include the "cpu" tag in the measurements for the cpu plugin.
[[inputs.cpu]]
percpu = true
totalcpu = true
taginclude = ["cpu"]
# Exclude the `fstype` tag from the measurements for the disk plugin.
[[inputs.disk]]
tagexclude = ["fstype"]
```
#### Input config: `prefix`, `suffix`, and `override`
This plugin will emit measurements with the name `cpu_total`.
```toml
[[inputs.cpu]]
name_suffix = "_total"
percpu = false
totalcpu = true
```
This will emit measurements with the name `foobar`.
```toml
[[inputs.cpu]]
name_override = "foobar"
percpu = false
totalcpu = true
```
#### Input config: tags
This plugin will emit measurements with two additional tags: `tag1=foo` and
`tag2=bar`.
NOTE: Order matters, the `[inputs.cpu.tags]` table must be at the _end_ of the
plugin definition.
```toml
[[inputs.cpu]]
percpu = false
totalcpu = true
[inputs.cpu.tags]
tag1 = "foo"
tag2 = "bar"
```
#### Multiple inputs of the same type
Additional inputs (or outputs) of the same type can be specified by defining these instances in the configuration file. To avoid measurement collisions, use the `name_override`, `name_prefix`, or `name_suffix` config options:
```toml
[[inputs.cpu]]
percpu = false
totalcpu = true
[[inputs.cpu]]
percpu = true
totalcpu = false
name_override = "percpu_usage"
fielddrop = ["cpu_time*"]
```
#### Output configuration examples:
```toml
[[outputs.influxdb]]
urls = [ "http://localhost:8086" ]
database = "telegraf"
precision = "s"
# Drop all measurements that start with "aerospike"
namedrop = ["aerospike*"]
[[outputs.influxdb]]
urls = [ "http://localhost:8086" ]
database = "telegraf-aerospike-data"
precision = "s"
# Only accept aerospike data:
namepass = ["aerospike*"]
[[outputs.influxdb]]
urls = [ "http://localhost:8086" ]
database = "telegraf-cpu0-data"
precision = "s"
# Only store measurements where the tag "cpu" matches the value "cpu0"
[outputs.influxdb.tagpass]
cpu = ["cpu0"]
```
#### Aggregator Configuration Examples:
This will collect and emit the min/max of the system load1 metric every
30s, dropping the originals.
```toml
[[inputs.system]]
fieldpass = ["load1"] # collects system load1 metric.
[[aggregators.minmax]]
period = "30s" # send & clear the aggregate every 30s.
drop_original = true # drop the original metrics.
[[outputs.file]]
files = ["stdout"]
```
This will collect and emit the min/max of the swap metrics every
30s, dropping the originals. The aggregator will not be applied
to the system load metrics due to the `namepass` parameter.
```toml
[[inputs.swap]]
[[inputs.system]]
fieldpass = ["load1"] # collects system load1 metric.
[[aggregators.minmax]]
period = "30s" # send & clear the aggregate every 30s.
drop_original = true # drop the original metrics.
namepass = ["swap"] # only "pass" swap metrics through the aggregator.
[[outputs.file]]
files = ["stdout"]
```

18
content/telegraf/v1.17/administration/enterprise-plugins.md Normal file
View File

@ -0,0 +1,18 @@
---
title: Recommended Telegraf plugins for Enterprise users
menu:
telegraf_1_17:
name: Recommended plugins for Enterprise users
weight: 20
parent: Administration
draft: true
---
The Telegraf configuration file (`telegraf.conf`) lists all of the available plugins. The current version is available here:
[telegraf.conf](https://github.com/influxdata/telegraf/blob/master/etc/telegraf.conf)
## Core Telegraf plugins for Enterprise users
## Optional Telegraf plugins for Enterprise users

89
content/telegraf/v1.17/administration/troubleshooting.md Normal file
View File

@ -0,0 +1,89 @@
---
title: Troubleshoot Telegraf
description: Capture Telegraf output, submit sample metrics, and see how Telegraf formats and emits points to its output plugins.
menu:
telegraf_1_17:
name: Troubleshoot
weight: 30
parent: Administration
---
This guide will show you how to capture Telegraf output, submit sample metrics, and see how Telegraf formats and emits points to its output plugins.
## Capture output
A quick way to view Telegraf output is by enabling a new UDP output plugin to run in parallel with the existing output plugins. Since each output plugin creates its own stream, the already existing outputs will not be affected. Traffic will be replicated to all active outputs.
> **NOTE:** This approach requires Telegraf to be restarted, which will cause a brief interruption to your metrics collection.
The minimal Telegraf configuration required to enable a UDP output is:
```
[[outputs.influxdb]]
urls = ["udp://localhost:8089"]
```
This setup utilizes the UDP format of the [InfluxDB output plugin](https://github.com/influxdata/telegraf/tree/master/plugins/outputs/influxdb) and emits points formatted in InfluxDB's [line protocol](/{{< latest "influxdb" "v1" >}}/concepts/glossary/#line-protocol).
You will need to append this section to the Telegraf configuration file and restart Telegraf for the change to take effect.
Now you are ready to start listening on the destination port (`8089` in this example) using a simple tool like `netcat`:
```
nc -lup 8089
```
`nc` will print the exact Telegraf output on stdout.
You can also direct the output to a file for further inspection:
```
nc -lup 8089 > telegraf_dump.txt
```
## Submit test inputs
Once you have Telegraf's output arriving to your `nc` socket, you can enable the [inputs.socket_listener](https://github.com/influxdata/telegraf/tree/master/plugins/inputs/socket_listener) plugins to submit some sample metrics.
Append the TCP or UDP input section to Telegraf's config file and restart Telegraf for the change to take effect.
```
[[inputs.socket_listener]]
service_address = "tcp://:8094"
data_format = "influx"
```
Submit sample data to the Telegraf socket listener:
```
echo 'mymeasurement,my_tag_key=mytagvalue my_field="my field value"' | nc localhost 8094
```
The output from your `netcat` listener will look like the following:
```
mymeasurement,host=kubuntu,my_tag_key=mytagvalue my_field="my field value" 1478106104713745634
```
## Testing other plugins
The same approach can be used to test other plugins, like the [inputs.statsd](https://github.com/influxdata/telegraf/tree/master/plugins/inputs/statsd) plugin.
Here is a basic configuration example of how to set up the Telegraf statsd input plugin:
```
[[inputs.statsd]]
service_address = ":8125"
metric_separator = "_"
allowed_pending_messages = 10000
```
Sending a sample metric to the Telegraf statsd port:
```
echo "a.b.c:1|g" | nc -u localhost 8125
```
The output from `nc` will look like the following:
```
a_b_c,host=myserver,metric_type=gauge value=1 1478106500000000000
```

66
content/telegraf/v1.17/administration/windows_service.md Normal file
View File

@ -0,0 +1,66 @@
---
title: Running Telegraf as a Windows service
description: How to configure Telegraf as a Windows service using PowerShell.
menu:
telegraf_1_17:
name: Running as Windows service
weight: 20
parent: Administration
---
Telegraf natively supports running as a Windows service.
The following commands are available:
| Command | Effect |
|------------------------------------|-------------------------------|
| `telegraf.exe --service install` | Install telegraf as a service |
| `telegraf.exe --service uninstall` | Remove the telegraf service |
| `telegraf.exe --service start` | Start the telegraf service |
| `telegraf.exe --service stop` | Stop the telegraf service |
Outlined below are the general steps to install Telegraf as a Service.
{{% note %}}
Installing a Windows service requires administrative permissions.
Be sure to [launch Powershell as administrator](
https://docs.microsoft.com/en-us/powershell/scripting/windows-powershell/starting-windows-powershell?view=powershell-7#with-administrative-privileges-run-as-administrator).
{{% /note %}}
1. Download the Telegraf binary and unzip its contents to `C:\Program Files\InfluxData\Telegraf`.
2. In PowerShell, run the following as an administrator:
```powershell
> cd "C:\Program Files\InfluxData\Telegraf"
> .\telegraf.exe --service install --config "C:\Program Files\InfluxData\Telegraf\telegraf.conf"
```
When installing Telegraf as a Windows service, provide the absolute path of the Telegraf configuration file.
Otherwise the Windows service may fail to start.
3. To test that the installation works, run:
```powershell
> C:\"Program Files"\InfluxData\Telegraf\telegraf.exe --config C:\"Program Files"\InfluxData\Telegraf\telegraf.conf --test
```
4. To start collecting data, run:
```powershell
telegraf.exe --service start
```
<!--
#### Config Directory
You can also specify a `--config-directory` for the service to use:
1. Create a directory for configuration snippets: `C:\Program Files\Telegraf\telegraf.d`
2. Include the `--config-directory` option when registering the service:
```
> C:\"Program Files"\Telegraf\telegraf.exe --service install --config C:\"Program Files"\Telegraf\telegraf.conf --config-directory C:\"Program Files"\Telegraf\telegraf.d
```
-->
{{% note %}}
## Logging and troubleshooting
When Telegraf runs as a Windows service, Telegraf logs messages to Windows event logs.
If the Telegraf service fails to start, view error logs by selecting **Event Viewer**→**Windows Logs**→**Application**.
{{% /note %}}

11
content/telegraf/v1.17/concepts/_index.md Normal file
View File

@ -0,0 +1,11 @@
---
title: Key Telegraf concepts
description: Includes information on supported input data formats, output data formats, aggregator and processor plugins, and includes a glossary of important terms.
menu:
telegraf_1_17:
name: Concepts
weight: 30
---
This section discusses key concepts about Telegraf, the plug-in driven server agent component of the InfluxData time series platform. Topics covered include metrics, aggregator and processor plugins, and a glossary of important terms.
{{< children >}}

49
content/telegraf/v1.17/concepts/aggregator_processor_plugins.md Normal file
View File

@ -0,0 +1,49 @@
---
title: Telegraf aggregator and processor plugins
description: Aggregator and processor plugins work between the input plugins and output plugins to aggregate and process metrics in Telegraf.
menu:
telegraf_1_17:
name: Aggregator and processor plugins
weight: 20
parent: Concepts
---
Besides the input plugins and output plugins, Telegraf includes aggregator and processor plugins, which are used to aggregate and process metrics as they pass through Telegraf.
{{< diagram >}}
graph TD
Process[Process<br/> - transform<br/> - decorate<br/> - filter]
Aggregate[Aggregate<br/> - transform<br/> - decorate<br/> - filter]
CPU --> Process
Memory --> Process
MySQL --> Process
SNMP --> Process
Docker --> Process
Process --> Aggregate
Aggregate --> InfluxDB
Aggregate --> File
Aggregate --> Kafka
style Process text-align:left
style Aggregate text-align:left
{{< /diagram >}}
**Processor plugins** process metrics as they pass through and immediately emit
results based on the values they process. For example, this could be printing
all metrics or adding a tag to all metrics that pass through.
**Aggregator plugins**, on the other hand, are a bit more complicated. Aggregators
are typically for emitting new _aggregate_ metrics, such as a running mean,
minimum, maximum, quantiles, or standard deviation. For this reason, all _aggregator_
plugins are configured with a `period`. The `period` is the size of the window
of metrics that each _aggregate_ represents. In other words, the emitted
_aggregate_ metric will be the aggregated value of the past `period` seconds.
Since many users will only care about their aggregates and not every single metric
gathered, there is also a `drop_original` argument, which tells Telegraf to only
emit the aggregates and not the original metrics.
**NOTE** Since aggregator plugins only aggregate metrics within their periods,
historical data is not supported. In other words, if your metric timestamp is more
than `now() - period` in the past, it will not be aggregated. If this is a feature
that you need, please comment on this [GitHub issue](https://github.com/influxdata/telegraf/issues/1992).

103
content/telegraf/v1.17/concepts/glossary.md Normal file
View File

@ -0,0 +1,103 @@
---
title: Telegraf glossary of terms
description: This section includes definitions of important terms for related to Telegraf.
menu:
telegraf_1_17:
name: Glossary of terms
weight: 30
parent: Concepts
---
## agent
An agent is the core part of Telegraf that gathers metrics from the declared input plugins and sends metrics to the declared output plugins, based on the plugins enabled by the given configuration.
Related entries: [input plugin](/telegraf/v1.15/concepts/glossary/#input-plugin), [output plugin](/telegraf/v1.15/concepts/glossary/#output-plugin)
## aggregator plugin
Aggregator plugins receive raw metrics from input plugins and create aggregate metrics from them.
The aggregate metrics are then passed to the configured output plugins.
Related entries: [input plugin](/telegraf/v1.15/concepts/glossary/#input-plugin), [output plugin](/telegraf/v1.15/concepts/glossary/#output-plugin), [processor plugin](/telegraf/v1.15/concepts/glossary/#processor-plugin)
## batch size
The Telegraf agent sends metrics to output plugins in batches, not individually.
The batch size controls the size of each write batch that Telegraf sends to the output plugins.
Related entries: [output plugin](/telegraf/v1.15/concepts/glossary/#output-plugin)
## collection interval
The default global interval for collecting data from each input plugin.
The collection interval can be overridden by each individual input plugin's configuration.
Related entries: [input plugin](/telegraf/v1.15/concepts/glossary/#input-plugin)
## collection jitter
Collection jitter is used to prevent every input plugin from collecting metrics simultaneously, which can have a measurable effect on the system.
Each collection interval, every input plugin will sleep for a random time between zero and the collection jitter before collecting the metrics.
Related entries: [collection interval](/telegraf/v1.15/concepts/glossary/#collection-interval), [input plugin](/telegraf/v1.15/concepts/glossary/#input-plugin)
## flush interval
The global interval for flushing data from each output plugin to its destination.
This value should not be set lower than the collection interval.
Related entries: [collection interval](/telegraf/v1.15/concepts/glossary/#collection-interval), [flush jitter](/telegraf/v1.15/concepts/glossary/#flush-jitter), [output plugin](/telegraf/v1.15/concepts/glossary/#output-plugin)
## flush jitter
Flush jitter is used to prevent every output plugin from sending writes simultaneously, which can overwhelm some data sinks.
Each flush interval, every output plugin will sleep for a random time between zero and the flush jitter before emitting metrics.
This helps smooth out write spikes when running a large number of Telegraf instances.
Related entries: [flush interval](/telegraf/v1.15/concepts/glossary/#flush-interval), [output plugin](/telegraf/v1.15/concepts/glossary/#output-plugin)
## input plugin
Input plugins actively gather metrics and deliver them to the core agent, where aggregator, processor, and output plugins can operate on the metrics.
In order to activate an input plugin, it needs to be enabled and configured in Telegraf's configuration file.
Related entries: [aggregator plugin](/telegraf/v1.15/concepts/glossary/#aggregator-plugin), [collection interval](/telegraf/v1.15/concepts/glossary/#collection-interval), [output plugin](/telegraf/v1.15/concepts/glossary/#output-plugin), [processor plugin](/telegraf/v1.15/concepts/glossary/#processor-plugin)
## metric buffer
The metric buffer caches individual metrics when writes are failing for an output plugin.
Telegraf will attempt to flush the buffer upon a successful write to the output.
The oldest metrics are dropped first when this buffer fills.
Related entries: [output plugin](/telegraf/v1.15/concepts/glossary/#output-plugin)
## output plugin
Output plugins deliver metrics to their configured destination. In order to activate an output plugin, it needs to be enabled and configured in Telegraf's configuration file.
Related entries: [aggregator plugin](/telegraf/v1.15/concepts/glossary/#aggregator-plugin), [flush interval](/telegraf/v1.15/concepts/glossary/#flush-interval), [input plugin](/telegraf/v1.15/concepts/glossary/#input-plugin), [processor plugin](/telegraf/v1.15/concepts/glossary/#processor-plugin)
## precision
The precision configuration setting determines how much timestamp precision is retained in the points received from input plugins. All incoming timestamps are truncated to the given precision.
Telegraf then pads the truncated timestamps with zeros to create a nanosecond timestamp; output plugins will emit timestamps in nanoseconds.
Valid precisions are `ns`, `us` or `µs`, `ms`, and `s`.
For example, if the precision is set to `ms`, the nanosecond epoch timestamp `1480000000123456789` would be truncated to `1480000000123` in millisecond precision and then padded with zeroes to make a new, less precise nanosecond timestamp of `1480000000123000000`.
Output plugins do not alter the timestamp further. The precision setting is ignored for service input plugins.
Related entries: [aggregator plugin](/telegraf/v1.15/concepts/glossary/#aggregator-plugin), [input plugin](/telegraf/v1.15/concepts/glossary/#input-plugin), [output plugin](/telegraf/v1.15/concepts/glossary/#output-plugin), [processor plugin](/telegraf/v1.15/concepts/glossary/#processor-plugin), [service input plugin](/telegraf/v1.15/concepts/glossary/#service-input-plugin)
## processor plugin
Processor plugins transform, decorate, and/or filter metrics collected by input plugins, passing the transformed metrics to the output plugins.
Related entries: [aggregator plugin](/telegraf/v1.15/concepts/glossary/#aggregator-plugin), [input plugin](/telegraf/v1.15/concepts/glossary/#input-plugin), [output plugin](/telegraf/v1.15/concepts/glossary/#output-plugin)
## service input plugin
Service input plugins are input plugins that run in a passive collection mode while the Telegraf agent is running.
They listen on a socket for known protocol inputs, or apply their own logic to ingested metrics before delivering them to the Telegraf agent.
Related entries: [aggregator plugin](/telegraf/v1.15/concepts/glossary/#aggregator-plugin), [input plugin](/telegraf/v1.15/concepts/glossary/#input-plugin), [output plugin](/telegraf/v1.15/concepts/glossary/#output-plugin), [processor plugin](/telegraf/v1.15/concepts/glossary/#processor-plugin)

28
content/telegraf/v1.17/concepts/metrics.md Normal file
View File

@ -0,0 +1,28 @@
---
title: Telegraf metrics
description: Telegraf metrics are internal representations used to model data during processing and are based on InfluxDB's data model. Each metric component includes the measurement name, tags, fields, and timestamp.
menu:
telegraf_1_17:
name: Metrics
weight: 10
parent: Concepts
---
Telegraf metrics are the internal representation used to model data during
processing. These metrics are closely based on InfluxDB's data model and contain
four main components:
- **Measurement name**: Description and namespace for the metric.
- **Tags**: Key/Value string pairs and usually used to identify the
metric.
- **Fields**: Key/Value pairs that are typed and usually contain the
metric data.
- **Timestamp**: Date and time associated with the fields.
This metric type exists only in memory and must be converted to a concrete
representation in order to be transmitted or viewed. Telegraf provides [output data formats][output data formats] (also known as *serializers*) for these conversions. Telegraf's default serializer converts to [InfluxDB Line
Protocol][line protocol], which provides a high performance and one-to-one
direct mapping from Telegraf metrics.
[output data formats]: /telegraf/v1.15/data_formats/output/
[line protocol]: /telegraf/v1.15/data_formats/output/influx/

12
content/telegraf/v1.17/data_formats/_index.md Normal file
View File

@ -0,0 +1,12 @@
---
title: Telegraf data formats
description: Telegraf supports input data formats and output data formats for converting input and output data.
menu:
telegraf_1_17:
name: Data formats
weight: 50
---
This section covers the input data formats and output data formats used in the Telegraf plugin-driven server agent component of the InfluxData time series platform.
{{< children hlevel="h2" >}}

46
content/telegraf/v1.17/data_formats/input/_index.md Normal file
View File

@ -0,0 +1,46 @@
---
title: Telegraf input data formats
description: Telegraf supports parsing input data formats into Telegraf metrics for InfluxDB Line Protocol, CollectD, CSV, Dropwizard, Graphite, Grok, JSON, Logfmt, Nagios, Value, and Wavefront.
menu:
telegraf_1_17:
name: Input data formats
weight: 1
parent: Data formats
---
Telegraf contains many general purpose plugins that support parsing input data
using a configurable parser into [metrics][]. This allows, for example, the
`kafka_consumer` input plugin to process messages in either InfluxDB Line
Protocol or in JSON format. Telegraf supports the following input data formats:
- [InfluxDB Line Protocol](/telegraf/v1.15/data_formats/input/influx/)
- [collectd](/telegraf/v1.15/data_formats/input/collectd/)
- [CSV](/telegraf/v1.15/data_formats/input/csv/)
- [Dropwizard](/telegraf/v1.15/data_formats/input/dropwizard/)
- [Graphite](/telegraf/v1.15/data_formats/input/graphite/)
- [Grok](/telegraf/v1.15/data_formats/input/grok/)
- [JSON](/telegraf/v1.15/data_formats/input/json/)
- [logfmt](/telegraf/v1.15/data_formats/input/logfmt/)
- [Nagios](/telegraf/v1.15/data_formats/input/nagios/)
- [Value](/telegraf/v1.15/data_formats/input/value/), ie: 45 or "booyah"
- [Wavefront](/telegraf/v1.15/data_formats/input/wavefront/)
Any input plugin containing the `data_format` option can use it to select the
desired parser:
```toml
[[inputs.exec]]
## Commands array
commands = ["/tmp/test.sh", "/usr/bin/mycollector --foo=bar"]
## measurement name suffix (for separating different commands)
name_suffix = "_mycollector"
## Data format to consume.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md
data_format = "json"
```
[metrics]: /telegraf/v1.15/concepts/metrics/

48
content/telegraf/v1.17/data_formats/input/collectd.md Normal file
View File

@ -0,0 +1,48 @@
---
title: Collectd input data format
description: Use the `collectd` input data format to parse the collectd network binary protocol to create tags for host, instance, type, and type instance.
menu:
telegraf_1_17:
name: collectd
weight: 10
parent: Input data formats
---
The collectd input data format parses the collectd network binary protocol to create tags for host, instance, type, and type instance. All collectd values are added as float64 fields.
For more information, see [binary protocol](https://collectd.org/wiki/index.php/Binary_protocol) in the collectd Wiki.
You can control the cryptographic settings with parser options.
Create an authentication file and set `collectd_auth_file` to the path of the file, then set the desired security level in `collectd_security_level`.
For more information, including client setup, see
[Cryptographic setup](https://collectd.org/wiki/index.php/Networking_introduction#Cryptographic_setup) in the collectd Wiki.
You can also change the path to the typesdb or add additional typesdb using
`collectd_typesdb`.
## Configuration
```toml
[[inputs.file]]
files = ["example"]
## Data format to consume.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md
data_format = "collectd"
## Authentication file for cryptographic security levels
collectd_auth_file = "/etc/collectd/auth_file"
## One of none (default), sign, or encrypt
collectd_security_level = "encrypt"
## Path of to TypesDB specifications
collectd_typesdb = ["/usr/share/collectd/types.db"]
## Multi-value plugins can be handled two ways.
## "split" will parse and store the multi-value plugin data into separate measurements
## "join" will parse and store the multi-value plugin as a single multi-value measurement.
## "split" is the default behavior for backward compatability with previous versions of influxdb.
collectd_parse_multivalue = "split"
```

111
content/telegraf/v1.17/data_formats/input/csv.md Normal file
View File

@ -0,0 +1,111 @@
---
title: CSV input data format
description: Use the `csv` input data format to parse a document containing comma-separated values into Telegraf metrics.
menu:
telegraf_1_17:
name: CSV
weight: 20
parent: Input data formats
---
The CSV input data format parses documents containing comma-separated values into Telegraf metrics.
## Configuration
```toml
[[inputs.file]]
files = ["example"]
## Data format to consume.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md
data_format = "csv"
## Indicates how many rows to treat as a header. By default, the parser assumes
## there is no header and will parse the first row as data. If set to anything more
## than 1, column names will be concatenated with the name listed in the next header row.
## If `csv_column_names` is specified, the column names in header will be overridden.
csv_header_row_count = 0
## For assigning custom names to columns
## If this is specified, all columns should have a name
## Unnamed columns will be ignored by the parser.
## If `csv_header_row_count` is set to 0, this config must be used
csv_column_names = []
## Indicates the number of rows to skip before looking for header information.
csv_skip_rows = 0
## Indicates the number of columns to skip before looking for data to parse.
## These columns will be skipped in the header as well.
csv_skip_columns = 0
## The seperator between csv fields
## By default, the parser assumes a comma (",")
csv_delimiter = ","
## The character reserved for marking a row as a comment row
## Commented rows are skipped and not parsed
csv_comment = ""
## If set to true, the parser will remove leading whitespace from fields
## By default, this is false
csv_trim_space = false
## Columns listed here will be added as tags. Any other columns
## will be added as fields.
csv_tag_columns = []
## The column to extract the name of the metric from
csv_measurement_column = ""
## The column to extract time information for the metric
## `csv_timestamp_format` must be specified if this is used
csv_timestamp_column = ""
## The format of time data extracted from `csv_timestamp_column`
## this must be specified if `csv_timestamp_column` is specified
csv_timestamp_format = ""
```
### csv_timestamp_column, csv_timestamp_format
By default the current time will be used for all created metrics, to set the
time using the JSON document you can use the `csv_timestamp_column` and
`csv_timestamp_format` options together to set the time to a value in the parsed
document.
The `csv_timestamp_column` option specifies the column name containing the
time value and `csv_timestamp_format` must be set to a Go "reference time"
which is defined to be the specific time: `Mon Jan 2 15:04:05 MST 2006`.
Consult the Go [time][time parse] package for details and additional examples
on how to set the time format.
## Metrics
One metric is created for each row with the columns added as fields. The type
of the field is automatically determined based on the contents of the value.
## Examples
Config:
```
[[inputs.file]]
files = ["example"]
data_format = "csv"
csv_header_row_count = 1
csv_timestamp_column = "time"
csv_timestamp_format = "2006-01-02T15:04:05Z07:00"
```
Input:
```
measurement,cpu,time_user,time_system,time_idle,time
cpu,cpu0,42,42,42,2018-09-13T13:03:28Z
```
Output:
```
cpu cpu=cpu0,time_user=42,time_system=42,time_idle=42 1536869008000000000
```

179
content/telegraf/v1.17/data_formats/input/dropwizard.md Normal file
View File

@ -0,0 +1,179 @@
---
title: Dropwizard input data format
description: Use the `dropwizard` input data format to parse Dropwizard JSON representations into Telegraf metrics.
menu:
telegraf_1_17:
name: Dropwizard
weight: 30
parent: Input data formats
---
The `dropwizard` data format can parse a [Dropwizard JSON representation][dropwizard] representation of a single metrics registry. By default, tags are parsed from metric names as if they were actual InfluxDB Line Protocol keys (`measurement<,tag_set>`) which can be overridden using custom [template patterns][templates]. All field value types are supported, including `string`, `number` and `boolean`.
[templates]: /telegraf/v1.15/data_formats/template-patterns/
[dropwizard]: http://metrics.dropwizard.io/3.1.0/manual/json/
## Configuration
```toml
[[inputs.file]]
files = ["example"]
## Data format to consume.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md
data_format = "dropwizard"
## Used by the templating engine to join matched values when cardinality is > 1
separator = "_"
## Each template line requires a template pattern. It can have an optional
## filter before the template and separated by spaces. It can also have optional extra
## tags following the template. Multiple tags should be separated by commas and no spaces
## similar to the line protocol format. There can be only one default template.
## Templates support below format:
## 1. filter + template
## 2. filter + template + extra tag(s)
## 3. filter + template with field key
## 4. default template
## By providing an empty template array, templating is disabled and measurements are parsed as influxdb line protocol keys (measurement<,tag_set>)
templates = []
## You may use an appropriate [gjson path](https://github.com/tidwall/gjson#path-syntax)
## to locate the metric registry within the JSON document
# dropwizard_metric_registry_path = "metrics"
## You may use an appropriate [gjson path](https://github.com/tidwall/gjson#path-syntax)
## to locate the default time of the measurements within the JSON document
# dropwizard_time_path = "time"
# dropwizard_time_format = "2006-01-02T15:04:05Z07:00"
## You may use an appropriate [gjson path](https://github.com/tidwall/gjson#path-syntax)
## to locate the tags map within the JSON document
# dropwizard_tags_path = "tags"
## You may even use tag paths per tag
# [inputs.exec.dropwizard_tag_paths]
# tag1 = "tags.tag1"
# tag2 = "tags.tag2"
```
## Examples
A typical JSON of a dropwizard metric registry:
```json
{
"version": "3.0.0",
"counters" : {
"measurement,tag1=green" : {
"count" : 1
}
},
"meters" : {
"measurement" : {
"count" : 1,
"m15_rate" : 1.0,
"m1_rate" : 1.0,
"m5_rate" : 1.0,
"mean_rate" : 1.0,
"units" : "events/second"
}
},
"gauges" : {
"measurement" : {
"value" : 1
}
},
"histograms" : {
"measurement" : {
"count" : 1,
"max" : 1.0,
"mean" : 1.0,
"min" : 1.0,
"p50" : 1.0,
"p75" : 1.0,
"p95" : 1.0,
"p98" : 1.0,
"p99" : 1.0,
"p999" : 1.0,
"stddev" : 1.0
}
},
"timers" : {
"measurement" : {
"count" : 1,
"max" : 1.0,
"mean" : 1.0,
"min" : 1.0,
"p50" : 1.0,
"p75" : 1.0,
"p95" : 1.0,
"p98" : 1.0,
"p99" : 1.0,
"p999" : 1.0,
"stddev" : 1.0,
"m15_rate" : 1.0,
"m1_rate" : 1.0,
"m5_rate" : 1.0,
"mean_rate" : 1.0,
"duration_units" : "seconds",
"rate_units" : "calls/second"
}
}
}
```
Would get translated into 4 different measurements:
```
measurement,metric_type=counter,tag1=green count=1
measurement,metric_type=meter count=1,m15_rate=1.0,m1_rate=1.0,m5_rate=1.0,mean_rate=1.0
measurement,metric_type=gauge value=1
measurement,metric_type=histogram count=1,max=1.0,mean=1.0,min=1.0,p50=1.0,p75=1.0,p95=1.0,p98=1.0,p99=1.0,p999=1.0
measurement,metric_type=timer count=1,max=1.0,mean=1.0,min=1.0,p50=1.0,p75=1.0,p95=1.0,p98=1.0,p99=1.0,p999=1.0,stddev=1.0,m15_rate=1.0,m1_rate=1.0,m5_rate=1.0,mean_rate=1.0
```
You may also parse a dropwizard registry from any JSON document which contains a dropwizard registry in some inner field.
Eg. to parse the following JSON document:
```json
{
"time" : "2017-02-22T14:33:03.662+02:00",
"tags" : {
"tag1" : "green",
"tag2" : "yellow"
},
"metrics" : {
"counters" : {
"measurement" : {
"count" : 1
}
},
"meters" : {},
"gauges" : {},
"histograms" : {},
"timers" : {}
}
}
```
and translate it into:
```
measurement,metric_type=counter,tag1=green,tag2=yellow count=1 1487766783662000000
```
you simply need to use the following additional configuration properties:
```toml
dropwizard_metric_registry_path = "metrics"
dropwizard_time_path = "time"
dropwizard_time_format = "2006-01-02T15:04:05Z07:00"
dropwizard_tags_path = "tags"
## tag paths per tag are supported too, eg.
#[inputs.yourinput.dropwizard_tag_paths]
# tag1 = "tags.tag1"
# tag2 = "tags.tag2"
```

55
content/telegraf/v1.17/data_formats/input/graphite.md Normal file
View File

@ -0,0 +1,55 @@
---
title: Graphite input data format
description: Us the Graphite data format to translate Graphite dot buckets directly into Telegraf measurement names, with a single value field, and without any tags.
menu:
telegraf_1_17:
name: Graphite
weight: 40
parent: Input data formats
---
The Graphite data format translates Graphite *dot* buckets directly into
Telegraf measurement names, with a single value field, and without any tags.
By default, the separator is left as `.`, but this can be changed using the
`separator` argument. For more advanced options, Telegraf supports specifying
[templates](#templates) to translate graphite buckets into Telegraf metrics.
## Configuration
```toml
[[inputs.exec]]
## Commands array
commands = ["/tmp/test.sh", "/usr/bin/mycollector --foo=bar"]
## measurement name suffix (for separating different commands)
name_suffix = "_mycollector"
## Data format to consume.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md
data_format = "graphite"
## This string will be used to join the matched values.
separator = "_"
## Each template line requires a template pattern. It can have an optional
## filter before the template and separated by spaces. It can also have optional extra
## tags following the template. Multiple tags should be separated by commas and no spaces
## similar to the line protocol format. There can be only one default template.
## Templates support below format:
## 1. filter + template
## 2. filter + template + extra tag(s)
## 3. filter + template with field key
## 4. default template
templates = [
"*.app env.service.resource.measurement",
"stats.* .host.measurement* region=eu-east,agent=sensu",
"stats2.* .host.measurement.field",
"measurement*"
]
```
### templates
For information on creating templates, see [Template patterns](/telegraf/v1.15/data_formats/template-patterns/).

226
content/telegraf/v1.17/data_formats/input/grok.md Normal file
View File

@ -0,0 +1,226 @@
---
title: Grok input data format
description: Use the grok data format to parse line-delimited data using a regular expression-like language.
menu:
telegraf_1_17:
name: Grok
weight: 40
parent: Input data formats
---
The grok data format parses line delimited data using a regular expression-like
language.
If you need to become familiar with grok patterns, see [Grok Basics](https://www.elastic.co/guide/en/logstash/current/plugins-filters-grok.html#_grok_basics)
in the Logstash documentation. The grok parser uses a slightly modified version of logstash "grok"
patterns, using the format:
```
%{<capture_syntax>[:<semantic_name>][:<modifier>]}
```
The `capture_syntax` defines the grok pattern that is used to parse the input
line and the `semantic_name` is used to name the field or tag. The extension
`modifier` controls the data type that the parsed item is converted to or
other special handling.
By default, all named captures are converted into string fields.
Timestamp modifiers can be used to convert captures to the timestamp of the
parsed metric. If no timestamp is parsed the metric will be created using the
current time.
You must capture at least one field per line.
- Available modifiers:
- string (default if nothing is specified)
- int
- float
- duration (ie, 5.23ms gets converted to int nanoseconds)
- tag (converts the field into a tag)
- drop (drops the field completely)
- measurement (use the matched text as the measurement name)
- Timestamp modifiers:
- ts (This will auto-learn the timestamp format)
- ts-ansic ("Mon Jan _2 15:04:05 2006")
- ts-unix ("Mon Jan _2 15:04:05 MST 2006")
- ts-ruby ("Mon Jan 02 15:04:05 -0700 2006")
- ts-rfc822 ("02 Jan 06 15:04 MST")
- ts-rfc822z ("02 Jan 06 15:04 -0700")
- ts-rfc850 ("Monday, 02-Jan-06 15:04:05 MST")
- ts-rfc1123 ("Mon, 02 Jan 2006 15:04:05 MST")
- ts-rfc1123z ("Mon, 02 Jan 2006 15:04:05 -0700")
- ts-rfc3339 ("2006-01-02T15:04:05Z07:00")
- ts-rfc3339nano ("2006-01-02T15:04:05.999999999Z07:00")
- ts-httpd ("02/Jan/2006:15:04:05 -0700")
- ts-epoch (seconds since unix epoch, may contain decimal)
- ts-epochnano (nanoseconds since unix epoch)
- ts-syslog ("Jan 02 15:04:05", parsed time is set to the current year)
- ts-"CUSTOM"
CUSTOM time layouts must be within quotes and be the representation of the
"reference time", which is `Mon Jan 2 15:04:05 -0700 MST 2006`.
To match a comma decimal point you can use a period. For example `%{TIMESTAMP:timestamp:ts-"2006-01-02 15:04:05.000"}` can be used to match `"2018-01-02 15:04:05,000"`
To match a comma decimal point you can use a period in the pattern string.
See https://golang.org/pkg/time/#Parse for more details.
Telegraf has many of its own [built-in patterns](https://github.com/influxdata/telegraf/blob/master/plugins/parsers/grok/influx_patterns.go),
as well as support for most of
[logstash's builtin patterns](https://github.com/logstash-plugins/logstash-patterns-core/blob/master/patterns/grok-patterns).
_Golang regular expressions do not support lookahead or lookbehind.
logstash patterns that depend on these are not supported._
If you need help building patterns to match your logs, the
[Grok Debugger application](https://grokdebug.herokuapp.com) might be helpful.
## Configuration
```toml
[[inputs.file]]
## Files to parse each interval.
## These accept standard unix glob matching rules, but with the addition of
## ** as a "super asterisk". ie:
## /var/log/**.log -> recursively find all .log files in /var/log
## /var/log/*/*.log -> find all .log files with a parent dir in /var/log
## /var/log/apache.log -> only tail the apache log file
files = ["/var/log/apache/access.log"]
## The dataformat to be read from files
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md
data_format = "grok"
## This is a list of patterns to check the given log file(s) for.
## Note that adding patterns here increases processing time. The most
## efficient configuration is to have one pattern.
## Other common built-in patterns are:
## %{COMMON_LOG_FORMAT} (plain apache & nginx access logs)
## %{COMBINED_LOG_FORMAT} (access logs + referrer & agent)
grok_patterns = ["%{COMBINED_LOG_FORMAT}"]
## Full path(s) to custom pattern files.
grok_custom_pattern_files = []
## Custom patterns can also be defined here. Put one pattern per line.
grok_custom_patterns = '''
'''
## Timezone allows you to provide an override for timestamps that
## don't already include an offset
## e.g. 04/06/2016 12:41:45 data one two 5.43µs
##
## Default: "" which renders UTC
## Options are as follows:
## 1. Local -- interpret based on machine localtime
## 2. "Canada/Eastern" -- Unix TZ values like those found in https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
## 3. UTC -- or blank/unspecified, will return timestamp in UTC
grok_timezone = "Canada/Eastern"
```
### Timestamp examples
This example input and config parses a file using a custom timestamp conversion:
```
2017-02-21 13:10:34 value=42
```
```toml
[[inputs.file]]
grok_patterns = ['%{TIMESTAMP_ISO8601:timestamp:ts-"2006-01-02 15:04:05"} value=%{NUMBER:value:int}']
```
This example input and config parses a file using a timestamp in unix time:
```
1466004605 value=42
1466004605.123456789 value=42
```
```toml
[[inputs.file]]
grok_patterns = ['%{NUMBER:timestamp:ts-epoch} value=%{NUMBER:value:int}']
```
This example parses a file using a built-in conversion and a custom pattern:
```
Wed Apr 12 13:10:34 PST 2017 value=42
```
```toml
[[inputs.file]]
grok_patterns = ["%{TS_UNIX:timestamp:ts-unix} value=%{NUMBER:value:int}"]
grok_custom_patterns = '''
TS_UNIX %{DAY} %{MONTH} %{MONTHDAY} %{HOUR}:%{MINUTE}:%{SECOND} %{TZ} %{YEAR}
'''
```
For cases where the timestamp itself is without offset, the `timezone` config var is available
to denote an offset. By default (with `timezone` either omit, blank or set to `"UTC"`), the times
are processed as if in the UTC timezone. If specified as `timezone = "Local"`, the timestamp
will be processed based on the current machine timezone configuration. Lastly, if using a
timezone from the list of Unix [timezones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones),
grok will offset the timestamp accordingly.
### TOML escaping
When saving patterns to the configuration file, keep in mind the different TOML
[string](https://github.com/toml-lang/toml#string) types and the escaping
rules for each. These escaping rules must be applied in addition to the
escaping required by the grok syntax. Using the Multi-line line literal
syntax with `'''` may be useful.
The following config examples will parse this input file:
```
|42|\uD83D\uDC2F|'telegraf'|
```
Since `|` is a special character in the grok language, we must escape it to
get a literal `|`. With a basic TOML string, special characters such as
backslash must be escaped, requiring us to escape the backslash a second time.
```toml
[[inputs.file]]
grok_patterns = ["\\|%{NUMBER:value:int}\\|%{UNICODE_ESCAPE:escape}\\|'%{WORD:name}'\\|"]
grok_custom_patterns = "UNICODE_ESCAPE (?:\\\\u[0-9A-F]{4})+"
```
We cannot use a literal TOML string for the pattern, because we cannot match a
`'` within it. However, it works well for the custom pattern.
```toml
[[inputs.file]]
grok_patterns = ["\\|%{NUMBER:value:int}\\|%{UNICODE_ESCAPE:escape}\\|'%{WORD:name}'\\|"]
grok_custom_patterns = 'UNICODE_ESCAPE (?:\\u[0-9A-F]{4})+'
```
A multi-line literal string allows us to encode the pattern:
```toml
[[inputs.file]]
grok_patterns = ['''
\|%{NUMBER:value:int}\|%{UNICODE_ESCAPE:escape}\|'%{WORD:name}'\|
''']
grok_custom_patterns = 'UNICODE_ESCAPE (?:\\u[0-9A-F]{4})+'
```
### Tips for creating patterns
Writing complex patterns can be difficult, here is some advice for writing a
new pattern or testing a pattern developed [online](https://grokdebug.herokuapp.com).
Create a file output that writes to stdout, and disable other outputs while
testing. This will allow you to see the captured metrics. Keep in mind that
the file output will only print once per `flush_interval`.
```toml
[[outputs.file]]
files = ["stdout"]
```
- Start with a file containing only a single line of your input.
- Remove all but the first token or piece of the line.
- Add the section of your pattern to match this piece to your configuration file.
- Verify that the metric is parsed successfully by running Telegraf.
- If successful, add the next token, update the pattern and retest.
- Continue one token at a time until the entire line is successfully parsed.

27
content/telegraf/v1.17/data_formats/input/influx.md Normal file
View File

@ -0,0 +1,27 @@
---
title: InfluxDB Line Protocol input data format
description: Use the InfluxDB Line Protocol input data format to parse InfluxDB metrics directly into Telegraf metrics.
menu:
telegraf_1_17:
name: InfluxDB Line Protocol input
weight: 60
parent: Input data formats
---
There are no additional configuration options for InfluxDB [line protocol][]. The
InfluxDB metrics are parsed directly into Telegraf metrics.
[line protocol]: /{{< latest "influxdb" "v1" >}}/write_protocols/line/
### Configuration
```toml
[[inputs.file]]
files = ["example"]
## Data format to consume.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md
data_format = "influx"
```

224
content/telegraf/v1.17/data_formats/input/json.md Normal file
View File

@ -0,0 +1,224 @@
---
title: JSON input data format
description: Use the JSON input data format to parse [JSON][json] objects, or an array of objects, into Telegraf metric fields.
menu:
telegraf_1_17:
name: JSON input
weight: 70
parent: Input data formats
---
The JSON input data format parses a [JSON][json] object or an array of objects
into Telegraf metric fields.
**NOTE:** All JSON numbers are converted to float fields. JSON String are
ignored unless specified in the `tag_key` or `json_string_fields` options.
## Configuration
```toml
[[inputs.file]]
files = ["example"]
## Data format to consume.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md
data_format = "json"
## Query is a GJSON path that specifies a specific chunk of JSON to be
## parsed, if not specified the whole document will be parsed.
##
## GJSON query paths are described here:
## https://github.com/tidwall/gjson#path-syntax
json_query = ""
## Tag keys is an array of keys that should be added as tags.
tag_keys = [
"my_tag_1",
"my_tag_2"
]
## String fields is an array of keys that should be added as string fields.
json_string_fields = []
## Name key is the key to use as the measurement name.
json_name_key = ""
## Time key is the key containing the time that should be used to create the
## metric.
json_time_key = ""
## Time format is the time layout that should be used to interprete the
## json_time_key. The time must be `unix`, `unix_ms` or a time in the
## "reference time".
## ex: json_time_format = "Mon Jan 2 15:04:05 -0700 MST 2006"
## json_time_format = "2006-01-02T15:04:05Z07:00"
## json_time_format = "unix"
## json_time_format = "unix_ms"
json_time_format = ""
```
### `json_query`
The `json_query` is a [GJSON][gjson] path that can be used to limit the
portion of the overall JSON document that should be parsed. The result of the
query should contain a JSON object or an array of objects.
Consult the GJSON [path syntax][gjson syntax] for details and examples.
### json_time_key, json_time_format
By default the current time will be used for all created metrics, to set the
time using the JSON document you can use the `json_time_key` and
`json_time_format` options together to set the time to a value in the parsed
document.
The `json_time_key` option specifies the key containing the time value and
`json_time_format` must be set to `unix`, `unix_ms`, or the Go "reference
time" which is defined to be the specific time: `Mon Jan 2 15:04:05 MST 2006`.
Consult the Go [time][time parse] package for details and additional examples
on how to set the time format.
## Examples
### Basic parsing
Config:
```toml
[[inputs.file]]
files = ["example"]
name_override = "myjsonmetric"
data_format = "json"
```
Input:
```json
{
"a": 5,
"b": {
"c": 6
},
"ignored": "I'm a string"
}
```
Output:
```
myjsonmetric a=5,b_c=6
```
### Name, tags, and string fields
Config:
```toml
[[inputs.file]]
files = ["example"]
json_name_key = "name"
tag_keys = ["my_tag_1"]
json_string_fields = ["my_field"]
data_format = "json"
```
Input:
```json
{
"a": 5,
"b": {
"c": 6,
"my_field": "description"
},
"my_tag_1": "foo",
"name": "my_json"
}
```
Output:
```
my_json,my_tag_1=foo a=5,b_c=6,my_field="description"
```
### Arrays
If the JSON data is an array, then each object within the array is parsed with
the configured settings.
Config:
```toml
[[inputs.file]]
files = ["example"]
data_format = "json"
json_time_key = "b_time"
json_time_format = "02 Jan 06 15:04 MST"
```
Input:
```json
[
{
"a": 5,
"b": {
"c": 6,
"time":"04 Jan 06 15:04 MST"
},
},
{
"a": 7,
"b": {
"c": 8,
"time":"11 Jan 07 15:04 MST"
},
}
]
```
Output:
```
file a=5,b_c=6 1136387040000000000
file a=7,b_c=8 1168527840000000000
```
### Query
The `json_query` option can be used to parse a subset of the document.
Config:
```toml
[[inputs.file]]
files = ["example"]
data_format = "json"
tag_keys = ["first"]
json_string_fields = ["last"]
json_query = "obj.friends"
```
Input:
```json
{
"obj": {
"name": {"first": "Tom", "last": "Anderson"},
"age":37,
"children": ["Sara","Alex","Jack"],
"fav.movie": "Deer Hunter",
"friends": [
{"first": "Dale", "last": "Murphy", "age": 44},
{"first": "Roger", "last": "Craig", "age": 68},
{"first": "Jane", "last": "Murphy", "age": 47}
]
}
}
```
Output:
```
file,first=Dale last="Murphy",age=44
file,first=Roger last="Craig",age=68
file,first=Jane last="Murphy",age=47
```
[gjson]: https://github.com/tidwall/gjson
[gjson syntax]: https://github.com/tidwall/gjson#path-syntax
[json]: https://www.json.org/
[time parse]: https://golang.org/pkg/time/#Parse

42
content/telegraf/v1.17/data_formats/input/logfmt.md Normal file
View File

@ -0,0 +1,42 @@
---
title: Logfmt input data format
description: Use the `logfmt` input data format to parse logfmt data into Telegraf metrics.
menu:
telegraf_1_17:
name: logfmt
weight: 80
parent: Input data formats
---
The `logfmt` data format parses [logfmt] data into Telegraf metrics.
[logfmt]: https://brandur.org/logfmt
## Configuration
```toml
[[inputs.file]]
files = ["example"]
## Data format to consume.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md
data_format = "logfmt"
## Set the name of the created metric, if unset the name of the plugin will
## be used.
metric_name = "logfmt"
```
## Metrics
Each key/value pair in the line is added to a new metric as a field. The type
of the field is automatically determined based on the contents of the value.
## Examples
```
- method=GET host=example.org ts=2018-07-24T19:43:40.275Z connect=4ms service=8ms status=200 bytes=1653
+ logfmt method="GET",host="example.org",ts="2018-07-24T19:43:40.275Z",connect="4ms",service="8ms",status=200i,bytes=1653i
```

29
content/telegraf/v1.17/data_formats/input/nagios.md Normal file
View File

@ -0,0 +1,29 @@
---
title: Nagios input data format
description: Use the Nagios input data format to parse the output of Nagios plugins into Telegraf metrics.
menu:
telegraf_1_17:
name: Nagios
weight: 90
parent: Input data formats
---
# Nagios
The Nagios input data format parses the output of
[Nagios plugins](https://www.nagios.org/downloads/nagios-plugins/) into
Telegraf metrics.
## Configuration
```toml
[[inputs.exec]]
## Commands array
commands = ["/usr/lib/nagios/plugins/check_load -w 5,6,7 -c 7,8,9"]
## Data format to consume.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md
data_format = "nagios"
```

44
content/telegraf/v1.17/data_formats/input/value.md Normal file
View File

@ -0,0 +1,44 @@
---
title: Value input data format
description: Use the `value` input data format to parse single values into Telegraf metrics.
menu:
telegraf_1_17:
name: Value
weight: 100
parent: Input data formats
---
The "value" input data format translates single values into Telegraf metrics. This
is done by assigning a measurement name and setting a single field ("value")
as the parsed metric.
## Configuration
You **must** tell Telegraf what type of metric to collect by using the
`data_type` configuration option. Available data type options are:
1. integer
2. float or long
3. string
4. boolean
> **Note:** It is also recommended that you set `name_override` to a measurement
name that makes sense for your metric; otherwise, it will just be set to the
name of the plugin.
```toml
[[inputs.exec]]
## Commands array
commands = ["cat /proc/sys/kernel/random/entropy_avail"]
## override the default metric name of "exec"
name_override = "entropy_available"
## Data format to consume.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md
data_format = "value"
data_type = "integer" # required
```

28
content/telegraf/v1.17/data_formats/input/wavefront.md Normal file
View File

@ -0,0 +1,28 @@
---
title: Wavefront input data format
description: Use the Wavefront input data format to parse Wavefront data into Telegraf metrics.
menu:
telegraf_1_17:
name: Wavefront
weight: 110
parent: Input data formats
---
The Wavefront input data format parse Wavefront data into Telegraf metrics.
For more information on the Wavefront native data format, see
[Wavefront Data Format](https://docs.wavefront.com/wavefront_data_format.html) in the Wavefront documentation.
## Configuration
There are no additional configuration options for Wavefront Data Format line-protocol.
```toml
[[inputs.file]]
files = ["example"]
## Data format to consume.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md
data_format = "wavefront"
```

35
content/telegraf/v1.17/data_formats/output/_index.md Normal file
View File

@ -0,0 +1,35 @@
---
title: Telegraf output data formats
description: Telegraf serializes metrics into output data formats for InfluxDB Line Protocol, JSON, Graphite, and Splunk metrics.
menu:
telegraf_1_17:
name: Output data formats
weight: 1
parent: Data formats
---
In addition to output-specific data formats, Telegraf supports the following set
of common data formats that may be selected when configuring many of the Telegraf
output plugins.
* [Carbon2](/telegraf/v1.15/data_formats/output/carbon2)
* [Graphite](/telegraf/v1.15/data_formats/output/graphite)
* [InfluxDB Line Protocol](/telegraf/v1.15/data_formats/output/influx)
* [JSON](/telegraf/v1.15/data_formats/output/json)
* [ServiceNow Metrics](/telegraf/v1.15/data_formats/output/nowmetric)
* [SplunkMetric](/telegraf/v1.15/data_formats/output/splunkmetric)
You will be able to identify the plugins with support by the presence of a
`data_format` configuration option, for example, in the File (`file`) output plugin:
```toml
[[outputs.file]]
## Files to write to, "stdout" is a specially handled file.
files = ["stdout"]
## Data format to output.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_OUTPUT.md
data_format = "influx"
```

60
content/telegraf/v1.17/data_formats/output/carbon2.md Normal file
View File

@ -0,0 +1,60 @@
---
title: Carbon2 output data format
description: Use the Carbon2 output data format (serializer) converts Telegraf metrics into the Carbon2 format.
menu:
telegraf_1_17:
name: Carbon2
weight: 10
parent: Output data formats
---
The `carbon2` output data format (serializer) translates the Telegraf metric format to the [Carbon2 format](http://metrics20.org/implementations/).
### Configuration
```toml
[[outputs.file]]
## Files to write to, "stdout" is a specially handled file.
files = ["stdout", "/tmp/metrics.out"]
## Data format to output.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_OUTPUT.md
data_format = "carbon2"
```
Standard form:
```
metric=name field=field_1 host=foo 30 1234567890
metric=name field=field_2 host=foo 4 1234567890
metric=name field=field_N host=foo 59 1234567890
```
### Metrics
The serializer converts the metrics by creating `intrinsic_tags` using the combination of metric name and fields. So, if one Telegraf metric has 4 fields, the `carbon2` output will be 4 separate metrics. There will be a `metric` tag that represents the name of the metric and a `field` tag to represent the field.
### Example
If we take the following InfluxDB Line Protocol:
```
weather,location=us-midwest,season=summer temperature=82,wind=100 1234567890
```
After serializing in Carbon2, the result would be:
```
metric=weather field=temperature location=us-midwest season=summer 82 1234567890
metric=weather field=wind location=us-midwest season=summer 100 1234567890
```
### Fields and tags with spaces
When a field key or tag key/value have spaces, spaces will be replaced with `_`.
### Tags with empty values
When a tag's value is empty, it will be replaced with `null`.

58
content/telegraf/v1.17/data_formats/output/graphite.md Normal file
View File

@ -0,0 +1,58 @@
---
title: Graphite output data format
description: Use the Graphite output data format to serialize data from Telegraf metrics.
menu:
telegraf_1_17:
name: Graphite output
weight: 20
parent: Output data formats
---
The Graphite data format is serialized from Telegraf metrics using either the
template pattern or tag support method. You can select between the two
methods using the [`graphite_tag_support`](#graphite-tag-support) option. When set, the tag support method is used,
otherwise the [template pattern][templates]) option is used.
## Configuration
```toml
[[outputs.file]]
## Files to write to, "stdout" is a specially handled file.
files = ["stdout", "/tmp/metrics.out"]
## Data format to output.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_OUTPUT.md
data_format = "graphite"
## Prefix added to each graphite bucket
prefix = "telegraf"
## Graphite template pattern
template = "host.tags.measurement.field"
## Support Graphite tags, recommended to enable when using Graphite 1.1 or later.
# graphite_tag_support = false
```
### graphite_tag_support
When the `graphite_tag_support` option is enabled, the template pattern is not
used. Instead, tags are encoded using
[Graphite tag support](http://graphite.readthedocs.io/en/latest/tags.html),
added in Graphite 1.1. The `metric_path` is a combination of the optional
`prefix` option, measurement name, and field name.
The tag `name` is reserved by Graphite, any conflicting tags and will be encoded as `_name`.
**Example conversion**:
```
cpu,cpu=cpu-total,dc=us-east-1,host=tars usage_idle=98.09,usage_user=0.89 1455320660004257758
=>
cpu.usage_user;cpu=cpu-total;dc=us-east-1;host=tars 0.89 1455320690
cpu.usage_idle;cpu=cpu-total;dc=us-east-1;host=tars 98.09 1455320690
```
### templates
For more information on templates and template patterns, see [Template patterns](/telegraf/v1.15/data_formats/template-patterns/).

41
content/telegraf/v1.17/data_formats/output/influx.md Normal file
View File

@ -0,0 +1,41 @@
---
title: InfluxDB Line Protocol output data format
description: The `influx` data format outputs metrics into the InfluxDB Line Protocol format.
menu:
telegraf_1_17:
name: InfluxDB Line Protocol
weight: 30
parent: Output data formats
---
The `influx` output data format outputs metrics into [InfluxDB Line Protocol][line protocol]. InfluxData recommends this data format unless another format is required for interoperability.
## Configuration
```toml
[[outputs.file]]
## Files to write to, "stdout" is a specially handled file.
files = ["stdout", "/tmp/metrics.out"]
## Data format to output.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_OUTPUT.md
data_format = "influx"
## Maximum line length in bytes. Useful only for debugging.
influx_max_line_bytes = 0
## When true, fields will be output in ascending lexical order. Enabling
## this option will result in decreased performance and is only recommended
## when you need predictable ordering while debugging.
influx_sort_fields = false
## When true, Telegraf will output unsigned integers as unsigned values,
## i.e.: `42u`. You will need a version of InfluxDB supporting unsigned
## integer values. Enabling this option will result in field type errors if
## existing data has been written.
influx_uint_support = false
```
[line protocol]: /{{< latest "influxdb" "v1" >}}/write_protocols/line_protocol_tutorial/

89
content/telegraf/v1.17/data_formats/output/json.md Normal file
View File

@ -0,0 +1,89 @@
---
title: JSON output data format
description: Telegraf's `json` output data format converts metrics into JSON documents.
menu:
telegraf_1_17:
name: JSON
weight: 40
parent: Output data formats
---
The `json` output data format serializes Telegraf metrics into JSON documents.
## Configuration
```toml
[[outputs.file]]
## Files to write to, "stdout" is a specially handled file.
files = ["stdout", "/tmp/metrics.out"]
## Data format to output.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_OUTPUT.md
data_format = "json"
## The resolution to use for the metric timestamp. Must be a duration string
## such as "1ns", "1us", "1ms", "10ms", "1s". Durations are truncated to
## the power of 10 less than the specified units.
json_timestamp_units = "1s"
```
## Examples
### Standard format
```json
{
"fields": {
"field_1": 30,
"field_2": 4,
"field_N": 59,
"n_images": 660
},
"name": "docker",
"tags": {
"host": "raynor"
},
"timestamp": 1458229140
}
```
### Batch format
When an output plugin needs to emit multiple metrics at one time, it may use the
batch format. The use of batch format is determined by the plugin -- reference
the documentation for the specific plugin.
```json
{
"metrics": [
{
"fields": {
"field_1": 30,
"field_2": 4,
"field_N": 59,
"n_images": 660
},
"name": "docker",
"tags": {
"host": "raynor"
},
"timestamp": 1458229140
},
{
"fields": {
"field_1": 30,
"field_2": 4,
"field_N": 59,
"n_images": 660
},
"name": "docker",
"tags": {
"host": "raynor"
},
"timestamp": 1458229140
}
]
}
```

90
content/telegraf/v1.17/data_formats/output/nowmetric.md Normal file
View File

@ -0,0 +1,90 @@
---
title: ServiceNow Metrics output data format
description: Use the ServiceNow Metrics output data format (serializer) to output metrics in the ServiceNow Operational Intelligence format.
menu:
telegraf_1_17:
name: ServiceNow Metrics
weight: 50
parent: Output data formats
---
The ServiceNow Metrics output data format (serializer) outputs metrics in the [ServiceNow Operational Intelligence format](https://docs.servicenow.com/bundle/london-it-operations-management/page/product/event-management/reference/mid-POST-metrics.html).
It can be used to write to a file using the File output plugin, or for sending metrics to a MID Server with Enable REST endpoint activated using the standard telegraf HTTP output.
If you're using the HTTP output plugin, this serializer knows how to batch the metrics so you don't end up with an HTTP POST per metric.
An example event looks like:
```javascript
[{
"metric_type": "Disk C: % Free Space",
"resource": "C:\\",
"node": "lnux100",
"value": 50,
"timestamp": 1473183012000,
"ci2metric_id": {
"node": "lnux100"
},
"source": “Telegraf”
}]
```
## Using with the HTTP output plugin
To send this data to a ServiceNow MID Server with Web Server extension activated, you can use the HTTP output plugin, there are some custom headers that you need to add to manage the MID Web Server authorization, here's a sample config for an HTTP output:
```toml
[[outputs.http]]
## URL is the address to send metrics to
url = "http://<mid server fqdn or ip address>:9082/api/mid/sa/metrics"
## Timeout for HTTP message
# timeout = "5s"
## HTTP method, one of: "POST" or "PUT"
method = "POST"
## HTTP Basic Auth credentials
username = 'evt.integration'
password = 'P@$$w0rd!'
## Optional TLS Config
# tls_ca = "/etc/telegraf/ca.pem"
# tls_cert = "/etc/telegraf/cert.pem"
# tls_key = "/etc/telegraf/key.pem"
## Use TLS but skip chain & host verification
# insecure_skip_verify = false
## Data format to output.
## Each data format has it's own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_OUTPUT.md
data_format = "nowmetric"
## Additional HTTP headers
[outputs.http.headers]
# # Should be set manually to "application/json" for json data_format
Content-Type = "application/json"
Accept = "application/json"
```
Starting with the London release, you also need to explicitly create event rule to allow binding of metric events to host CIs.
https://docs.servicenow.com/bundle/london-it-operations-management/page/product/event-management/task/event-rule-bind-metrics-to-host.html
## Using with the File output plugin
You can use the File output plugin to output the payload in a file.
In this case, just add the following section to your telegraf configuration file.
```toml
[[outputs.file]]
## Files to write to, "stdout" is a specially handled file.
files = ["C:/Telegraf/metrics.out"]
## Data format to output.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_OUTPUT.md
data_format = "nowmetric"
```

147
content/telegraf/v1.17/data_formats/output/splunkmetric.md Normal file
View File

@ -0,0 +1,147 @@
---
title: SplunkMetric output data format
description: The SplunkMetric serializer formats and outputs data in a format that can be consumed by a Splunk metrics index.
menu:
telegraf_1_17:
name: SplunkMetric
weight: 60
parent: Output data formats
---
The SplunkMetric serializer formats and outputs the metric data in a format that can be consumed by a Splunk metrics index.
It can be used to write to a file using the file output, or for sending metrics to a HEC using the standard Telegraf HTTP output.
If you're using the HTTP output, this serializer knows how to batch the metrics so you don't end up with an HTTP POST per metric.
Th data is output in a format that conforms to the specified Splunk HEC JSON format as found here:
[Send metrics in JSON format](http://dev.splunk.com/view/event-collector/SP-CAAAFDN).
An example event looks like:
```javascript
{
"time": 1529708430,
"event": "metric",
"host": "patas-mbp",
"fields": {
"_value": 0.6,
"cpu": "cpu0",
"dc": "mobile",
"metric_name": "cpu.usage_user",
"user": "ronnocol"
}
}
```
In the above snippet, the following keys are dimensions:
* cpu
* dc
* user
## Using with the HTTP output
To send this data to a Splunk HEC, you can use the HTTP output, there are some custom headers that you need to add
to manage the HEC authorization, here's a sample config for an HTTP output:
```toml
[[outputs.http]]
## URL is the address to send metrics to
url = "https://localhost:8088/services/collector"
## Timeout for HTTP message
# timeout = "5s"
## HTTP method, one of: "POST" or "PUT"
# method = "POST"
## HTTP Basic Auth credentials
# username = "username"
# password = "pa$$word"
## Optional TLS Config
# tls_ca = "/etc/telegraf/ca.pem"
# tls_cert = "/etc/telegraf/cert.pem"
# tls_key = "/etc/telegraf/key.pem"
## Use TLS but skip chain & host verification
# insecure_skip_verify = false
## Data format to output.
## Each data format has it's own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_OUTPUT.md
data_format = "splunkmetric"
## Provides time, index, source overrides for the HEC
splunkmetric_hec_routing = true
## Additional HTTP headers
[outputs.http.headers]
# Should be set manually to "application/json" for json data_format
Content-Type = "application/json"
Authorization = "Splunk xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
X-Splunk-Request-Channel = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
```
## Overrides
You can override the default values for the HEC token you are using by adding additional tags to the config file.
The following aspects of the token can be overriden with tags:
* index
* source
You can either use `[global_tags]` or using a more advanced configuration as documented [here](https://github.com/influxdata/telegraf/blob/master/docs/CONFIGURATION.md).
Such as this example which overrides the index just on the cpu metric:
```toml
[[inputs.cpu]]
percpu = false
totalcpu = true
[inputs.cpu.tags]
index = "cpu_metrics"
```
## Using with the File output
You can use the file output when running telegraf on a machine with a Splunk forwarder.
A sample event when `hec_routing` is false (or unset) looks like:
```javascript
{
"_value": 0.6,
"cpu": "cpu0",
"dc": "mobile",
"metric_name": "cpu.usage_user",
"user": "ronnocol",
"time": 1529708430
}
```
Data formatted in this manner can be ingested with a simple `props.conf` file that
looks like this:
```ini
[telegraf]
category = Metrics
description = Telegraf Metrics
pulldown_type = 1
DATETIME_CONFIG =
NO_BINARY_CHECK = true
SHOULD_LINEMERGE = true
disabled = false
INDEXED_EXTRACTIONS = json
KV_MODE = none
TIMESTAMP_FIELDS = time
TIME_FORMAT = %s.%3N
```
An example configuration of a file based output is:
```toml
# Send telegraf metrics to file(s)
[[outputs.file]]
## Files to write to, "stdout" is a specially handled file.
files = ["/tmp/metrics.out"]
## Data format to output.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_OUTPUT.md
data_format = "splunkmetric"
hec_routing = false
```

143
content/telegraf/v1.17/data_formats/template-patterns.md Normal file
View File

@ -0,0 +1,143 @@
---
title: Telegraf template patterns
description: Use template patterns to describe how dot-delimited strings should map to and from Telegraf metrics.
menu:
telegraf_1_17:
name: Template patterns
weight: 30
parent: Data formats
---
Template patterns are a mini language that describes how a dot delimited
string should be mapped to and from [metrics][].
A template has the form:
```
"host.mytag.mytag.measurement.measurement.field*"
```
Where the following keywords can be set:
1. `measurement`: specifies that this section of the graphite bucket corresponds
to the measurement name. This can be specified multiple times.
2. `field`: specifies that this section of the graphite bucket corresponds
to the field name. This can be specified multiple times.
3. `measurement*`: specifies that all remaining elements of the graphite bucket
correspond to the measurement name.
4. `field*`: specifies that all remaining elements of the graphite bucket
correspond to the field name.
Any part of the template that is not a keyword is treated as a tag key. This
can also be specified multiple times.
**NOTE:** `field*` cannot be used in conjunction with `measurement*`.
## Examples
### Measurement and tag templates
The most basic template is to specify a single transformation to apply to all
incoming metrics. So the following template:
```toml
templates = [
"region.region.measurement*"
]
```
would result in the following Graphite -> Telegraf transformation.
```
us.west.cpu.load 100
=> cpu.load,region=us.west value=100
```
Multiple templates can also be specified, but these should be differentiated
using _filters_ (see below for more details)
```toml
templates = [
"*.*.* region.region.measurement", # <- all 3-part measurements will match this one.
"*.*.*.* region.region.host.measurement", # <- all 4-part measurements will match this one.
]
```
### Field templates
The field keyword tells Telegraf to give the metric that field name.
So the following template:
```toml
separator = "_"
templates = [
"measurement.measurement.field.field.region"
]
```
would result in the following Graphite -> Telegraf transformation.
```
cpu.usage.idle.percent.eu-east 100
=> cpu_usage,region=eu-east idle_percent=100
```
The field key can also be derived from all remaining elements of the graphite
bucket by specifying `field*`:
```toml
separator = "_"
templates = [
"measurement.measurement.region.field*"
]
```
which would result in the following Graphite -> Telegraf transformation.
```
cpu.usage.eu-east.idle.percentage 100
=> cpu_usage,region=eu-east idle_percentage=100
```
### Filter templates
Users can also filter the template(s) to use based on the name of the bucket,
using glob matching, like so:
```toml
templates = [
"cpu.* measurement.measurement.region",
"mem.* measurement.measurement.host"
]
```
which would result in the following transformation:
```
cpu.load.eu-east 100
=> cpu_load,region=eu-east value=100
mem.cached.localhost 256
=> mem_cached,host=localhost value=256
```
### Adding Tags
Additional tags can be added to a metric that don't exist on the received metric.
You can add additional tags by specifying them after the pattern.
Tags have the same format as the line protocol.
Multiple tags are separated by commas.
```toml
templates = [
"measurement.measurement.field.region datacenter=1a"
]
```
would result in the following Graphite -> Telegraf transformation.
```
cpu.usage.idle.eu-east 100
=> cpu_usage,region=eu-east,datacenter=1a idle=100
```
[metrics]: /telegraf/v1.15/concepts/metrics/

12
content/telegraf/v1.17/guides/_index.md Normal file
View File

@ -0,0 +1,12 @@
---
title: Telegraf Guides
description: Step-by-step tutorials for Telegraf.
menu:
telegraf_1_17:
name: Guides
weight: 20
---
The following articles guide you through step-by-step Telegraf configuration examples.
{{< children >}}

116
content/telegraf/v1.17/guides/using_http.md Normal file
View File

@ -0,0 +1,116 @@
---
title: Using the HTTP input plugin with Citi Bike data
description: Collect live metrics on Citi Bike stations in New York City with the HTTP input plugin.
menu:
telegraf_1_17:
name: Using the HTTP plugin
weight: 30
parent: Guides
---
This example walks through using the Telegraf HTTP input plugin to collect live metrics on Citi Bike stations in New York City. Live station data is available in JSON format from [NYC OpenData](https://data.cityofnewyork.us/NYC-BigApps/Citi-Bike-Live-Station-Feed-JSON-/p94q-8hxh).
For the following example to work, configure [`influxdb` output plugin](/telegraf/v1.15/plugins/#influxdb). This plugin is what allows Telegraf to write the metrics to your InfluxDB.
## Configure the HTTP Input plugin in your Telegraf configuration file
To retrieve data from the Citi Bike URL endpoint, enable the `inputs.http` input plugin in your Telegraf configuration file.
Specify the following options:
### `urls`
One or more URLs to read metrics from. For this example, use `https://feeds.citibikenyc.com/stations/stations.json`.
### `data_format`
The format of the data in the HTTP endpoints that Telegraf will ingest. For this example, use JSON.
## Add parser information to your Telegraf configuration
Specify the following JSON-specific options.
### JSON
#### `json_query`
To parse only the relevant portion of JSON data, set the `json_query` option with a [GJSON](https://github.com/tidwall/gjson) path. The result of the query should contain a JSON object or an array of objects.
In this case, we don't want to parse the JSON query's `executionTime` at the beginning of the data, so we'll limit this to include only the data in the `stationBeanList` array.
#### `tag_keys`
List of one or more JSON keys that should be added as tags. For this example, we'll use the tag keys `id`, `stationName`, `city`, and `postalCode`.
#### `json_string_fields`
List the keys of fields that are in string format so that they can be parsed as strings. Here, the string fields are `statusValue`, `stAddress1`, `stAddress2`, `location`, and `landMark`.
#### `json_time_key`
Key from the JSON file that creates the timestamp metric. In this case, we want to use the time that station data was last reported, or the `lastCommunicationTime`. If you don't specify a key, the time that Telegraf reads the data becomes the timestamp.
#### `json_time_format`
The format used to interpret the designated `json_time_key`. This example uses [Go reference time format](https://golang.org/pkg/time/#Time.Format). For example, `Mon Jan 2 15:04:05 MST 2006`.
#### `json_timezone`
The timezone We'll set this to the Unix TZ value where our bike data takes place, `America/New_York`.
#### Example configuration
```toml
[[inputs.http]]
#URL for NYC's Citi Bike station data in JSON format
urls = ["https://feeds.citibikenyc.com/stations/stations.json"]
#Overwrite measurement name from default `http` to `citibikenyc`
name_override = "citibikenyc"
#Exclude url and host items from tags
tagexclude = ["url", "host"]
#Data from HTTP in JSON format
data_format = "json"
#Parse `stationBeanList` array only
json_query = "stationBeanList"
#Set station metadata as tags
tag_keys = ["id", "stationName", "city", "postalCode"]
#Do not include station landmark data as fields
fielddrop = ["landMark"]
#JSON values to set as string fields
json_string_fields = ["statusValue", "stAddress1", "stAddress2", "location", "landMark"]
#Latest station information reported at `lastCommunicationTime`
json_time_key = "lastCommunicationTime"
#Time is reported in Golang "reference time" format
json_time_format = "2006-01-02 03:04:05 PM"
#Time is reported in Eastern Standard Time (EST)
json_timezone = "America/New_York"
```
## Start Telegraf and verify data appears
[Start the Telegraf service](/telegraf/v1.15/introduction/getting-started/#start-telegraf-service).
To test that the data is being sent to InfluxDB, run the following (replacing `telegraf.conf` with the path to your configuration file):
```
telegraf -config ~/telegraf.conf -test
```
This command should return line protocol that looks similar to the following:
```
citibikenyc,id=3443,stationName=W\ 52\ St\ &\ 6\ Ave statusKey=1,location="",totalDocks=41,availableDocks=32,latitude=40.76132983124814,longitude=-73.97982001304626,availableBikes=8,stAddress2="",stAddress1="W 52 St & 6 Ave",statusValue="In Service" 1581533519000000000
citibikenyc,id=367,stationName=E\ 53\ St\ &\ Lexington\ Ave availableBikes=8,stAddress1="E 53 St & Lexington Ave",longitude=-73.97069431,latitude=40.75828065,stAddress2="",statusKey=1,location="",statusValue="In Service",totalDocks=34,availableDocks=24 1581533492000000000
citibikenyc,id=359,stationName=E\ 47\ St\ &\ Park\ Ave totalDocks=64,availableBikes=15,statusValue="In Service",location="",latitude=40.75510267,availableDocks=49,stAddress1="E 47 St & Park Ave",longitude=-73.97498696,statusKey=1,stAddress2="" 1581533535000000000
citibikenyc,id=304,stationName=Broadway\ &\ Battery\ Pl statusValue="In Service",availableDocks=11,stAddress1="Broadway & Battery Pl",statusKey=1,stAddress2="",location="",totalDocks=33,latitude=40.70463334,longitude=-74.01361706,availableBikes=22 1581533499000000000
```
Now, you can explore and query the Citi Bike data in InfluxDB. The example below is an InfluxQL query and visualization showing the number of available bikes over the past 15 minutes at the Broadway and West 29th Street station.
![Citi Bike visualization](/img/telegraf/1-13-citibike_query.png)

12
content/telegraf/v1.17/introduction/_index.md Normal file
View File

@ -0,0 +1,12 @@
---
title: Introducing Telegraf
description: Get up and running with Telegraf.
menu:
telegraf_1_17:
name: Introduction
weight: 20
---
To get up and running with Telegraf, complete the following tasks:
{{< children >}}

13
content/telegraf/v1.17/introduction/downloading.md Normal file
View File

@ -0,0 +1,13 @@
---
title: Download Telegraf
description: Download the latest version of Telegraf.
menu:
telegraf_1_17:
name: Download
weight: 10
parent: Introduction
---
Download the latest Telegraf release at the [InfluxData download page](https://portal.influxdata.com/downloads).

135
content/telegraf/v1.17/introduction/getting-started.md Normal file
View File

@ -0,0 +1,135 @@
---
title: Get started with Telegraf
description: Configure and start the Telegraf service.
aliases:
- /telegraf/v1.15/introduction/getting_started/
menu:
telegraf_1_17:
name: Get started
weight: 30
parent: Introduction
---
Use Telegraf to collect and write metrics into InfluxDB and other supported outputs.
To get up and running, do the following:
1. [Download and install Telegraf](#download-and-install-telegraf)
2. [Configure Telegraf](#configure-telegraf)
3. [Start Telegraf service](#start-telegraf-service)
## Download and install Telegraf
Follow the instructions in the Telegraf section on the [Downloads page](https://influxdata.com/downloads/).
> **Note:** Telegraf will start automatically using the default configuration when installed from a deb package.
## Configure Telegraf
### Configuration file location by installation type
* macOS [Homebrew](http://brew.sh/): `/usr/local/etc/telegraf.conf`
* Linux debian and RPM packages: `/etc/telegraf/telegraf.conf`
* Standalone Binary: see the next section for how to create a configuration file
> **Note:** You can also specify a remote URL endpoint to pull a configuration file from. See [Configuration file locations](/telegraf/v1.15/administration/configuration/#configuration-file-locations).
### Create and edit the configuration file
Before starting the Telegraf server, create or edit the initial configuration to specify your [inputs](/telegraf/v1.15/plugins/inputs/) (where the metrics come from) and [outputs](/telegraf/v1.15/plugins/outputs/) (where the metrics go). You can do this [several ways](/telegraf/v1.15/administration/configuration/).
The following example shows how to create a configuration file called `telegraf.conf` and specify two inputs (`cpu` and `mem`) with the `--input-filter` flag and specify InfluxDB as the output with the `--output-filter` flag.
```bash
telegraf -sample-config --input-filter cpu:mem --output-filter influxdb > telegraf.conf
```
`cpu` and `mem` reads metrics about the system's cpu usage and memory usage, and then output this data to InfluxDB.
## Start Telegraf service
Start the Telegraf service and direct it to the relevant configuration file or URL to pull a configuration file from a remote endpoint:
### macOS [Homebrew](http://brew.sh/)
```bash
telegraf --config telegraf.conf
```
### Linux (sysvinit and upstart installations)
```bash
sudo service telegraf start
```
### Linux (systemd installations)
```bash
systemctl start telegraf
```
## Results
Telegraf starts collecting and writing data to the specified output.
Returning to our sample configuration, we show what the `cpu` and `mem` data looks like in InfluxDB below.
Note that we used the default input and output configuration settings to get this data.
* List all [measurements](/influxdb/v1.4/concepts/glossary/#measurement) in the `telegraf` [database](/influxdb/v1.4/concepts/glossary/#database):
```
> SHOW MEASUREMENTS
name: measurements
------------------
name
cpu
mem
```
* List all [field keys](/influxdb/v1.4/concepts/glossary/#field-key) by measurement:
```
> SHOW FIELD KEYS
name: cpu
---------
fieldKey fieldType
usage_guest float
usage_guest_nice float
usage_idle float
usage_iowait float
usage_irq float
usage_nice float
usage_softirq float
usage_steal float
usage_system float
usage_user float
name: mem
---------
fieldKey fieldType
active integer
available integer
available_percent float
buffered integer
cached integer
free integer
inactive integer
total integer
used integer
used_percent float
```
* Select a sample of the data in the [field](/influxdb/v1.4/concepts/glossary/#field) `usage_idle` in the measurement `cpu_usage_idle`:
```bash
> SELECT usage_idle FROM cpu WHERE cpu = 'cpu-total' LIMIT 5
name: cpu
---------
time usage_idle
2016-01-16T00:03:00Z 97.56189047261816
2016-01-16T00:03:10Z 97.76305923519121
2016-01-16T00:03:20Z 97.32533433320835
2016-01-16T00:03:30Z 95.68857785553611
2016-01-16T00:03:40Z 98.63715928982245
```
Notice that the timestamps occur at rounded ten second intervals (that is, `:00`, `:10`, `:20`, and so on) - this is a configurable setting.
That's it! You ready to use Telegraf to collect metrics and write them to your output of choice.

389
content/telegraf/v1.17/introduction/installation.md Normal file
View File

@ -0,0 +1,389 @@
---
title: Install Telegraf
description: Install Telegraf on your operating system.
menu:
telegraf_1_17:
name: Install
weight: 20
parent: Introduction
---
This page provides directions for installing, starting, and configuring Telegraf.
## Requirements
Installation of the Telegraf package may require `root` or administrator privileges in order to complete successfully.
### Networking
Telegraf offers multiple service [input plugins](/telegraf/v1.17/plugins/inputs/) that may
require custom ports.
Modify port mappings through the configuration file (`telegraf.conf`).
For Linux distributions, this file is located at `/etc/telegraf` for default installations.
For Windows distributions, the configuration file is located in the directory where you unzipped the Telegraf ZIP archive.
The default location is `C:\InfluxData\telegraf`.
### NTP
Telegraf uses a host's local time in UTC to assign timestamps to data.
Use the Network Time Protocol (NTP) to synchronize time between hosts; if hosts' clocks
aren't synchronized with NTP, the timestamps on the data can be inaccurate.
## Installation
{{< tabs-wrapper >}}
{{% tabs %}}
[Ubuntu & Debian](#)
[RedHat & CentOS](#)
[SLES & openSUSE](#)
[FreeBSD/PC-BSD](#)
[macOS](#)
[Windows](#)
{{% /tabs %}}
<!---------- BEGIN Ubuntu & Debian ---------->
{{% tab-content %}}
Debian and Ubuntu users can install the latest stable version of Telegraf using the `apt-get` package manager.
**Ubuntu:** Add the InfluxData repository with the following commands:
{{< code-tabs-wrapper >}}
{{% code-tabs %}}
[wget](#)
[curl](#)
{{% /code-tabs %}}
{{% code-tab-content %}}
```bash
wget -qO- https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/lsb-release
echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
```
{{% /code-tab-content %}}
{{% code-tab-content %}}
```bash
curl -s https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/lsb-release
echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
```
{{% /code-tab-content %}}
{{< /code-tabs-wrapper >}}
**Debian:** Add the InfluxData repository with the following commands:
{{< code-tabs-wrapper >}}
{{% code-tabs %}}
[wget](#)
[curl](#)
{{% /code-tabs %}}
{{% code-tab-content %}}
```bash
# Before adding Influx repository, run this so that apt will be able to read the repository.
sudo apt-get update && sudo apt-get install apt-transport-https
# Add the InfluxData key
wget -qO- https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/os-release
test $VERSION_ID = "7" && echo "deb https://repos.influxdata.com/debian wheezy stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
test $VERSION_ID = "8" && echo "deb https://repos.influxdata.com/debian jessie stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
test $VERSION_ID = "9" && echo "deb https://repos.influxdata.com/debian stretch stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
test $VERSION_ID = "10" && echo "deb https://repos.influxdata.com/debian buster stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
```
{{% /code-tab-content %}}
{{% code-tab-content %}}
```bash
# Before adding Influx repository, run this so that apt will be able to read the repository.
sudo apt-get update && sudo apt-get install apt-transport-https
# Add the InfluxData key
curl -s https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/os-release
test $VERSION_ID = "7" && echo "deb https://repos.influxdata.com/debian wheezy stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
test $VERSION_ID = "8" && echo "deb https://repos.influxdata.com/debian jessie stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
test $VERSION_ID = "9" && echo "deb https://repos.influxdata.com/debian stretch stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
```
{{% /code-tab-content %}}
{{< /code-tabs-wrapper >}}
Then, install and start the Telegraf service:
```bash
sudo apt-get update && sudo apt-get install telegraf
sudo service telegraf start
```
Or if your operating system is using systemd (Ubuntu 15.04+, Debian 8+):
```
sudo apt-get update && sudo apt-get install telegraf
sudo systemctl start telegraf
```
**Install from a `.deb` file**:
To manually install the Debian package from a `.deb` file:
1. Download the latest Telegraf `.deb` release
from the Telegraf section of the [downloads page](https://influxdata.com/downloads/).
2. Run the following command (making sure to supply the correct version number for the downloaded file):
```sh
sudo sudo dpkg -i telegraf_1.17_amd64.deb
```
{{% telegraf/verify %}}
## Configuration
### Create a configuration file with default input and output plugins.
Every plugin will be in the file, but most will be commented out.
```
telegraf config > telegraf.conf
```
### Create a configuration file with specific inputs and outputs
```
telegraf --input-filter <pluginname>[:<pluginname>] --output-filter <outputname>[:<outputname>] config > telegraf.conf
```
For more advanced configuration details, see the
[configuration documentation](/telegraf/v1.17/administration/configuration/).
{{% /tab-content %}}
<!---------- BEGIN RedHat & CentOS ---------->
{{% tab-content %}}
For instructions on how to manually install the RPM package from a file, please see the [downloads page](https://influxdata.com/downloads/).
**RedHat and CentOS:** Install the latest stable version of Telegraf using the `yum` package manager:
```bash
cat <<EOF | sudo tee /etc/yum.repos.d/influxdb.repo
[influxdb]
name = InfluxDB Repository - RHEL \$releasever
baseurl = https://repos.influxdata.com/rhel/\$releasever/\$basearch/stable
enabled = 1
gpgcheck = 1
gpgkey = https://repos.influxdata.com/influxdb.key
EOF
```
Once repository is added to the `yum` configuration,
install and start the Telegraf service by running:
```bash
sudo yum install telegraf
sudo service telegraf start
```
Or if your operating system is using systemd (CentOS 7+, RHEL 7+):
```
sudo yum install telegraf
sudo systemctl start telegraf
```
{{% telegraf/verify %}}
## Configuration
### Create a configuration file with default input and output plugins.
Every plugin will be in the file, but most will be commented out.
```
telegraf config > telegraf.conf
```
### Create a configuration file with specific inputs and outputs
```
telegraf --input-filter <pluginname>[:<pluginname>] --output-filter <outputname>[:<outputname>] config > telegraf.conf
```
For more advanced configuration details, see the
[configuration documentation](/telegraf/v1.17/administration/configuration/).
{{% /tab-content %}}
<!---------- BEGIN SLES & openSUSE ---------->
{{% tab-content %}}
There are RPM packages provided by openSUSE Build Service for SUSE Linux users:
```bash
# add go repository
zypper ar -f obs://devel:languages:go/ go
# install latest telegraf
zypper in telegraf
```
{{% telegraf/verify %}}
## Configuration
### Create a configuration file with default input and output plugins.
Every plugin will be in the file, but most will be commented out.
```
telegraf config > telegraf.conf
```
### Create a configuration file with specific inputs and outputs
```
telegraf --input-filter <pluginname>[:<pluginname>] --output-filter <outputname>[:<outputname>] config > telegraf.conf
```
For more advanced configuration details, see the
[configuration documentation](/telegraf/v1.17/administration/configuration/).
{{% /tab-content %}}
<!---------- BEGIN FreeBSD/PC-BSD ---------->
{{% tab-content %}}
Telegraf is part of the FreeBSD package system.
It can be installed by running:
```bash
sudo pkg install telegraf
```
The configuration file is located at `/usr/local/etc/telegraf.conf` with examples in `/usr/local/etc/telegraf.conf.sample`.
{{% telegraf/verify %}}
## Configuration
### Create a configuration file with default input and output plugins.
Every plugin will be in the file, but most will be commented out.
```
telegraf config > telegraf.conf
```
### Create a configuration file with specific inputs and outputs
```
telegraf --input-filter <pluginname>[:<pluginname>] --output-filter <outputname>[:<outputname>] config > telegraf.conf
```
For more advanced configuration details, see the
[configuration documentation](/telegraf/v1.17/administration/configuration/).
{{% /tab-content %}}
<!---------- BEGIN macOS ---------->
{{% tab-content %}}
Users of macOS 10.8 and higher can install Telegraf using the [Homebrew](http://brew.sh/) package manager.
Once `brew` is installed, you can install Telegraf by running:
```bash
brew update
brew install telegraf
```
To have launchd start telegraf at next login:
```
ln -sfv /usr/local/opt/telegraf/*.plist ~/Library/LaunchAgents
```
To load telegraf now:
```
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.telegraf.plist
```
Or, if you don't want/need launchctl, you can just run:
```
telegraf -config /usr/local/etc/telegraf.conf
```
{{% telegraf/verify %}}
## Configuration
### Create a configuration file with default input and output plugins.
Every plugin will be in the file, but most will be commented out.
```
telegraf config > telegraf.conf
```
### Create a configuration file with specific inputs and outputs
```
telegraf --input-filter <pluginname>[:<pluginname>] --output-filter <outputname>[:<outputname>] config > telegraf.conf
```
For more advanced configuration details, see the
[configuration documentation](/telegraf/v1.17/administration/configuration/).
{{% /tab-content %}}
<!---------- BEGIN Windows ---------->
{{% tab-content %}}
## Installation
Download the Telegraf ZIP archive for Windows from the [InfluxData downloads page](https://portal.influxdata.com/downloads).
Extract the contents of the ZIP archive to `C:\Program Files\InfluxData\Telegraf`.
##### Verify the integrity of the downloaded Telegraf binary (optional)
To obtain the SHA256 hash for the Windows Telegraf download, use the following PowerShell command:
```powershell
CertUtil -hashfile <path to your download>/telegraf-1.17_windows_amd64.zip SHA256
```
Compare the output from this command to the hash listed on the downloads page to ensure the integrity of the download.
### Configure an input plugin
The Telegraf ZIP archive contains a default configuration file (`telegraf.conf`).
In this file, the input plugin for capturing basic [Windows system metrics](/telegraf/v1.17/plugins/#win_perf_counters) is already activated.
With this plugin, Telegraf monitors the following defined Windows Operating System objects:
- Processor
- LogicalDisk
- PhysicalDisk
- Network Interface
- System
- Memory
- Paging File
Telegraf can capture metrics and log information from a wide variety of sources.
For more advanced configuration details, see the [configuration documentation](/telegraf/v1.17/administration/configuration/).
### Configure an output plugin
Before you start the Telegraf agent, configure an output plugin to send data to InfluxDB.
Choose the appropriate plugin based on the version of InfluxDB you are using.
The `telegraf.conf` file included in the ZIP archive contains sections for configuring
both the [InfluxDB v1](/telegraf/v1.17/plugins/#influxdb) and
[InfluxDB v2](/telegraf/v1.17/plugins/#influxdb_v2) output plugins.
#### Writing data to InfluxDB 1.x
Open `telegraf.conf` in a text editor and fill in the `database` field under `[[outputs.influxdb]]`.
#### Writing data to InfluxDB 2.0
Open `telegraf.conf` in a text editor and comment out the InfluxDB v1 plugin
by placing a `#` in front of `[[outputs.influxdb]]`.
Then remove the `#` in front of `[[outputs.influxdb_v2]]`.
For detailed instructions on configuring Telegraf to write to InfluxDB 2.0, see
[Enable and configure the InfluxDB v2 output plugin](/{{< latest "influxdb" "v2" >}}/write-data/use-telegraf/manual-config/#enable-and-configure-the-influxdb-v2-output-plugin).
### Start the agent
Once configured, run the following commands in PowerShell to begin sending metrics with Telegraf:
```powershell
> cd C:\Program Files\InfluxData\Telegraf # path to extracted Telegraf directory
> .\telegraf.exe -config <path_to_telegraf.conf>
```
## Install Telegraf as a Windows Service
See [Running Telegraf as a Windows service](/telegraf/v1.17/administration/windows_service).
{{< /tab-content >}}
{{< /tabs-wrapper >}}

50
content/telegraf/v1.17/plugins.md Normal file
View File

@ -0,0 +1,50 @@
---
title: Telegraf plugins
description: >
Telegraf is a plugin-driven agent that collects, processes, aggregates, and writes metrics.
It supports four categories of plugins including input, output, aggregator, and processor.
View and search all available Telegraf plugins.
menu:
telegraf_1_17:
weight: 40
weight: 6
aliases:
- /telegraf/v1.16/plugins/plugins-list/
- /telegraf/v1.16/plugins/aggregators/
- /telegraf/v1.16/plugins/inputs/
- /telegraf/v1.16/plugins/outputs/
- /telegraf/v1.16/plugins/processors/
---
Telegraf is a plugin-driven agent that collects, processes, aggregates, and writes metrics.
It supports four categories of plugins including input, output, aggregator, and processor.
{{< telegraf/filters >}}
**Jump to:**
- [Input plugins](#input-plugins)
- [Output plugins](#output-plugins)
- [Aggregator plugins](#aggregator-plugins)
- [Processor plugins](#processor-plugins)
## Input plugins
Telegraf input plugins are used with the InfluxData time series platform to collect
metrics from the system, services, or third party APIs.
{{< telegraf/plugins type="input" >}}
## Output plugins
Telegraf processor plugins write metrics to various destinations.
{{< telegraf/plugins type="output" >}}
## Aggregator plugins
Telegraf aggregator plugins create aggregate metrics (for example, mean, min, max, quantiles, etc.)
{{< telegraf/plugins type="aggregator" >}}
## Processor plugins
Telegraf output plugins transform, decorate, and filter metrics.
{{< telegraf/plugins type="processor" >}}

49
content/telegraf/v1.9/concepts/aggregator_processor_plugins.md
View File

@ -10,37 +10,24 @@ menu:
Besides the input plugins and output plugins, Telegraf includes aggregator and processor plugins, which are used to aggregate and process metrics as they pass through Telegraf.
```
┌───────────┐
│ │
│ CPU │───┐
│ │ │
└───────────┘ │
│
┌───────────┐ │ ┌───────────┐
│ │ │ │ │
│ Memory │───┤ ┌──▶│ InfluxDB │
│ │ │ │ │ │
└───────────┘ │ ┌─────────────┐ ┌─────────────┐ │ └───────────┘
│ │ │ │Aggregate │ │
┌───────────┐ │ │Process │ │ - mean │ │ ┌───────────┐
│ │ │ │ - transform │ │ - quantiles │ │ │ │
│ MySQL │───┼──▶│ - decorate │────▶│ - min/max │───┼──▶│ File │
│ │ │ │ - filter │ │ - count │ │ │ │
└───────────┘ │ │ │ │ │ │ └───────────┘
│ └─────────────┘ └─────────────┘ │
┌───────────┐ │ │ ┌───────────┐
│ │ │ │ │ │
│ SNMP │───┤ └──▶│ Kafka │
│ │ │ │ │
└───────────┘ │ └───────────┘
│
┌───────────┐ │
│ │ │
│ Docker │───┘
│ │
└───────────┘
```
{{< diagram >}}
graph TD
Process[Process<br/> - transform<br/> - decorate<br/> - filter]
Aggregate[Aggregate<br/> - transform<br/> - decorate<br/> - filter]
CPU --> Process
Memory --> Process
MySQL --> Process
SNMP --> Process
Docker --> Process
Process --> Aggregate
Aggregate --> InfluxDB
Aggregate --> File
Aggregate --> Kafka
style Process text-align:left
style Aggregate text-align:left
{{< /diagram >}}
**Processor plugins** process metrics as they pass through and immediately emit
results based on the values they process. For example, this could be printing

1
data/influxdb_urls.yml
View File

@ -38,3 +38,4 @@ cloud:
- name: East US (Virginia)
location: Virginia, USA
url: https://eastus-1.azure.cloud2.influxdata.com

4
data/products.yml
View File

@ -20,8 +20,8 @@ telegraf:
name: Telegraf
namespace: telegraf
list_order: 4
versions: [v1.9, v1.10, v1.11, v1.12, v1.13, v1.14, v1.15, v1.16]
latest: v1.16
versions: [v1.9, v1.10, v1.11, v1.12, v1.13, v1.14, v1.15, v1.16, v1.17]
latest: v1.17
chronograf:
name: Chronograf

44
data/telegraf_plugins.yml
View File

@ -687,6 +687,13 @@ input:
introduced: 1.16.0
tags: [linux, macos, windows, data-stores]
- name: Intel Powerstat
id: intel_powerstat
description: |
The Intel Powerstat input plugin collects information provided by the monitoring features of Intel Powerstat.
introduced: 1.17.0
tags: [linux]
- name: Intel RDT
id: intel_rdt
description: |
@ -1407,6 +1414,13 @@ input:
introduced: 0.10.4
tags: [linux, macos, windows, data-stores]
- name: Riemann Listener
id: riemann_listener
description: |
The Riemann Listener input plugin listens for messages Riemann clients using Riemann-Protobuff format.
introduced: 1.17.0
tags: [linux, macos, windows]
- name: Salesforce
id: salesforce
description: |
@ -1965,6 +1979,13 @@ output:
introduced: 0.2.0
tags: [linux, macos, windows, cloud]
- name: Logz.io
id: logzio
description: |
The Logz.io output plugin sends metrics to Logz.io over HTTPs.
introduced: 1.17.0
tags: [linux, macos, windows]
- name: Microsoft Azure Application Insights
id: application_insights
description: |
@ -2038,13 +2059,27 @@ output:
introduced: 0.1.9
tags: [linux, macos, windows, data-stores]
- name: Prometheus Text-Based Format
id: prometheus
description: |
The Prometheus parser plugin is used internally in the Prometheus input plugin or the HTTP Listener v2 input plugin to simulate Pushgateway.
introduced: 1.17.0
tags: [linux, macos, windows, applications]
- name: Prometheus Client
id: prometheus_client
description: |
The Prometheus Client output plugin starts a [Prometheus](https://prometheus.io/) Client,
it exposes all metrics on `/metrics` (default) to be polled by a Prometheus server.
introduced: 0.2.1
tags: [linux, macos, windows, applications, data-stores]
tags: [linux, macos, windows, applications]
- name: Prometheus Remote Write
id: prometheusremotewrite
description: |
The Prometheus Remote Write data format output plugin converts metrics into the Prometheus protobuf exposition format.
introduced: 1.17.0
tags: [linux, macos, windows, applications]
- name: Riemann
id: riemann
@ -2063,6 +2098,7 @@ output:
deprecated: 1.2.1
tags: [linux, macos, windows, applications]
- name: Socket Writer
id: socket_writer
description: |
@ -2119,6 +2155,12 @@ output:
introduced: 1.5.0
tags: [linux, macos, windows, applications, cloud]
- name: Yandex Cloud Monitoring
id: yandex_cloud_monitoring
description: |
The Yandex Cloud Monitoring output plugin sends custom metrics to Yandex Cloud Monitoring.
introduced: 1.17.0
tags: [linux, macos, windows]
# %%%% %%%% %%%% %%%%% %%%%%% %%%% %%%% %%%%%% %%%% %%%%% %%%% #
# %% %% %% %% %% %% %% %% %% %% %% %% %% %% %% %% #

2
deploy/edge.js
View File

@ -5,7 +5,7 @@ const path = require('path');
const latestVersions = {
'influxdb': 'v2.0',
'influxdbv2': 'v2.0',
'telegraf': 'v1.16',
'telegraf': 'v1.17',
'chronograf': 'v1.8',
'kapacitor': 'v1.5',
'enterprise': 'v1.8',

19
layouts/partials/footer/javascript.html
View File

@ -19,3 +19,22 @@
<!-- Load footer.js -->
<script type="text/javascript" src="{{ $footerjs.RelPermalink }}" ></script>
{{ if .Page.HasShortcode "diagram" }}
<!-- Load mermaid.js for diagrams -->
<script src="https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.min.js"></script>
<script>
mermaid.initialize({
startOnLoad:true,
mermaid: {
callback:function(id) {
$('.mermaid').css('opacity', 1);
}
},
themeVariables: {
fontFamily: "Rubik",
fontSize: '18px',
}
})
</script>
{{ end }}

3
layouts/shortcodes/diagram.html Normal file
View File

@ -0,0 +1,3 @@
<div class="mermaid">
{{.Inner}}
</div>