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 configure dynamic, remotely configurable head sampling for your trace data.
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 from OpenTelemetry metrics to Prometheus-compatible metrics:
-
Sanitize metric and label names to conform to Prometheus naming conventions. For example, an OpenTelemetry metric named
http.duration
becomeshttp_duration
. -
Multiple consecutive underscore (
_
) characters get collapsed to a single underscore character. -
Observability Platform doesn't apply suffixes to metrics as defined in the OpenMetrics specification, with the exception of Histograms. Customers can submit a Chronosphere Support ticket to enable OpenMetrics naming. When OpenMetrics naming is enabled, units such as
seconds
orbytes
append to the metric name, and the_total
suffix appends to counter types to conform to the OpenMetrics specification.Metric names for OpenTelemetry histograms follow the OpenMetrics specification to correctly name the time series for each histogram bucket. For example, a histogram will have K
_bucket
series, one for each bucket, and a series for the_sum
and_count
. -
Observability Platform requires
service.name
andservice.instance.id
as resource attributes for all metrics to construct the Prometheustarget_info
(opens in a new tab) metric. Observability Platform rejects metrics without these labels.- Metrics about resources are written to
target_info
metric. This functionally is equivalent toup
metric whose presence indicates that a resource is available. Labels from this metric can be used to augment others using either a Prometheus join or derived metrics. - The conversion uses the
service.name
resource attribute for the job label value. - The conversion uses the
service.instance.id
resource attribute for the instance label. Resource names default to the name of the process, but resource IDs must be specified and are strongly encouraged to be unique. - Users can use a combination of their own resource attributes and resource detectors to bring in environment details. See Mapping resource attributes to Prometheus job and instance for examples.
- Metrics about resources are written to
-
Staleness markers are supported and are written whenever any OpenTelemetry data point presents a
NoRecordedValue
flag for the associated scope.