Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

Logging

OpenShift Container Platform 4.17

OpenShift Container Platform でのログの設定と使用

Red Hat OpenShift Documentation Team

概要

ログ記録を使用してログデータを収集、視覚化、転送、保存し、OpenShift Container Platform の問題のトラブルシューティング、パフォーマンスのボトルネックの特定、およびセキュリティーの脅威の検出を行います。

第1章 Logging 6.0
リンクのコピー

1.1. リリースノート
リンクのコピー

1.1.1. Logging 6.0.2
リンクのコピー

このリリースには RHBA-2024:10051 が含まれています。

1.1.1.1. バグ修正
リンクのコピー
  • この更新前は、Loki が一部の設定を正しくロードしなかったため、Alibaba Cloud または IBM Cloud オブジェクトストレージを使用するときに問題が発生していました。この更新により、Loki の設定読み込みコードが修正され、問題が解決されます。(LOG-5325)
  • この更新前は、コレクターが設定されたしきい値を超えた監査ログメッセージを破棄していました。この更新により、最大行サイズと読み取りサイクル中に読み取られるバイト数の監査設定しきい値が変更されます。(LOG-5998)
  • この更新前は、Cluster Logging Operator が、以前のリリースのように ClusterLogForwarder のインスタンスに関連付けられたリソースを監視および調整していませんでした。この更新により、Operator が変更され、所有および作成するすべてのリソースを監視および調整するようになります。(LOG-6264)
  • この更新前は、重大度レベルが不明なログイベントが Google Cloud Logging に送信されると、Vector コレクターで警告がトリガーされ、重大度がデフォルトで 'DEFAULT' に設定されていました。この更新により、ログの重大度レベルが Google Cloud Logging 仕様に合わせて標準化され、監査ログに 'INFO' の重大度が割り当てられるようになりました。(LOG-6296)
  • この更新前は、インフラストラクチャー namespace がアプリケーション入力に含まれている場合、log_type が application に設定されていました。この更新により、アプリケーション入力に含まれるインフラストラクチャー namespace の log_type が、infrastructure に設定されるようになります。(LOG-6354)
  • この更新前は、ClusterLogForwarder の syslog.enrichment フィールドに値を指定すると、コンテナー以外のログのメッセージに namespace_name、container_name、および pod_name が追加されていました。この更新により、syslog.enrichment が設定されている場合に、コンテナーログのメッセージにのみ namespace_name、container_name、および pod_name が含まれるようになります。(LOG-6402)
1.1.1.2. CVE
リンクのコピー

1.1.2. Logging 6.0.1
リンクのコピー

このリリースには、OpenShift Logging バグ修正リリース 6.0.1 が含まれています。

1.1.2.1. バグ修正
リンクのコピー
  • この更新により、コレクターのデフォルトのメモリー制限が 1024 Mi から 2024 Mi に増加します。ただし、ユーザーはクラスターの仕様とニーズに応じてリソース制限を調整する必要があります。(LOG-6180)
  • この更新前は、Loki Operator はすべての AlertingRule リソースにデフォルトの namespace ラベルを追加できなかったため、User-Workload-Monitoring Alertmanager がこれらのアラートのルーティングをスキップしていました。この更新では、すべてのアラートルールおよび記録ルールにルール namespace がラベルとして追加されます。これにより問題が解決され、Alertmanager での適切なアラートルーティングが復元されます。(LOG-6151)
  • この更新前は、LokiStack ルーラーコンポーネントビューが適切に初期化されず、ルーラーコンポーネントが無効になっているときに無効フィールドエラーが発生しました。この更新により、コンポーネントビューが空の値で初期化されるようになり、問題は解決されます。(LOG-6129)
  • この更新前は、prune フィルターで log_source を設定でき、そのためにログデータの一貫性が失われる可能性がありました。この更新により、設定は適用前に検証され、prune フィルターに log_source が含まれる設定はすべて拒否されます。(LOG-6202)
1.1.2.2. CVE
リンクのコピー

1.1.3. Logging 6.0.0
リンクのコピー

このリリースには、Logging for Red Hat OpenShift バグ修正リリース 6.0.0 が含まれています。

注記

Logging は、コアの OpenShift Container Platform とは異なるリリースサイクルで、インストール可能なコンポーネントとして提供されます。Red Hat OpenShift Container Platform ライフサイクルポリシー は、リリースの互換性を概説しています。

Expand
表1.1 アップストリームコンポーネントのバージョン
Logging バージョンコンポーネントのバージョン

Operator

eventrouter

logfilemetricexporter

loki

lokistack-gateway

opa-openshift

vector

6.0

0.4

1.1

3.1.0

0.1

0.1

0.37.1

1.1.4. 削除通知
リンクのコピー

  • このリリースにより、ロギングは ClusterLogging.logging.openshift.io および ClusterLogForwarder.logging.openshift.io カスタムリソースをサポートしなくなりました。代替の機能に関する詳細は、製品ドキュメントを参照してください。(LOG-5803)
  • このリリースにより、ロギングでは、ログストレージ (Elasticsearch など)、視覚化 (Kibana など)、または Fluentd ベースのログコレクターが管理またはデプロイされなくなりました。(LOG-5368)
注記

elasticsearch-operator によって管理される Elasticsearch と Kibana を引き続き使用するには、管理者は ClusterLogging リソースを削除する前に、それらのオブジェクトの ownerRefs を変更する必要があります。

1.1.5. 新機能および機能拡張
リンクのコピー

  • この機能は、ストレージ、視覚化、収集などのコンポーネントの責任を関連する Operator に移すことで、Red Hat OpenShift のロギング用の新しいアーキテクチャーを導入します。ログの収集および転送用の ClusterLogForwarder.observability.openshift.io API を導入します。ClusterLogging.logging.openshift.io および ClusterLogForwarder.logging.openshift.io API のサポートと、Red Hat Managed Elastic スタック (Elasticsearch および Kibana) のサポートが削除されました。ログの保存には Red Hat LokiStack への移行が推奨されます。既存の Managed Elasticsearch デプロイメントは、限られた期間使用できます。ログ収集の自動移行は提供されていないため、管理者は新しい ClusterLogForwarder.observability.openshift.io 仕様を作成して、以前のカスタムリソースを置き換える必要があります。詳細は、公式の製品ドキュメントを参照してください。(LOG-3493)
  • このリリースにより、ロギングビュープラグインのデプロイの責任が Red Hat OpenShift Logging Operator から Cluster Observability Operator (COO) に移行します。視覚化が必要な新しいログストレージのインストールでは、Cluster Observability Operator と関連する UIPlugin リソースをデプロイする必要があります。詳細は、製品ドキュメントの Cluster Observability Operator の概要 を参照してください。(LOG-5461)
  • この機能拡張により、Vector ドキュメントの推奨事項に基づいて、Vector コレクターのデプロイメントのメモリーと CPU 使用量のデフォルトの要求と制限が設定されます。(LOG-4745)
  • この機能拡張により、アップストリームバージョン v0.37.1 に合わせて Vector が更新されます。(LOG-5296)
  • この機能拡張により、ログコレクターがログをノードのファイルシステムにバッファーし、利用可能な領域の 15% 超を使用する場合にトリガーするアラートが導入され、バックプレッシャーの問題の可能性を示すようになりました。(LOG-5381)
  • この機能拡張により、すべてのコンポーネントのセレクターが更新され、共通の Kubernetes ラベルが使用されます。(LOG-5906)
  • この機能拡張により、コレクター設定がシークレットではなく ConfigMap としてデプロイされるように変更され、ClusterLogForwarder が Unmanaged に設定されている場合にユーザーが設定を表示および編集できるようになります。(LOG-5599)
  • この機能拡張により、trace、debug、info、warn、error、または off などのオプションと共に、ClusterLogForwarder のアノテーションを使用して Vector コレクターログレベルを設定する機能が追加されました。(LOG-5372)
  • この機能拡張により、Amazon CloudWatch 出力で複数の AWS ロールが使用される設定を拒否するための検証が追加され、誤ったログルーティングが防止されます。(LOG-5640)
  • この機能拡張により、メトリクスダッシュボードから Log Bytes Collected および Log Bytes Sent グラフが削除されます。(LOG-5964)
  • この機能拡張により、must-gather 機能が更新され、ClusterLogForwarder.observability.openshift.io リソースから Red Hat Managed LokiStack など、Logging 6.0 コンポーネントを検査するための情報のみがキャプチャーされるようになりました。(LOG-5949)
  • この機能拡張により、特定のエラー状態に対する早期警告が提供され、Azure ストレージシークレットの検証が改善されます。(LOG-4571)

1.1.6. テクノロジープレビュー機能
リンクのコピー

  • このリリースでは、OpenTelemetry を使用したログ転送のテクノロジープレビュー機能が導入されています。新しい出力タイプ `OTLP` を使用すると、OpenTelemetry データモデルとリソースのセマンティック規則を使用して、JSON でエンコードされたログレコードを送信できます。(LOG-4225)

1.1.7. バグ修正
リンクのコピー

  • この更新前は、CollectorHighErrorRate および CollectorVeryHighErrorRate アラートがまだ存在していました。この更新により、両方のアラートが logging 6.0 リリースで削除されましたが、今後のリリースで復活する可能性はあります。(LOG-3432)

1.1.8. CVE
リンクのコピー

1.2. Logging 6.0
リンクのコピー

ClusterLogForwarder カスタムリソース (CR) は、ログの収集と転送の中心的な設定ポイントです。

1.2.1. 入力および出力
リンクのコピー

入力では、転送するログのソースを指定します。Logging には、クラスターのさまざまな部分からログを選択する組み込みの入力タイプ (application、infrastructure、および audit) が用意されています。namespace または Pod ラベルに基づいてカスタム入力を定義し、ログの選択を微調整することもできます。

出力は、ログが送信される宛先を定義します。各出力タイプには独自の設定オプションセットがあり、動作と認証設定をカスタマイズできます。

1.2.2. レシーバー入力タイプ
リンクのコピー

レシーバー入力タイプにより、Logging システムは外部ソースからのログを受け入れることができます。ログを受信するための 2 つの形式 (http と syslog) がサポートされます。

ReceiverSpec は、レシーバー入力の設定を定義します。

1.2.3. パイプラインとフィルター
リンクのコピー

パイプラインは、入力から出力へのログのフローを決定します。パイプラインは、1 つ以上の入力参照、出力参照、およびオプションのフィルター参照で構成されます。フィルターを使用して、パイプライン内のログメッセージを変換または削除できます。フィルターは順番に適用されるため、フィルターの順序は重要であり、最初の方のフィルターを使用すると、ログメッセージが後のステージに到達するのを防ぐことができます。

1.2.4. Operator の行動
リンクのコピー

Cluster Logging Operator は、managementState フィールドに基づいて、コレクターのデプロイメントと設定を管理します。

  • Managed (デフォルト) に設定すると、Operator は仕様で定義された設定に一致するように、ロギングリソースをアクティブに管理します。
  • Unmanaged に設定すると、Operator はアクションを実行せず、ロギングコンポーネントを手動で管理できます。

1.2.5. 検証
リンクのコピー

ロギングには、スムーズでエラーのない設定エクスペリエンスを確保するために、広範な検証ルールやデフォルト値が含まれます。ClusterLogForwarder リソースは、必須フィールド、フィールド間の依存関係、および入力値の形式の検証チェックを強制します。特定のフィールドにはデフォルト値が提供されるため、一般的なシナリオで明示的な設定を行う必要性が軽減されます。

1.2.5.1. クイックスタート
リンクのコピー

前提条件

  • クラスター管理者のパーミッション。

手順

  1. OperatorHub から OpenShift Logging および Loki Operator をインストールします。

  2. openshift-logging namespace に LokiStack カスタムリソース (CR) を作成します。 

    apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  managementState: Managed
  size: 1x.extra-small
  storage:
    schemas:
    - effectiveDate: '2022-06-01'
      version: v13
    secret:
      name: logging-loki-s3
      type: s3
    storageClassName: gp3-csi
  tenants:
    mode: openshift-logging
    Copy to Clipboard Toggle word wrap

  3. コレクターのサービスアカウントを作成します。 

    $ oc create sa collector -n openshift-logging
    Copy to Clipboard Toggle word wrap

  4. コレクター用の ClusterRole を作成します。 

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: logging-collector-logs-writer
rules:
- apiGroups:
  - loki.grafana.com
  resourceNames:
  - logs
  resources:
  - application
  - audit
  - infrastructure
  verbs:
  - create
    Copy to Clipboard Toggle word wrap

  5. ClusterRole をサービスアカウントにバインドします。 

    $ oc adm policy add-cluster-role-to-user logging-collector-logs-writer -z collector
    Copy to Clipboard Toggle word wrap
  6. Cluster Observability Operator をインストールします。

  7. Observe タブの Log セクションを有効にするには、UIPlugin を作成します。 

    apiVersion: observability.openshift.io/v1alpha1
kind: UIPlugin
metadata:
  name: logging
spec:
  type: Logging
  logging:
    lokiStack:
      name: logging-loki
    Copy to Clipboard Toggle word wrap

  8. コレクターサービスアカウントにロールを追加します。 

    $ oc project openshift-logging
$ oc adm policy add-cluster-role-to-user collect-application-logs -z collector
$ oc adm policy add-cluster-role-to-user collect-audit-logs -z collector
$ oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z collector
    Copy to Clipboard Toggle word wrap

  9. ログ転送を設定するには、ClusterLogForwarder CR を作成します。 

    apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: collector
  namespace: openshift-logging
spec:
  serviceAccount:
    name: collector
  outputs:
  - name: default-lokistack
    type: lokiStack
    lokiStack:
      target:
        name: logging-loki
        namespace: openshift-logging
      authentication:
        token:
          from: serviceAccount
    tls:
      ca:
        key: service-ca.crt
        configMapName: openshift-service-ca.crt
  pipelines:
  - name: default-logstore
    inputRefs:
    - application
    - infrastructure
    outputRefs:
    - default-lokistack
    Copy to Clipboard Toggle word wrap
  10. OpenShift Web コンソールの Observe タブの Log セクションにログが表示されていることを確認します。

1.3. Logging 6.0 へのアップグレード
リンクのコピー

Logging v6.0 は以前のリリースからの大幅なアップグレードであり、Cluster Logging の長年の目標のいくつかを達成しています。

  • ロギングコンポーネント (collectors、storage、visualization など) を管理するための個別の Operator の導入。
  • Elastic 製品 (Elasticsearch、Kibana など) に基づく管理ログストレージと視覚化のサポートが削除されました。
  • Fluentd ログコレクター実装の非推奨化。
  • ClusterLogging.logging.openshift.io および ClusterLogForwarder.logging.openshift.io リソースのサポートが削除されました。
注記

cluster-logging-operator は、自動アップグレードプロセスを提供しません。

ログの収集、転送、およびストレージのさまざまな設定を指定すると、cluster-logging-operator によって自動アップグレードは提供されません。このドキュメントは、管理者が既存の ClusterLogging.logging.openshift.io および ClusterLogForwarder.logging.openshift.io仕様を新しい API に変換する際に役立ちます。一般的なユースケース向けに移行された ClusterLogForwarder.observability.openshift.io リソースの例が含まれています。

1.3.1. oc explain コマンドの使用
リンクのコピー

oc explain コマンドは、カスタムリソース (CR) 内のフィールドの詳細な説明を提供する OpenShift CLI oc の重要なツールです。このコマンドは、OpenShift クラスターのリソースを設定またはトラブルシューティングする管理者および開発者にとって非常に重要です。

1.3.1.1. リソースの説明
リンクのコピー

oc explain は、特定のオブジェクトに関連するすべてのフィールドの詳細な説明を提供します。これには、Pod やサービスなどの標準リソースだけでなく、ステートフルセットや Operator によって定義されたカスタムリソースなどのより複雑なエンティティーも含まれます。

ClusterLogForwarder カスタムリソースの outputs フィールドのドキュメントを表示するには、以下を使用します。 

$ oc explain clusterlogforwarders.observability.openshift.io.spec.outputs
Copy to Clipboard Toggle word wrap
注記

clusterlogforwarder の代わりに、短い形式の obsclf を使用できます。

これにより、これらのフィールドの詳細情報 (タイプ、デフォルト値、関連するサブフィールドなど) が表示されます。

1.3.1.2. 階層構造
リンクのコピー

このコマンドは、リソースフィールドの構造を階層形式で表示し、さまざまな設定オプション間の関係を明確にします。

たとえば、LokiStack カスタムリソースの storage 設定をドリルダウンする方法を次に示します。 

$ oc explain lokistacks.loki.grafana.com
$ oc explain lokistacks.loki.grafana.com.spec
$ oc explain lokistacks.loki.grafana.com.spec.storage
$ oc explain lokistacks.loki.grafana.com.spec.storage.schemas
Copy to Clipboard Toggle word wrap

各コマンドは、リソース仕様のより深いレベルを表示し、構造を明確にします。

1.3.1.3. タイプ情報
リンクのコピー

oc explain は、各フィールドのタイプ (文字列、整数、ブール値など) も示すため、リソース定義で正しいデータタイプが使用されていることを確認できます。

以下に例を示します。 

$ oc explain lokistacks.loki.grafana.com.spec.size
Copy to Clipboard Toggle word wrap

これは、整数値を使用して size を定義する必要があることを示しています。

1.3.1.4. デフォルト値
リンクのコピー

該当する場合は、コマンドはフィールドのデフォルト値を表示し、明示的に指定されていない場合に使用される値に関する洞察を提供します。

ここでも、例として lokistacks.loki.grafana.com を使用します。 

$ oc explain lokistacks.spec.template.distributor.replicas
Copy to Clipboard Toggle word wrap

出力例

GROUP:      loki.grafana.com
KIND:       LokiStack
VERSION:    v1

FIELD: replicas <integer>

DESCRIPTION:
    Replicas defines the number of replica pods of the component.
Copy to Clipboard Toggle word wrap

1.3.2. ログのストレージ
リンクのコピー

このリリースで利用できる唯一のマネージドログストレージソリューションは、loki-operator によって管理される Lokistack です。以前は Managed Elasticsearch オファリングの優先される代替手段として利用可能だったこのソリューションは、デプロイメントプロセスで変更されないままとなります。

重要

elasticsearch-operator によって提供される既存の Red Hat Managed Elasticsearch または Kibana デプロイメントを引き続き使用するには、openshift-logging namespace の elasticsearch という名前の Elasticsearch リソースと kibana という名前の Kibana リソースから所有者参照を削除してから、同じ namespace の instance という名前の ClusterLogging リソースを削除します。

  1. ClusterLogging を一時的に Unmanaged 状態に設定します。 

    $ oc -n openshift-logging patch clusterlogging/instance -p '{"spec":{"managementState": "Unmanaged"}}' --type=merge
    Copy to Clipboard Toggle word wrap

  2. Elasticsearch リソースから ClusterLogging ownerReferences を削除します。

    次のコマンドは、ClusterLogging が Elasticsearch リソースを所有していないことを確認します。ClusterLogging リソースの logStore フィールドが更新されても、Elasticsearch リソースには影響しなくなります。 

    $ oc -n openshift-logging patch elasticsearch/elasticsearch -p '{"metadata":{"ownerReferences": []}}' --type=merge
    Copy to Clipboard Toggle word wrap

  3. Kibana リソースから ClusterLogging ownerReferences を削除します。

    次のコマンドは、ClusterLogging が Kibana リソースを所有していないことを確認します。ClusterLogging リソースの visualization フィールドが更新されても、Kibana リソースには影響しなくなります。 

    $ oc -n openshift-logging patch kibana/kibana -p '{"metadata":{"ownerReferences": []}}' --type=merge
    Copy to Clipboard Toggle word wrap
  4. ClusterLogging を Managed に設定します。 
$ oc -n openshift-logging patch clusterlogging/instance -p '{"spec":{"managementState": "Managed"}}' --type=merge
Copy to Clipboard Toggle word wrap

1.3.3. ログの視覚化
リンクのコピー

ログ視覚化用の OpenShift コンソール UI プラグインは、cluster-logging-operator から cluster-observability-operator に移動されました。

1.3.4. ログの収集および転送
リンクのコピー

ログ収集と転送の設定は、observability.openshift.io API グループの一部である新しい API で指定されるようになりました。次のセクションでは、古い API リソースとの違いを説明します。

注記

Vector は唯一のサポートされているコレクター実装です。

1.3.5. 管理、リソース割り当て、ワークロードのスケジュール
リンクのコピー

管理状態 (マネージド、マネージド以外など)、リソース要求と制限、toleration、およびノード選択の設定が、新しい ClusterLogForwarder API の一部になりました。

以前の設定

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
spec:
  managementState: "Managed"
  collection:
    resources:
      limits: {}
      requests: {}
    nodeSelector: {}
    tolerations: {}
Copy to Clipboard Toggle word wrap

現在の設定

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  managementState: Managed
  collector:
    resources:
      limits: {}
      requests: {}
    nodeSelector: {}
    tolerations: {}
Copy to Clipboard Toggle word wrap

1.3.6. 入力仕様
リンクのコピー

入力仕様は、ClusterLogForwarder 仕様のオプション部分です。管理者は引き続き、application、infrastructure、audit の定義済み値を使用して、これらのソースを収集できます。

1.3.6.1. アプリケーション入力
リンクのコピー

namespace とコンテナーの包含と除外が 1 つのフィールドに統合されました。

5.9 namespace とコンテナーの包含と除外を含むアプリケーション入力

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
   - name: application-logs
     type: application
     application:
       namespaces:
       - foo
       - bar
       includes:
       - namespace: my-important
         container: main
       excludes:
       - container: too-verbose
