3.5. Loki での OTLP データ取り込み
Logging 6.1 では、OpenTelemetry Protocol (OTLP) を使用した API エンドポイントが有効になります。OTLP は Loki 専用に設計されたものではない標準化された形式であるため、OpenTelemetry のデータ形式を Loki のデータモデルにマッピングするには、Loki 側で追加の設定が必要です。OTLP には、ストリームラベル や 構造化メタデータ などの概念がありません。代わりに、OTLP はログエントリーに関するメタデータを 属性 として提供し、次の 3 つのカテゴリーにグループ化します。
- リソース
- Scope
- Log
これにより、必要に応じて複数のエントリーに同時に、または個別にメタデータを設定できます。
3.5.1. OTLP データ取り込み用の LokiStack 設定
OpenTelemetry Protocol (OTLP) 出力ログフォワーダーは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
OTLP 取り込み用に LokiStack
カスタムリソース (CR) を設定するには、次の手順に従います。
前提条件
- Loki セットアップが、OTLP ログの取り込みを有効にするためにスキーマバージョン 13 で導入された構造化メタデータをサポートしていることを確認します。
手順
スキーマバージョンを設定します。
新しい
LokiStack
CR を作成する場合は、ストレージスキーマ設定でversion: v13
を設定します。注記既存の設定の場合は、
version: v13
と現在より後のeffectiveDate
を持つ新しいスキーマエントリーを追加します。スキーマバージョンの更新の詳細は、Upgrading Schemas (Grafana ドキュメント) を参照してください。
ストレージスキーマを次のように設定します。
ストレージスキーマの設定例
# ... spec: storage: schemas: - version: v13 effectiveDate: 2024-10-25
effectiveDate
を過ぎると v13 スキーマが有効になり、LokiStack
は構造化メタデータを保存できるようになります。
3.5.2. 属性マッピング
Loki Operator が openshift-logging
モードに設定されている場合、デフォルトの属性マッピングセットが自動的に適用されます。これらのマッピングは、特定の OTLP 属性を Loki のストリームラベルおよび構造化メタデータと一致させます。
一般的なセットアップでは、デフォルトのマッピングで十分です。ただし、次の場合には属性マッピングをカスタマイズする必要があることもあります。
- カスタムコレクターを使用する場合: セットアップに追加の属性を生成するカスタムコレクターが含まれている場合は、これらの属性を Loki に保持するためにマッピングをカスタマイズすることを検討してください。
- 属性の詳細レベルを調整する場合: デフォルトの属性セットが必要以上に詳細な場合は、必須の属性のみに減らすことができます。そうすることで、過剰なデータ保存を回避し、ロギングプロセスを合理化できます。
ストリームラベルと構造化メタデータのいずれにもマッピングされていない属性は、Loki に保存されません。
3.5.2.1. OpenShift のカスタム属性マッピング
Loki Operator を openshift-logging
モードで使用する場合、属性マッピングは OpenShift のデフォルトに従いますが、カスタムマッピングを設定して調整できます。カスタムマッピングにより、特定のニーズを満たすための追加の設定が可能になります。
openshift-logging
モードでは、カスタム属性マッピングをすべてのテナントに対してグローバルに設定することも、必要に応じて個々のテナントに対して設定することもできます。カスタムマッピングが定義されると、OpenShift のデフォルトに追加されます。デフォルトの推奨ラベルが不要な場合は、テナント設定で無効にできます。
Loki Operator と Loki の主な違いは、継承の処理にあります。Loki は、デフォルトでは default_resource_attributes_as_index_labels
のみをテナントにコピーしますが、Loki Operator は openshift-logging
モードで各テナントにグローバル設定全体を適用します。
LokiStack
内では、属性マッピング設定は limits
設定を通じて管理されます。
# ... spec: limits: global: otlp: {} 1 tenants: application: otlp: {} 2
グローバルおよびテナントごとの OTLP 設定の両方で、属性をストリームラベルまたは構造化メタデータにマッピングできます。ログエントリーを Loki ストレージに保存するには、少なくとも 1 つのストリームラベルが必要です。設定がその要件を満たしていることを確認してください。
ストリームラベルはリソースレベルの属性からのみ導出され、LokiStack
リソース構造はそれを反映します。
spec: limits: global: otlp: streamLabels: resourceAttributes: - name: "k8s.namespace.name" - name: "k8s.pod.name" - name: "k8s.container.name"
対照的に、構造化メタデータはリソース、スコープ、またはログレベルの属性から生成できます。
# ... spec: limits: global: otlp: streamLabels: # ... structuredMetadata: resourceAttributes: - name: "process.command_line" - name: "k8s\\.pod\\.labels\\..+" regex: true scopeAttributes: - name: "service.name" logAttributes: - name: "http.route"
Loki で類似の属性をマッピングする場合は、、属性名に regex: true
を設定して正規表現を使用します。
データ量が増加する可能性があるため、ストリームラベルに正規表現を使用することは避けてください。
3.5.2.2. OpenShift のデフォルトのカスタマイズ
openshift-logging
モードでは、特定の属性が必須であり、OpenShift 機能でのロールのため、設定から削除できません。推奨 のラベルが付いているその他の属性は、パフォーマンスに影響がある場合は無効化されている可能性があります。
カスタム属性なしで openshift-logging
モードを使用すると、即座に OpenShift ツールとの互換性が確保されます。ストリームラベルまたは構造化メタデータとして追加の属性が必要な場合は、カスタム設定を使用します。カスタム設定はデフォルト設定とマージできます。
3.5.2.3. 推奨属性の削除
openshift-logging
モードでデフォルト属性を減らすには、推奨属性を無効にします。
# ...
spec:
tenants:
mode: openshift-logging
openshift:
otlp:
disableRecommendedAttributes: true 1
- 1
- 推奨属性を削除するには、
disableRecommendedAttributes: true
を設定します。これにより、デフォルトの属性が 必須属性 に制限されます。
このオプションは、デフォルトの属性によってパフォーマンスやストレージの問題が発生する場合に役立ちます。この設定により、デフォルトのストリームラベルが削除されるため、クエリーのパフォーマンスに悪影響が及ぶ可能性があります。クエリーに不可欠な属性を保持するためには、このオプションをカスタム属性設定と組み合わせる必要があります。