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 Palo Alto Networks Cortex XCOR. You must create a service account. Cortex XCOR 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 Cortex XCOR.
    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

Cortex XCOR 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. Cortex XCOR 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.
  • Cortex XCOR supports staleness markers and writes them whenever any OpenTelemetry data point presents a NoRecordedValue flag for the associated scope.
  • Cortex XCOR 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. Cortex XCOR deviates from the OpenTelemetry to Prometheus Specification to reduce operational chores and improve metric usability.
  • Cortex XCOR 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.
  • Cortex XCOR drops OpenTelemetry resource and data point attributes that have empty values from the time series. Cortex XCOR then accepts the resulting time series for processing.
  • Cortex XCOR 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.
  • Cortex XCOR 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.