Copy to Clipboard Toggle word wrap

6.0 namespace とコンテナーの包含と除外を含むアプリケーション入力

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
   - name: application-logs
     type: application
     application:
       includes:
       - namespace: foo
       - namespace: bar
       - namespace: my-important
         container: main
       excludes:
       - container: too-verbose
Copy to Clipboard Toggle word wrap

注記

application、infrastructure、audit は予約語であり、入力を定義する際は名前として使用できません。

1.3.6.2. Input Receiver
リンクのコピー

Input Receiver への変更は次のとおりです。

  • レシーバーレベルでのタイプの明示的な設定。
  • ポート設定がレシーバーレベルに移動されました。

5.9 Input Receiver

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
  - name: an-http
    receiver:
      http:
        port: 8443
        format: kubeAPIAudit
  - name: a-syslog
    receiver:
      type: syslog
      syslog:
        port: 9442
Copy to Clipboard Toggle word wrap

6.0 Input Receiver

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
  - name: an-http
    type: receiver
    receiver:
      type: http
      port: 8443
      http:
        format: kubeAPIAudit
  - name: a-syslog
    type: receiver
    receiver:
      type: syslog
      port: 9442
Copy to Clipboard Toggle word wrap

1.3.7. 出力仕様
リンクのコピー

出力仕様に対する高レベルの変更には以下が含まれます。

  • URL 設定が各出力タイプの仕様に移動されました。
  • チューニングパラメーターが各出力タイプの仕様に移動されました。
  • TLS 設定と認証の分離。
  • TLS および認証用のキーとシークレット/configmap の明示的な設定。

1.3.8. シークレットと TLS 設定
リンクのコピー

シークレットと TLS 設定は、各出力の認証と TLS 設定に分離されました。管理者が認識されたキーを使用してシークレットを定義するのではなく、仕様で明示的に定義する必要があります。TLS と認可設定をアップグレードするには、管理者は既存のシークレットを引き続き使用するために、以前に認識されたキーを理解する必要があります。次のセクションの例では、ClusterLogForwarder シークレットを設定して、既存の Red Hat 管理のログストレージソリューションに転送する方法を詳しく説明します。

1.3.9. Red Hat Managed Elasticsearch
リンクのコピー

v5.9 Red Hat Managed Elasticsearch への転送

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  logStore:
    type: elasticsearch
Copy to Clipboard Toggle word wrap

v6.0 Red Hat Managed Elasticsearch への転送

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: default-elasticsearch
    type: elasticsearch
    elasticsearch:
      url: https://elasticsearch:9200
      version: 6
      index: <log_type>-write-{+yyyy.MM.dd}
    tls:
      ca:
        key: ca-bundle.crt
        secretName: collector
      certificate:
        key: tls.crt
        secretName: collector
      key:
        key: tls.key
        secretName: collector
  pipelines:
  - outputRefs:
    - default-elasticsearch
  - inputRefs:
    - application
    - infrastructure
Copy to Clipboard Toggle word wrap

注記

この例では、アプリケーションログは app-write ではなく application-write エイリアス/インデックスに書き込まれます。

1.3.10. Red Hat Managed LokiStack
リンクのコピー

v5.9 Red Hat Managed LokiStack への転送

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  logStore:
    type: lokistack
    lokistack:
      name: lokistack-dev
Copy to Clipboard Toggle word wrap

v6.0 Red Hat Managed LokiStack への転送

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: default-lokistack
    type: lokiStack
    lokiStack:
      target:
        name: lokistack-dev
        namespace: openshift-logging
      authentication:
        token:
          from: serviceAccount
    tls:
      ca:
        key: service-ca.crt
        configMapName: openshift-service-ca.crt
  pipelines:
  - outputRefs:
    - default-lokistack
  - inputRefs:
    - application
    - infrastructure
Copy to Clipboard Toggle word wrap

1.3.11. フィルターとパイプラインの設定
リンクのコピー

パイプライン設定では、入力ソースから出力先へのルーティングのみが定義され、必要な変換はフィルターとして個別に設定されるようになりました。以前のリリースのパイプラインのすべての属性は、このリリースではフィルターに変換されています。個々のフィルターは filters 仕様で定義され、パイプラインによって参照されます。

5.9 Filters

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
spec:
  pipelines:
   - name: application-logs
     parse: json
     labels:
       foo: bar
     detectMultilineErrors: true
Copy to Clipboard Toggle word wrap

6.0 Filter の設定

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
spec:
  filters:
  - name: detectexception
    type: detectMultilineException
  - name: parse-json
    type: parse
  - name: labels
    type: openshiftLabels
    openshiftLabels:
      foo: bar
  pipelines:
  - name: application-logs
    filterRefs:
    - detectexception
    - labels
    - parse-json
Copy to Clipboard Toggle word wrap

1.3.12. 検証とステータス
リンクのコピー

ほとんどの検証は、リソースが作成または更新されたときに実行され、即時のフィードバックが提供されます。これは、作成後に検証が行われ、リソースのステータスを検査する必要があった以前のリリースからの移行になります。作成時または更新時に検証できない場合は、引き続き作成後に一部の検証が行われます。

Operator がログコレクターをデプロイする前に、ClusterLogForwarder.observability.openshift.io のインスタンスが、Authorized、Valid、Ready の条件を満たしている必要があります。これらの条件の例は次のとおりです。

6.0 ステータス条件

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
status:
  conditions:
  - lastTransitionTime: "2024-09-13T03:28:44Z"
    message: 'permitted to collect log types: [application]'
    reason: ClusterRolesExist
    status: "True"
    type: observability.openshift.io/Authorized
  - lastTransitionTime: "2024-09-13T12:16:45Z"
    message: ""
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/Valid
  - lastTransitionTime: "2024-09-13T12:16:45Z"
    message: ""
    reason: ReconciliationComplete
    status: "True"
    type: Ready
  filterConditions:
  - lastTransitionTime: "2024-09-13T13:02:59Z"
    message: filter "detectexception" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidFilter-detectexception
  - lastTransitionTime: "2024-09-13T13:02:59Z"
    message: filter "parse-json" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidFilter-parse-json
  inputConditions:
  - lastTransitionTime: "2024-09-13T12:23:03Z"
    message: input "application1" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidInput-application1
  outputConditions:
  - lastTransitionTime: "2024-09-13T13:02:59Z"
    message: output "default-lokistack-application1" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidOutput-default-lokistack-application1
  pipelineConditions:
  - lastTransitionTime: "2024-09-13T03:28:44Z"
    message: pipeline "default-before" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidPipeline-default-before
Copy to Clipboard Toggle word wrap

注記

条件が満たされ、適用可能な場合の "ステータス" 値は "True" になります。ステータスが "True" 以外の条件は、理由と問題を説明するメッセージを提供します。

1.4. ログ転送の設定
リンクのコピー

ClusterLogForwarder (CLF) を使用すると、ユーザーはさまざまな宛先へのログの転送を設定できます。さまざまなソースからログメッセージを選択し、それらを変換またはフィルタリングできるパイプラインを介して送信して、1 つ以上の出力に転送する柔軟な方法を提供します。

ClusterLogForwarder の主な機能

  • 入力を使用してログメッセージを選択する
  • 出力を使用してログを外部の宛先に転送する
  • フィルターを使用してログメッセージをフィルタリング、変換、およびドロップする
  • 入力、フィルター、出力を接続するログ転送パイプラインを定義する

1.4.1. ログ収集のセットアップ
リンクのコピー

このリリースの Cluster Logging では、管理者が ClusterLogForwarder に関連付けられたサービスアカウントにログ収集権限を明示的に付与する必要があります。これは、ClusterLogging およびオプションで ClusterLogForwarder.logging.openshift.io リソースで構成されるレガシーロギングシナリオでは、以前のリリースでは必要ありませんでした。

Red Hat OpenShift Logging Operator は、collect-audit-logs、collect-application-logs、collect-infrastructure-logs クラスターロールを提供します。これにより、コレクターは監査ログ、アプリケーションログ、およびインフラストラクチャーログをそれぞれ収集できます。

必要なクラスターロールをサービスアカウントにバインドして、ログ収集をセットアップします。

1.4.1.1. レガシーサービスアカウント
リンクのコピー

既存のレガシーサービスアカウント logcollector を使用するには、次の ClusterRoleBinding を作成します。 

$ oc adm policy add-cluster-role-to-user collect-application-logs system:serviceaccount:openshift-logging:logcollector
$ oc adm policy add-cluster-role-to-user collect-infrastructure-logs system:serviceaccount:openshift-logging:logcollector
Copy to Clipboard Toggle word wrap

さらに、監査ログを収集する場合は、次の ClusterRoleBinding を作成します。 

$ oc adm policy add-cluster-role-to-user collect-audit-logs system:serviceaccount:openshift-logging:logcollector
Copy to Clipboard Toggle word wrap
1.4.1.2. サービスアカウントの作成
リンクのコピー

前提条件

  • Red Hat OpenShift Logging Operator が openshift-logging namespace にインストールされている。
  • 管理者権限がある。

手順

  1. コレクターのサービスアカウントを作成します。認証にトークンを必要とするストレージにログを書き込む場合は、サービスアカウントにトークンを含める必要があります。

  2. 適切なクラスターロールをサービスアカウントにバインドします。

    バインドコマンドの例

    $ oc adm policy add-cluster-role-to-user <cluster_role_name> system:serviceaccount:<namespace_name>:<service_account_name>
    Copy to Clipboard Toggle word wrap

1.4.1.2.1. サービスアカウントのクラスターロールバインディング
リンクのコピー

role_binding.yaml ファイルは、ClusterLogging Operator の ClusterRole を特定の ServiceAccount にバインドし、クラスター全体で Kubernetes リソースを管理できるようにします。 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: manager-rolebinding
roleRef:
1 

  apiGroup: rbac.authorization.k8s.io
2 

  kind: ClusterRole
3 

  name: cluster-logging-operator
4 

subjects:
5 

  - kind: ServiceAccount
6 

    name: cluster-logging-operator
7 

    namespace: openshift-logging
8
Copy to Clipboard Toggle word wrap
1
roleRef: バインディングが適用される ClusterRole を参照します。
2
apiGroup: RBAC API グループを示し、ClusterRole が Kubernetes の RBAC システムの一部であることを指定します。
3
kind: 参照されるロールがクラスター全体に適用される ClusterRole であることを指定します。
4
name: ServiceAccount にバインドされる ClusterRole の名前 (ここでは cluster-logging-operator)。
5
subjects: ClusterRole から権限が付与されるエンティティー (ユーザーまたはサービスアカウント) を定義します。
6
kind: サブジェクトが ServiceAccount であることを指定します。
7
Name: 権限が付与される ServiceAccount の名前。
8
namespace: ServiceAccount が配置されている namespace を示します。
1.4.1.2.2. アプリケーションログの書き込み
リンクのコピー

write-application-logs-clusterrole.yaml ファイルは、Loki ロギングアプリケーションにアプリケーションログを書き込む権限を付与する ClusterRole を定義します。 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-application-logs
rules:
1 

  - apiGroups:
2 

      - loki.grafana.com
3 

    resources:
4 

      - application
5 

    resourceNames:
6 

      - logs
7 

    verbs:
8 

      - create
9 

Annotations
<1> rules: Specifies the permissions granted by this ClusterRole.
<2> apiGroups: Refers to the API group loki.grafana.com, which relates to the Loki logging system.
<3> loki.grafana.com: The API group for managing Loki-related resources.
<4> resources: The resource type that the ClusterRole grants permission to interact with.
<5> application: Refers to the application resources within the Loki logging system.
<6> resourceNames: Specifies the names of resources that this role can manage.
<7> logs: Refers to the log resources that can be created.
<8> verbs: The actions allowed on the resources.
<9> create: Grants permission to create new logs in the Loki system.
Copy to Clipboard Toggle word wrap
1.4.1.2.3. 監査ログの書き込み
リンクのコピー

write-audit-logs-clusterrole.yaml ファイルは、Loki ロギングシステムに監査ログを作成する権限を付与する ClusterRole を定義します。 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-audit-logs
rules:
1 

  - apiGroups:
2 

      - loki.grafana.com
3 

    resources:
4 

      - audit
5 

    resourceNames:
6 

      - logs
7 

    verbs:
8 

      - create
9
Copy to Clipboard Toggle word wrap
1 1
rules: この ClusterRole によって付与される権限を定義します。
2 2
apiGroups: API グループ loki.grafana.com を指定します。
3 3
loki.grafana.com: Loki ロギングリソースを管理する API グループ。
4 4
resources: このロールが管理するリソースタイプ (この場合は audit) を指します。
5 5
audit: ロールが Loki 内の監査ログを管理することを指定します。
6 6
resourceNames: ロールがアクセスできる特定のリソースを定義します。
7 7
logs: このロールで管理できるログを指します。
8 8
verbs: リソースで許可されるアクション。
9 9
create: 新しい監査ログを作成する権限を付与します。
1.4.1.2.4. インフラストラクチャーログの書き込み
リンクのコピー

write-infrastructure-logs-clusterrole.yaml ファイルは、Loki ロギングシステムにインフラストラクチャーログを作成する権限を付与する ClusterRole を定義します。

YAML 例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-infrastructure-logs
rules:
1 

  - apiGroups:
2 

      - loki.grafana.com
3 

    resources:
4 

      - infrastructure
5 

    resourceNames:
6 

      - logs
7 

    verbs:
8 

      - create
9
Copy to Clipboard Toggle word wrap

1
ルール: この ClusterRole が付与する権限を指定します。
2
apiGroups: Loki 関連リソースの API グループを指定します。
3
loki.grafana.com: Loki ロギングシステムを管理する API グループ。
4
resources: このロールが対話できるリソースタイプを定義します。
5
infrastructure: このロールが管理するインフラストラクチャー関連のリソースを指します。
6
resourceNames: このロールが管理できるリソースの名前を指定します。
7
logs: インフラストラクチャーに関連するログリソースを指します。
8
verbs: このロールによって許可されるアクションです。
9
create: Loki システムにインフラストラクチャーログを作成する権限を付与します。
1.4.1.2.5. ClusterLogForwarder 編集者ロール
リンクのコピー

clusterlogforwarder-editor-role.yaml ファイルは、ユーザーが OpenShift で ClusterLogForwarders を管理できるようにする ClusterRole を定義します。 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: clusterlogforwarder-editor-role
rules:
1 

  - apiGroups:
2 

      - observability.openshift.io
3 

    resources:
4 

      - clusterlogforwarders
5 

    verbs:
6 

      - create
7 

      - delete
8 

      - get
9 

      - list
10 

      - patch
11 

      - update
12 

      - watch
13
Copy to Clipboard Toggle word wrap
1
ルール: この ClusterRole が付与する権限を指定します。
2
apiGroups: OpenShift 固有の API グループを指します。
3
obervability.openshift.io: ロギングなどの可観測性リソースを管理するための API グループ。
4
resources: このロールが管理できるリソースを指定します。
5
clusterlogforwarders: OpenShift のログ転送リソースを指します。
6
verbs: ClusterLogForwarders で許可されるアクションを指定します。
7
create: 新しい ClusterLogForwarders を作成する権限を付与します。
8
delete: 既存の ClusterLogForwarders を削除する権限を付与します。
9
get: 特定の ClusterLogForwarders に関する情報を取得する権限を付与します。
10
list: すべての ClusterLogForwarders のリスト表示を許可します。
11
patch: ClusterLogForwarders を部分的に変更する権限を付与します。
12
update: 既存の ClusterLogForwarders を更新する権限を付与します。
13
watch: ClusterLogForwarders への変更を監視する権限を付与します。

1.4.2. コレクターのログレベルの変更
リンクのコピー

コレクターでログレベルを変更するには、observability.openshift.io/log-level アノテーションを trace、debug、info、warn、error、および off に設定します。

ログレベルアノテーションの例

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: collector
  annotations:
    observability.openshift.io/log-level: debug
# ...
Copy to Clipboard Toggle word wrap

1.4.3. Operator の管理
リンクのコピー

ClusterLogForwarder リソースには、Operator がリソースをアクティブに管理するか、管理対象外のままにするかを制御する managementState フィールドがあります。

Managed
(デフォルト) Operator は、CLF 仕様の目的の状態に一致するようにロギングリソースを駆動します。
管理対象外
Operator は、ロギングコンポーネントに関連するアクションを一切実行しません。

これにより、管理者は managementState を Unmanaged に設定して、ログ転送を一時的に停止できます。

1.4.4. ClusterLogForwarder の構造
リンクのコピー

CLF には、次の主要コンポーネントを含む spec セクションがあります。

Inputs
転送するログメッセージを選択します。組み込みの入力タイプである application、infrastructure、および audit は、クラスターのさまざまな部分からログを転送します。カスタム入力を定義することもできます。
出力
ログを転送する宛先を定義します。各出力には、一意の名前とタイプ固有の設定があります。
Pipelines
ログが入力からフィルターを経由して出力されるまでのパスを定義します。パイプラインには一意の名前があり、入力名、出力名、フィルター名のリストで構成されます。
Filters
パイプライン内のログメッセージを変換またはドロップします。ユーザーは、特定のログフィールドに一致するフィルターを定義し、メッセージをドロップまたは変更できます。フィルターはパイプラインで指定された順序で適用されます。
1.4.4.1. Inputs
リンクのコピー

入力は spec.inputs の下の配列で設定されます。組み込みの入力タイプは 3 つあります。

application
default、openshift などのインフラストラクチャー namespace や、kube- または openshift- の接頭辞を持つ namespace 内のログを除いた、すべてのアプリケーションコンテナーからログを選択します。
infrastructure
default および openshift namespace とノードログで実行されているインフラストラクチャーコンポーネントからログを選択します。
audit
OpenShift API サーバー監査ログ、Kubernetes API サーバー監査ログ、ovn 監査ログ、および auditd からのノード監査ログからログを選択します。

ユーザーは、特定の namespace からログを選択するか、または Pod ラベルを使用してログを選択する application のカスタム入力を定義できます。

1.4.4.2. 出力
リンクのコピー

出力は spec.outputs の下の配列で構成されます。各出力には一意の名前とタイプが必要です。サポートされているタイプは次のとおりです。

azureMonitor
ログを Azure Monitor に転送します。
cloudwatch
ログを AWS CloudWatch に転送します。
elasticsearch
ログを外部の Elasticsearch インスタンスに転送します。
googleCloudLogging
ログを Google Cloud Logging に転送します。
http
ログを汎用 HTTP エンドポイントに転送します。
kafka
ログを Kafka ブローカーに転送します。
loki
ログを Loki ロギングバックエンドに転送します。
lokistack
ログを、OpenShift Container Platform 認証インテグレーションによる Loki と Web プロキシーのロギングがサポートされている組み合わせに転送します。LokiStack のプロキシーは、OpenShift Container Platform 認証を使用してマルチテナンシーを適用します。
otlp
OpenTelemetry プロトコルを使用してログを転送します。
splunk
ログを Splunk に転送します。
syslog
ログを外部の syslog サーバーに転送します。

各出力タイプには独自の設定フィールドがあります。

1.4.4.3. Pipelines
リンクのコピー

パイプラインは spec.pipelines の下の配列で設定されます。各パイプラインには一意の名前があり、次の要素で構成される必要があります。

inputRefs
このパイプラインにログを転送する入力の名前。
outputRefs
ログを送信する出力の名前。
filterRefs
(オプション) 適用するフィルターの名前。

filterRef の順序は、順次適用されるため重要です。以前のフィルターは、後のフィルターで処理されないメッセージをドロップする可能性があります。

1.4.4.4. Filters
リンクのコピー

フィルターは spec.filters の下の配列で設定されます。構造化フィールドの値に基づいて受信ログメッセージを照合し、変更または削除できます。

管理者は次のタイプのフィルターを設定できます。

1.4.4.5. 複数行の例外検出の有効化
リンクのコピー

コンテナーログの複数行のエラー検出を有効にします。

警告

この機能を有効にすると、パフォーマンスに影響が出る可能性があり、追加のコンピューティングリソースや代替のロギングソリューションが必要になる場合があります。

ログパーサーは頻繁に、同じ例外の個別の行を別々の例外として誤って識別します。その結果、余分なログエントリーが発生し、トレースされた情報が不完全または不正確な状態で表示されます。

Java 例外の例

java.lang.NullPointerException: Cannot invoke "String.toString()" because "<param1>" is null
    at testjava.Main.handle(Main.java:47)
    at testjava.Main.printMe(Main.java:19)
    at testjava.Main.main(Main.java:10)
Copy to Clipboard Toggle word wrap

  • ロギングを有効にして複数行の例外を検出し、それらを 1 つのログエントリーに再アセンブルできるようにする場合は、ClusterLogForwarder カスタムリソース (CR) に .spec.filters の下の detectMultilineErrors フィールドが含まれていることを確認します。

ClusterLogForwarder CR の例

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
  namespace: <log_forwarder_namespace>
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <name>
    type: detectMultilineException
  pipelines:
    - inputRefs:
        - <input-name>
      name: <pipeline-name>
      filterRefs:
        - <filter-name>
      outputRefs:
        - <output-name>
Copy to Clipboard Toggle word wrap

1.4.4.5.1. 詳細
リンクのコピー

ログメッセージが例外スタックトレースを形成する連続したシーケンスとして表示される場合、それらは単一の統合ログレコードに結合されます。最初のログメッセージの内容は、シーケンス内のすべてのメッセージフィールドの連結コンテンツに置き換えられます。

