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

# Oodle AI

The Oodle AI destination exports logs, metrics, and traces from a Bindplane pipeline to an Oodle instance over OTLP/HTTP. Telemetry is sent to per-signal Oodle ingest endpoints derived from your instance name, authenticated with an API token. Ingested metrics are converted to Prometheus format on the Oodle side.

### Supported Telemetry

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

### Prerequisites

* An Oodle account with an active instance.
* Your Oodle instance name. It forms the ingest endpoint hostnames (`<instance>.collector.oodle.ai` for metrics and traces, `<instance>-logs.collector.oodle.ai` for logs).
* An Oodle API token for authentication. The token is sent in the `X-API-KEY` header.
* Outbound HTTPS (port 443) connectivity from the collector to `*.collector.oodle.ai`.

In the Oodle UI, open Settings and select Connect on the OpenTelemetry tile to view your instance endpoint and API key. See the Oodle OTLP ingest docs for [metrics](https://docs.oodle.ai/integrations/metrics/otel/), [logs](https://docs.oodle.ai/integrations/logs/otel), and [traces](https://docs.oodle.ai/integrations/traces/otel).

### Configuration

<figure><img src="/files/ib7NuXYxuUUcjtYq044k" alt="Bindplane docs - Oodle AI - image 1"><figcaption></figcaption></figure>

**Connection**

| Parameter             | Type               | Required | Default                     | Description                                                                                                                     |
| --------------------- | ------------------ | -------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Choose Telemetry Type | Telemetry Selector | Yes      | `Logs`, `Metrics`, `Traces` | Which signals to export. Each selected signal is routed to its corresponding Oodle ingest endpoint.                             |
| Oodle Instance Name   | String             | Yes      | *(empty)*                   | The Oodle instance to send telemetry to. Used to build the ingest endpoint hostnames and sent in the `X-OODLE-INSTANCE` header. |
| API Token             | String             | Yes      | *(empty)*                   | API token for authenticating with the Oodle API. Sensitive value, sent in the `X-API-KEY` header.                               |

**Advanced**

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

**Retry on Failure**

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

**Sending Queue**

| Parameter                 | Type      | Required | Default                         | Description                                                                                                                          |
| ------------------------- | --------- | -------- | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| Enable Sending Queue      | Boolean   | No       | `true`                          | Buffer telemetry temporarily before sending to help avoid loss during a temporary network outage.                                    |
| Number of Consumers       | Integer   | No       | `10`                            | Number of consumers that dequeue batches. Relevant when the sending queue is enabled.                                                |
| Queue Size                | Integer   | No       | `5000`                          | Maximum number of batches kept in memory before dropping. Relevant when the sending queue is enabled.                                |
| Enable Persistent Queuing | Boolean   | No       | `true`                          | Buffer telemetry to disk so it is not lost during network outages or collector restarts. Relevant when the sending queue is enabled. |
| Persistent Queue Storage  | Extension | Yes      | `file_storage_persistent_queue` | The storage extension used for the persistent queue. Relevant when both the sending queue and persistent queuing are enabled.        |

### Examples

This example exports all three signals to the `my-instance` Oodle instance, with retry, the in-memory sending queue, and persistent (on-disk) queuing enabled for resilience across network outages and collector restarts.

```yaml
apiVersion: bindplane.observiq.com/v1
kind: Destination
metadata:
  name: oodle-ai
spec:
  type: oodle
  parameters:
    - name: telemetry_types
      value:
        - Logs
        - Metrics
        - Traces
    - name: oodle_instance_name
      value: my-instance
    - name: api_token
      value: ${OODLE_API_TOKEN}
    - name: timeout
      value: 30
    - name: drop_raw_copy
      value: true
    - name: retry_on_failure_enabled
      value: true
    - name: sending_queue_enabled
      value: true
    - name: persistent_queue_enabled
      value: true
```

### Configuration Tips

* Set the instance name to your exact Oodle instance identifier. It builds the ingest hostnames (`<instance>.collector.oodle.ai`, `<instance>-logs.collector.oodle.ai`) and is sent as `X-OODLE-INSTANCE`, so a mismatch routes data to the wrong endpoint or fails authentication.
* Leave Drop Raw Copy enabled to avoid shipping the duplicated `log.record.original` field, which reduces log volume. Disable it only when you need the original raw record downstream.
* For production, keep the sending queue and persistent queuing enabled so telemetry survives collector restarts and network outages. Ensure the persistent queue storage directory exists and is writable.

### Troubleshooting

**401 Unauthorized / authentication errors**

Symptom: Telemetry is rejected and the collector logs show 401 or authentication errors.

Solution: Verify the API token is correct, current, and entered without surrounding whitespace. Confirm the instance name matches your Oodle instance, since it is sent as `X-OODLE-INSTANCE`.

**Connection refused or timeout**

Symptom: Batches fail to send with connection-refused or timeout errors.

Solution: Confirm outbound HTTPS to `*.collector.oodle.ai` on port 443 is permitted by firewalls and proxies. Verify the instance name resolves to the expected ingest hostname.

**Telemetry dropped after restarts or outages**

Symptom: Data is lost when the collector restarts or the network is briefly unavailable.

Solution: Enable the sending queue and persistent queuing, and confirm the persistent queue storage directory exists with write permission. Enable retry on failure to absorb transient errors.

### Standalone Destination

```yaml
apiVersion: bindplane.observiq.com/v1
kind: Destination
metadata:
  name: oodle-ai
spec:
  type: oodle
  parameters:
    - name: telemetry_types
      value:
        - Logs
        - Metrics
        - Traces
    - name: oodle_instance_name
      value: my-instance
    - name: api_token
      value: ${OODLE_API_TOKEN}
```

### Related Resources

* [OTLP/HTTP Exporter (otlphttpexporter)](https://github.com/open-telemetry/opentelemetry-collector/blob/main/exporter/otlphttpexporter/README.md)
* [Oodle OTLP ingest for metrics](https://docs.oodle.ai/integrations/metrics/otel/)
* [Oodle OTLP ingest for logs](https://docs.oodle.ai/integrations/logs/otel)
* [Oodle OTLP ingest for traces](https://docs.oodle.ai/integrations/traces/otel)


---

# 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/oodle-ai.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.
