> For the complete documentation index, see [llms.txt](https://docs.bindplane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bindplane.com/integrations/destinations/influxdb.md). # InfluxDB The InfluxDB destination writes metrics, logs, and traces from a Bindplane pipeline to an InfluxDB 2.x system using the InfluxDB v2 write API (`/api/v2/write`). Telemetry is written to a named organization and bucket. Metrics are written using the Telegraf Prometheus schema; spans and logs are mapped to InfluxDB measurements using configurable tag dimensions. ### Supported Telemetry | Metrics | Logs | Traces | | ------- | ---- | ------ | | ✓ | ✓ | ✓ | ### Prerequisites You need a reachable InfluxDB 2.x server (InfluxDB OSS v2 or InfluxDB Cloud) and the following: * **Organization** — the name of the InfluxDB organization that owns the target bucket. * **Bucket** — a pre-created bucket to write telemetry to. * **API token** — a token with write permission to the target bucket. Create one from the InfluxDB UI under **Load Data > API Tokens**, or with `influx auth create -o --write-bucket `. See [Create an API token in InfluxDB](https://docs.influxdata.com/influxdb/v2/admin/tokens/create-token/). * **Network reachability** — the collector must reach the InfluxDB host and port (default `8086`) over HTTP or HTTPS. To create the bucket, see [Create a bucket in InfluxDB](https://docs.influxdata.com/influxdb/v2/admin/buckets/create-bucket/). ### Configuration
Bindplane docs - InfluxDB - image 1
**Connection** | Parameter | Type | Required | Default | Description | | --------------------- | ------------------ | -------- | --------------- | ------------------------------------------------------------------------------------------------- | | Choose Telemetry Type | Telemetry Selector | No | `["Metrics"]` | Which signals to send to InfluxDB: Logs, Metrics, Traces. | | InfluxDB Host | String | Yes | `localhost` | The IP address or hostname of the InfluxDB server to send telemetry to. | | InfluxDB Port | Integer | Yes | `8086` | The port that the InfluxDB server is listening on for telemetry data. Range 1–65535. | | API Path | String | Yes | `/api/v2/write` | URL path to send telemetry to. | | Organization | String | Yes | *(empty)* | Name of the InfluxDB organization that the target bucket belongs to. | | Bucket | String | Yes | *(empty)* | Name of the InfluxDB bucket to write telemetry to. | | Authentication Token | String | No | *(empty)* | The authentication token used to authenticate with InfluxDB. Sensitive value; stored as a secret. | **Schema and Dimensions** | Parameter | Type | Required | Default | Description | | --------------- | -------------------------------------------------------- | -------- | ------------------------------- | ------------------------------------------------------------------------------------------- | | Metrics Schema | Enum: `telegraf-prometheus-v1`, `telegraf-prometheus-v2` | No | `telegraf-prometheus-v1` | The metrics schema to use when writing metrics to InfluxDB. Shown when Metrics is selected. | | Span Dimensions | Strings | No | `["service.name", "span.name"]` | Span attributes to use as InfluxDB tags. Shown when Traces is selected. | | Log Dimensions | Strings | No | `["service.name"]` | Log attributes to use as InfluxDB tags. Shown when Logs is selected. | **Advanced** | Parameter | Type | Required | Default | Description | | ----------------------- | -------------------- | -------- | ------- | -------------------------------------------------------------------------------------------- | | Additional HTTP Headers | Map | No | `{}` | Additional headers to attach to each HTTP request. | | Compression | Enum: `none`, `gzip` | No | `gzip` | Compression algorithm to use when sending telemetry to InfluxDB. | | Drop Raw Copy | Boolean | No | `true` | When enabled, the raw copy of the log stored in `log.record.original` is dropped. Logs only. | **Advanced — TLS** | Parameter | Type | Required | Default | Description | | --------------------------------- | ------- | -------- | --------- | ------------------------------------------------------------------------------------------------------------------------------- | | Enable TLS | Boolean | No | `false` | Configure advanced TLS settings. When enabled, the endpoint uses `https`. | | Skip TLS Certificate Verification | Boolean | No | `false` | Skip TLS certificate verification. Shown when TLS is enabled. | | TLS Certificate Authority File | String | No | *(empty)* | Certificate authority used to validate TLS certificates. Shown when TLS is enabled and certificate verification is not skipped. | **Advanced — Retry on Failure** | Parameter | Type | Required | Default | Description | | ----------------------- | ------- | -------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | Enable Retry on Failure | Boolean | No | `true` | Attempt to resend telemetry data that has failed to be transmitted to the destination. | | Initial interval | Integer | No | `5` | Time (in seconds) to wait after the first failure before retrying. Shown when retry is enabled. | | Max interval | Integer | No | `30` | The upper bound (in seconds) on backoff. Shown when retry is enabled. | | Max elapsed time | Integer | No | `300` | The maximum amount of time (in seconds) spent trying to send a batch, used to avoid a never-ending retry loop. Shown when retry is enabled. | **Advanced — Sending Queue** | Parameter | Type | Required | Default | Description | | ------------------------- | --------- | -------- | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Enable Sending Queue | Boolean | No | `true` | Buffer telemetry data temporarily before sending to help ensure telemetry data is not lost during a temporary network outage. | | Number of Consumers | Integer | No | `10` | Number of consumers that dequeue batches. Shown when the sending queue is enabled. | | Queue Size | Integer | No | `5000` | Maximum number of batches kept in memory before dropping. Shown when the sending queue is enabled. | | Enable Persistent Queuing | Boolean | No | `true` | Buffer telemetry data to disk before sending to help ensure data is not lost during network outages or collector restarts. Shown when the sending queue is enabled. | | Persistent Queue Storage | Extension | Yes | `file_storage_persistent_queue` | The storage extension to use for the persistent queue. Shown when the sending queue and persistent queuing are enabled. | ### Examples Write metrics to an InfluxDB OSS v2 instance running on the same host as the collector, into the `otel` bucket owned by the `my-org` organization. ```yaml apiVersion: bindplane.observiq.com/v1 kind: Destination metadata: name: influxdb spec: type: influxdb parameters: - name: telemetry_types value: - Metrics - name: host value: localhost - name: port value: 8086 - name: api_path value: /api/v2/write - name: org value: my-org - name: bucket value: otel - name: token value: - name: metrics_schema value: telegraf-prometheus-v1 - name: compression value: gzip ``` ### Configuration Tips * Match the **Metrics Schema** to how you query the data downstream. `telegraf-prometheus-v1` assigns each metric its own measurement from the metric name; `telegraf-prometheus-v2` stores all metric points in a single `prometheus` measurement. * Leave **Compression** at `gzip` for remote InfluxDB endpoints to reduce egress; set it to `none` only when sending to a local instance where CPU is the constraint. * Keep **Enable Persistent Queuing** on for production so buffered telemetry survives collector restarts. The persistent queue requires a storage extension, which Bindplane provisions by default at `${OIQ_OTEL_COLLECTOR_HOME}/storage`. ### Troubleshooting #### Writes are rejected with 401 or 403 Symptoms: telemetry is not written and the collector logs HTTP 401 or 403 responses from InfluxDB. Solutions: 1. Confirm the **Authentication Token** is valid and has write permission to the target bucket. 2. Confirm the **Organization** and **Bucket** names match exactly what exists in InfluxDB (names, not IDs). #### Connection refused or TLS errors Symptoms: the collector cannot reach InfluxDB, or reports a certificate validation failure. Solutions: 1. Verify the **InfluxDB Host** and **InfluxDB Port** are reachable from the collector and that the API Path is `/api/v2/write`. 2. For HTTPS endpoints, enable **Enable TLS**. If the server uses a private CA, set **TLS Certificate Authority File**; only use **Skip TLS Certificate Verification** for testing. #### Telemetry is dropped under load or during outages Symptoms: gaps in data in InfluxDB during network instability or bursts. Solutions: 1. Keep **Enable Sending Queue** and **Enable Persistent Queuing** on so data is buffered to disk rather than dropped. 2. If the queue fills (the configured **Queue Size** is exceeded), increase the queue size or the **Number of Consumers**, and confirm retry is enabled. ### Standalone Destination ```yaml apiVersion: bindplane.observiq.com/v1 kind: Destination metadata: name: influxdb spec: type: influxdb parameters: - name: telemetry_types value: - Metrics - name: host value: localhost - name: port value: 8086 - name: api_path value: /api/v2/write - name: org value: my-org - name: bucket value: otel - name: token value: ``` ### Related Resources * [OpenTelemetry InfluxDB Exporter (`influxdbexporter`)](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/influxdbexporter/README.md) * [Create an API token in InfluxDB](https://docs.influxdata.com/influxdb/v2/admin/tokens/create-token/) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.bindplane.com/integrations/destinations/influxdb.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.