コレクターは次の言語をサポートしています。

  • Java
  • JS
  • Ruby
  • Python
  • golang
  • PHP
  • Dart
1.4.4.6. 不要なログレコードを削除するコンテンツフィルターの設定
リンクのコピー

drop フィルターが設定されている場合、ログコレクターは転送する前にフィルターに従ってログストリームを評価します。コレクターは、指定された設定に一致する不要なログレコードを削除します。

手順

  1. フィルターの設定を ClusterLogForwarder CR の filters 仕様に追加します。

    以下の例は、正規表現に基づいてログレコードを削除するように ClusterLogForwarder CR を設定する方法を示しています。

    ClusterLogForwarder CR の例

    apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <filter_name>
    type: drop
    1 
    
    drop:
    2 
    
    - test:
    3 
    
      - field: .kubernetes.labels."foo-bar/baz"
    4 
    
        matches: .+
    5 
    
      - field: .kubernetes.pod_name
        notMatches: "my-pod"
    6 
    
  pipelines:
  - name: <pipeline_name>
    7 
    
    filterRefs: ["<filter_name>"]
# ...
    Copy to Clipboard Toggle word wrap

    1
    フィルターのタイプを指定します。drop フィルターは、フィルター設定に一致するログレコードをドロップします。
    2
    drop フィルターを適用するための設定オプションを指定します。
    3
    ログレコードが削除されるかどうかを評価するために使用されるテストの設定を指定します。
    • テストに指定されたすべての条件が true の場合、テストは合格し、ログレコードは削除されます。
    • drop フィルター設定に複数のテストが指定されている場合、いずれかのテストに合格すると、レコードは削除されます。
    • 条件の評価中にエラーが発生した場合 (たとえば、評価対象のログレコードにフィールドがない場合)、その条件は false と評価されます。
    4
    ドットで区切られたフィールドパス (ログレコード内のフィールドへのパス) を指定します。パスには、英数字とアンダースコア (a-zA-Z0-9_) を含めることができます (例: .kubernetes.namespace_name)。セグメントにこの範囲外の文字が含まれている場合、セグメントを引用符で囲む必要があります (例: .kubernetes.labels."foo.bar-bar/baz")。1 つの test 設定に複数のフィールドパスを含めることができますが、テストに合格して drop フィルターを適用するには、すべてのフィールドパスが true と評価される必要があります。
    5
    正規表現を指定します。ログレコードがこの正規表現と一致する場合は、破棄されます。単一の field パスに対して matches または notMatches 条件のいずれかを設定できますが、両方を設定することはできません。
    6
    正規表現を指定します。ログレコードがこの正規表現に一致しない場合、破棄されます。単一の field パスに対して matches または notMatches 条件のいずれかを設定できますが、両方を設定することはできません。
    7
    drop フィルターが適用されるパイプラインを指定します。

  2. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

追加例

次の例は、優先度の高いログレコードのみを保持するように drop フィルターを設定する方法を示しています。 

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: important
    type: drop
    drop:
    - test:
      - field: .message
        notMatches: "(?i)critical|error"
      - field: .level
        matches: "info|warning"
# ...
Copy to Clipboard Toggle word wrap

単一の test 設定に複数のフィールドパスを追加する以外に、OR チェックとして扱われる追加のテストも追加できます。次の例では、いずれかの test 設定が true と評価されるとレコードが削除されます。ただし、2 番目の test 設定では、true と評価されるためには、両方のフィールド仕様が true である必要があります。 

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: important
    type: drop
    drop:
    - test:
      - field: .kubernetes.namespace_name
        matches: "^open"
    - test:
      - field: .log_type
        matches: "application"
      - field: .kubernetes.pod_name
        notMatches: "my-pod"
# ...
Copy to Clipboard Toggle word wrap
1.4.4.7. API 監査フィルターの概要
リンクのコピー

OpenShift API サーバーは、API 呼び出しごとに、リクエスト、レスポンス、リクエスターの ID の詳細を示す監査イベントを生成するため、大量のデータが生成されます。API 監査フィルターはルールを使用して、重要でないイベントを除外してイベントサイズを減少できるようにし、監査証跡をより管理しやすくします。ルールは順番にチェックされ、最初の一致でチェックが停止します。イベントに含まれるデータの量は、level フィールドの値によって決まります。

  • None: イベントはドロップされます。
  • Metadata: 監査メタデータが含まれ、リクエストおよびレスポンスの本文は削除されます。
  • Request: 監査メタデータとリクエスト本文が含まれ、レスポンス本文は削除されます。
  • RequestResponse: メタデータ、リクエスト本文、レスポンス本文のすべてのデータが含まれます。レスポンス本文が非常に大きくなる可能性があります。たとえば、oc get pods -A はクラスター内のすべての Pod の YAML 記述を含むレスポンス本文を生成します。

ClusterLogForwarder カスタムリソース (CR) は、以下の追加機能を提供しますが、標準の Kubernetes 監査ポリシー と同じ形式を使用します。

ワイルドカード
ユーザー、グループ、namespace、およびリソースの名前には、先頭または末尾に * アスタリスク文字を付けることができます。たとえば、namespace openshift-\* は openshift-apiserver または openshift-authentication に一致します。リソース \*/status は、Pod/status または Deployment/status と一致します。
デフォルトのルール

ポリシーのルールに一致しないイベントは、以下のようにフィルターされます。

  • get、list、watch などの読み取り専用システムイベントは削除されます。
  • サービスアカウントと同じ namespace 内で発生するサービスアカウント書き込みイベントはドロップされます。
  • 他のすべてのイベントは、設定されたレート制限に従って転送されます。

これらのデフォルトを無効にするには、level フィールドのみが含まれるルールでルールリストを終了するか、空のルールを追加します。

応答コードが省略される
省略する整数ステータスコードのリスト。イベントが作成されない HTTP ステータスコードをリストする OmitResponseCodes フィールドを使用して、応答で HTTP ステータスコードに基づいてイベントをドロップできます。デフォルト値は [404, 409, 422, 429] です。値が空のリスト [] の場合、ステータスコードは省略されません。

ClusterLogForwarder CR の監査ポリシーは、OpenShift Container Platform の監査ポリシーに加えて動作します。ClusterLogForwarder CR 監査フィルターは、ログコレクターが転送する内容を変更し、verb、user、group、namespace、または resource でフィルタリングする機能を提供します。複数のフィルターを作成して、同じ監査ストリームの異なるサマリーを異なる場所に送信できます。たとえば、詳細なストリームをローカルクラスターログストアに送信し、詳細度の低いストリームをリモートサイトに送信できます。

注記

監査ログを収集するには、クラスターロール collect-audit-logs が必要です。提供されている例は、監査ポリシーで可能なルールの範囲を示すことを目的としており、推奨される設定ではありません。

監査ポリシーの例

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
  namespace: <log_forwarder_namespace>
spec:
  serviceAccount:
    name: <service_account_name>
  pipelines:
    - name: my-pipeline
      inputRefs: audit
1 

      filterRefs: my-policy
2 

  filters:
    - name: my-policy
      type: kubeAPIAudit
      kubeAPIAudit:
        # Don't generate audit events for all requests in RequestReceived stage.
        omitStages:
          - "RequestReceived"

        rules:
          # Log pod changes at RequestResponse level
          - level: RequestResponse
            resources:
            - group: ""
              resources: ["pods"]

          # Log "pods/log", "pods/status" at Metadata level
          - level: Metadata
            resources:
            - group: ""
              resources: ["pods/log", "pods/status"]

          # Don't log requests to a configmap called "controller-leader"
          - level: None
            resources:
            - group: ""
              resources: ["configmaps"]
              resourceNames: ["controller-leader"]

          # Don't log watch requests by the "system:kube-proxy" on endpoints or services
          - level: None
            users: ["system:kube-proxy"]
            verbs: ["watch"]
            resources:
            - group: "" # core API group
              resources: ["endpoints", "services"]

          # Don't log authenticated requests to certain non-resource URL paths.
          - level: None
            userGroups: ["system:authenticated"]
            nonResourceURLs:
            - "/api*" # Wildcard matching.
            - "/version"

          # Log the request body of configmap changes in kube-system.
          - level: Request
            resources:
            - group: "" # core API group
              resources: ["configmaps"]
            # This rule only applies to resources in the "kube-system" namespace.
            # The empty string "" can be used to select non-namespaced resources.
            namespaces: ["kube-system"]

          # Log configmap and secret changes in all other namespaces at the Metadata level.
          - level: Metadata
            resources:
            - group: "" # core API group
              resources: ["secrets", "configmaps"]

          # Log all other resources in core and extensions at the Request level.
          - level: Request
            resources:
            - group: "" # core API group
            - group: "extensions" # Version of group should NOT be included.

          # A catch-all rule to log all other requests at the Metadata level.
          - level: Metadata
Copy to Clipboard Toggle word wrap

1
収集されるログのタイプ。このフィールドの値は、監査ログの場合は audit、アプリケーションログの場合は application、インフラストラクチャーログの場合は infrastructure、またはアプリケーションに定義された指定の入力になります。
2
監査ポリシーの名前。

input セレクターを使用して、ラベル式または照合するラベルキーとその値に基づいてアプリケーションログを含めることができます。

手順

  1. ClusterLogForwarder CR の input 仕様にフィルターの設定を追加します。

    以下の例は、ラベル式または一致したラベルキー/値に基づいてログを組み込むように ClusterLogForwarder CR を設定する方法を示しています。

    ClusterLogForwarder CR の例

    apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs
      application:
        selector:
          matchExpressions:
          - key: env
    1 
    
            operator: In
    2 
    
            values: ["prod", "qa"]
    3 
    
          - key: zone
            operator: NotIn
            values: ["east", "west"]
          matchLabels:
    4 
    
            app: one
            name: app1
      type: application
# ...
    Copy to Clipboard Toggle word wrap

    1
    照合するラベルキーを指定します。
    2
    Operator を指定します。有効な値には、In、NotIn、Exists、DoesNotExist などがあります。
    3
    文字列値の配列を指定します。Operator 値が Exists または DoesNotExist のいずれかの場合、値の配列は空である必要があります。
    4
    正確なキーまたは値のマッピングを指定します。

  2. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap
1.4.4.9. ログレコードを削除するコンテンツフィルターの設定
リンクのコピー

prune フィルターが設定されると、ログコレクターは転送前にフィルターをもとにログレベルを評価します。コレクターは、Pod アノテーションなどの値の低いフィールドを削除してログレコードを整理します。

手順

  1. フィルターの設定を ClusterLogForwarder CR の prune 仕様に追加します。

    次の例は、フィールドパスに基づいてログレコードを削除するように ClusterLogForwarder CR を設定する方法を示しています。

    重要

    両方が指定されている場合、最初に notIn 配列に基づいてレコードが整理され、in 配列よりも優先されます。notIn 配列を使用してレコードが整理された後、in 配列を使用してレコードが整理されます。

    ClusterLogForwarder CR の例

    apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <filter_name>
    type: prune
    1 
    
    prune:
    2 
    
      in: [.kubernetes.annotations, .kubernetes.namespace_id]
    3 
    
      notIn: [.kubernetes,.log_type,.message,."@timestamp"]
    4 
    
  pipelines:
  - name: <pipeline_name>
    5 
    
    filterRefs: ["<filter_name>"]
# ...
    Copy to Clipboard Toggle word wrap

    1
    フィルターのタイプを指定します。prune フィルターでは、設定されたフィールドでログレコードをプルーニングします。
    2
    prune フィルターを適用するための設定オプションを指定します。in フィールドと notIn フィールドは、ログレコード内のフィールドへのパスであるドット区切りのフィールドパスの配列として指定されます。これらのパスには、英数字とアンダースコア (a-zA-Z0-9_) を含めることができます (例: .kubernetes.namespace_name)。セグメントにこの範囲外の文字が含まれている場合、セグメントを引用符で囲む必要があります (例: .kubernetes.labels."foo.bar-bar/baz")。
    3
    オプション: この配列で指定されたフィールドはすべてログレコードから削除されます。
    4
    オプション: この配列で指定されていないフィールドはログレコードから削除されます。
    5
    prune フィルターを適用するパイプラインを指定します。
    注記

    フィルターは、log_type、.log_source、および .message フィールドを除外します。

  2. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

1.4.5. ソースによる監査およびインフラストラクチャーログ入力のフィルタリング
リンクのコピー

input セレクターを使用して、ログを収集する audit および infrastructure ソースのリストを定義できます。

手順

  1. ClusterLogForwarder CR に audit および infrastructure ソースを定義する設定を追加します。

    次の例は、ClusterLogForwarder CR を設定して audit および infrastructure ソースを定義する方法を示しています。

    ClusterLogForwarder CR の例

    apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs1
      type: infrastructure
      infrastructure:
        sources:
    1 
    
          - node
    - name: mylogs2
      type: audit
      audit:
        sources:
    2 
    
          - kubeAPI
          - openshiftAPI
          - ovn
# ...
    Copy to Clipboard Toggle word wrap

    1
    収集するインフラストラクチャーソースのリストを指定します。有効なソースには以下が含まれます。
    • node: ノードからのジャーナルログ
    • container: namespace にデプロイされたワークロードからのログ
    2
    収集する audit ソースのリストを指定します。有効なソースには以下が含まれます。
    • kubeAPI: Kubernetes API サーバーからのログ
    • openshiftAPI: OpenShift API サーバーからのログ
    • auditd: ノードの auditd サービスからのログ
    • ovn: オープン仮想ネットワークサービスからのログ

  2. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

input セレクターを使用して、namespace とコンテナー名に基づいてアプリケーションログを含めたり除外したりできます。

手順

  1. ClusterLogForwarder CR に namespace とコンテナー名を含めるか除外するかの設定を追加します。

    以下の例は、namespace およびコンテナー名を含めるか、除外するように ClusterLogForwarder CR を設定する方法を示しています。

    ClusterLogForwarder CR の例

    apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs
      application:
        includes:
          - namespace: "my-project"
    1 
    
            container: "my-container"
    2 
    
        excludes:
          - container: "other-container*"
    3 
    
            namespace: "other-namespace"
    4 
    
      type: application
# ...
    Copy to Clipboard Toggle word wrap

    1
    ログがこれらの namespace からのみ収集されることを指定します。
    2
    ログがこれらのコンテナーからのみ収集されることを指定します。
    3
    ログを収集するときに無視する namespace のパターンを指定します。
    4
    ログを収集するときに無視するコンテナーのセットを指定します。
    注記

    excludes フィールドは includes フィールドよりも優先されます。

  2. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

1.5. LokiStack でログを保存する
リンクのコピー

アプリケーション、監査、インフラストラクチャー関連のログを保存するように LokiStack CR を設定できます。

Loki は、OpenShift Observability UI で視覚化できる Red Hat OpenShift のログ記録用の GA ログストアとして提供される、水平方向にスケーラブルで可用性の高いマルチテナントログ集約システムです。OpenShift Logging が提供する Loki 設定は、収集されたログを使用してユーザーが迅速にトラブルシューティングを実行できるように設計された短期ログストアです。この目的のために、Loki の Red Hat OpenShift 設定のロギングには短期ストレージがあり、最新のクエリーに最適化されています。

重要

長期間にわたる保存やクエリーの場合、ユーザーはクラスター外部のログストアを探す必要があります。Loki のサイズ設定は、最大 30 日間の短期ストレージに対してのみテストおよびサポートされます。

1.5.1. 前提条件
リンクのコピー

  • CLI または Web コンソールを使用して Loki Operator をインストールしている。
  • ClusterLogForwarder を作成するのと同じ namespace に serviceAccount がある。
  • serviceAccount に collect-audit-logs、collect-application-logs、collect-infrastructure-logs のクラスターロールが割り当てられている。

1.5.2. コアのセットアップと設定
リンクのコピー

ロールベースのアクセス制御、基本的なモニタリング、および Loki をデプロイするための Pod の配置。

1.5.3. LokiStack ルールの RBAC 権限の認可
リンクのコピー

管理者は、クラスターロールをユーザー名にバインドすることで、ユーザーが独自のアラートおよび記録ルールを作成および管理できるようにすることができます。クラスターロールは、ユーザーに必要なロールベースのアクセス制御 (RBAC) 権限を含む ClusterRole オブジェクトとして定義されます。

LokiStack では、アラートおよび記録ルール用の次のクラスターロールが利用できます。

Expand
ルール名説明

alertingrules.loki.grafana.com-v1-admin

このロールを持つユーザーは、アラートルールを管理する管理レベルのアクセス権を持ちます。このクラスターロールは、loki.grafana.com/v1 API グループ内の AlertingRule リソースを作成、読み取り、更新、削除、リスト表示、および監視する権限を付与します。

alertingrules.loki.grafana.com-v1-crdview

このロールを持つユーザーは、loki.grafana.com/v1 API グループ内の AlertingRule リソースに関連するカスタムリソース定義 (CRD) の定義を表示できますが、これらのリソースを変更または管理する権限を持ちません。

alertingrules.loki.grafana.com-v1-edit

このロールを持つユーザーは、AlertingRule リソースを作成、更新、および削除する権限を持ちます。

alertingrules.loki.grafana.com-v1-view

このロールを持つユーザーは、loki.grafana.com/v1 API グループ内の AlertingRule リソースを読み取ることができます。既存のアラートルールの設定、ラベル、およびアノテーションを検査できますが、それらを変更することはできません。

recordingrules.loki.grafana.com-v1-admin

このロールを持つユーザーは、記録ルールを管理する管理レベルのアクセス権を持ちます。このクラスターロールは、loki.grafana.com/v1 API グループ内の RecordingRule リソースを作成、読み取り、更新、削除、リスト表示、および監視する権限を付与します。

recordingrules.loki.grafana.com-v1-crdview

このロールを持つユーザーは、loki.grafana.com/v1 API グループ内の RecordingRule リソースに関連するカスタムリソース定義 (CRD) の定義を表示できますが、これらのリソースを変更または管理する権限を持ちません。

recordingrules.loki.grafana.com-v1-edit

このロールを持つユーザーは、RecordingRule リソースを作成、更新、および削除する権限を持ちます。

recordingrules.loki.grafana.com-v1-view

このロールを持つユーザーは、loki.grafana.com/v1 API グループ内の RecordingRule リソースを読み取ることができます。既存のアラートルールの設定、ラベル、およびアノテーションを検査できますが、それらを変更することはできません。

1.5.3.1. 例
リンクのコピー

ユーザーにクラスターロールを適用するには、既存のクラスターロールを特定のユーザー名にバインドする必要があります。

クラスターロールは、使用するロールバインディングの種類に応じて、クラスタースコープまたは namespace スコープにすることができます。RoleBinding オブジェクトを使用する場合は、oc adm policy add-role-to-user コマンドを使用する場合と同様に、クラスターロールが指定した namespace にのみ適用されます。ClusterRoleBinding オブジェクトを使用する場合は、oc adm policy add-cluster-role-to-user コマンドを使用する場合と同様に、クラスターロールがクラスター内のすべての namespace に適用されます。

次のコマンド例では、指定したユーザーに、クラスター内の特定の namespace のアラートルールに対する作成、読み取り、更新、および削除 (CRUD) 権限を付与します。

特定の namespace のアラートルールに対する CRUD 権限を付与するクラスターロールバインディングコマンドの例

$ oc adm policy add-role-to-user alertingrules.loki.grafana.com-v1-admin -n <namespace> <username>
Copy to Clipboard Toggle word wrap

次のコマンドは、指定したユーザーに、すべての namespace のアラートルールに対する管理者権限を付与します。

管理者権限を付与するクラスターロールバインディングコマンドの例

$ oc adm policy add-cluster-role-to-user alertingrules.loki.grafana.com-v1-admin <username>
Copy to Clipboard Toggle word wrap

1.5.4. Loki を使用したログベースのアラートルールの作成
リンクのコピー

AlertingRule CR には、単一の LokiStack インスタンスのアラートルールグループを宣言するために使用する、仕様および Webhook 検証定義のセットが含まれます。Webhook 検証定義は、ルール検証条件もサポートします。

  • AlertingRule CR に無効な interval 期間が含まれる場合、無効なアラートルールです。
  • AlertingRule CR に無効な for 期間が含まれる場合、無効なアラートルールです。
  • AlertingRule CR に無効な LogQL expr が含まれる場合、無効なアラートルールです。
  • AlertingRule CR に同じ名前のグループが 2 つ含まれる場合、無効なアラートルールです。
  • 上記のいずれも該当しない場合、アラートルールは有効とみなされます。
Expand
表1.2 AlertingRule の定義
テナントタイプAlertingRule CR の有効な namespace

application

<your_application_namespace>

audit

openshift-logging

infrastructure

