Skip to main content
The OpenTelemetry Collector 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.

​
Get started

To get started with the OpenTelemetry Collector:
  1. Instrument your app with an OpenTelemetry SDK.
  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 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:
  • 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, 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 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 drops OpenTelemetry resource and data point attributes that have empty values from the time series. Observability Platform then accepts the resulting time series for processing.
  • 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 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 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.