OpenTelemetry Collector

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:

  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. 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 Chronosphere.

    ⚠️

    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

Chronosphere 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.

Chronosphere 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 becomes http_duration.

  • Multiple consecutive underscore (_) characters get collapsed to a single underscore character.

  • Chronosphere doesn't apply suffixes to metrics as defined in the OpenMetrics specification, with the exception of Histograms. Customers can submit Chronosphere Support ticket to enable OpenMetrics naming. When OpenMetrics naming is enabled, units such as seconds or bytes 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.

  • Chronosphere requires service.name and service.instance.id as resource attributes for all metrics to construct the Prometheus target_info (opens in a new tab) metric. Chronosphere rejects metrics without these labels.

    • Metrics about resources are written to target_info metric. This functionally is equivalent to up 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.
  • Staleness markers are supported and are written whenever any OpenTelemetry data point presents a NoRecordedValue flag for the associated scope.