openshift-/*、kube-/\*、default

手順

  1. AlertingRule カスタムリソース (CR) を作成します。

    インフラストラクチャー AlertingRule CR の例

      apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: loki-operator-alerts
    namespace: openshift-operators-redhat
    1 
    
    labels:
    2 
    
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "infrastructure"
    3 
    
    groups:
      - name: LokiOperatorHighReconciliationError
        rules:
          - alert: HighPercentageError
            expr: |
    4 
    
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"} |= "error" [1m])) by (job)
                /
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"}[1m])) by (job)
                > 0.01
            for: 10s
            labels:
              severity: critical
    5 
    
            annotations:
              summary: High Loki Operator Reconciliation Errors
    6 
    
              description: High Loki Operator Reconciliation Errors
    7
    Copy to Clipboard Toggle word wrap

    1
    この AlertingRule CR が作成される namespace には、LokiStack spec.rules.namespaceSelector 定義に一致するラベルが必要です。
    2
    labels ブロックは、LokiStack の spec.rules.selector 定義と一致する必要があります。
    3
    infrastructure テナントの AlertingRule CR は、openshift-*、kube-\*、または default namespaces でのみサポートされます。
    4
    kubernetes_namespace_name: の値は、metadata.namespace の値と一致する必要があります。
    5
    この必須フィールドの値は、critical、warning、または info である必要があります。
    6
    このフィールドは必須です。
    7
    このフィールドは必須です。

    アプリケーション AlertingRule CR の例

      apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: app-user-workload
    namespace: app-ns
    1 
    
    labels:
    2 
    
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "application"
    groups:
      - name: AppUserWorkloadHighError
        rules:
          - alert:
            expr: |
    3 
    
              sum(rate({kubernetes_namespace_name="app-ns", kubernetes_pod_name=~"podName.*"} |= "error" [1m])) by (job)
            for: 10s
            labels:
              severity: critical
    4 
    
            annotations:
              summary:
    5 
    
              description:
    6
    Copy to Clipboard Toggle word wrap

    1
    この AlertingRule CR が作成される namespace には、LokiStack spec.rules.namespaceSelector 定義に一致するラベルが必要です。
    2
    labels ブロックは、LokiStack の spec.rules.selector 定義と一致する必要があります。
    3
    kubernetes_namespace_name: の値は、metadata.namespace の値と一致する必要があります。
    4
    この必須フィールドの値は、critical、warning、または info である必要があります。
    5
    この必須フィールドの値は、ルールの概要です。
    6
    この必須フィールドの値は、ルールの詳細な説明です。

  2. AlertingRule CR を適用します。 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

1.5.5. メンバーリストの作成の失敗を許容する Loki の設定
リンクのコピー

OpenShift Container Platform クラスターでは、管理者は通常、非プライベート IP ネットワーク範囲を使用します。その結果、LokiStack メンバーリストはデフォルトでプライベート IP ネットワークのみを使用するため、LokiStack メンバーリストの設定は失敗します。

管理者は、メンバーリスト設定の Pod ネットワークを選択できます。LokiStack カスタムリソース (CR) を変更して、hashRing 仕様で podIP アドレスを使用できます。LokiStack CR を設定するには、以下のコマンドを使用します。 

$ oc patch LokiStack logging-loki -n openshift-logging  --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP"},"type":"memberlist"}}}'
Copy to Clipboard Toggle word wrap

podIPを含める LokiStack の例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  hashRing:
    type: memberlist
    memberlist:
      instanceAddrType: podIP
# ...
Copy to Clipboard Toggle word wrap

1.5.6. Loki でストリームベースの保持の有効化
リンクのコピー

ログストリームに基づいて保持ポリシーを設定できます。これらのルールは、グローバル、テナントごと、またはその両方で設定できます。両方で設定すると、グローバルルールの前にテナントルールが適用されます。

重要

s3 バケットまたは LokiStack カスタムリソース (CR) に保存期間が定義されていない場合、ログは削除されず、s3 バケットに永久に残り、s3 ストレージがいっぱいになる可能性があります。

注記

スキーマ v13 が推奨されます。

手順

  1. LokiStack CR を作成します。

    • 次の例に示すように、ストリームベースの保持をグローバルに有効にします。

      AWS のグローバルストリームベースの保持の例

      apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
   global:
      1 
      
      retention:
      2 
      
        days: 20
        streams:
        - days: 4
          priority: 1
          selector: '{kubernetes_namespace_name=~"test.+"}'
      3 
      
        - days: 1
          priority: 1
          selector: '{log_type="infrastructure"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v13
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging
      Copy to Clipboard Toggle word wrap

      1
      すべてのログストリームの保持ポリシーを設定します。注記: このフィールドは、オブジェクトストレージに保存されたログの保持期間には影響しません。
      2
      このブロックが CR に追加されると、クラスターで保持が有効になります。
      3
      ログ stream.spec: 制限を定義するために使用される LogQL クエリー が含まれます。

    • 次の例に示すように、テナントごとにストリームベースの保持を有効にします。

      AWS のテナントごとのストリームベースの保持の例

      apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global:
      retention:
        days: 20
    tenants:
      1 
      
      application:
        retention:
          days: 1
          streams:
            - days: 4
              selector: '{kubernetes_namespace_name=~"test.+"}'
      2 
      
      infrastructure:
        retention:
          days: 5
          streams:
            - days: 1
              selector: '{kubernetes_namespace_name=~"openshift-cluster.+"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v13
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging
      Copy to Clipboard Toggle word wrap

      1
      テナントごとの保持ポリシーを設定します。有効なテナントタイプは、application、audit、および infrastructure です。
      2
      ログストリームの定義に使用される LogQL クエリー が含まれています。

  2. LokiStack CR を適用します。 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

1.5.7. Loki Pod の配置
リンクのコピー

Pod の toleration またはノードセレクターを使用して、Loki Pod が実行するノードを制御し、他のワークロードがそれらのノードを使用しないようにできます。

LokiStack カスタムリソース (CR) を使用して toleration をログストア Pod に適用し、ノード仕様を使用して taint をノードに適用できます。ノードの taint は、taint を容認しないすべての Pod を拒否するようノードに指示する key:value ペアです。他の Pod にはない特定の key:value ペアを使用すると、ログストア Pod のみがそのノードで実行できるようになります。

ノードセレクターを使用する LokiStack の例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
1 

      nodeSelector:
        node-role.kubernetes.io/infra: ""
2 

    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
# ...
Copy to Clipboard Toggle word wrap

1
ノードセレクターに適用されるコンポーネント Pod タイプを指定します。
2
定義されたラベルが含まれるノードに移動する Pod を指定します。

ノードセレクターと toleration を使用する LokiStack CR の例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
# ...
Copy to Clipboard Toggle word wrap

LokiStack (CR) の nodeSelector フィールドと tolerations フィールドを設定するには、oc explain コマンドを使用して、特定のリソースの説明とフィールドを表示します。 

$ oc explain lokistack.spec.template
Copy to Clipboard Toggle word wrap

出力例

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: template <Object>

DESCRIPTION:
     Template defines the resource/limits/tolerations/nodeselectors per
     component

FIELDS:
   compactor	<Object>
     Compactor defines the compaction component spec.

   distributor	<Object>
     Distributor defines the distributor component spec.
...
Copy to Clipboard Toggle word wrap

詳細情報用に、特定のフィールドを追加できます。 

$ oc explain lokistack.spec.template.compactor
Copy to Clipboard Toggle word wrap

出力例

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: compactor <Object>

DESCRIPTION:
     Compactor defines the compaction component spec.

FIELDS:
   nodeSelector	<map[string]string>
     NodeSelector defines the labels required by a node to schedule the
     component onto it.
...
Copy to Clipboard Toggle word wrap

1.5.7.1. 信頼性とパフォーマンスの向上
リンクのコピー

実稼働環境における Loki の信頼性と効率性を確保するための設定。

1.5.7.2. 有効期間の短いトークンを使用したクラウドベースのログストアへの認証の有効化
リンクのコピー

ワークロードアイデンティティーフェデレーションを使用すると、有効期間の短いトークンを使用してクラウドベースのログストアに対して認証できます。

手順

  • 認証を有効にするには、次のいずれかのオプションを使用します。

    • OpenShift Container Platform Web コンソールを使用して Loki Operator をインストールすると、有効期間が短いトークンを使用するクラスターが自動的に検出されます。プロンプトが表示され、ロールを作成するように求められます。また、Loki Operator が CredentialsRequest オブジェクトを作成するのに必要なデータを提供するように求められます。このオブジェクトにより、シークレットが設定されます。

    • OpenShift CLI (oc) を使用して Loki Operator をインストールする場合は、次の例に示すように、ストレージプロバイダーに適したテンプレートを使用して Subscription オブジェクトを手動で作成する必要があります。この認証ストラテジーは、指定のストレージプロバイダーでのみサポートされます。

      Azure サンプルサブスクリプションの例

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-6.0"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
      - name: CLIENTID
        value: <your_client_id>
      - name: TENANTID
        value: <your_tenant_id>
      - name: SUBSCRIPTIONID
        value: <your_subscription_id>
      - name: REGION
        value: <your_region>
      Copy to Clipboard Toggle word wrap

      AWS サンプルサブスクリプションの例

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-6.0"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
    - name: ROLEARN
      value: <role_ARN>
      Copy to Clipboard Toggle word wrap

1.5.7.3. ノードの障害を許容するための Loki の設定
リンクのコピー

Loki Operator は、同じコンポーネントの Pod がクラスター内の異なる使用可能なノードにスケジュールされるように要求する Pod アンチアフィニティールールの設定をサポートしています。

アフィニティーとは、スケジュールするノードを制御する Pod の特性です。非アフィニティーとは、Pod がスケジュールされることを拒否する Pod の特性です。

OpenShift Container Platform では、Pod のアフィニティー と Pod の非アフィニティー によって、他の Pod のキー/値ラベルに基づいて、Pod のスケジュールに適したノードを制限できます。

Operator は、すべての Loki コンポーネント (compactor、distributor、gateway、indexGateway、ingester、querier、queryFrontend、および ruler コンポーネントを含む) に対してデフォルトの優先 podAntiAffinity ルールを設定します。

requiredDuringSchedulingIgnoredDuringExecution フィールドに必要な設定を指定して、Loki コンポーネントの希望の podAntiAffinity 設定を上書きできます。

インジェスターコンポーネントのユーザー設定の例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    ingester:
      podAntiAffinity:
      # ...
        requiredDuringSchedulingIgnoredDuringExecution:
1 

        - labelSelector:
            matchLabels:
2 

              app.kubernetes.io/component: ingester
          topologyKey: kubernetes.io/hostname
# ...
Copy to Clipboard Toggle word wrap

1
必要なルールを定義するスタンザです。
2
ルールを適用するために一致している必要のあるキー/値のペア (ラベル) です。
1.5.7.4. クラスターの再起動中の LokiStack 動作
リンクのコピー

OpenShift Container Platform クラスターが再起動されると、LokiStack の取り込みとクエリーパスは、ノードで使用可能な CPU およびメモリーリソース内で引き続き動作します。つまり、OpenShift Container Platform クラスターの更新中に LokiStack でダウンタイムは発生しません。この動作は、PodDisruptionBudget リソースを使用して実現されます。Loki Operator は、Loki に PodDisruptionBudget リソースをプロビジョニングするため、特定の条件下で通常の動作を保証するためにコンポーネントごとに必要最小限、使用可能な Pod 数が決定されます。

1.5.7.5. 高度なデプロイメントとスケーラビリティー
リンクのコピー

高可用性、スケーラビリティー、エラー処理のための特殊な設定。

1.5.7.6. ゾーン対応のデータレプリケーション
リンクのコピー

Loki Operator は、Pod トポロジーの分散制約を通じて、ゾーン対応のデータレプリケーションのサポートを提供します。この機能を有効にすると、信頼性が向上し、1 つのゾーンで障害が発生した場合のログ損失に対する保護が強化されます。デプロイメントサイズを 1x.extra.small、1x.small、または 1x.medium に設定すると、replication.factor フィールドは自動的に 2 に設定されます。

適切なレプリケーションを実現するには、少なくともレプリケーション係数で指定されているのと同じ数のアベイラビリティーゾーンが必要です。レプリケーション係数より多くのアベイラビリティーゾーンを設定することは可能ですが、ゾーンが少ないと書き込みエラーが発生する可能性があります。最適な運用を実現するには、各ゾーンで同じ数のインスタンスをホストする必要があります。

ゾーンレプリケーションが有効になっている LokiStack CR の例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
 name: logging-loki
 namespace: openshift-logging
spec:
 replicationFactor: 2
1 

 replication:
   factor: 2
2 

   zones:
   -  maxSkew: 1
3 

      topologyKey: topology.kubernetes.io/zone
4
Copy to Clipboard Toggle word wrap

1
非推奨のフィールド。入力された値は replication.factor によって上書きされます。
2
この値は、セットアップ時にデプロイメントサイズが選択されると自動的に設定されます。
3
任意の 2 つのトポロジードメイン間の Pod 数の最大差。デフォルトは 1 で、0 の値を指定することはできません。
4
ノードラベルに対応するトポロジーキーの形式でゾーンを定義します。
1.5.7.7. 障害が発生したゾーンからの Loki Pod の回復
リンクのコピー

OpenShift Container Platform では、特定のアベイラビリティーゾーンのリソースにアクセスできなくなると、ゾーン障害が発生します。アベイラビリティーゾーンは、冗長性とフォールトトレランスを強化することを目的とした、クラウドプロバイダーのデータセンター内の分離されたエリアです。OpenShift Container Platform クラスターがこの問題を処理するように設定されていない場合、ゾーン障害によりサービスまたはデータの損失が発生する可能性があります。

Loki Pod は StatefulSet の一部であり、StorageClass オブジェクトによってプロビジョニングされた永続ボリューム要求 (PVC) が付属しています。各 Loki Pod とその PVC は同じゾーンに存在します。クラスターでゾーン障害が発生すると、StatefulSet コントローラーが、障害が発生したゾーン内の影響を受けた Pod の回復を自動的に試みます。

警告

次の手順では、障害が発生したゾーン内の PVC とそこに含まれるすべてのデータを削除します。完全なデータ損失を回避するには、LokiStack CR のレプリケーション係数フィールドを常に 1 より大きい値に設定して、Loki が確実にレプリケートされるようにする必要があります。

前提条件

  • LokiStack CR のレプリケーション係数が 1 より大きいことを確認している。
  • コントロールプレーンによってゾーン障害が検出され、障害が発生したゾーン内のノードがクラウドプロバイダー統合によってマークされている。

StatefulSet コントローラーは、障害が発生したゾーン内の Pod を自動的に再スケジュールしようとします。関連する PVC も障害が発生したゾーンにあるため、別のゾーンへの自動再スケジュールは機能しません。新しいゾーンでステートフル Loki Pod とそのプロビジョニングされた PVC を正常に再作成できるようにするには、障害が発生したゾーンの PVC を手動で削除する必要があります。

手順

  1. 次のコマンドを実行して、Pending 中ステータスの Pod をリスト表示します。 

    $ oc get pods --field-selector status.phase==Pending -n openshift-logging
    Copy to Clipboard Toggle word wrap

    oc get pods の出力例

    NAME                           READY   STATUS    RESTARTS   AGE
    1 
    
logging-loki-index-gateway-1   0/1     Pending   0          17m
logging-loki-ingester-1        0/1     Pending   0          16m
logging-loki-ruler-1           0/1     Pending   0          16m
    Copy to Clipboard Toggle word wrap

    1
    これらの Pod は、障害が発生したゾーンに対応する PVC があるため、Pending ステータスになっています。

  2. 次のコマンドを実行して、Pending ステータスの PVC をリストします。 

    $ oc get pvc -o=json -n openshift-logging | jq '.items[] | select(.status.phase == "Pending") | .metadata.name' -r
    Copy to Clipboard Toggle word wrap

    oc get pvc の出力例

    storage-logging-loki-index-gateway-1
storage-logging-loki-ingester-1
wal-logging-loki-ingester-1
storage-logging-loki-ruler-1
wal-logging-loki-ruler-1
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して Pod の PVC を削除します。 

    $ oc delete pvc <pvc_name>  -n openshift-logging
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して Pod を削除します。 

    $ oc delete pod <pod_name>  -n openshift-logging
    Copy to Clipboard Toggle word wrap

    これらのオブジェクトが正常に削除されると、使用可能なゾーンでオブジェクトが自動的に再スケジュールされます。

1.5.7.7.1. terminating 状態の PVC のトラブルシューティング
リンクのコピー

PVC メタデータファイナライザーが kubernetes.io/pv-protection に設定されている場合、PVC が削除されずに terminating 状態でハングする可能性があります。ファイナライザーを削除すると、PVC が正常に削除されるようになります。

  • 以下のコマンドを実行して各 PVC のファイナライザーを削除し、削除を再試行します。 

    $ oc patch pvc <pvc_name> -p '{"metadata":{"finalizers":null}}' -n openshift-logging
    Copy to Clipboard Toggle word wrap
1.5.7.8. Loki レート制限エラーのトラブルシューティング
リンクのコピー

Log Forwarder API がレート制限を超える大きなメッセージブロックを Loki に転送すると、Loki により、レート制限 (429) エラーが生成されます。

これらのエラーは、通常の動作中に発生する可能性があります。たとえば、すでにいくつかのログがあるクラスターにロギングを追加する場合、ロギングが既存のログエントリーをすべて取り込もうとするとレート制限エラーが発生する可能性があります。この場合、新しいログの追加速度が合計レート制限よりも低い場合、履歴データは最終的に取り込まれ、ユーザーの介入を必要とせずにレート制限エラーが解決されます。

レート制限エラーが引き続き発生する場合は、LokiStack カスタムリソース (CR) を変更することで問題を解決できます。

重要

LokiStack CR は、Grafana がホストする Loki では利用できません。このトピックは、Grafana がホストする Loki サーバーには適用されません。

条件

  • Log Forwarder API は、ログを Loki に転送するように設定されている。

  • システムは、次のような 2MB を超えるメッセージのブロックを Loki に送信する。以下に例を示します。 

    "values":[["1630410392689800468","{\"kind\":\"Event\",\"apiVersion\":\
.......
......
......
......
\"received_at\":\"2021-08-31T11:46:32.800278+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-31T11:46:32.799692+00:00\",\"viaq_index_name\":\"audit-write\",\"viaq_msg_id\":\"MzFjYjJkZjItNjY0MC00YWU4LWIwMTEtNGNmM2E5ZmViMGU4\",\"log_type\":\"audit\"}"]]}]}
    Copy to Clipboard Toggle word wrap

  • oc logs -n openshift-logging -l component=collector と入力すると、クラスター内のコレクターログに、次のいずれかのエラーメッセージを含む行が表示されます。 

    429 Too Many Requests Ingestion rate limit exceeded
    Copy to Clipboard Toggle word wrap

    Vector エラーメッセージの例

    2023-08-25T16:08:49.301780Z  WARN sink{component_kind="sink" component_id=default_loki_infra component_type=loki component_name=default_loki_infra}: vector::sinks::util::retries: Retrying after error. error=Server responded with an error: 429 Too Many Requests internal_log_rate_limit=true
    Copy to Clipboard Toggle word wrap

    Fluentd エラーメッセージの例

    2023-08-30 14:52:15 +0000 [warn]: [default_loki_infra] failed to flush the buffer. retry_times=2 next_retry_time=2023-08-30 14:52:19 +0000 chunk="604251225bf5378ed1567231a1c03b8b" error_class=Fluent::Plugin::LokiOutput::LogPostError error="429 Too Many Requests Ingestion rate limit exceeded for user infrastructure (limit: 4194304 bytes/sec) while attempting to ingest '4082' lines totaling '7820025' bytes, reduce log volume or contact your Loki administrator to see if the limit can be increased\n"
    Copy to Clipboard Toggle word wrap

    このエラーは受信側にも表示されます。たとえば、LokiStack 取り込み Pod で以下を行います。

    Loki 取り込みエラーメッセージの例

    level=warn ts=2023-08-30T14:57:34.155592243Z caller=grpc_logging.go:43 duration=1.434942ms method=/logproto.Pusher/Push err="rpc error: code = Code(429) desc = entry with timestamp 2023-08-30 14:57:32.012778399 +0000 UTC ignored, reason: 'Per stream rate limit exceeded (limit: 3MB/sec) while attempting to ingest for stream
    Copy to Clipboard Toggle word wrap

手順

  • LokiStack CR の ingestionBurstSize および ingestionRate フィールドを更新します。 

    apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global:
      ingestion:
        ingestionBurstSize: 16
    1 
    
        ingestionRate: 8
    2 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    ingestionBurstSize フィールドは、ディストリビューターレプリカごとに最大ローカルレート制限サンプルサイズを MB 単位で定義します。この値はハードリミットです。この値を、少なくとも 1 つのプッシュリクエストで想定される最大ログサイズに設定します。ingestionBurstSize 値より大きい単一リクエストは使用できません。
    2
    ingestionRate フィールドは、1 秒あたりに取り込まれるサンプルの最大量 (MB 単位) に対するソフト制限です。ログのレートが制限を超えているにもかかわらず、コレクターがログの送信を再試行すると、レート制限エラーが発生します。合計平均が制限よりも少ない場合に限り、システムは回復し、ユーザーの介入なしでエラーが解決されます。

1.6. ロギングの可視化
リンクのコピー

ロギングの可視化は、Cluster Observability Operator の Logging UI プラグイン をデプロイすることで提供されます。そのためには Operator のインストールが必要です。

重要

現在は テクノロジープレビュー (TP) 機能である Cluster Observability Operator (COO) の一般提供 (GA) リリースが近づくまで、Red Hat は、OpenShift Container Platform 4.14 以降の Logging UI プラグイン の COO で Logging 6.0 以降を使用しているお客様にサポートを提供します。COO にはいくつかの独立した機能が含まれており、その一部はまだテクノロジープレビュー機能であるため、このサポート例外は一時的なものです。ただし、Logging UI プラグインは GA の準備が完了しています。

第2章 Logging 6.1
リンクのコピー

2.1. Logging 6.1
リンクのコピー

2.1.1. Logging 6.1.0 リリースノート
リンクのコピー

このリリースには、Logging for Red Hat OpenShift バグ修正リリース 6.1.0 が含まれています。

2.1.1.1. 新機能および改良された機能
リンクのコピー
2.1.1.1.1. ログの収集
リンクのコピー
  • この機能拡張により、収集されたコンテナーログから送信される属性にソース iostream が追加されます。値は、コレクターがそれを受信した方法に基づき、stdout または stderr のいずれかに設定されます。(LOG-5292)
  • この更新により、コレクターのデフォルトのメモリー制限が 1024 Mi から 2048 Mi に増加します。ユーザーは、クラスターの特定のニーズと仕様に基づきリソース制限を調整する必要があります。(LOG-6072)
  • この更新により、ユーザーは ClusterLogForwarder CR の syslog 出力配信モードを AtLeastOnce または AtMostOnce のいずれかに設定できるようになります。(LOG-6355)
2.1.1.1.2. ログのストレージ
リンクのコピー
  • この更新により、新しい 1x.pico LokiStack サイズは、ワークロードとログボリュームが少ないクラスター (最大 50 GB/日) をサポーするようになります。(LOG-5939)
2.1.1.2. テクノロジープレビュー
リンクのコピー
重要

OpenTelemetry Protocol (OTLP) 出力ログフォワーダーは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

  • この更新により、OTel (OpenTelemetry) データモデルを使用して OpenTelemetry ログを Red Hat Managed LokiStack インスタンスに転送できるようになります。この機能を有効にするには、ClusterLogForwarder 設定に observability.openshift.io/tech-preview-otlp-output: "enabled" アノテーションを追加します。追加の設定情報については、OTLP 転送 を参照してください。
  • この更新により、lokiStack 出力仕様に dataModel フィールドが追加されます。OpenTelemetry データ形式を使用するログ転送を設定するには、dataModel を Otel に設定します。デフォルトは Viaq に設定されています。データマッピングの詳細は、OTLP 仕様 を参照してください。
2.1.1.3. バグ修正
リンクのコピー

なし。

2.1.1.4. CVE
リンクのコピー

2.2. Logging 6.1
リンクのコピー

コンテキスト：logging-6x-6.1

ClusterLogForwarder カスタムリソース (CR) は、ログの収集と転送の中心的な設定ポイントです。

2.2.1. 入力と出力
リンクのコピー

入力では、転送するログのソースを指定します。Logging には、クラスターのさまざまな部分からログを選択するための入力タイプ (application、receiver、infrastructure、audit) が組み込まれています。namespace または Pod ラベルに基づいてカスタム入力を定義し、ログの選択を微調整することもできます。

出力は、ログが送信される宛先を定義します。各出力タイプには独自の設定オプションセットがあり、動作と認証設定をカスタマイズできます。

2.2.2. レシーバー入力タイプ
リンクのコピー

レシーバー入力タイプにより、Logging システムは外部ソースからのログを受け入れることができます。ログを受信するための 2 つの形式 (http と syslog) がサポートされます。

ReceiverSpec は、レシーバー入力の設定を定義します。

2.2.3. パイプラインとフィルター
リンクのコピー

パイプラインは、入力から出力へのログのフローを決定します。パイプラインは、1 つ以上の入力参照、出力参照、およびオプションのフィルター参照で構成されます。フィルターを使用して、パイプライン内のログメッセージを変換または削除できます。フィルターは順番に適用されるため、フィルターの順序は重要であり、最初の方のフィルターを使用すると、ログメッセージが後のステージに到達するのを防ぐことができます。

2.2.4. Operator の動作
リンクのコピー

Cluster Logging Operator は、ClusterLogForwarder リソースの managementState フィールドに基づき、コレクターのデプロイメントと設定を管理します。

  • Managed (デフォルト) に設定すると、Operator は仕様で定義された設定に一致するように、ロギングリソースをアクティブに管理します。
  • Unmanaged に設定すると、Operator はアクションを実行せず、ロギングコンポーネントを手動で管理できます。

2.2.5. 検証
リンクのコピー

ロギングには、スムーズでエラーのない設定エクスペリエンスを確保するために、広範な検証ルールやデフォルト値が含まれます。ClusterLogForwarder リソースは、必須フィールド、フィールド間の依存関係、および入力値の形式の検証チェックを強制します。特定のフィールドにはデフォルト値が提供されるため、一般的なシナリオで明示的な設定を行う必要性が軽減されます。

2.2.6. クイックスタート
リンクのコピー

OpenShift Logging は 2 つのデータモデルをサポートしています。

  • ViaQ (一般提供)
  • OpenTelemetry (テクノロジープレビュー)

ClusterLogForwarder の lokiStack.dataModel フィールドを設定することにより、要件に基づきこれらのデータモデルのいずれかを選択できます。ViaQ は、ログを LokiStack に転送する際のデフォルトのデータモデルです。

注記

OpenShift Logging の今後のリリースでは、デフォルトのデータモデルが ViaQ から OpenTelemetry に変更されます。

2.2.6.1. ViaQ のクイックスタート
リンクのコピー

デフォルトの ViaQ データモデルを使用するには、次の手順に従います。

前提条件

  • クラスター管理者のパーミッション。

手順

  1. OperatorHub から、Red Hat OpenShift Logging Operator、Loki Operator、Cluster Observability Operator (COO) をインストールします。

  2. openshift-logging namespace に LokiStack カスタムリソース (CR) を作成します。 

    apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  managementState: Managed
  size: 1x.extra-small
  storage:
    schemas:
    - effectiveDate: '2024-10-01'
      version: v13
    secret:
      name: logging-loki-s3
      type: s3
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging
    Copy to Clipboard Toggle word wrap
    注記

    事前に logging-loki-s3 シークレットが事前に作成されていることを確認します。このシークレットの内容は、使用しているオブジェクトストレージにより異なります。詳細は、シークレットと TLS 設定を参照してください。

  3. コレクターのサービスアカウントを作成します。 

    $ oc create sa collector -n openshift-logging
    Copy to Clipboard Toggle word wrap

  4. コレクターのサービスアカウントによる LokiStack CR へのデータ書き込みを許可します。 

    $ oc adm policy add-cluster-role-to-user logging-collector-logs-writer -z collector
    Copy to Clipboard Toggle word wrap
    注記

    ClusterRole リソースは、Cluster Logging Operato のインストール中に自動的に作成されるため、手動で作成する必要はありません。

  5. コレクターのサービスアカウントによるログ収集を許可します。 

    $ oc project openshift-logging
    Copy to Clipboard Toggle word wrap 
    $ oc adm policy add-cluster-role-to-user collect-application-logs -z collector
    Copy to Clipboard Toggle word wrap 
    $ oc adm policy add-cluster-role-to-user collect-audit-logs -z collector
    Copy to Clipboard Toggle word wrap 
    $ oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z collector
    Copy to Clipboard Toggle word wrap
    注記

    この例では、コレクターを 3 つのロール (アプリケーション、インフラストラクチャー、監査) すべてにバインドしますが、デフォルトでは、アプリケーションログとインフラストラクチャーログのみが収集されます。監査ログを収集するには、ClusterLogForwarder 設定を更新して監査ログを含めます。環境に必要な特定のログタイプに基づきロールを割り当てます。

  6. Observe タブの Log セクションを有効にするには、UIPlugin CR を作成します。 

    apiVersion: observability.openshift.io/v1alpha1
kind: UIPlugin
metadata:
  name: logging
spec:
  type: Logging
  logging:
    lokiStack:
      name: logging-loki
    Copy to Clipboard Toggle word wrap

  7. ログ転送を設定するには、ClusterLogForwarder CR を作成します。 

    apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: collector
  namespace: openshift-logging
spec:
  serviceAccount:
    name: collector
  outputs:
  - name: default-lokistack
    type: lokiStack
    lokiStack:
      authentication:
        token:
          from: serviceAccount
      target:
        name: logging-loki
        namespace: openshift-logging
    tls:
      ca:
        key: service-ca.crt
        configMapName: openshift-service-ca.crt
  pipelines:
  - name: default-logstore
    inputRefs:
    - application
    - infrastructure
    outputRefs:
    - default-lokistack
    Copy to Clipboard Toggle word wrap
    注記

    dataModel フィールドはオプションであり、デフォルトでは未設定 (dataModel: "") になっています。これにより、Cluster Logging Operator (CLO) はデータモデルを自動的に選択できるようになります。現在、このフィールドが設定されていない場合の CLO はデフォルトで ViaQ モデルになりますが、これは今後のリリースで変更される予定です。dataModel: ViaQ を指定すると、デフォルトが変更されても設定の互換性が維持されます。

検証

  • OpenShift Web コンソールの Observe タブの Log セクションにログが表示されていることを確認します。
2.2.6.2. OpenTelemetry のクイックスタート
リンクのコピー
重要

OpenTelemetry Protocol (OTLP) 出力ログフォワーダーは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

OTLP 取り込みを設定し、OpenTelemetry データモデルを有効にするには、次の手順を実行します。

前提条件

  • クラスター管理者のパーミッション。

手順

  1. OperatorHub から、Red Hat OpenShift Logging Operator、Loki Operator、Cluster Observability Operator (COO) をインストールします。

  2. openshift-logging namespace に LokiStack カスタムリソース (CR) を作成します。 

    apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  managementState: Managed
  size: 1x.extra-small
  storage:
    schemas:
    - effectiveDate: '2024-10-01'
      version: v13
    secret:
      name: logging-loki-s3
      type: s3
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging
    Copy to Clipboard Toggle word wrap
    注記

    事前に logging-loki-s3 シークレットが事前に作成されていることを確認します。このシークレットの内容は、使用しているオブジェクトストレージにより異なります。詳細は、「シークレットと TLS 設定」を参照してください。

  3. コレクターのサービスアカウントを作成します。 

    $ oc create sa collector -n openshift-logging
    Copy to Clipboard Toggle word wrap

  4. コレクターのサービスアカウントによる LokiStack CR へのデータ書き込みを許可します。 

    $ oc adm policy add-cluster-role-to-user logging-collector-logs-writer -z collector
    Copy to Clipboard Toggle word wrap
    注記

    ClusterRole リソースは、Cluster Logging Operato のインストール中に自動的に作成されるため、手動で作成する必要はありません。

  5. コレクターのサービスアカウントによるログ収集を許可します。 

    $ oc project openshift-logging
    Copy to Clipboard Toggle word wrap 
    $ oc adm policy add-cluster-role-to-user collect-application-logs -z collector
    Copy to Clipboard Toggle word wrap 
    $ oc adm policy add-cluster-role-to-user collect-audit-logs -z collector
    Copy to Clipboard Toggle word wrap 
    $ oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z collector
    Copy to Clipboard Toggle word wrap
    注記

    この例では、コレクターを 3 つのロール (アプリケーション、インフラストラクチャー、監査) すべてにバインドします。デフォルトでは、アプリケーションログとインフラストラクチャーログのみが収集されます。監査ログを収集するには、ClusterLogForwarder 設定を更新して監査ログを含めます。環境に必要な特定のログタイプに基づきロールを割り当てます。

  6. Observe タブの Log セクションを有効にするには、UIPlugin CR を作成します。 

    apiVersion: observability.openshift.io/v1alpha1
kind: UIPlugin
metadata:
  name: logging
spec:
  type: Logging
  logging:
    lokiStack:
      name: logging-loki
    Copy to Clipboard Toggle word wrap

  7. ログ転送を設定するには、ClusterLogForwarder CR を作成します。 

    apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: collector
  namespace: openshift-logging
  annotations:
    observability.openshift.io/tech-preview-otlp-output: "enabled"
    1 
    
spec:
  serviceAccount:
    name: collector
  outputs:
  - name: loki-otlp
    type: lokiStack
    2 
    
    lokiStack:
      target:
        name: logging-loki
        namespace: openshift-logging
      dataModel: Otel
    3 
    
      authentication:
        token:
          from: serviceAccount
    tls:
      ca:
        key: service-ca.crt
        configMapName: openshift-service-ca.crt
  pipelines:
  - name: my-pipeline
    inputRefs:
    - application
    - infrastructure
    outputRefs:
    - loki-otlp
    Copy to Clipboard Toggle word wrap
    1
    アノテーションを使用して、テクノロジープレビュー機能である Otel データモデルを有効にします。
    2
    出力タイプを lokiStack として定義します。
    3
    OpenTelemetry データモデルを指定します。
    注記

    dataModel が Otel の場合、lokiStack.labelKeys は使用できません。dataModel が Otel の場合に同様の機能を得るには、「OTLP データ取り込み用の LokiStack 設定」を参照してください。

検証

  • OpenShift Web コンソールで Observe → OpenShift Logging → LokiStack → Writes に移動し、Distributor - Structured Metadata を確認して、OTLP が正常に機能していることを確認します。

2.3. ログ転送の設定
リンクのコピー

ClusterLogForwarder (CLF) を使用すると、ユーザーはさまざまな宛先へのログの転送を設定できます。さまざまなソースからログメッセージを選択し、それらを変換またはフィルタリングできるパイプラインを介して送信して、1 つ以上の出力に転送する柔軟な方法を提供します。

ClusterLogForwarder の主な機能

  • 入力を使用してログメッセージを選択する
  • 出力を使用してログを外部の宛先に転送する
  • フィルターを使用してログメッセージをフィルタリング、変換、およびドロップする
  • 入力、フィルター、出力を接続するログ転送パイプラインを定義する

2.3.1. ログ収集のセットアップ
リンクのコピー

このリリースの Cluster Logging では、管理者が ClusterLogForwarder に関連付けられたサービスアカウントにログ収集権限を明示的に付与する必要があります。これは、ClusterLogging およびオプションで ClusterLogForwarder.logging.openshift.io リソースで構成されるレガシーロギングシナリオでは、以前のリリースでは必要ありませんでした。

Red Hat OpenShift Logging Operator は、collect-audit-logs、collect-application-logs、collect-infrastructure-logs クラスターロールを提供します。これにより、コレクターは監査ログ、アプリケーションログ、およびインフラストラクチャーログをそれぞれ収集できます。

必要なクラスターロールをサービスアカウントにバインドして、ログ収集をセットアップします。

2.3.1.1. レガシーサービスアカウント
リンクのコピー

既存のレガシーサービスアカウント logcollector を使用するには、次の ClusterRoleBinding を作成します。 

$ oc adm policy add-cluster-role-to-user collect-application-logs system:serviceaccount:openshift-logging:logcollector
$ oc adm policy add-cluster-role-to-user collect-infrastructure-logs system:serviceaccount:openshift-logging:logcollector
Copy to Clipboard Toggle word wrap

さらに、監査ログを収集する場合は、次の ClusterRoleBinding を作成します。 

$ oc adm policy add-cluster-role-to-user collect-audit-logs system:serviceaccount:openshift-logging:logcollector
Copy to Clipboard Toggle word wrap
2.3.1.2. サービスアカウントの作成
リンクのコピー

前提条件

  • Red Hat OpenShift Logging Operator が openshift-logging namespace にインストールされている。
  • 管理者権限がある。

手順

  1. コレクターのサービスアカウントを作成します。認証にトークンを必要とするストレージにログを書き込む場合は、サービスアカウントにトークンを含める必要があります。

  2. 適切なクラスターロールをサービスアカウントにバインドします。

    バインドコマンドの例

    $ oc adm policy add-cluster-role-to-user <cluster_role_name> system:serviceaccount:<namespace_name>:<service_account_name>
    Copy to Clipboard Toggle word wrap

2.3.1.2.1. サービスアカウントのクラスターロールバインディング
リンクのコピー

role_binding.yaml ファイルは、ClusterLogging Operator の ClusterRole を特定の ServiceAccount にバインドし、クラスター全体で Kubernetes リソースを管理できるようにします。 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: manager-rolebinding
roleRef:
1 

  apiGroup: rbac.authorization.k8s.io
2 

  kind: ClusterRole
3 

  name: cluster-logging-operator
4 

subjects:
5 

  - kind: ServiceAccount
6 

    name: cluster-logging-operator
7 

    namespace: openshift-logging
8
Copy to Clipboard Toggle word wrap
1
roleRef: バインディングが適用される ClusterRole を参照します。
2
apiGroup: RBAC API グループを示し、ClusterRole が Kubernetes の RBAC システムの一部であることを指定します。
3
kind: 参照されるロールがクラスター全体に適用される ClusterRole であることを指定します。
4
name: ServiceAccount にバインドされる ClusterRole の名前 (ここでは cluster-logging-operator)。
5
subjects: ClusterRole から権限が付与されるエンティティー (ユーザーまたはサービスアカウント) を定義します。
6
kind: サブジェクトが ServiceAccount であることを指定します。
7
Name: 権限が付与される ServiceAccount の名前。
8
namespace: ServiceAccount が配置されている namespace を示します。
2.3.1.2.2. アプリケーションログの書き込み
リンクのコピー

write-application-logs-clusterrole.yaml ファイルは、Loki ロギングアプリケーションにアプリケーションログを書き込む権限を付与する ClusterRole を定義します。 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-application-logs
rules:
1 

  - apiGroups:
2 

      - loki.grafana.com
3 

    resources:
4 

      - application
5 

    resourceNames:
6 

      - logs
7 

    verbs:
8 

      - create
9 

Annotations
<1> rules: Specifies the permissions granted by this ClusterRole.
<2> apiGroups: Refers to the API group loki.grafana.com, which relates to the Loki logging system.
<3> loki.grafana.com: The API group for managing Loki-related resources.
<4> resources: The resource type that the ClusterRole grants permission to interact with.
<5> application: Refers to the application resources within the Loki logging system.
<6> resourceNames: Specifies the names of resources that this role can manage.
<7> logs: Refers to the log resources that can be created.
<8> verbs: The actions allowed on the resources.
<9> create: Grants permission to create new logs in the Loki system.
Copy to Clipboard Toggle word wrap
2.3.1.2.3. 監査ログの書き込み
リンクのコピー

write-audit-logs-clusterrole.yaml ファイルは、Loki ロギングシステムに監査ログを作成する権限を付与する ClusterRole を定義します。 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-audit-logs
rules:
1 

  - apiGroups:
2 

      - loki.grafana.com
3 

    resources:
4 

      - audit
5 

    resourceNames:
6 

      - logs
7 

    verbs:
8 

      - create
9
Copy to Clipboard Toggle word wrap
1 1
rules: この ClusterRole によって付与される権限を定義します。
2 2
apiGroups: API グループ loki.grafana.com を指定します。
3 3
loki.grafana.com: Loki ロギングリソースを管理する API グループ。
4 4
resources: このロールが管理するリソースタイプ (この場合は audit) を指します。
5 5
audit: ロールが Loki 内の監査ログを管理することを指定します。
6 6
resourceNames: ロールがアクセスできる特定のリソースを定義します。
7 7
logs: このロールで管理できるログを指します。
8 8
verbs: リソースで許可されるアクション。
9 9
create: 新しい監査ログを作成する権限を付与します。
2.3.1.2.4. インフラストラクチャーログの書き込み
リンクのコピー

write-infrastructure-logs-clusterrole.yaml ファイルは、Loki ロギングシステムにインフラストラクチャーログを作成する権限を付与する ClusterRole を定義します。

YAML 例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-infrastructure-logs
rules:
1 

  - apiGroups:
2 

      - loki.grafana.com
3 

    resources:
4 

      - infrastructure
5 

    resourceNames:
6 

      - logs
7 

    verbs:
8 

      - create
9
Copy to Clipboard Toggle word wrap

1
ルール: この ClusterRole が付与する権限を指定します。
2
apiGroups: Loki 関連リソースの API グループを指定します。
3
loki.grafana.com: Loki ロギングシステムを管理する API グループ。
4
resources: このロールが対話できるリソースタイプを定義します。
5
infrastructure: このロールが管理するインフラストラクチャー関連のリソースを指します。
6
resourceNames: このロールが管理できるリソースの名前を指定します。
7
logs: インフラストラクチャーに関連するログリソースを指します。
8
verbs: このロールによって許可されるアクションです。
9
create: Loki システムにインフラストラクチャーログを作成する権限を付与します。
2.3.1.2.5. ClusterLogForwarder 編集者ロール
リンクのコピー

clusterlogforwarder-editor-role.yaml ファイルは、ユーザーが OpenShift で ClusterLogForwarders を管理できるようにする ClusterRole を定義します。 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: clusterlogforwarder-editor-role
rules:
1 

  - apiGroups:
2 

      - observability.openshift.io
3 

    resources:
4 

      - clusterlogforwarders
5 

    verbs:
6 

      - create
7 

      - delete
8 

      - get
9 

      - list
10 

      - patch
11 

      - update
12 

      - watch
13
Copy to Clipboard Toggle word wrap
1
ルール: この ClusterRole が付与する権限を指定します。
2
apiGroups: OpenShift 固有の API グループを指します。
3
obervability.openshift.io: ロギングなどの可観測性リソースを管理するための API グループ。
4
resources: このロールが管理できるリソースを指定します。
5
clusterlogforwarders: OpenShift のログ転送リソースを指します。
6
verbs: ClusterLogForwarders で許可されるアクションを指定します。
7
create: 新しい ClusterLogForwarders を作成する権限を付与します。
8
delete: 既存の ClusterLogForwarders を削除する権限を付与します。
9
get: 特定の ClusterLogForwarders に関する情報を取得する権限を付与します。
10
list: すべての ClusterLogForwarders のリスト表示を許可します。
11
patch: ClusterLogForwarders を部分的に変更する権限を付与します。
12
update: 既存の ClusterLogForwarders を更新する権限を付与します。
13
watch: ClusterLogForwarders への変更を監視する権限を付与します。

2.3.2. コレクターのログレベルの変更
リンクのコピー

コレクターでログレベルを変更するには、observability.openshift.io/log-level アノテーションを trace、debug、info、warn、error、および off に設定します。

ログレベルアノテーションの例

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: collector
  annotations:
    observability.openshift.io/log-level: debug
# ...
Copy to Clipboard Toggle word wrap

2.3.3. Operator の管理
リンクのコピー

ClusterLogForwarder リソースには、Operator がリソースをアクティブに管理するか、管理対象外のままにするかを制御する managementState フィールドがあります。

Managed
(デフォルト) Operator は、CLF 仕様の目的の状態に一致するようにロギングリソースを駆動します。
管理対象外
Operator は、ロギングコンポーネントに関連するアクションを一切実行しません。

これにより、管理者は managementState を Unmanaged に設定して、ログ転送を一時的に停止できます。

2.3.4. ClusterLogForwarder の構造
リンクのコピー

CLF には、次の主要コンポーネントを含む spec セクションがあります。

Inputs
転送するログメッセージを選択します。組み込みの入力タイプである application、infrastructure、および audit は、クラスターのさまざまな部分からログを転送します。カスタム入力を定義することもできます。
出力
ログを転送する宛先を定義します。各出力には、一意の名前とタイプ固有の設定があります。
Pipelines
ログが入力からフィルターを経由して出力されるまでのパスを定義します。パイプラインには一意の名前があり、入力名、出力名、フィルター名のリストで構成されます。
Filters
パイプライン内のログメッセージを変換またはドロップします。ユーザーは、特定のログフィールドに一致するフィルターを定義し、メッセージをドロップまたは変更できます。フィルターはパイプラインで指定された順序で適用されます。
2.3.4.1. Inputs
リンクのコピー

入力は spec.inputs の下の配列で設定されます。組み込みの入力タイプは 3 つあります。

application
default、openshift などのインフラストラクチャー namespace や、kube- または openshift- の接頭辞を持つ namespace 内のログを除いた、すべてのアプリケーションコンテナーからログを選択します。
infrastructure
default および openshift namespace とノードログで実行されているインフラストラクチャーコンポーネントからログを選択します。
audit
OpenShift API サーバー監査ログ、Kubernetes API サーバー監査ログ、ovn 監査ログ、および auditd からのノード監査ログからログを選択します。

ユーザーは、特定の namespace からログを選択するか、または Pod ラベルを使用してログを選択する application のカスタム入力を定義できます。

2.3.4.2. 出力
リンクのコピー

出力は spec.outputs の下の配列で構成されます。各出力には一意の名前とタイプが必要です。サポートされているタイプは次のとおりです。

azureMonitor
ログを Azure Monitor に転送します。
cloudwatch
ログを AWS CloudWatch に転送します。
elasticsearch
ログを外部の Elasticsearch インスタンスに転送します。
googleCloudLogging
ログを Google Cloud Logging に転送します。
http
ログを汎用 HTTP エンドポイントに転送します。
kafka
ログを Kafka ブローカーに転送します。
loki
ログを Loki ロギングバックエンドに転送します。
lokistack
ログを、OpenShift Container Platform 認証インテグレーションによる Loki と Web プロキシーのロギングがサポートされている組み合わせに転送します。LokiStack のプロキシーは、OpenShift Container Platform 認証を使用してマルチテナンシーを適用します。
otlp
OpenTelemetry プロトコルを使用してログを転送します。
splunk
ログを Splunk に転送します。
syslog
ログを外部の syslog サーバーに転送します。

各出力タイプには独自の設定フィールドがあります。

2.3.5. OTLP 出力の設定
リンクのコピー

クラスター管理者は、OpenTelemetry Protocol (OTLP) 出力を使用してログを収集し、OTLP レシーバーに転送できます。OTLP 出力は、OpenTelemetry Observability フレームワーク で定義された仕様を使用して、HTTP を介して JSON エンコーディングでデータを送信します。

重要

OpenTelemetry Protocol (OTLP) 出力ログフォワーダーは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

手順

  • OTLP を使用した転送を有効にするには、次のアノテーションを追加して ClusterLogForwarder カスタムリソース (CR) を作成または編集します。

    ClusterLogForwarder CR の例

    apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  annotations:
    observability.openshift.io/tech-preview-otlp-output: "enabled"
    1 
    
  name: clf-otlp
spec:
  serviceAccount:
    name: <service_account_name>
  outputs:
  - name: otlp
    type: otlp
    otlp:
      tuning:
        compression: gzip
        deliveryMode: AtLeastOnce
        maxRetryDuration: 20
        maxWrite: 10M
        minRetryDuration: 5
      url: <otlp_url>
    2 
    
  pipelines:
  - inputRefs:
    - application
    - infrastructure
    - audit
    name: otlp-logs
    outputRefs:
    - otlp
    Copy to Clipboard Toggle word wrap

    1
    このアノテーションを使用して OpenTelemetry Protocol (OTLP) 出力を有効にします。これはテクノロジープレビュー機能です。
    2
    これは絶対 URL でなければならず、ログの送信先である OTLP エンドポイントのプレースホルダーです。
注記

OTLP 出力では OpenTelemetry データモデルが使用されますが、これは他の出力タイプで使用される ViaQ データモデルとは異なります。これは、OpenTelemetry Observability フレームワークで定義された OpenTelemetry Semantic Conventions を使用することで OTLP に準拠しています。

2.3.5.1. Pipelines
リンクのコピー

パイプラインは spec.pipelines の下の配列で設定されます。各パイプラインには一意の名前があり、次の要素で構成される必要があります。

inputRefs
このパイプラインにログを転送する入力の名前。
outputRefs
ログを送信する出力の名前。
filterRefs
(オプション) 適用するフィルターの名前。

filterRef の順序は、順次適用されるため重要です。以前のフィルターは、後のフィルターで処理されないメッセージをドロップする可能性があります。

2.3.5.2. Filters
リンクのコピー

フィルターは spec.filters の下の配列で設定されます。構造化フィールドの値に基づいて受信ログメッセージを照合し、変更または削除できます。

管理者は次のタイプのフィルターを設定できます。

2.3.5.3. 複数行の例外検出の有効化
リンクのコピー

コンテナーログの複数行のエラー検出を有効にします。

警告

この機能を有効にすると、パフォーマンスに影響が出る可能性があり、追加のコンピューティングリソースや代替のロギングソリューションが必要になる場合があります。

ログパーサーは頻繁に、同じ例外の個別の行を別々の例外として誤って識別します。その結果、余分なログエントリーが発生し、トレースされた情報が不完全または不正確な状態で表示されます。

Java 例外の例

java.lang.NullPointerException: Cannot invoke "String.toString()" because "<param1>" is null
    at testjava.Main.handle(Main.java:47)
    at testjava.Main.printMe(Main.java:19)
    at testjava.Main.main(Main.java:10)
Copy to Clipboard Toggle word wrap

  • ロギングを有効にして複数行の例外を検出し、それらを 1 つのログエントリーに再アセンブルできるようにする場合は、ClusterLogForwarder カスタムリソース (CR) に .spec.filters の下の detectMultilineErrors フィールドが含まれていることを確認します。

ClusterLogForwarder CR の例

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
  namespace: <log_forwarder_namespace>
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <name>
    type: detectMultilineException
  pipelines:
    - inputRefs:
        - <input-name>
      name: <pipeline-name>
      filterRefs:
        - <filter-name>
      outputRefs:
        - <output-name>
Copy to Clipboard Toggle word wrap

2.3.5.3.1. 詳細
リンクのコピー

ログメッセージが例外スタックトレースを形成する連続したシーケンスとして表示される場合、それらは単一の統合ログレコードに結合されます。最初のログメッセージの内容は、シーケンス内のすべてのメッセージフィールドの連結コンテンツに置き換えられます。

コレクターは次の言語をサポートしています。

  • Java
  • JS
  • Ruby
  • Python
  • golang
  • PHP
  • Dart
2.3.5.4. 不要なログレコードを削除するコンテンツフィルターの設定
リンクのコピー

drop フィルターが設定されている場合、ログコレクターは転送する前にフィルターに従ってログストリームを評価します。コレクターは、指定された設定に一致する不要なログレコードを削除します。

手順

  1. フィルターの設定を ClusterLogForwarder CR の filters 仕様に追加します。

    以下の例は、正規表現に基づいてログレコードを削除するように ClusterLogForwarder CR を設定する方法を示しています。

    ClusterLogForwarder CR の例

    apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <filter_name>
    type: drop
    1 
    
    drop:
    2 
    
    - test:
    3 
    
      - field: .kubernetes.labels."foo-bar/baz"
    4 
    
        matches: .+
    5 
    
      - field: .kubernetes.pod_name
        notMatches: "my-pod"
    6 
    
  pipelines:
  - name: <pipeline_name>
    7 
    
    filterRefs: ["<filter_name>"]
# ...
    Copy to Clipboard Toggle word wrap

    1
    フィルターのタイプを指定します。drop フィルターは、フィルター設定に一致するログレコードをドロップします。
    2
    drop フィルターを適用するための設定オプションを指定します。
    3
    ログレコードが削除されるかどうかを評価するために使用されるテストの設定を指定します。
    • テストに指定されたすべての条件が true の場合、テストは合格し、ログレコードは削除されます。
    • drop フィルター設定に複数のテストが指定されている場合、いずれかのテストに合格すると、レコードは削除されます。
    • 条件の評価中にエラーが発生した場合 (たとえば、評価対象のログレコードにフィールドがない場合)、その条件は false と評価されます。
    4
    ドットで区切られたフィールドパス (ログレコード内のフィールドへのパス) を指定します。パスには、英数字とアンダースコア (a-zA-Z0-9_) を含めることができます (例: .kubernetes.namespace_name)。セグメントにこの範囲外の文字が含まれている場合、セグメントを引用符で囲む必要があります (例: .kubernetes.labels."foo.bar-bar/baz")。1 つの test 設定に複数のフィールドパスを含めることができますが、テストに合格して drop フィルターを適用するには、すべてのフィールドパスが true と評価される必要があります。
    5
    正規表現を指定します。ログレコードがこの正規表現と一致する場合は、破棄されます。単一の field パスに対して matches または notMatches 条件のいずれかを設定できますが、両方を設定することはできません。
    6
    正規表現を指定します。ログレコードがこの正規表現に一致しない場合、破棄されます。単一の field パスに対して matches または notMatches 条件のいずれかを設定できますが、両方を設定することはできません。
    7
    drop フィルターが適用されるパイプラインを指定します。

  2. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

追加例

次の例は、優先度の高いログレコードのみを保持するように drop フィルターを設定する方法を示しています。 

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: important
    type: drop
    drop:
    - test:
      - field: .message
        notMatches: "(?i)critical|error"
      - field: .level
        matches: "info|warning"
# ...
Copy to Clipboard Toggle word wrap

単一の test 設定に複数のフィールドパスを追加する以外に、OR チェックとして扱われる追加のテストも追加できます。次の例では、いずれかの test 設定が true と評価されるとレコードが削除されます。ただし、2 番目の test 設定では、true と評価されるためには、両方のフィールド仕様が true である必要があります。 

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: important
    type: drop
    drop:
    - test:
      - field: .kubernetes.namespace_name
        matches: "^open"
    - test:
      - field: .log_type
        matches: "application"
      - field: .kubernetes.pod_name
        notMatches: "my-pod"
# ...
Copy to Clipboard Toggle word wrap
2.3.5.5. API 監査フィルターの概要
リンクのコピー

OpenShift API サーバーは、API 呼び出しごとに、リクエスト、レスポンス、リクエスターの ID の詳細を示す監査イベントを生成するため、大量のデータが生成されます。API 監査フィルターはルールを使用して、重要でないイベントを除外してイベントサイズを減少できるようにし、監査証跡をより管理しやすくします。ルールは順番にチェックされ、最初の一致でチェックが停止します。イベントに含まれるデータの量は、level フィールドの値によって決まります。

  • None: イベントはドロップされます。
  • Metadata: 監査メタデータが含まれ、リクエストおよびレスポンスの本文は削除されます。
  • Request: 監査メタデータとリクエスト本文が含まれ、レスポンス本文は削除されます。
  • RequestResponse: メタデータ、リクエスト本文、レスポンス本文のすべてのデータが含まれます。レスポンス本文が非常に大きくなる可能性があります。たとえば、oc get pods -A はクラスター内のすべての Pod の YAML 記述を含むレスポンス本文を生成します。

ClusterLogForwarder カスタムリソース (CR) は、以下の追加機能を提供しますが、標準の Kubernetes 監査ポリシー と同じ形式を使用します。

ワイルドカード
ユーザー、グループ、namespace、およびリソースの名前には、先頭または末尾に * アスタリスク文字を付けることができます。たとえば、namespace openshift-\* は openshift-apiserver または openshift-authentication に一致します。リソース \*/status は、Pod/status または Deployment/status と一致します。
デフォルトのルール

