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, 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:
-
Instrument your app (opens in a new tab) with an OpenTelemetry SDK (opens in a new tab).
-
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.
-
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
becomeshttp_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 aservice.instance.id
resource attribute. To configure a value forservice.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. Thetarget_info
metric is equivalent to theup
metric, the presence of which indicates that a resource is available. You can change your configuration to enabletarget_info
metric creation.