OpenTelemetry Collector

Ingest metrics and traces using the OpenTelemetry Collector

The OpenTelemetry Collector (opens in a new tab) is vendor-agnostic, open source, and supports popular backends and the OpenTelemetry Protocol. You can use the OpenTelemetry Collector to ingest metric data, and configure dynamic, remotely configurable head sampling for your trace data.

💡

To learn more about using the OpenTelemetry Collector, current Observability Platform customers and Chronosphere partners can register for an Instrumenting Basics on-demand ChroKnow course (opens in a new tab) provided by Chronosphere University.

Get started

To get started with The OpenTelemetry Collector:

  1. Instrument your app (opens in a new tab) with an OpenTelemetry SDK (opens in a new tab).

  2. Create an API token to authenticate with Chronosphere Observability Platform. You must create a service account. Chronosphere recommends creating a restricted service account with a write-only scope. Use the generated API token in the OpenTelemetry Collector file config.yml to authenticate with Observability Platform.

    ⚠️

    Store your API token in a secure location. If you lose your token, you must create a new service account.

  3. Configure your OpenTelemetry Collector to ingest metrics or traces.

Conversion from OpenTelemetry to Prometheus-compatible metrics

Observability Platform follows the OpenTelemetry to Prometheus Specification (opens in a new tab) to convert OpenTelemetry metrics to Prometheus-compatible metrics and adds delta temporality aggregation support to provide a more seamless experience for delta metrics.

Observability Platform implements the following data conversions as defined in the OpenTelemetry to Prometheus Specification (opens in a new tab):

  • Sanitize metric and label names to conform to Prometheus naming conventions. For example, an OpenTelemetry metric named http.duration becomes http_duration.

  • Collapse multiple consecutive underscore (_) characters to a single underscore character.

  • Metric names for OpenTelemetry explicit bucket boundary histograms follow the OpenMetrics specification to correctly name the time series for each histogram bucket. For example, a histogram has one _bucket series for each bucket, and a series for the _sum and _count.

  • Observability Platform supports staleness markers and writes them whenever any OpenTelemetry data point presents a NoRecordedValue flag for the associated scope.

  • Observability Platform requires service.instance.id for all metric time series to ensure metric writer uniqueness (opens in a new tab), and rejects metrics without a service.instance.id resource attribute. To configure a value for service.instance.id, follow the recommendations in Map resource attributes to Prometheus job and instance.

    Observability Platform deviates from the OpenTelemetry to Prometheus Specification (opens in a new tab) to reduce operational chores and improve metric usability.

  • Observability Platform preserves metric names and doesn't apply metric type or unit suffixes to metrics as defined in the OpenMetrics specification, with the exception of explicit bucket boundary histograms.

  • Observability Platform merges both OpenTelemetry Protocol resource attributes and individual data point attributes into a single set of Prometheus labels for each time series. Merging resource attributes after ingestion removes the need to manually configure resource attribute copying (opens in a new tab) in your OpenTelemetry Collector configuration. To configure resource attribute exclusions or turn off resource attribute merging, see Configure OpenTelemetry ingestion.

  • Observability Platform doesn't create a target_info (opens in a new tab) metric by default. The target_info metric is equivalent to the up metric, the presence of which indicates that a resource is available. You can change your configuration to enable target_info metric creation.