ポリシーのルールに一致しないイベントは、以下のようにフィルターされます。

  • get、list、watch などの読み取り専用システムイベントは削除されます。
  • サービスアカウントと同じ namespace 内で発生するサービスアカウント書き込みイベントはドロップされます。
  • 他のすべてのイベントは、設定されたレート制限に従って転送されます。

これらのデフォルトを無効にするには、level フィールドのみが含まれるルールでルールリストを終了するか、空のルールを追加します。

応答コードが省略される
省略する整数ステータスコードのリスト。イベントが作成されない HTTP ステータスコードをリストする OmitResponseCodes フィールドを使用して、応答で HTTP ステータスコードに基づいてイベントをドロップできます。デフォルト値は [404, 409, 422, 429] です。値が空のリスト [] の場合、ステータスコードは省略されません。

ClusterLogForwarder CR の監査ポリシーは、OpenShift Container Platform の監査ポリシーに加えて動作します。ClusterLogForwarder CR 監査フィルターは、ログコレクターが転送する内容を変更し、verb、user、group、namespace、または resource でフィルタリングする機能を提供します。複数のフィルターを作成して、同じ監査ストリームの異なるサマリーを異なる場所に送信できます。たとえば、詳細なストリームをローカルクラスターログストアに送信し、詳細度の低いストリームをリモートサイトに送信できます。

