> ## Documentation Index
> Fetch the complete documentation index at: https://docs.e6data.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Observability export

> Export e6data telemetry to your own observability stack via OpenTelemetry - metrics, logs, and traces.

e6data exposes its operational telemetry via **OpenTelemetry** so you can route metrics, logs, and traces into your own observability platform (Datadog, Honeycomb, Grafana, New Relic, and so on).

## What's exposed

| Signal | What's emitted |
| - | - |
| **Metrics** | Cluster utilization, query rate, query latency, executor health, cache hit rate |
| **Logs** | Query lifecycle events, cluster lifecycle events, errors |
| **Traces** | Distributed traces for queries (parser → planner → executors) |

All three follow the OpenTelemetry standard, so any OTLP-compatible backend can ingest them.

## Configure OTel export

In the Compute Plane, go to **Settings → Observability**:

1. Enable **Export to OpenTelemetry**.
2. Set the **OTLP endpoint** for your backend (HTTPS, typically port 443 or 4318).
3. Set the **Authorization header** if your backend requires one (for example, `Bearer <token>`).
4. Select which signals to export (Metrics, Logs, Traces).
5. (Optional) Set a **sampling rate** for traces (default 100%; reduce for high-volume workloads).
6. Save.

Telemetry flows to your backend immediately - no restart required.

## Common backends

| Backend | OTLP endpoint format |
| - | - |
| Datadog | `https://otlp.datadoghq.com/v1/...` (region-specific) |
| Honeycomb | `https://api.honeycomb.io/v1/...` |
| Grafana Cloud | `https://otlp-gateway-<cluster>.grafana.net/otlp` |
| New Relic | `https://otlp.nr-data.net` |
| Self-hosted OTel Collector | Your collector's endpoint |

Check your backend's documentation for the exact endpoint URL and auth header format.

## What to dashboard

| Dashboard | Key metrics |
| - | - |
| Cluster health | Executor count, CPU/memory, queue depth |
| Query performance | P50/P95/P99 query latency, slow query count |
| Workload patterns | Queries per minute, concurrent queries, cache hit rate |
| Errors | Failed query rate, error type breakdown, timeout rate |

## Trace sampling

100% trace sampling on a busy workspace can be expensive (bandwidth, ingestion cost). Typical settings:

| Workload | Sampling rate |
| - | - |
| Dev/test | 100% |
| Production with moderate load | 10–20% |
| High-volume production | 1–5% |

You can also use **error-based sampling** - capture 100% of failed queries but a fraction of successful ones - configured in the OTel sampling settings or via your collector.

## Privacy and compliance

Telemetry contains query metadata (timing, status, user identity) but not query text by default. To include query text in traces, enable **Include query text in spans** in the observability settings - this may expose sensitive SQL to your backend, so review compliance implications first. Query results are never exported.

## See also

* [Monitoring](/platform/monitoring) - in-product cluster and query monitoring.
* [Query history and saved queries](/query/querying/query-history)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.