> 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/observe.md). # Observe The Observe destination exports metrics, logs, and traces from a Bindplane pipeline to [Observe](https://www.observeinc.com/). Telemetry is sent to your account's customer-specific OTLP/HTTP ingest endpoint (`https://.collect.observeinc.com/v2/otel`) using a Datastream token for authentication. ### Supported Telemetry | Metrics | Logs | Traces | | ------- | ---- | ------ | | ✓ | ✓ | ✓ | ### Prerequisites You need an Observe tenant, its OTLP/HTTP ingest endpoint, and a Datastream ingest token: * **Observe tenant** — an active Observe account. Your **Customer ID** is the 12-digit number that identifies your account and appears in the URL you use to log into Observe. * **Ingest endpoint** — Observe exposes a customer-specific ingest host at `https://.collect.observeinc.com`. This destination posts OTLP/HTTP to the `/v2/otel` path. The endpoint is derived automatically from your Customer ID, so no endpoint field is exposed. * **Ingest token** — a token with write-access to a Datastream in your Observe account. Create the token from the Observe UI and supply it in the destination's **Token** field. The token is sent as a `Bearer` credential in the `Authorization` header. By default the Observe platform does not surface metrics and logs. Enable them by opening **Applications**, choosing **Manage** on the OpenTelemetry application, and toggling support for metrics and logs. See Observe's [Endpoints](https://docs.observeinc.com/en/latest/content/data-ingestion/endpoints.html) documentation for details on the Customer ID, ingest token creation, and authentication. ### Configuration
Bindplane docs - Observe - image 1
**Connection** | Parameter | Type | Required | Default | Description | | ----------- | ------------------ | -------- | --------- | ------------------------------------------------------------------------------------------------------------------------------- | | Customer ID | String | Yes | *(empty)* | A 12-digit number that identifies your account and is displayed in the URL you use to log into Observe. | | Token | string (sensitive) | Yes | *(empty)* | A token with write-access to a Datastream in your Observe account. Sent as a `Bearer` credential in the `Authorization` header. | **Advanced** | Parameter | Type | Required | Default | Description | | ------------------------- | --------- | -------- | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Drop Raw Copy | Boolean | No | `true` | When enabled, the raw copy of the log stored in `log.record.original` is dropped. Applies to logs only. | | 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. Applies when Retry on Failure is enabled. | | Max interval | Integer | No | `30` | The upper bound (in seconds) on backoff. Applies when Retry on Failure 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. Applies when Retry on Failure is enabled. | | Enable Sending Queue | Boolean | No | `true` | Buffer telemetry data temporarily before sending to help ensure telemetry data is not lost in case of 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 kept in memory before dropping. Applies when the Sending Queue is enabled. | | Enable Persistent Queuing | Boolean | No | `true` | Buffer telemetry data to disk before sending to help ensure telemetry data is not lost in case of network outages or collector restarts. Applies when the Sending Queue is enabled. | | Persistent Queue Storage | extension | Yes | `file_storage_persistent_queue` | The storage extension to use for the persistent queue. Applies when the Sending Queue and Persistent Queuing are enabled. | Compression is set to `gzip` for all signals. {% hint style="info" %} **NOTE** The Observe platform relies on the "Timestamp" field for indexing logs. You can use the\ [Parse Timestamp processor](/integrations/processors/parse-timestamp.md) to parse your application's timestamps if they are not already parsed by your configured sources. Most Bindplane sources will handle timestamps correctly without additional configuration. {% endhint %} ### Examples Forward metrics, traces, and logs to the account `165866210346` using a Datastream token created in the Observe web interface. Retry, sending queue, and persistent queue use their defaults. ```yaml apiVersion: bindplane.observiq.com/v1 kind: Destination metadata: name: observe spec: type: observeinc parameters: - name: customer_id value: '165866210346' - name: token value: (sensitive) ``` ### Configuration Tips * The ingest endpoint is built from the Customer ID, so confirm the 12-digit value matches the one in your Observe login URL. A wrong Customer ID resolves to a different (or non-existent) tenant host. * Leave persistent queuing enabled for production. It buffers telemetry to disk so data survives collector restarts and longer network outages, not just brief ones. * Keep `Drop Raw Copy` enabled unless you specifically need the unparsed log in `log.record.original`. Dropping it reduces ingest volume in Observe. ### Troubleshooting **Symptom:** Exports are rejected with a 401 or 403 authentication error. **Solution:** Verify the Token has write-access to a Datastream and that it is current. The token is sent as `Authorization: Bearer `; a revoked or mistyped token fails authentication. **Symptom:** Data is not arriving and the collector logs DNS or connection-refused errors for `*.collect.observeinc.com`. **Solution:** Confirm the Customer ID is the correct 12-digit value from your Observe login URL. The endpoint host is derived from it, so an incorrect ID points the exporter at the wrong tenant. **Symptom:** Telemetry is dropped during network outages or collector restarts. **Solution:** Enable the Sending Queue and Persistent Queuing. The persistent queue buffers batches to disk via the configured storage extension so they are retried after connectivity is restored. ### Standalone Destination ```yaml apiVersion: bindplane.observiq.com/v1 kind: Destination metadata: name: observe spec: type: observeinc parameters: - name: customer_id value: '165866210346' - name: token value: (sensitive) ``` ### Related Resources * [OTLP/HTTP Exporter](https://github.com/open-telemetry/opentelemetry-collector/tree/main/exporter/otlphttpexporter) — the upstream OpenTelemetry exporter used to send telemetry to Observe. * [Observe Endpoints documentation](https://docs.observeinc.com/en/latest/content/data-ingestion/endpoints.html) — Customer ID, ingest token creation, and authentication. --- # 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/observe.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.