注記

監査ログを収集するには、クラスターロール collect-audit-logs が必要です。提供されている例は、監査ポリシーで可能なルールの範囲を示すことを目的としており、推奨される設定ではありません。

監査ポリシーの例

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
  namespace: <log_forwarder_namespace>
spec:
  serviceAccount:
    name: <service_account_name>
  pipelines:
    - name: my-pipeline
      inputRefs: audit
1 

      filterRefs: my-policy
2 

  filters:
    - name: my-policy
      type: kubeAPIAudit
      kubeAPIAudit:
        # Don't generate audit events for all requests in RequestReceived stage.
        omitStages:
          - "RequestReceived"

        rules:
          # Log pod changes at RequestResponse level
          - level: RequestResponse
            resources:
            - group: ""
              resources: ["pods"]

          # Log "pods/log", "pods/status" at Metadata level
          - level: Metadata
            resources:
            - group: ""
              resources: ["pods/log", "pods/status"]

          # Don't log requests to a configmap called "controller-leader"
          - level: None
            resources:
            - group: ""
              resources: ["configmaps"]
              resourceNames: ["controller-leader"]

          # Don't log watch requests by the "system:kube-proxy" on endpoints or services
          - level: None
            users: ["system:kube-proxy"]
            verbs: ["watch"]
            resources:
            - group: "" # core API group
              resources: ["endpoints", "services"]

          # Don't log authenticated requests to certain non-resource URL paths.
          - level: None
            userGroups: ["system:authenticated"]
            nonResourceURLs:
            - "/api*" # Wildcard matching.
            - "/version"

          # Log the request body of configmap changes in kube-system.
          - level: Request
            resources:
            - group: "" # core API group
              resources: ["configmaps"]
            # This rule only applies to resources in the "kube-system" namespace.
            # The empty string "" can be used to select non-namespaced resources.
            namespaces: ["kube-system"]

          # Log configmap and secret changes in all other namespaces at the Metadata level.
          - level: Metadata
            resources:
            - group: "" # core API group
              resources: ["secrets", "configmaps"]

          # Log all other resources in core and extensions at the Request level.
          - level: Request
            resources:
            - group: "" # core API group
            - group: "extensions" # Version of group should NOT be included.

          # A catch-all rule to log all other requests at the Metadata level.
          - level: Metadata
Copy to Clipboard Toggle word wrap

1
収集されるログのタイプ。このフィールドの値は、監査ログの場合は audit、アプリケーションログの場合は application、インフラストラクチャーログの場合は infrastructure、またはアプリケーションに定義された指定の入力になります。
2
監査ポリシーの名前。

input セレクターを使用して、ラベル式または照合するラベルキーとその値に基づいてアプリケーションログを含めることができます。

手順

  1. ClusterLogForwarder CR の input 仕様にフィルターの設定を追加します。

    以下の例は、ラベル式または一致したラベルキー/値に基づいてログを組み込むように ClusterLogForwarder CR を設定する方法を示しています。

    ClusterLogForwarder CR の例

    apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs
      application:
        selector:
          matchExpressions:
          - key: env
    1 
    
            operator: In
    2 
    
            values: ["prod", "qa"]
    3 
    
          - key: zone
            operator: NotIn
            values: ["east", "west"]
          matchLabels:
    4 
    
            app: one
            name: app1
      type: application
# ...
    Copy to Clipboard Toggle word wrap

    1
    照合するラベルキーを指定します。
    2
    Operator を指定します。有効な値には、In、NotIn、Exists、DoesNotExist などがあります。
    3
    文字列値の配列を指定します。Operator 値が Exists または DoesNotExist のいずれかの場合、値の配列は空である必要があります。
    4
    正確なキーまたは値のマッピングを指定します。

  2. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap
2.3.5.7. ログレコードを削除するコンテンツフィルターの設定
リンクのコピー

prune フィルターが設定されると、ログコレクターは転送前にフィルターをもとにログレベルを評価します。コレクターは、Pod アノテーションなどの値の低いフィールドを削除してログレコードを整理します。

手順

  1. フィルターの設定を ClusterLogForwarder CR の prune 仕様に追加します。

    次の例は、フィールドパスに基づいてログレコードを削除するように ClusterLogForwarder CR を設定する方法を示しています。

    重要

    両方が指定されている場合、最初に notIn 配列に基づいてレコードが整理され、in 配列よりも優先されます。notIn 配列を使用してレコードが整理された後、in 配列を使用してレコードが整理されます。

    ClusterLogForwarder CR の例

    apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <filter_name>
    type: prune
    1 
    
    prune:
    2 
    
      in: [.kubernetes.annotations, .kubernetes.namespace_id]
    3 
    
      notIn: [.kubernetes,.log_type,.message,."@timestamp"]
    4 
    
  pipelines:
  - name: <pipeline_name>
    5 
    
    filterRefs: ["<filter_name>"]
# ...
    Copy to Clipboard Toggle word wrap

    1
    フィルターのタイプを指定します。prune フィルターでは、設定されたフィールドでログレコードをプルーニングします。
    2
    prune フィルターを適用するための設定オプションを指定します。in フィールドと notIn フィールドは、ログレコード内のフィールドへのパスであるドット区切りのフィールドパスの配列として指定されます。これらのパスには、英数字とアンダースコア (a-zA-Z0-9_) を含めることができます (例: .kubernetes.namespace_name)。セグメントにこの範囲外の文字が含まれている場合、セグメントを引用符で囲む必要があります (例: .kubernetes.labels."foo.bar-bar/baz")。
    3
    オプション: この配列で指定されたフィールドはすべてログレコードから削除されます。
    4
    オプション: この配列で指定されていないフィールドはログレコードから削除されます。
    5
    prune フィルターを適用するパイプラインを指定します。
    注記

    フィルターは、log_type、.log_source、および .message フィールドを除外します。

  2. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

2.3.6. ソースによる監査およびインフラストラクチャーログ入力のフィルタリング
リンクのコピー

input セレクターを使用して、ログを収集する audit および infrastructure ソースのリストを定義できます。

手順

  1. ClusterLogForwarder CR に audit および infrastructure ソースを定義する設定を追加します。

    次の例は、ClusterLogForwarder CR を設定して audit および infrastructure ソースを定義する方法を示しています。

    ClusterLogForwarder CR の例

    apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs1
      type: infrastructure
      infrastructure:
        sources:
    1 
    
          - node
    - name: mylogs2
      type: audit
      audit:
        sources:
    2 
    
          - kubeAPI
          - openshiftAPI
          - ovn
# ...
    Copy to Clipboard Toggle word wrap

    1
    収集するインフラストラクチャーソースのリストを指定します。有効なソースには以下が含まれます。
    • node: ノードからのジャーナルログ
    • container: namespace にデプロイされたワークロードからのログ
    2
    収集する audit ソースのリストを指定します。有効なソースには以下が含まれます。
    • kubeAPI: Kubernetes API サーバーからのログ
    • openshiftAPI: OpenShift API サーバーからのログ
    • auditd: ノードの auditd サービスからのログ
    • ovn: オープン仮想ネットワークサービスからのログ

  2. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

input セレクターを使用して、namespace とコンテナー名に基づいてアプリケーションログを含めたり除外したりできます。

手順

  1. ClusterLogForwarder CR に namespace とコンテナー名を含めるか除外するかの設定を追加します。

    以下の例は、namespace およびコンテナー名を含めるか、除外するように ClusterLogForwarder CR を設定する方法を示しています。

    ClusterLogForwarder CR の例

    apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs
      application:
        includes:
          - namespace: "my-project"
    1 
    
            container: "my-container"
    2 
    
        excludes:
          - container: "other-container*"
    3 
    
            namespace: "other-namespace"
    4 
    
      type: application
