OpenTelemetry Protocol format considerations

This section describes metrics and logs conversion considerations for data sent using OpenTelemetry Protocol (OTLP). For a guide to get started, see Send data using OpenTelemetry Protocol.

Note: We only support OTLP over HTTP today, and plan to support gRPC in the future.


We store the metrics in a Prometheus-compatible store. We currently follow the official specification described here: OTLP Metric points to Prometheus.

The following sections describe common issues you might experience.

Dots (.) are converted to _

Because Prometheus metrics don’t support . and - in metric or label names, they are converted to _ in Prometheus.

For example:

requests.duration{http.status_code=500, cloud.region=us-central1} in OTLP becomes requests_duration{http_status_code=”500”, cloud_region=”us-central1”} in Prometheus.

Resource attributes are added to target_info metric

As described in the Resource Attributes specification, we add resource attributes to a special target_info metric.

However, <service.namespace>/<> or <> (if namespace is empty), is added as job label and is added as instance label to every metric.


Because it is too costly from a cardinality perspective, Grafana Loki indexes a few attributes from log entries instead of indexing all available attributes or the entire log message. As such, you must provide hints to the Loki translator, stating which attributes to promote to Loki labels. You can do this by adding new synthetic attributes, which are read by the Loki translator and removed before the data is sent over the network.

The following snippet shows how the processors section looks when you add a resource processor that adds the loki.resource.labels hint. This example tells the Loki translator that the host_name resource attribute should be promoted to a label. You are not required to add labels, and every entry that passes through the Loki exporter will have a static label exporter with the value OTLP by default.

For more information about labels and how to chose the right ones for your use case, refer to the Loki documentation.


    # this is how we tell Loki to add `host_name` as a label
    - action: insert
      key: loki.resource.labels
      value: host_name

    # this would ideally come from the data source itself, but we set it here
    # for simplicity
    - action: insert
      key: host_name
      value: guarana