このコンテンツは選択した言語では利用できません。

Chapter 4. OTLP data ingestion in Loki


You can use an API endpoint by using the OpenTelemetry Protocol (OTLP) with Logging. As OTLP is a standardized format not specifically designed for Loki, OTLP requires an additional Loki configuration to map data format of OpenTelemetry to data model of Loki. OTLP lacks concepts such as stream labels or structured metadata. Instead, OTLP provides metadata about log entries as attributes, grouped into the following three categories:

  • Resource
  • Scope
  • Log

You can set metadata for multiple entries simultaneously or individually as needed.

4.1. Configuring LokiStack for OTLP data ingestion

To configure a LokiStack custom resource (CR) for OTLP ingestion, follow these steps:

Prerequisites

  • Ensure that your Loki setup supports structured metadata, introduced in schema version 13 to enable OTLP log ingestion.

Procedure

  1. Set the schema version:

    • When creating a new LokiStack CR, set version: v13 in the storage schema configuration.

      Note

      For existing configurations, add a new schema entry with version: v13 and an effectiveDate in the future. For more information on updating schema versions, see Upgrading Schemas (Grafana documentation).

  2. Configure the storage schema as follows:

    Example configure storage schema

    # ...
    spec:
      storage:
        schemas:
        - version: v13
          effectiveDate: 2024-10-25

    Once the effectiveDate has passed, the v13 schema takes effect, enabling your LokiStack to store structured metadata.

  3. If you use the OpenShift Container Platform web console to query logs, enable console labels:

    # ...
    spec:
      tenants:
        mode: openshift-logging
        openshift:
          otlp:
            enableConsoleLabels: true

4.2. Attribute mapping

When you set the Loki Operator to the openshift-logging mode, Loki Operator automatically applies a default set of attribute mappings. These mappings align specific OTLP attributes with stream labels and structured metadata of Loki.

For typical setups, these default mappings are sufficient. However, you might need to customize attribute mapping in the following cases:

  • Using a custom collector: If your setup includes a custom collector that generates additional attributes that you do not want to store, consider customizing the mapping to ensure these attributes are dropped by Loki.
  • Adjusting attribute detail levels: If the default attribute set is more detailed than necessary, you can reduce it to essential attributes only. This can avoid excessive data storage and streamline the logging process.

4.2.1. Custom attribute mapping for OpenShift

When using the Loki Operator in openshift-logging mode, attribute mapping follow OpenShift default values, but you can configure custom mappings to adjust default values. In the openshift-logging mode, you can configure custom attribute mappings globally for all tenants or for individual tenants as needed. When you define custom mappings, they are appended to the OpenShift default values. If you do not need default labels, you can disable them in the tenant configuration.

Note

A major difference between the Loki Operator and Loki lies in inheritance handling. Loki copies only default_resource_attributes_as_index_labels to tenants by default, while the Loki Operator applies the entire global configuration to each tenant in the openshift-logging mode.

Within LokiStack, attribute mapping configuration is managed through the limits setting. See the following example LokiStack configuration:

# ...
spec:
  limits:
    global:
      otlp: {} 
1

    tenants:
      application:
        otlp: {} 
2
1
Defines global OTLP attribute configuration.
2
Defines the OTLP attribute configuration for the application tenant within the openshift-logging mode. You can also configure infrastructure and audit tenants in addition to application tenants.
Note

You can use both global and per-tenant OTLP configurations for mapping attributes to stream labels.

Stream labels derive only from resource-level attributes, which the LokiStack resource structure reflects. See the following LokiStack example configuration:

spec:
  limits:
    global:
      otlp:
        streamLabels:
          resourceAttributes:
          - name: "k8s.namespace.name"
          - name: "k8s.pod.name"
          - name: "k8s.container.name"

You can drop attributes of type resource, scope, or log from the log entry.

# ...
spec:
  limits:
    global:
      otlp:
        streamLabels:
# ...
        drop:
          resourceAttributes:
          - name: "process.command_line"
          - name: "k8s\\.pod\\.labels\\..+"
            regex: true
          scopeAttributes:
          - name: "service.name"
          logAttributes:
          - name: "http.route"

You can use regular expressions by setting regex: true to apply a configuration for attributes with similar names.

Important

Avoid using regular expressions for stream labels, as this can increase data volume.

Attributes that are not explicitly set as stream labels or dropped from the entry are saved as structured metadata by default.

4.2.2. Required and optional default labels for OpenShift

In the openshift-logging mode, you must not remove certain required attributes because they are essential to OpenShift functions.

If you use the OpenShift Container Platform web console to query logs, enable the attributes called console labels. When you enable console labels, the following attributes are added to stream labels:

  • k8s.container.name
  • k8s.cronjob.name
  • k8s.daemonset.name
  • k8s.deployment.name
  • k8s.job.name
  • k8s.node.name
  • k8s.pod.name
  • k8s.statefulset.name
  • kubernetes.container_name
  • kubernetes.host
  • kubernetes.pod_name
  • service.name

For information about enabling console attributes, see Configuring LokiStack for OTLP data ingestion.

You can add custom stream labels or drop information from the structured metadata when you use the openshift-logging mode. The custom configuration is merged with the OpenShift defaults.

For information about the attributes, see OpenTelemetry data model attributes.

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る