# ...
    Copy to Clipboard Toggle word wrap

    1
    ログがこれらの namespace からのみ収集されることを指定します。
    2
    ログがこれらのコンテナーからのみ収集されることを指定します。
    3
    ログを収集するときに無視する namespace のパターンを指定します。
    4
    ログを収集するときに無視するコンテナーのセットを指定します。
    注記

    excludes フィールドは includes フィールドよりも優先されます。

  2. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

2.4. LokiStack でログを保存する
リンクのコピー

アプリケーション、監査、インフラストラクチャー関連のログを保存するように LokiStack CR を設定できます。

Loki は、OpenShift Observability UI で視覚化できる Red Hat OpenShift のログ記録用の GA ログストアとして提供される、水平方向にスケーラブルで可用性の高いマルチテナントログ集約システムです。OpenShift Logging が提供する Loki 設定は、収集されたログを使用してユーザーが迅速にトラブルシューティングを実行できるように設計された短期ログストアです。この目的のために、Loki の Red Hat OpenShift 設定のロギングには短期ストレージがあり、最新のクエリーに最適化されています。

重要

長期間にわたる保存やクエリーの場合、ユーザーはクラスター外部のログストアを探す必要があります。Loki のサイズ設定は、最大 30 日間の短期ストレージに対してのみテストおよびサポートされます。

2.4.1. Loki デプロイメントのサイズ
リンクのコピー

Loki のサイズは 1x.<size> の形式に従います。この場合の 1x はインスタンスの数を、<size> は性能を指定します。

1x.pico 設定は、最小限のリソースと制限要件を持つ単一の Loki デプロイメントを定義し、すべての Loki コンポーネントに高可用性 (HA) サポートを提供します。この設定は、単一のレプリケーションファクターまたは自動圧縮を必要としないデプロイメントに適しています。

ディスク要求はサイズ設定にかかわらず類似しているため、お客様はさまざまなサイズをテストして、それぞれのデプロイメントニーズに最適なサイズを決定できます。

重要

デプロイメントサイズの 1x の数は変更できません。

Expand
表2.1 Loki のサイズ
 1x.demo1x.pico [6.1+ のみ]1x.extra-small1x.small1x.medium

Data transfer

デモ使用のみ

50 GB/日

100 GB/日

500 GB/日

2 TB/日

1 秒あたりのクエリー数 (QPS)

デモ使用のみ

200 ミリ秒で 1 - 25 QPS

200 ミリ秒で 1 - 25 QPS

200 ミリ秒で 25 - 50 QPS

200 ミリ秒で 25 - 75 QPS

レプリケーション係数

なし

2

2

2

2

合計 CPU 要求

なし

仮想 CPU 7 個

仮想 CPU 14 個

仮想 CPU 34 個

仮想 CPU 54 個

ルーラーを使用する場合の合計 CPU リクエスト

なし

仮想 CPU 8 個

仮想 CPU 16 個

仮想 CPU 42 個

仮想 CPU 70 個

合計メモリー要求

なし

17 Gi

31 Gi

67 Gi

139 Gi

ルーラーを使用する場合の合計メモリーリクエスト

なし

18 Gi

35 Gi

83 Gi

171 Gi

合計ディスク要求

40 Gi

590 Gi

430 Gi

430 Gi

590 Gi

ルーラーを使用する場合の合計ディスクリクエスト

80 Gi

910 Gi

750 Gi

750 Gi

910 Gi

2.4.2. 前提条件
リンクのコピー

  • CLI または Web コンソールを使用して Loki Operator をインストールしている。
  • ClusterLogForwarder を作成するのと同じ namespace に serviceAccount がある。
  • serviceAccount に collect-audit-logs、collect-application-logs、collect-infrastructure-logs のクラスターロールが割り当てられている。

2.4.3. コアのセットアップと設定
リンクのコピー

ロールベースのアクセス制御、基本的なモニタリング、および Loki をデプロイするための Pod の配置。

2.4.4. LokiStack ルールの RBAC 権限の認可
リンクのコピー

管理者は、クラスターロールをユーザー名にバインドすることで、ユーザーが独自のアラートおよび記録ルールを作成および管理できるようにすることができます。クラスターロールは、ユーザーに必要なロールベースのアクセス制御 (RBAC) 権限を含む ClusterRole オブジェクトとして定義されます。

LokiStack では、アラートおよび記録ルール用の次のクラスターロールが利用できます。

Expand
ルール名説明

alertingrules.loki.grafana.com-v1-admin

このロールを持つユーザーは、アラートルールを管理する管理レベルのアクセス権を持ちます。このクラスターロールは、loki.grafana.com/v1 API グループ内の AlertingRule リソースを作成、読み取り、更新、削除、リスト表示、および監視する権限を付与します。

alertingrules.loki.grafana.com-v1-crdview

このロールを持つユーザーは、loki.grafana.com/v1 API グループ内の AlertingRule リソースに関連するカスタムリソース定義 (CRD) の定義を表示できますが、これらのリソースを変更または管理する権限を持ちません。

alertingrules.loki.grafana.com-v1-edit

このロールを持つユーザーは、AlertingRule リソースを作成、更新、および削除する権限を持ちます。

alertingrules.loki.grafana.com-v1-view

このロールを持つユーザーは、loki.grafana.com/v1 API グループ内の AlertingRule リソースを読み取ることができます。既存のアラートルールの設定、ラベル、およびアノテーションを検査できますが、それらを変更することはできません。

recordingrules.loki.grafana.com-v1-admin

このロールを持つユーザーは、記録ルールを管理する管理レベルのアクセス権を持ちます。このクラスターロールは、loki.grafana.com/v1 API グループ内の RecordingRule リソースを作成、読み取り、更新、削除、リスト表示、および監視する権限を付与します。

recordingrules.loki.grafana.com-v1-crdview

このロールを持つユーザーは、loki.grafana.com/v1 API グループ内の RecordingRule リソースに関連するカスタムリソース定義 (CRD) の定義を表示できますが、これらのリソースを変更または管理する権限を持ちません。

recordingrules.loki.grafana.com-v1-edit

このロールを持つユーザーは、RecordingRule リソースを作成、更新、および削除する権限を持ちます。

recordingrules.loki.grafana.com-v1-view

このロールを持つユーザーは、loki.grafana.com/v1 API グループ内の RecordingRule リソースを読み取ることができます。既存のアラートルールの設定、ラベル、およびアノテーションを検査できますが、それらを変更することはできません。

2.4.4.1. 例
リンクのコピー

ユーザーにクラスターロールを適用するには、既存のクラスターロールを特定のユーザー名にバインドする必要があります。

クラスターロールは、使用するロールバインディングの種類に応じて、クラスタースコープまたは namespace スコープにすることができます。RoleBinding オブジェクトを使用する場合は、oc adm policy add-role-to-user コマンドを使用する場合と同様に、クラスターロールが指定した namespace にのみ適用されます。ClusterRoleBinding オブジェクトを使用する場合は、oc adm policy add-cluster-role-to-user コマンドを使用する場合と同様に、クラスターロールがクラスター内のすべての namespace に適用されます。

次のコマンド例では、指定したユーザーに、クラスター内の特定の namespace のアラートルールに対する作成、読み取り、更新、および削除 (CRUD) 権限を付与します。

特定の namespace のアラートルールに対する CRUD 権限を付与するクラスターロールバインディングコマンドの例

$ oc adm policy add-role-to-user alertingrules.loki.grafana.com-v1-admin -n <namespace> <username>
Copy to Clipboard Toggle word wrap

次のコマンドは、指定したユーザーに、すべての namespace のアラートルールに対する管理者権限を付与します。

管理者権限を付与するクラスターロールバインディングコマンドの例

$ oc adm policy add-cluster-role-to-user alertingrules.loki.grafana.com-v1-admin <username>
Copy to Clipboard Toggle word wrap

2.4.5. Loki を使用したログベースのアラートルールの作成
リンクのコピー

AlertingRule CR には、単一の LokiStack インスタンスのアラートルールグループを宣言するために使用する、仕様および Webhook 検証定義のセットが含まれます。Webhook 検証定義は、ルール検証条件もサポートします。

  • AlertingRule CR に無効な interval 期間が含まれる場合、無効なアラートルールです。
  • AlertingRule CR に無効な for 期間が含まれる場合、無効なアラートルールです。
  • AlertingRule CR に無効な LogQL expr が含まれる場合、無効なアラートルールです。
  • AlertingRule CR に同じ名前のグループが 2 つ含まれる場合、無効なアラートルールです。
  • 上記のいずれも該当しない場合、アラートルールは有効とみなされます。
Expand
表2.2 AlertingRule の定義
テナントタイプAlertingRule CR の有効な namespace

application

<your_application_namespace>

audit

openshift-logging

infrastructure

