> 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/axiom.md).

# Axiom

The Axiom destination exports telemetry from a Bindplane pipeline to [Axiom](https://axiom.co/) over OTLP/HTTP. It sends logs and traces to the Axiom dataset named in the configuration. Metrics support is staged in the resource type for a future Axiom release and is not yet exported.

### Supported Telemetry

| Metrics | Logs | Traces |
| ------- | ---- | ------ |
|         | ✓    | ✓      |

### Prerequisites

* An [Axiom account](https://axiom.co/).
* A dataset to receive the telemetry. Create one under **Settings > Datasets** in the Axiom UI.
* An Axiom API token with permission to ingest into that dataset. Create a basic API token under **Settings > API tokens** and grant it access to the target dataset. Copy the token when it is shown; it is not displayed again. See [Authenticate API requests with tokens](https://axiom.co/docs/reference/tokens).

Telemetry is sent to the Axiom OTLP endpoint `https://api.axiom.co`. See [Send OpenTelemetry data to Axiom](https://axiom.co/docs/send-data/opentelemetry).

### Configuration

<figure><img src="/files/G0X5knMyLQU4Ckq3ZQVc" alt="Bindplane docs - Axiom - image 1"><figcaption></figcaption></figure>

**Connection**

| Parameter             | Type               | Required | Default      | Description                                                                                                          |
| --------------------- | ------------------ | -------- | ------------ | -------------------------------------------------------------------------------------------------------------------- |
| Choose Telemetry Type | Telemetry Selector | No       | Logs, Traces | Which signals to export. Valid values are Logs, Metrics, and Traces. Metrics is reserved for a future Axiom release. |
| Bearer Token          | String             | Yes      | *(empty)*    | Axiom API token used to authenticate ingest requests. Sent as the `Authorization: Bearer` header. Sensitive value.   |
| Dataset Name          | String             | Yes      | *(empty)*    | Axiom dataset that receives the telemetry. Sent as the `x-axiom-dataset` header.                                     |

**Advanced**

| Parameter     | Type    | Required | Default | Description                                                           |
| ------------- | ------- | -------- | ------- | --------------------------------------------------------------------- |
| Timeout       | Integer | Yes      | `30`    | Timeout in seconds for sending a batch to Axiom.                      |
| Drop Raw Copy | Boolean | No       | `true`  | When enabled, drops the raw log copy stored in `log.record.original`. |

**Retry on Failure**

| Parameter               | Type    | Required | Default | Description                                                                                                                            |
| ----------------------- | ------- | -------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| Enable Retry on Failure | Boolean | No       | `true`  | Resend telemetry that failed to transmit.                                                                                              |
| Initial Interval        | Integer | No       | `5`     | Seconds to wait after the first failure before retrying. Applies when retry on failure is enabled.                                     |
| Max Interval            | Integer | No       | `30`    | Upper bound in seconds on the backoff interval. Applies when retry on failure is enabled.                                              |
| Max Elapsed Time        | Integer | No       | `300`   | Maximum seconds spent retrying a batch before giving up, to avoid a never-ending retry loop. Applies when retry on failure is enabled. |

**Sending Queue**

| Parameter                 | Type      | Required | Default                         | Description                                                                                                                                                                                                  |
| ------------------------- | --------- | -------- | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Enable Sending Queue      | Boolean   | No       | `true`                          | Buffer telemetry before sending so data is not lost during a temporary network outage.                                                                                                                       |
| Number of Consumers       | Integer   | No       | `10`                            | Number of consumers that dequeue batches. Applies when the sending queue is enabled.                                                                                                                         |
| Queue Size                | Integer   | No       | `5000`                          | Maximum number of batches held in memory before dropping. Applies when the sending queue is enabled.                                                                                                         |
| Enable Persistent Queuing | Boolean   | No       | `true`                          | Buffer telemetry to disk so data survives network outages and collector restarts. Applies when the sending queue is enabled.                                                                                 |
| Persistent Queue Storage  | Extension | Yes      | `file_storage_persistent_queue` | Storage extension backing the persistent queue. Applies when both the sending queue and persistent queuing are enabled. See [persistent queue](/configuration/bindplane-otel-collector/persistent-queue.md). |

### Examples

Export logs and traces to the `bindplane` dataset in Axiom, retrying failed sends and buffering to disk.

```yaml
apiVersion: bindplane.observiq.com/v1
kind: Destination
metadata:
  name: axiom
spec:
  type: axiom
  parameters:
    - name: telemetry_types
      value:
        - Logs
        - Traces
    - name: bearer_token
      value: xaat-your-axiom-token
    - name: dataset_name
      value: bindplane
    - name: retry_on_failure_enabled
      value: true
    - name: sending_queue_enabled
      value: true
    - name: persistent_queue_enabled
      value: true
```

### Configuration Tips

* Create a basic API token scoped to only the target dataset rather than a personal access token, following least privilege.
* Telemetry is compressed with gzip before being sent to Axiom; no additional compression configuration is needed.
* Leave persistent queuing enabled so buffered telemetry survives a collector restart. The default storage extension writes to `${OIQ_OTEL_COLLECTOR_HOME}/storage`.

### Troubleshooting

#### Authentication failures (401/403)

Symptoms: ingest requests are rejected and no data reaches the dataset.

Solutions:

1. Confirm the Bearer Token is a valid Axiom API token and has not expired.
2. Confirm the token grants ingest access to the dataset named in Dataset Name.

#### Data not appearing in the dataset

Symptoms: requests succeed but the expected dataset shows no data.

Solutions:

1. Verify Dataset Name exactly matches an existing Axiom dataset; Axiom does not auto-create datasets for ingest.
2. Confirm the Choose Telemetry Type selection includes the signals you are sending.

#### Dropped telemetry under load or outage

Symptoms: gaps in data during network issues or collector restarts.

Solutions:

1. Keep the sending queue enabled and raise Queue Size if memory allows.
2. Enable persistent queuing so buffered batches survive restarts.

### Standalone Destination

```yaml
apiVersion: bindplane.observiq.com/v1
kind: Destination
metadata:
  name: axiom
spec:
  type: axiom
  parameters:
    - name: telemetry_types
      value:
        - Logs
        - Traces
    - name: bearer_token
      value: xaat-your-axiom-token
    - name: dataset_name
      value: bindplane
    - name: timeout
      value: 30
    - name: persistent_queue_storage_extension
      value:
        type: file_storage_persistent_queue
        parameters:
          - name: persistent_queue_directory
            value: ${OIQ_OTEL_COLLECTOR_HOME}/storage
          - name: timeout
            value: 1
          - name: persistent_queue_fsync
            value: true
```

### Related Resources

* [OTLP/HTTP Exporter — OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector/blob/main/exporter/otlphttpexporter/README.md)
* [Send OpenTelemetry data to Axiom](https://axiom.co/docs/send-data/opentelemetry)
* [Authenticate API requests with tokens — Axiom](https://axiom.co/docs/reference/tokens)


---

# 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/axiom.md?ask=<question>&goal=<endgoal>
```

`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.