openshift-/*、kube-/\*、default

手順

  1. AlertingRule カスタムリソース (CR) を作成します。

    インフラストラクチャー AlertingRule CR の例

      apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: loki-operator-alerts
    namespace: openshift-operators-redhat
    1 
    
    labels:
    2 
    
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "infrastructure"
    3 
    
    groups:
      - name: LokiOperatorHighReconciliationError
        rules:
          - alert: HighPercentageError
            expr: |
    4 
    
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"} |= "error" [1m])) by (job)
                /
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"}[1m])) by (job)
                > 0.01
            for: 10s
            labels:
              severity: critical
    5 
    
            annotations:
              summary: High Loki Operator Reconciliation Errors
    6 
    
              description: High Loki Operator Reconciliation Errors
    7
    Copy to Clipboard Toggle word wrap

    1
    この AlertingRule CR が作成される namespace には、LokiStack spec.rules.namespaceSelector 定義に一致するラベルが必要です。
    2
    labels ブロックは、LokiStack の spec.rules.selector 定義と一致する必要があります。
    3
    infrastructure テナントの AlertingRule CR は、openshift-*、kube-\*、または default namespaces でのみサポートされます。
    4
    kubernetes_namespace_name: の値は、metadata.namespace の値と一致する必要があります。
    5
    この必須フィールドの値は、critical、warning、または info である必要があります。
    6
    このフィールドは必須です。
    7
    このフィールドは必須です。

    アプリケーション AlertingRule CR の例

      apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: app-user-workload
    namespace: app-ns
    1 
    
    labels:
    2 
    
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "application"
    groups:
      - name: AppUserWorkloadHighError
        rules:
          - alert:
            expr: |
    3 
    
              sum(rate({kubernetes_namespace_name="app-ns", kubernetes_pod_name=~"podName.*"} |= "error" [1m])) by (job)
            for: 10s
            labels:
              severity: critical
    4 
    
            annotations:
              summary:
    5 
    
              description:
    6
    Copy to Clipboard Toggle word wrap

    1
    この AlertingRule CR が作成される namespace には、LokiStack spec.rules.namespaceSelector 定義に一致するラベルが必要です。
    2
    labels ブロックは、LokiStack の spec.rules.selector 定義と一致する必要があります。
    3
    kubernetes_namespace_name: の値は、metadata.namespace の値と一致する必要があります。
    4
    この必須フィールドの値は、critical、warning、または info である必要があります。
    5
    この必須フィールドの値は、ルールの概要です。
    6
    この必須フィールドの値は、ルールの詳細な説明です。

  2. AlertingRule CR を適用します。 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

2.4.6. メンバーリストの作成の失敗を許容する Loki の設定
リンクのコピー

OpenShift Container Platform クラスターでは、管理者は通常、非プライベート IP ネットワーク範囲を使用します。その結果、LokiStack メンバーリストはデフォルトでプライベート IP ネットワークのみを使用するため、LokiStack メンバーリストの設定は失敗します。

管理者は、メンバーリスト設定の Pod ネットワークを選択できます。LokiStack カスタムリソース (CR) を変更して、hashRing 仕様で podIP アドレスを使用できます。LokiStack CR を設定するには、以下のコマンドを使用します。 

$ oc patch LokiStack logging-loki -n openshift-logging  --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP"},"type":"memberlist"}}}'
Copy to Clipboard Toggle word wrap

podIPを含める LokiStack の例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  hashRing:
    type: memberlist
    memberlist:
      instanceAddrType: podIP
# ...
Copy to Clipboard Toggle word wrap

2.4.7. Loki でストリームベースの保持の有効化
リンクのコピー

ログストリームに基づいて保持ポリシーを設定できます。これらのルールは、グローバル、テナントごと、またはその両方で設定できます。両方で設定すると、グローバルルールの前にテナントルールが適用されます。

重要

s3 バケットまたは LokiStack カスタムリソース (CR) に保存期間が定義されていない場合、ログは削除されず、s3 バケットに永久に残り、s3 ストレージがいっぱいになる可能性があります。

注記

スキーマ v13 が推奨されます。

手順

  1. LokiStack CR を作成します。

    • 次の例に示すように、ストリームベースの保持をグローバルに有効にします。

      AWS のグローバルストリームベースの保持の例

      apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
   global:
      1 
      
      retention:
      2 
      
        days: 20
        streams:
        - days: 4
          priority: 1
          selector: '{kubernetes_namespace_name=~"test.+"}'
      3 
      
        - days: 1
          priority: 1
          selector: '{log_type="infrastructure"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v13
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging
      Copy to Clipboard Toggle word wrap

      1
      すべてのログストリームの保持ポリシーを設定します。注記: このフィールドは、オブジェクトストレージに保存されたログの保持期間には影響しません。
      2
      このブロックが CR に追加されると、クラスターで保持が有効になります。
      3
      ログ stream.spec: 制限を定義するために使用される LogQL クエリー が含まれます。

    • 次の例に示すように、テナントごとにストリームベースの保持を有効にします。

      AWS のテナントごとのストリームベースの保持の例

      apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global:
      retention:
        days: 20
    tenants:
      1 
      
      application:
        retention:
          days: 1
          streams:
            - days: 4
              selector: '{kubernetes_namespace_name=~"test.+"}'
      2 
      
      infrastructure:
        retention:
          days: 5
          streams:
            - days: 1
              selector: '{kubernetes_namespace_name=~"openshift-cluster.+"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v13
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging
      Copy to Clipboard Toggle word wrap

      1
      テナントごとの保持ポリシーを設定します。有効なテナントタイプは、application、audit、および infrastructure です。
      2
      ログストリームの定義に使用される LogQL クエリー が含まれています。

  2. LokiStack CR を適用します。 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

2.4.8. Loki Pod の配置
リンクのコピー

Pod の toleration またはノードセレクターを使用して、Loki Pod が実行するノードを制御し、他のワークロードがそれらのノードを使用しないようにできます。

LokiStack カスタムリソース (CR) を使用して toleration をログストア Pod に適用し、ノード仕様を使用して taint をノードに適用できます。ノードの taint は、taint を容認しないすべての Pod を拒否するようノードに指示する key:value ペアです。他の Pod にはない特定の key:value ペアを使用すると、ログストア Pod のみがそのノードで実行できるようになります。

ノードセレクターを使用する LokiStack の例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
1 

      nodeSelector:
        node-role.kubernetes.io/infra: ""
2 

    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
# ...
Copy to Clipboard Toggle word wrap

1
ノードセレクターに適用されるコンポーネント Pod タイプを指定します。
2
定義されたラベルが含まれるノードに移動する Pod を指定します。

ノードセレクターと toleration を使用する LokiStack CR の例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
# ...
Copy to Clipboard Toggle word wrap

LokiStack (CR) の nodeSelector フィールドと tolerations フィールドを設定するには、oc explain コマンドを使用して、特定のリソースの説明とフィールドを表示します。 

$ oc explain lokistack.spec.template
Copy to Clipboard Toggle word wrap

出力例

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: template <Object>

DESCRIPTION:
     Template defines the resource/limits/tolerations/nodeselectors per
     component

FIELDS:
   compactor	<Object>
     Compactor defines the compaction component spec.

   distributor	<Object>
     Distributor defines the distributor component spec.
...
Copy to Clipboard Toggle word wrap

詳細情報用に、特定のフィールドを追加できます。 

$ oc explain lokistack.spec.template.compactor
Copy to Clipboard Toggle word wrap

出力例

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: compactor <Object>

DESCRIPTION:
     Compactor defines the compaction component spec.

FIELDS:
   nodeSelector	<map[string]string>
     NodeSelector defines the labels required by a node to schedule the
     component onto it.
...
Copy to Clipboard Toggle word wrap

2.4.8.1. 信頼性とパフォーマンスの向上
リンクのコピー

実稼働環境における Loki の信頼性と効率性を確保するための設定。

2.4.8.2. 有効期間の短いトークンを使用したクラウドベースのログストアへの認証の有効化
リンクのコピー

ワークロードアイデンティティーフェデレーションを使用すると、有効期間の短いトークンを使用してクラウドベースのログストアに対して認証できます。

手順

  • 認証を有効にするには、次のいずれかのオプションを使用します。

    • OpenShift Container Platform Web コンソールを使用して Loki Operator をインストールすると、有効期間が短いトークンを使用するクラスターが自動的に検出されます。プロンプトが表示され、ロールを作成するように求められます。また、Loki Operator が CredentialsRequest オブジェクトを作成するのに必要なデータを提供するように求められます。このオブジェクトにより、シークレットが設定されます。

    • OpenShift CLI (oc) を使用して Loki Operator をインストールする場合は、次の例に示すように、ストレージプロバイダーに適したテンプレートを使用して Subscription オブジェクトを手動で作成する必要があります。この認証ストラテジーは、指定のストレージプロバイダーでのみサポートされます。

      Azure サンプルサブスクリプションの例

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-6.0"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
      - name: CLIENTID
        value: <your_client_id>
      - name: TENANTID
        value: <your_tenant_id>
      - name: SUBSCRIPTIONID
        value: <your_subscription_id>
      - name: REGION
        value: <your_region>
      Copy to Clipboard Toggle word wrap

      AWS サンプルサブスクリプションの例

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-6.0"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
    - name: ROLEARN
      value: <role_ARN>
      Copy to Clipboard Toggle word wrap

2.4.8.3. ノードの障害を許容するための Loki の設定
リンクのコピー

Loki Operator は、同じコンポーネントの Pod がクラスター内の異なる使用可能なノードにスケジュールされるように要求する Pod アンチアフィニティールールの設定をサポートしています。

アフィニティーとは、スケジュールするノードを制御する Pod の特性です。非アフィニティーとは、Pod がスケジュールされることを拒否する Pod の特性です。

OpenShift Container Platform では、Pod のアフィニティー と Pod の非アフィニティー によって、他の Pod のキー/値ラベルに基づいて、Pod のスケジュールに適したノードを制限できます。

Operator は、すべての Loki コンポーネント (compactor、distributor、gateway、indexGateway、ingester、querier、queryFrontend、および ruler コンポーネントを含む) に対してデフォルトの優先 podAntiAffinity ルールを設定します。

requiredDuringSchedulingIgnoredDuringExecution フィールドに必要な設定を指定して、Loki コンポーネントの希望の podAntiAffinity 設定を上書きできます。

インジェスターコンポーネントのユーザー設定の例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    ingester:
      podAntiAffinity:
      # ...
        requiredDuringSchedulingIgnoredDuringExecution:
1 

        - labelSelector:
            matchLabels:
2 

              app.kubernetes.io/component: ingester
          topologyKey: kubernetes.io/hostname
# ...
Copy to Clipboard Toggle word wrap

1
必要なルールを定義するスタンザです。
2
ルールを適用するために一致している必要のあるキー/値のペア (ラベル) です。
2.4.8.4. クラスターの再起動中の LokiStack 動作
リンクのコピー

OpenShift Container Platform クラスターが再起動されると、LokiStack の取り込みとクエリーパスは、ノードで使用可能な CPU およびメモリーリソース内で引き続き動作します。つまり、OpenShift Container Platform クラスターの更新中に LokiStack でダウンタイムは発生しません。この動作は、PodDisruptionBudget リソースを使用して実現されます。Loki Operator は、Loki に PodDisruptionBudget リソースをプロビジョニングするため、特定の条件下で通常の動作を保証するためにコンポーネントごとに必要最小限、使用可能な Pod 数が決定されます。

2.4.8.5. 高度なデプロイメントとスケーラビリティー
リンクのコピー

高可用性、スケーラビリティー、エラー処理のための特殊な設定。

2.4.8.6. ゾーン対応のデータレプリケーション
リンクのコピー

Loki Operator は、Pod トポロジーの分散制約を通じて、ゾーン対応のデータレプリケーションのサポートを提供します。この機能を有効にすると、信頼性が向上し、1 つのゾーンで障害が発生した場合のログ損失に対する保護が強化されます。デプロイメントサイズを 1x.extra.small、1x.small、または 1x.medium に設定すると、replication.factor フィールドは自動的に 2 に設定されます。

適切なレプリケーションを実現するには、少なくともレプリケーション係数で指定されているのと同じ数のアベイラビリティーゾーンが必要です。レプリケーション係数より多くのアベイラビリティーゾーンを設定することは可能ですが、ゾーンが少ないと書き込みエラーが発生する可能性があります。最適な運用を実現するには、各ゾーンで同じ数のインスタンスをホストする必要があります。

ゾーンレプリケーションが有効になっている LokiStack CR の例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
 name: logging-loki
 namespace: openshift-logging
spec:
 replicationFactor: 2
1 

 replication:
   factor: 2
2 

   zones:
   -  maxSkew: 1
3 

      topologyKey: topology.kubernetes.io/zone
4
Copy to Clipboard Toggle word wrap

1
非推奨のフィールド。入力された値は replication.factor によって上書きされます。
2
この値は、セットアップ時にデプロイメントサイズが選択されると自動的に設定されます。
3
任意の 2 つのトポロジードメイン間の Pod 数の最大差。デフォルトは 1 で、0 の値を指定することはできません。
4
ノードラベルに対応するトポロジーキーの形式でゾーンを定義します。
2.4.8.7. 障害が発生したゾーンからの Loki Pod の回復
リンクのコピー

OpenShift Container Platform では、特定のアベイラビリティーゾーンのリソースにアクセスできなくなると、ゾーン障害が発生します。アベイラビリティーゾーンは、冗長性とフォールトトレランスを強化することを目的とした、クラウドプロバイダーのデータセンター内の分離されたエリアです。OpenShift Container Platform クラスターがこの問題を処理するように設定されていない場合、ゾーン障害によりサービスまたはデータの損失が発生する可能性があります。

Loki Pod は StatefulSet の一部であり、StorageClass オブジェクトによってプロビジョニングされた永続ボリューム要求 (PVC) が付属しています。各 Loki Pod とその PVC は同じゾーンに存在します。クラスターでゾーン障害が発生すると、StatefulSet コントローラーが、障害が発生したゾーン内の影響を受けた Pod の回復を自動的に試みます。

警告

次の手順では、障害が発生したゾーン内の PVC とそこに含まれるすべてのデータを削除します。完全なデータ損失を回避するには、LokiStack CR のレプリケーション係数フィールドを常に 1 より大きい値に設定して、Loki が確実にレプリケートされるようにする必要があります。

前提条件

  • LokiStack CR のレプリケーション係数が 1 より大きいことを確認している。
  • コントロールプレーンによってゾーン障害が検出され、障害が発生したゾーン内のノードがクラウドプロバイダー統合によってマークされている。

StatefulSet コントローラーは、障害が発生したゾーン内の Pod を自動的に再スケジュールしようとします。関連する PVC も障害が発生したゾーンにあるため、別のゾーンへの自動再スケジュールは機能しません。新しいゾーンでステートフル Loki Pod とそのプロビジョニングされた PVC を正常に再作成できるようにするには、障害が発生したゾーンの PVC を手動で削除する必要があります。

手順

  1. 次のコマンドを実行して、Pending 中ステータスの Pod をリスト表示します。 

    $ oc get pods --field-selector status.phase==Pending -n openshift-logging
    Copy to Clipboard Toggle word wrap

    oc get pods の出力例

    NAME                           READY   STATUS    RESTARTS   AGE
    1 
    
logging-loki-index-gateway-1   0/1     Pending   0          17m
logging-loki-ingester-1        0/1     Pending   0          16m
logging-loki-ruler-1           0/1     Pending   0          16m
    Copy to Clipboard Toggle word wrap

    1
    これらの Pod は、障害が発生したゾーンに対応する PVC があるため、Pending ステータスになっています。

  2. 次のコマンドを実行して、Pending ステータスの PVC をリストします。 

    $ oc get pvc -o=json -n openshift-logging | jq '.items[] | select(.status.phase == "Pending") | .metadata.name' -r
    Copy to Clipboard Toggle word wrap

    oc get pvc の出力例

    storage-logging-loki-index-gateway-1
storage-logging-loki-ingester-1
wal-logging-loki-ingester-1
storage-logging-loki-ruler-1
wal-logging-loki-ruler-1
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して Pod の PVC を削除します。 

    $ oc delete pvc <pvc_name>  -n openshift-logging
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して Pod を削除します。 

    $ oc delete pod <pod_name>  -n openshift-logging
    Copy to Clipboard Toggle word wrap

    これらのオブジェクトが正常に削除されると、使用可能なゾーンでオブジェクトが自動的に再スケジュールされます。

2.4.8.7.1. terminating 状態の PVC のトラブルシューティング
リンクのコピー

PVC メタデータファイナライザーが kubernetes.io/pv-protection に設定されている場合、PVC が削除されずに terminating 状態でハングする可能性があります。ファイナライザーを削除すると、PVC が正常に削除されるようになります。

  • 以下のコマンドを実行して各 PVC のファイナライザーを削除し、削除を再試行します。 

    $ oc patch pvc <pvc_name> -p '{"metadata":{"finalizers":null}}' -n openshift-logging
    Copy to Clipboard Toggle word wrap
2.4.8.8. Loki レート制限エラーのトラブルシューティング
リンクのコピー

Log Forwarder API がレート制限を超える大きなメッセージブロックを Loki に転送すると、Loki により、レート制限 (429) エラーが生成されます。

これらのエラーは、通常の動作中に発生する可能性があります。たとえば、すでにいくつかのログがあるクラスターにロギングを追加する場合、ロギングが既存のログエントリーをすべて取り込もうとするとレート制限エラーが発生する可能性があります。この場合、新しいログの追加速度が合計レート制限よりも低い場合、履歴データは最終的に取り込まれ、ユーザーの介入を必要とせずにレート制限エラーが解決されます。

レート制限エラーが引き続き発生する場合は、LokiStack カスタムリソース (CR) を変更することで問題を解決できます。

重要

LokiStack CR は、Grafana がホストする Loki では利用できません。このトピックは、Grafana がホストする Loki サーバーには適用されません。

条件

  • Log Forwarder API は、ログを Loki に転送するように設定されている。

  • システムは、次のような 2MB を超えるメッセージのブロックを Loki に送信する。以下に例を示します。 

    "values":[["1630410392689800468","{\"kind\":\"Event\",\"apiVersion\":\
.......
......
......
......
\"received_at\":\"2021-08-31T11:46:32.800278+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-31T11:46:32.799692+00:00\",\"viaq_index_name\":\"audit-write\",\"viaq_msg_id\":\"MzFjYjJkZjItNjY0MC00YWU4LWIwMTEtNGNmM2E5ZmViMGU4\",\"log_type\":\"audit\"}"]]}]}
    Copy to Clipboard Toggle word wrap

  • oc logs -n openshift-logging -l component=collector と入力すると、クラスター内のコレクターログに、次のいずれかのエラーメッセージを含む行が表示されます。 

    429 Too Many Requests Ingestion rate limit exceeded
    Copy to Clipboard Toggle word wrap

    Vector エラーメッセージの例

    2023-08-25T16:08:49.301780Z  WARN sink{component_kind="sink" component_id=default_loki_infra component_type=loki component_name=default_loki_infra}: vector::sinks::util::retries: Retrying after error. error=Server responded with an error: 429 Too Many Requests internal_log_rate_limit=true
    Copy to Clipboard Toggle word wrap

    Fluentd エラーメッセージの例

    2023-08-30 14:52:15 +0000 [warn]: [default_loki_infra] failed to flush the buffer. retry_times=2 next_retry_time=2023-08-30 14:52:19 +0000 chunk="604251225bf5378ed1567231a1c03b8b" error_class=Fluent::Plugin::LokiOutput::LogPostError error="429 Too Many Requests Ingestion rate limit exceeded for user infrastructure (limit: 4194304 bytes/sec) while attempting to ingest '4082' lines totaling '7820025' bytes, reduce log volume or contact your Loki administrator to see if the limit can be increased\n"
    Copy to Clipboard Toggle word wrap

    このエラーは受信側にも表示されます。たとえば、LokiStack 取り込み Pod で以下を行います。

    Loki 取り込みエラーメッセージの例

    level=warn ts=2023-08-30T14:57:34.155592243Z caller=grpc_logging.go:43 duration=1.434942ms method=/logproto.Pusher/Push err="rpc error: code = Code(429) desc = entry with timestamp 2023-08-30 14:57:32.012778399 +0000 UTC ignored, reason: 'Per stream rate limit exceeded (limit: 3MB/sec) while attempting to ingest for stream
    Copy to Clipboard Toggle word wrap

手順

  • LokiStack CR の ingestionBurstSize および ingestionRate フィールドを更新します。 

    apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global:
      ingestion:
        ingestionBurstSize: 16
    1 
    
        ingestionRate: 8
    2 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    ingestionBurstSize フィールドは、ディストリビューターレプリカごとに最大ローカルレート制限サンプルサイズを MB 単位で定義します。この値はハードリミットです。この値を、少なくとも 1 つのプッシュリクエストで想定される最大ログサイズに設定します。ingestionBurstSize 値より大きい単一リクエストは使用できません。
    2
    ingestionRate フィールドは、1 秒あたりに取り込まれるサンプルの最大量 (MB 単位) に対するソフト制限です。ログのレートが制限を超えているにもかかわらず、コレクターがログの送信を再試行すると、レート制限エラーが発生します。合計平均が制限よりも少ない場合に限り、システムは回復し、ユーザーの介入なしでエラーが解決されます。

2.5. Loki での OTLP データ取り込み
リンクのコピー

Logging 6.1 では、OpenTelemetry Protocol (OTLP) を使用した API エンドポイントが有効になります。OTLP は Loki 専用に設計されたものではない標準化された形式であるため、OpenTelemetry のデータ形式を Loki のデータモデルにマッピングするには、Loki 側で追加の設定が必要です。OTLP には、ストリームラベル や 構造化メタデータ などの概念がありません。代わりに、OTLP はログエントリーに関するメタデータを 属性 として提供し、次の 3 つのカテゴリーにグループ化します。

  • リソース
  • Scope
  • Log

これにより、必要に応じて複数のエントリーに同時に、または個別にメタデータを設定できます。

2.5.1. OTLP データ取り込み用の LokiStack 設定
リンクのコピー

重要

OpenTelemetry Protocol (OTLP) 出力ログフォワーダーは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

OTLP 取り込み用に LokiStack カスタムリソース (CR) を設定するには、次の手順に従います。

前提条件

  • Loki セットアップが、OTLP ログの取り込みを有効にするためにスキーマバージョン 13 で導入された構造化メタデータをサポートしていることを確認します。

手順

  1. スキーマバージョンを設定します。

    • 新しい LokiStack CR を作成する場合は、ストレージスキーマ設定で version: v13 を設定します。

      注記

      既存の設定の場合は、version: v13 と現在より後の effectiveDate を持つ新しいスキーマエントリーを追加します。スキーマバージョンの更新の詳細は、Upgrading Schemas (Grafana ドキュメント) を参照してください。

  2. ストレージスキーマを次のように設定します。

    ストレージスキーマの設定例

    # ...
spec:
  storage:
    schemas:
    - version: v13
      effectiveDate: 2024-10-25
    Copy to Clipboard Toggle word wrap

    effectiveDate を過ぎると v13 スキーマが有効になり、LokiStack は構造化メタデータを保存できるようになります。

2.5.2. 属性マッピング
リンクのコピー

Loki Operator が openshift-logging モードに設定されている場合、デフォルトの属性マッピングセットが自動的に適用されます。これらのマッピングは、特定の OTLP 属性を Loki のストリームラベルおよび構造化メタデータと一致させます。

一般的なセットアップでは、デフォルトのマッピングで十分です。ただし、次の場合には属性マッピングをカスタマイズする必要があることもあります。

  • カスタムコレクターを使用する場合: セットアップに追加の属性を生成するカスタムコレクターが含まれている場合は、これらの属性を Loki に保持するためにマッピングをカスタマイズすることを検討してください。
  • 属性の詳細レベルを調整する場合: デフォルトの属性セットが必要以上に詳細な場合は、必須の属性のみに減らすことができます。そうすることで、過剰なデータ保存を回避し、ロギングプロセスを合理化できます。
重要

ストリームラベルと構造化メタデータのいずれにもマッピングされていない属性は、Loki に保存されません。

2.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
Copy to Clipboard Toggle word wrap
1
グローバル OTLP 属性の設定。
2
openshift-logging モード内の application テナントの OTLP 属性設定。
注記

グローバルおよびテナントごとの OTLP 設定の両方で、属性をストリームラベルまたは構造化メタデータにマッピングできます。ログエントリーを Loki ストレージに保存するには、少なくとも 1 つのストリームラベルが必要です。設定がその要件を満たしていることを確認してください。

ストリームラベルはリソースレベルの属性からのみ導出され、LokiStack リソース構造はそれを反映します。 

spec:
  limits:
    global:
      otlp:
        streamLabels:
          resourceAttributes:
          - name: "k8s.namespace.name"
          - name: "k8s.pod.name"
          - name: "k8s.container.name"
Copy to Clipboard Toggle word wrap

対照的に、構造化メタデータはリソース、スコープ、またはログレベルの属性から生成できます。 

# ...
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"
Copy to Clipboard Toggle word wrap
ヒント

Loki で類似の属性をマッピングする場合は、、属性名に regex: true を設定して正規表現を使用します。

重要

データ量が増加する可能性があるため、ストリームラベルに正規表現を使用することは避けてください。

2.5.2.2. OpenShift のデフォルトのカスタマイズ
リンクのコピー

openshift-logging モードでは、特定の属性が必須であり、OpenShift 機能でのロールのため、設定から削除できません。推奨 のラベルが付いているその他の属性は、パフォーマンスに影響がある場合は無効化されている可能性があります。

カスタム属性なしで openshift-logging モードを使用すると、即座に OpenShift ツールとの互換性が確保されます。ストリームラベルまたは構造化メタデータとして追加の属性が必要な場合は、カスタム設定を使用します。カスタム設定はデフォルト設定とマージできます。

2.6. OpenTelemetry データモデル
リンクのコピー

このドキュメントでは、Logging 6.1 における Red Hat OpenShift Logging の OpenTelemetry サポートのプロトコルおよびセマンティック規約について概説します。

重要

OpenTelemetry Protocol (OTLP) 出力ログフォワーダーは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

2.6.1. 転送および取り込みプロトコル
リンクのコピー

Red Hat OpenShift Logging は、OTLP 仕様 を使用してログを収集し、OpenTelemetry エンドポイントに転送します。OTLP はテレメトリーデータをエンコード、転送、配信します。ログストリームを取り込むための OTLP エンドポイントを提供する Loki ストレージをデプロイすることもできます。このドキュメントでは、さまざまな OpenShift クラスターソースから収集されたログのセマンティック規約を定義します。

2.6.2. セマンティック規約
リンクのコピー

このソリューションのログコレクターは、次のログストリームを収集します。

  • コンテナーログ
  • クラスターノードジャーナルログ
  • クラスターノード監査ログ
  • Kubernetes および OpenShift API サーバーログ
  • OpenShift Virtual Network (OVN) ログ

これらのストリームは、OpenTelemetry セマンティック属性によって定義されたセマンティック規約に従って転送できます。OpenTelemetry のセマンティック規約では、リソースを属性によって識別される、テレメトリーを生成するエンティティーのイミュータブルな表現と定義しています。たとえばコンテナー内で実行されているプロセスには、container_name、cluster_id、pod_name、namespace などの属性が含まれ、場合によっては deployment または app_name も含まれます。これらの属性はリソースオブジェクトの下にグループ化されており、繰り返しを減らし、テレメトリーデータとしてのログ送信を最適化するのに役立ちます。

ログには、リソース属性に加え、計装ライブラリーに固有のスコープ属性と、各ログエントリーに固有のログ属性も含まれる場合があります。これらの属性は、各ログエントリーに関するより詳細な情報を提供し、ストレージ内のログをクエリーする際のフィルタリング機能を強化します。

次のセクションでは、一般的に転送される属性を定義しています。

2.6.2.1. ログエントリー構造
リンクのコピー

すべてのログストリームには、次の ログデータ フィールドが含まれます。

適用可能ソース 列は、各フィールドに適用するログソースを示しています。

  • all: このフィールドは、すべてのログに存在します。
  • container: このフィールドは、アプリケーションとインフラストラクチャーの両方の Kubernetes コンテナーログに存在します。
  • audit: このフィールドは、Kubernetes ログ、OpenShift API ログ、OVN ログに存在します。
  • auditd: このフィールドは、ノード監査ログに存在します。
  • journal: このフィールドは、ノードジャーナルログに存在します。
Expand
名前適用可能ソースコメント

body

all

 

observedTimeUnixNano

all

 

timeUnixNano

all

 

severitytext

container、journal

 

attributes

all

(オプション) ストリーム固有の属性を転送する場合に存在します

2.6.2.2. 属性
リンクのコピー

次の表に示すとおり、ログエントリーにはソースに基づくリソース属性、スコープ属性、ログ属性のセットが含まれます。

場所 列は属性のタイプを示しています。

  • resource: リソース属性を示します
  • scope: スコープ属性を示します
  • log: ログ属性を示します

ストレージ 列は、属性がデフォルトの openshift-logging モードを使用して LokiStack に保存されているか、および保存場所を示しています。

  • stream label:

    • 特定のラベルに基づく効率的なフィルタリングとクエリーを可能にします。
    • Loki Operator が設定でこの属性を強制する場合は、required としてラベル付けできます。

  • structured metadata:

    • キーと値のペアの詳細なフィルタリングと保存を可能にします。
    • JSON 解析を使用することなく、合理化されたクエリーに直接ラベルを使用できるようになります。

OTLP を使用すると、ユーザーは JSON 解析を使用するのではなく、ラベルで直接クエリーをフィルタリングできるため、クエリーの速度と効率が向上します。

Expand
名前場所適用可能ソースストレージ (LokiStack)コメント

log_source

resource

all

required stream label

(非推奨) 互換性属性。openshift.log.source と同じ情報が含まれます。

log_type

resource

all

required stream label

(非推奨) 互換性属性。openshift.log.type と同じ情報が含まれます。

kubernetes.container_name

resource

container

stream label

(非推奨) 互換性属性。k8s.container.name と同じ情報が含まれます。

kubernetes.host

resource

all

stream label

(非推奨) 互換性属性。k8s.node.name と同じ情報が含まれます。

kubernetes.namespace_name

resource

container

required stream label

(非推奨) 互換性属性。k8s.namespace.name と同じ情報が含まれます。

kubernetes.pod_name

resource

container

stream label

(非推奨) 互換性属性。k8s.pod.name と同じ情報が含まれます。

openshift.cluster_id

resource

all

 

(非推奨) 互換性属性。openshift.cluster.uid と同じ情報が含まれます。

level

log

container、journal

 

(非推奨) 互換性属性。severityText と同じ情報が含まれます。

openshift.cluster.uid

resource

all

required stream label

 

openshift.log.source

resource

all

required stream label

 

openshift.log.type

resource

all

required stream label

 

openshift.labels.*

resource

all

structured metadata

 

k8s.node.name

resource

all

stream label

 

k8s.namespace.name

resource

container

required stream label

 

k8s.container.name

resource

container

stream label

 

k8s.pod.labels.*

resource

container

structured metadata

 

k8s.pod.name

resource

container

stream label

 

k8s.pod.uid

resource

container

structured metadata

 

k8s.cronjob.name

resource

container

stream label

Pod 作成者に基づき条件付きで転送されます

k8s.daemonset.name

resource

container

stream label

Pod 作成者に基づき条件付きで転送されます

k8s.deployment.name

resource

container

stream label

Pod 作成者に基づき条件付きで転送されます

k8s.job.name

resource

container

stream label

Pod 作成者に基づき条件付きで転送されます

k8s.replicaset.name

resource

container

structured metadata

Pod 作成者に基づき条件付きで転送されます

k8s.statefulset.name

resource

container

stream label

Pod 作成者に基づき条件付きで転送されます

log.iostream

log

container

structured metadata

 

k8s.audit.event.level

log

audit

structured metadata

 

k8s.audit.event.stage

log

audit

structured metadata

 

k8s.audit.event.user_agent

log

audit

structured metadata

 

k8s.audit.event.request.uri

log

audit

structured metadata

 

k8s.audit.event.response.code

log

audit

structured metadata

 

k8s.audit.event.annotation.*

log

audit

structured metadata

 

k8s.audit.event.object_ref.resource

log

audit

structured metadata

 

k8s.audit.event.object_ref.name

log

audit

structured metadata

 

k8s.audit.event.object_ref.namespace

log

audit

structured metadata

 

k8s.audit.event.object_ref.api_group

log

audit

structured metadata

 

k8s.audit.event.object_ref.api_version

log

audit

structured metadata

 

k8s.user.username

log

audit

structured metadata

 

k8s.user.groups

log

audit

structured metadata

 

process.executable.name

resource

journal

structured metadata

 

process.executable.path

resource

journal

structured metadata

 

process.command_line

resource

journal

structured metadata

 

process.pid

resource

journal

structured metadata

 

service.name

resource

journal

stream label

 

systemd.t.*

log

journal

structured metadata

 

systemd.u.*

log

journal

structured metadata

 
注記

互換性属性 としてマークされた属性は、ViaQ データモデルとの最小限の下位互換性をサポートします。これらは非推奨の属性であり、UI 機能の継続を保証するための互換性レイヤーとして機能します。これらの属性は、Logging UI が今後のリリースにおける OpenTelemetry 対応機能を完全にサポートするまで引き続きサポートされます。

Loki は、ストレージへの保存時に属性名を変更します。名前は小文字になり、セット内のすべての文字 (.、/、-) はアンダースコア (_) に置き換えられます。たとえば、k8s.namespace.name は k8s_namespace_name になります。

2.7. ロギングの可視化
リンクのコピー

ロギングの可視化は、Cluster Observability Operator の Logging UI プラグイン をデプロイすることで提供されます。そのためには Operator のインストールが必要です。

重要

現在は テクノロジープレビュー (TP) 機能である Cluster Observability Operator (COO) の一般提供 (GA) リリースが近づくまで、Red Hat は、OpenShift Container Platform 4.14 以降の Logging UI プラグイン の COO で Logging 6.0 以降を使用しているお客様にサポートを提供します。COO にはいくつかの独立した機能が含まれており、その一部はまだテクノロジープレビュー機能であるため、このサポート例外は一時的なものです。ただし、Logging UI プラグインは GA の準備が完了しています。

Legal Notice
リンクのコピー

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat