ロギングの設定


Red Hat OpenShift Logging 6.1

ログ転送と LokiStack を設定します。

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、ログ転送や LokiStack などの OpenShift ロギング機能の設定に関する概要を説明します。

第1章 ログ転送の設定

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

ClusterLogForwarder の主な機能

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

1.1. ログ収集のセットアップ

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

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

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

1.1.1. レガシーサービスアカウント

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

$ oc adm policy add-cluster-role-to-user collect-application-logs system:serviceaccount:openshift-logging:logcollector
Copy to Clipboard Toggle word wrap
$ 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.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.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.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
Copy to Clipboard Toggle word wrap
1
rules: この ClusterRole によって付与される権限を指定します。
2
apiGroups: Loki ロギングシステムに関連する API グループ loki.grafana.com を参照します。
3
loki.grafana.com: Loki 関連のリソースを管理するための API グループ。
4
resources: この ClusterRole がやり取りする権限を付与するリソースタイプ。
5
application: Loki ロギングシステム内のアプリケーションリソースを参照します。
6
resourceNames: このロールが管理できるリソースの名前を指定します。
7
logs: 作成できるログリソースを参照します。
8
verbs: リソースで許可されるアクション。
9
create: Loki システムに新しいログを作成する権限を付与します。
1.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
rules: この ClusterRole によって付与される権限を定義します。
2
apiGroups: API グループ loki.grafana.com を指定します。
3
loki.grafana.com: Loki ロギングリソースを管理する API グループ。
4
resources: このロールが管理するリソースタイプ (この場合は audit) を指します。
5
audit: ロールが Loki 内の監査ログを管理することを指定します。
6
resourceNames: ロールがアクセスできる特定のリソースを定義します。
7
logs: このロールで管理できるログを指します。
8
verbs: リソースで許可されるアクション。
9
create: 新しい監査ログを作成する権限を付与します。
1.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.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.2. コレクターのログレベルの変更

コレクターでログレベルを変更するには、observability.openshift.io/log-level アノテーションを tracedebuginfowarnerror、および 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.3. Operator の管理

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

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

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

1.4. ClusterLogForwarder の構造

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

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

1.4.1. Inputs

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

application
インフラストラクチャー namespace 内のログを除く、すべてのアプリケーションコンテナーからログを選択します。
infrastructure

次の namespace で実行されているノードおよびインフラストラクチャーコンポーネントからログを選択します。

  • default
  • kube
  • openshift
  • kube- または openshift- 接頭辞を含む
audit
OpenShift API サーバー監査ログ、Kubernetes API サーバー監査ログ、ovn 監査ログ、および auditd からのノード監査ログからログを選択します。

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

1.4.2. 出力

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

azureMonitor
ログを Azure Monitor に転送します。
cloudwatch
ログを AWS CloudWatch に転送します。
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.3. 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 に準拠しています。

1.4.4. Pipelines

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

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

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

1.4.5. Filters

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

1.5. サードパーティーシステムへのログ転送

OpenShift Container Platform クラスターの内部および外部の特定のエンドポイントにログを送信するには、ClusterLogForwarder カスタムリソース (CR) で出力とパイプラインの組み合わせを指定します。入力を使用して、特定のプロジェクトに関連付けられたアプリケーションログをエンドポイントに転送することもできます。認証は Kubernetes Secret オブジェクトによって提供されます。

pipeline

1 つのログタイプから 1 つまたは複数の出力への単純なルーティング、または送信するログを定義します。ログタイプは以下のいずれかになります。

  • application。クラスターで実行される、インフラストラクチャーコンテナーアプリケーションを除くユーザーアプリケーションによって生成されるコンテナーログ。
  • infrastructureopenshift*kube*、または default プロジェクトで実行される Pod のコンテナーログおよびノードファイルシステムから取得されるジャーナルログ。
  • auditノード監査システム、auditd、Kubernetes API サーバー、OpenShift API サーバー、および OVN ネットワークで生成される監査ログ。

パイプラインで key:value ペアを使用すると、アウトバウンドログメッセージにラベルを追加できます。たとえば、他のデータセンターに転送されるメッセージにラベルを追加したり、タイプ別にログにラベルを付けたりできます。オブジェクトに追加されるラベルもログメッセージと共に転送されます。

input

特定のプロジェクトに関連付けられるアプリケーションログをパイプラインに転送します。

パイプラインでは、inputRef パラメーターを使用して転送するログタイプと、outputRef パラメーターを使用してログを転送する場所を定義します。

Secret
ユーザー認証情報などの機密データを含む key:value map

以下の点に注意してください。

  • ログタイプのパイプラインを定義しない場合、未定義タイプのログはドロップされます。たとえば、application および audit タイプのパイプラインを指定するものの、infrastructure タイプのパイプラインを指定しないと、infrastructure ログはドロップされます。
  • ClusterLogForwarder カスタムリソース (CR) で出力の複数のタイプを使用し、ログを複数の異なるプロトコルをサポートするサーバーに送信できます。

次の例では、監査ログをセキュアな外部 Elasticsearch インスタンスに転送します。

ログ転送の出力とパイプラインのサンプル

kind: ClusterLogForwarder
apiVersion: observability.openshift.io/v1
metadata:
  name: instance
  namespace: openshift-logging
spec:
  serviceAccount:
    name: logging-admin
  outputs:
    - name: external-es
      type: elasticsearch
      elasticsearch:
        url: 'https://example-elasticsearch-secure.com:9200'
        version: 8  
1

        index: '{.log_type||"undefined"}'  
2

        authentication:
          username:
            key: username
            secretName: es-secret  
3

          password:
            key: password
            secretName: es-secret  
4

      tls:
        ca:                        
5

          key: ca-bundle.crt
          secretName: es-secret
        certificate:
          key: tls.crt
          secretName: es-secret
        key:
          key: tls.key
          secretName: es-secret
  pipelines:
    - name: my-logs
      inputRefs:
        - application
        - infrastructure
      outputRefs:
        - external-es
Copy to Clipboard Toggle word wrap

1
バージョン 8.x 以降の外部 Elasticsearch に転送するには、version フィールドを指定する必要があります。
2
index は、フィールド値 .log_type を読み取るように設定されています。見つからない場合は "unknown" にフォールバックします。
3 4
ユーザー名とパスワードを使用してサーバーに認証します。
5
コレクターと elasticsearch 間の相互 Transport Layer Security (mTLS) を有効にします。この仕様では、それぞれの証明書に対応するキーとシークレットを指定しています。
サポート対象の認証キー

ここでは、一般的なキータイプを示します。出力タイプによっては、その出力固有の設定フィールドで解説されている、追加の専用キーをサポートしているものもあります。シークレットキーはすべて任意です。関連するキーを設定して、必要なセキュリティー機能を有効にします。キーやシークレット、サービスアカウント、ポートのオープン、またはグローバルプロキシー設定など、外部の宛先で必要となる可能性のある追加設定を作成し、維持する必要があります。OpenShift Logging は、認証の組み合わせ間の不一致を検証しません。

トランスポートレイヤーセキュリティー (Transport Layer Security, TLS)

シークレットなしで TLS URL (http://... または ssl://...) を使用すると、基本的な TLS サーバー側の認証が有効になります。シークレットを含め、次のオプションフィールドを設定すると、追加の TLS 機能が有効になります。

  • passphrase:(文字列) エンコードされた TLS 秘密鍵をデコードするためのパスフレーズ。tls.key が必要です。
  • ca-bundle.crt:(文字列) サーバー認証用のカスタマー CA のファイル名。
ユーザー名およびパスワード
  • username: (文字列) 認証ユーザー名。password が必要です。
  • password: (文字列) 認証パスワード。username が必要です。
Simple Authentication Security Layer (SASL)
  • sasl.enable (ブール値) SASL を明示的に有効または無効にします。ない場合は、SASL は、他の sasl. キーが設定されている場合に自動的に有効になります。
  • sasl.mechanisms:(配列) 許可された SASL メカニズム名のリスト。欠落しているか空の場合は、システムのデフォルトが使用されます。
  • sasl.allow-insecure:(ブール値) クリアテキストのパスワードを送信するメカニズムを許可します。デフォルトは false です。

1.5.1. シークレットの作成

次のコマンドを使用して、証明書とキーファイルを含むディレクトリーにシークレットを作成できます。

$ oc create secret generic -n <namespace> <secret_name> \
  --from-file=ca-bundle.crt=<your_bundle_file> \
  --from-literal=username=<your_username> \
  --from-literal=password=<your_password>
Copy to Clipboard Toggle word wrap
注記

最適な結果を得るには、generic または opaque シークレットを使用することを推奨します。

1.6. ログフォワーダーの作成

ログフォワーダーを作成するには、ClusterLogForwarder カスタムリソース (CR) を作成します。この CR は、サービスアカウント、許可される入力ログの種類、パイプライン、出力、および必要に応じてフィルターを定義します。

重要

ClusterLogForwarder CR を作成する namespace の管理者権限が必要です。

ClusterLogForwarder CR の例

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
  namespace: <log_forwarder_namespace>
spec:
  outputs:                       
1

    - name: <output_name>
      type: <output_type>
  inputs:                        
2

    - name: <input_name>
      type: <input_type>
  filters:                       
3

    - name: <filter_name>
      type: <filter_type>
  pipelines:
    - inputRefs:
      - <input_name>             
4

    - outputRefs:
      - <output_name>            
5

    - filterRefs:
      - <filter_name>            
6

  serviceAccount:
    name: <service_account_name> 
7

# ...
Copy to Clipboard Toggle word wrap

1
ログの転送先の出力のタイプ。このフィールドの値は、azureMonitorcloudwatchelasticsearchgoogleCloudLogginghttpkafkalokilokistackotlpsplunksyslog のいずれかです。
2
入力のリスト。applicationaudit、および infrastructure という名前は、デフォルトの入力用に予約されています。
3
このパイプラインを通過するレコードに適用するフィルターのリスト。各フィルターはここで定義された順序で適用されます。フィルターによってレコードが削除された場合、後続のフィルターは適用されません。
4
この値は入力名と同じである必要があります。デフォルトの入力名 applicationinfrastructure、および audit を使用することもできます。
5
この値は、出力名と同じである必要があります。
6
この値はフィルター名と同じである必要があります。
7
サービスアカウントの名前。

1.7. ログペイロードと配信の調整

ClusterLogForwarder カスタムリソース (CR) の tuning 仕様は、ログのスループットまたは永続性を優先するようにデプロイメントを設定する手段を提供します。

たとえば、コレクターの再起動時にログが失われる可能性を減らす必要がある場合や、規制要件に対応するために収集したログメッセージをコレクターの再起動後も保持する必要がある場合は、ログの永続性を優先するようにデプロイメントを調整できます。受信できるバッチのサイズに厳しい制限がある出力を使用する場合は、ログスループットを優先するようにデプロイメントを調整することを推奨します。

重要

この機能を使用するには、ロギングのデプロイメントが Vector コレクターを使用するように設定されている必要があります。Fluentd コレクターを使用する場合、ClusterLogForwarder CR の tuning 仕様はサポートされません。

次の例は、ClusterLogForwarder CR オプションで、こちらを変更してログフォワーダーの出力を調整できます。

ClusterLogForwarder CR チューニングオプションの例

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  # ...
  outputs:
  - name: default-lokistack
    type: lokiStack
    lokiStack:
      tuning:
        deliveryMode: AtLeastOnce 
1

        compression: none 
2

        maxWrite: <integer> 
3

        minRetryDuration: 1s 
4

        maxRetryDuration: 1s 
5

# ...
Copy to Clipboard Toggle word wrap

1
ログ転送の配信モードを指定します。
  • AtLeastOnce 配信とは、ログフォワーダーがクラッシュしたり再起動したりした場合に、クラッシュ前に読み取られたが宛先に送信されなかったログが、再送信されることを意味します。クラッシュ後に一部のログが重複している可能性があります。
  • AtMostOnce 配信とは、クラッシュ中に失われたログを、ログフォワーダーが復元しようとしにことを意味します。このモードではスループットが向上しますが、ログの損失が大きくなる可能性があります。
2
compression 設定を指定すると、データはネットワーク経由で送信される前に圧縮されます。すべての出力タイプが圧縮をサポートしているわけではないことに注意してください。指定された圧縮タイプが出力でサポートされていない場合は、エラーが発生します。詳細は、「チューニング出力でサポートされている圧縮タイプ」を参照してください。
3
出力への単一の送信操作の最大ペイロードの制限を指定します。
4
配信が失敗した後に次に再試行するまでの最小待機時間を指定します。この値は文字列であり、ミリ秒 (ms)、秒 (s)、または分 (m) を指定できます。
5
配信が失敗した後に次に再試行するまでの最大待機時間を指定します。この値は文字列であり、ミリ秒 (ms)、秒 (s)、または分 (m) を指定できます。
Expand
表1.1 チューニング出力でサポートされている圧縮タイプ
圧縮アルゴリズムSplunkAmazon CloudwatchElasticsearch 8LokiStackApache KafkaHTTPSyslogGoogle CloudMicrosoft Azure Monitoring

gzip

X

X

X

X

 

X

   

snappy

 

X

 

X

X

X

   

zlib

 

X

X

  

X

   

zstd

 

X

  

X

X

   

lz4

    

X

    

1.7.1. 複数行の例外検出の有効化

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

警告

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

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

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.7.1.1. 詳細

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

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

  • Java
  • JS
  • Ruby
  • Python
  • Golang
  • PHP
  • Dart

1.8. Google Cloud Platform (GCP) へのログ転送

ログを Google Cloud Logging に転送できます。

重要

AWS 上の Red Hat OpenShift では、GCP へのログの転送はサポートされていません。

前提条件

  • Red Hat OpenShift Logging Operator がインストールされている。

手順

  1. Google サービスアカウントキー を使用してシークレットを作成します。

    $ oc -n openshift-logging create secret generic gcp-secret --from-file google-application-credentials.json=<your_service_account_key_file.json>
    Copy to Clipboard Toggle word wrap
  2. 以下のテンプレートを使用して、ClusterLogForwarder カスタムリソース YAML を作成します。

    apiVersion: observability.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name>
      namespace: openshift-logging
    spec:
      serviceAccount:
        name: <service_account_name> 
    1
    
      outputs:
        - name: gcp-1
          type: googleCloudLogging
          googleCloudLogging:
            authentication:
              credentials:
                secretName: gcp-secret
                key: google-application-credentials.json
            id:
              type : project
              value: openshift-gce-devel 
    2
    
            logId : app-gcp 
    3
    
      pipelines:
        - name: test-app
          inputRefs: 
    4
    
            - application
          outputRefs:
            - gcp-1
    Copy to Clipboard Toggle word wrap
1
サービスアカウントの名前。
2
ログを保存する GCP リソース階層内の場所に応じて、projectfolderorganization、または billingAccount フィールドとそれに対応する値を設定します。
3
ログエントリーの logName フィールドに追加する値を設定します。値は、静的値と動的値を組み合わせたものにすることができます。フィールドパスとそれに続く || で構成され、その後に別のフィールドパスまたは静的値が続きます。動的値は 1 つの中括弧 {} で囲む必要があり、末尾に || で区切られた静的なフォールバック値を付ける必要があります。静的値には、英数字とダッシュ、アンダースコア、ドット、スラッシュのみを含めることができます。
4
このパイプラインの input.name フィールドで定義した入力の名前を指定します。組み込み値 applicationinfrastructureaudit を使用することもできます。

1.9. Splunk へのログ転送

ログを Splunk HTTP Event Collector (HEC) に転送できます。

前提条件

  • Red Hat OpenShift Logging Operator がインストールされている。
  • Base64 でエンコードされた Splunk HEC トークンを取得した。

手順

  1. Base64 でエンコードされた Splunk HEC トークンを使用してシークレットを作成します。

    $ oc -n openshift-logging create secret generic vector-splunk-secret --from-literal hecToken=<HEC_Token>
    Copy to Clipboard Toggle word wrap
  2. 以下のテンプレートを使用して、ClusterLogForwarder カスタムリソース (CR) を作成または編集します。

    apiVersion: observability.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name>
      namespace: openshift-logging
    spec:
      serviceAccount:
        name: <service_account_name> 
    1
    
      outputs:
        - name: splunk-receiver 
    2
    
          type: splunk 
    3
    
          splunk:
            url: '<http://your.splunk.hec.url:8088>' 
    4
    
            authentication:
              token:
                secretName: splunk-secret
                key: hecToken 
    5
    
            index: '{.log_type||"undefined"}' 
    6
    
            source: '{.log_source||"undefined"}' 
    7
    
            indexedFields: ['.log_type', '.log_source'] 
    8
    
            payloadKey: '.kubernetes' 
    9
    
            tuning:
                compression: gzip 
    10
    
      pipelines:
        - name: my-logs
          inputRefs: 
    11
    
            - application
            - infrastructure
          outputRefs:
            - splunk-receiver 
    12
    Copy to Clipboard Toggle word wrap
    1
    サービスアカウントの名前。
    2
    出力の名前を指定します。
    3
    出力タイプを splunk として指定します。
    5
    HEC トークンが含まれるシークレットの名前を指定します。
    4
    Splunk HEC の URL (ポートを含む) を指定します。
    6
    イベントの送信先となるインデックスの名前を指定します。インデックスを指定しない場合は、Splunk サーバー設定のデフォルトのインデックスが使用されます。これは任意のフィールドです。
    7
    このシンクに送信するイベントのソースを指定します。イベントごとに動的な値を設定できます。このフィールドは任意です。
    8
    Splunk インデックスに追加するフィールドを指定します。このフィールドは任意です。
    9
    ペイロードとして使用するレコードフィールドを指定します。このフィールドは任意です。
    10
    圧縮設定を指定します。gzip または none のいずれかを指定できます。デフォルト値は none です。このフィールドは任意です。
    11
    入力名を指定します。
    12
    このパイプラインでログを転送する時に使用する出力の名前を指定します。

1.10. HTTP 経由でのログ転送

HTTP 経由でログを転送できるようにするには、ClusterLogForwarder カスタムリソース (CR) で出力タイプとして http を指定します。

手順

  • 以下のテンプレートを使用して、ClusterLogForwarder CR を作成または編集します。

    ClusterLogForwarder CR の例

    apiVersion: observability.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name>
      namespace: <log_forwarder_namespace>
    spec:
      managementState: Managed
      outputs:
      - name: <output_name>
        type: http
        http:
          headers:  
    1
    
              h1: v1
              h2: v2
          authentication:
            username:
              key: username
              secretName: <http_auth_secret>
            password:
              key: password
              secretName: <http_auth_secret>
          timeout: 300
          proxyURL: <proxy_url> 
    2
    
          url: <url> 
    3
    
        tls:
          insecureSkipVerify: 
    4
    
          ca:
            key: <ca_certificate>
            secretName: <secret_name> 
    5
    
      pipelines:
        - inputRefs:
            - application
          name: pipe1
          outputRefs:
            - <output_name>  
    6
    
      serviceAccount:
        name: <service_account_name> 
    7
    Copy to Clipboard Toggle word wrap

    1
    ログレコードと送信する追加のヘッダー。
    2
    オプション: この出力から http または https 経由でログを転送するために使用する HTTP/HTTPS プロキシーの URL。この設定は、クラスターまたはノードのデフォルトのプロキシー設定をオーバーライドします。
    3
    ログの宛先アドレス。
    4
    値は true または false です。
    5
    宛先認証情報のシークレット名。
    6
    この値は、出力名と同じである必要があります。
    7
    サービスアカウントの名前。

1.11. Azure Monitor ログへの転送

ログを Azure Monitor Logs に転送できます。この機能は、Vector Azure Monitor Logs sink によって提供されます。

前提条件

  • Azure サービスに関する基本的な知識がある。
  • Azure Portal または Azure CLI アクセス用に設定された Azure アカウントがある。
  • Azure Monitor Logs のプライマリーセキュリティーキーまたはセカンダリーセキュリティーキーを取得している。
  • 転送するログの種類を決定している。
  • OpenShift CLI (oc) がインストールされている。
  • Red Hat OpenShift Logging Operator がインストールされている。
  • 管理者権限がある。

手順

  1. HTTP Data Collector API 経由で Azure Monitor ログへのログ転送を有効にします。

共有キーを使用してシークレットを作成します。

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: openshift-logging
type: Opaque
data:
  shared_key: <your_shared_key> 
1
Copy to Clipboard Toggle word wrap
1
要求を行う Log Analytics ワークスペース のプライマリーキーまたはセカンダリーキーを含める必要があります。
  1. 共有キー を取得するには、Azure CLI で次のコマンドを使用します。
Get-AzOperationalInsightsWorkspaceSharedKey -ResourceGroupName "<resource_name>" -Name "<workspace_name>”
Copy to Clipboard Toggle word wrap
  1. 選択したログに一致するテンプレートを使用して、ClusterLogForwarder CR を作成または編集します。

すべてのログの転送

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
  namespace: openshift-logging
spec:
  serviceAccount:
    name: <service_account_name> 
1

  outputs:
  - name: azure-monitor
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id 
2

      logType: my_log_type 
3

      authentication:
        sharedKey:
          secretName: my-secret
          key: shared_key
  pipelines:
    - name: app-pipeline
      inputRefs:
      - application
      outputRefs:
      - azure-monitor
Copy to Clipboard Toggle word wrap

1
サービスアカウントの名前。
2
Log Analytics ワークスペースの一意の識別子。必須フィールド。
3
送信されるデータのレコードタイプ。文字、数字、アンダースコア (_) のみを含めることができ、100 文字を超えることはできません。詳細は、Microsoft Azure ドキュメントの Azure record type を参照してください。

1.12. 特定のプロジェクトからのアプリケーションログの転送

内部ログストアの使用に加えて、またはその代わりに、アプリケーションログのコピーを特定のプロジェクトから外部ログアグリゲータに転送できます。また、外部ログアグリゲーターを OpenShift Container Platform からログデータを受信できるように設定する必要もあります。

アプリケーションログのプロジェクトからの転送を設定するには、プロジェクトから少なくとも 1 つの入力で ClusterLogForwarder カスタムリソース (CR) を作成し、他のログアグリゲーターのオプション出力、およびそれらの入出力を使用するパイプラインを作成する必要があります。

前提条件

  • 指定されたプロトコルまたは形式を使用してロギングデータを受信するように設定されたロギングサーバーが必要です。

手順

  1. ClusterLogForwarder CR を定義する YAML ファイルを作成または編集します。

    ClusterLogForwarder CR の例

    apiVersion: observability.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name>
      namespace: <log_forwarder_namespace>
    spec:
      serviceAccount:
        name: <service_account_name>
      outputs:
      - name: <output_name>
        type: <output_type>
      inputs:
      - name: my-app-logs    
    1
    
        type: application    
    2
    
        application:
          includes:  
    3
    
          - namespace: my-project
      filters:
      - name: my-project-labels
        type: openshiftLabels
        openshiftLabels:  
    4
    
          project: my-project
      - name: cluster-labels
        type: openshiftLabels
        openshiftLabels:
          clusterId: C1234
      pipelines:
      - name: <pipeline_name> 
    5
    
        inputRefs:
        - my-app-logs
        outputRefs:
        - <output_name>
        filterRefs:
        - my-project-labels
        - cluster-labels
    Copy to Clipboard Toggle word wrap

    1
    入力の名前を指定します。
    2
    アプリケーションからログを収集するには、タイプを application として指定します。
    3
    ログ収集時に収集対象に含める namespace とコンテナーのセットを指定します。
    4
    このパイプラインを通過するログレコードに適用するラベルを指定します。これらのラベルは、ログレコードの openshift.labels マップ内に表示されます。
    5
    パイプラインの名前を指定します。
  2. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。

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

1.13. 特定の Pod からのアプリケーションログの転送

クラスター管理者は、Kubernetes Pod ラベルを使用して特定の Pod からログデータを収集し、これをログコレクターに転送できます。

アプリケーションがさまざまな namespace の他の Pod と共に実行される Pod で構成されるとします。これらの Pod にアプリケーションを識別するラベルがある場合は、それらのログデータを収集し、特定のログコレクターに出力できます。

Pod ラベルを指定するには、1 つ以上の matchLabels のキー/値のペアを使用します。複数のキー/値のペアを指定する場合、Pod は選択されるそれらすべてに一致する必要があります。

手順

  1. ClusterLogForwarder CR オブジェクトを定義する YAML ファイルを作成または編集します。ファイルで、以下の例が示すように inputs[].name.application.selector.matchLabels の下で単純な等価ベース (Equality-based) のセレクターを使用して Pod ラベルを指定します。

    apiVersion: observability.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name>
      namespace: <log_forwarder_namespace>
    spec:
      serviceAccount:
        name: <service_account_name> 
    1
    
      outputs:
        - <output_name>
        # ...
      inputs:
      - name: exampleAppLogData 
    2
    
        type: application 
    3
    
        application:
          includes: 
    4
    
          - namespace: app1
          - namespace: app2
          selector:
            matchLabels: 
    5
    
              environment: production
              app: nginx
      pipelines:
      - inputRefs:
        - exampleAppLogData
        outputRefs:
        # ...
    Copy to Clipboard Toggle word wrap
    1
    サービスアカウント名を指定します。
    2
    入力の名前を指定します。
    3
    アプリケーションからログを収集するには、タイプを application として指定します。
    4
    ログ収集時に収集対象に含める namespace のセットを指定します。
    5
    収集するログデータを持つ Pod ラベルのキー/値のペアを指定します。キーだけではなく、キーと値の両方を指定する必要があります。Pod を選択するには、Pod はすべてのキーと値のペアと一致する必要があります。
  2. オプション: 異なる Pod ラベルを持つ追加のアプリケーションから同じパイプラインにログデータを送信できます。

    1. Pod ラベルの一意の組み合わせごとに、表示されるものと同様の追加の inputs[].name セクションを作成します。
    2. このアプリケーションの Pod ラベルに一致するように、selectors を更新します。
    3. 新規の inputs[].name 値を inputRefs に追加します。以下に例を示します。

      - inputRefs: [ myAppLogData, myOtherAppLogData ]
      Copy to Clipboard Toggle word wrap
  3. CR オブジェクトを作成します。

    $ oc create -f <file-name>.yaml
    Copy to Clipboard Toggle word wrap

1.13.1. 不要なログレコードを削除するコンテンツフィルターの設定

すべてのクラスターログを収集すると大量のデータが生成され、その移動と保存にコストがかかる可能性があります。ボリュームを削減するには、転送前に不要なログレコードを除外するように drop フィルターを設定できます。ログコレクターは、フィルターに対してログストリームを評価し、指定された条件に一致するレコードを破棄します。

drop フィルターは、test フィールドを使用して、ログレコードを評価するための 1 つ以上の条件を定義します。フィルターは、レコードを破棄するかどうかを確認するために次のルールを適用します。

  • 指定された条件がすべて true と評価された場合、テストは合格となります。
  • テストに合格すると、フィルターはログレコードを破棄します。
  • drop フィルター設定で複数のテストを定義すると、いずれかのテストに合格するとフィルターによってログレコードが破棄されます。
  • 条件の評価中にエラーが発生した場合 (参照先のフィールドが欠落している場合など)、その条件は false と評価されます。

前提条件

  • Red Hat OpenShift Logging Operator がインストールされている。
  • 管理者権限がある。
  • ClusterLogForwarder カスタムリソース (CR) を作成した。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 既存の ClusterLogForwarder 設定を抽出し、ローカルファイルとして保存します。

    $ oc get clusterlogforwarder <name> -n <namespace> -o yaml > <filename>.yaml
    Copy to Clipboard Toggle word wrap

    詳細は、以下のようになります。

    • <name> は、設定する ClusterLogForwarder インスタンスの名前です。
    • <namespace> は、ClusterLogForwarder インスタンスを作成した namespace です (例: openshift-logging)。
    • <filename> は、設定を保存するローカルファイルの名前です。
  2. ClusterLogForwarder CR の filters spec に、不要なログレコードを破棄する設定を追加します。

    ClusterLogForwarder CR の例

    apiVersion: observability.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      # ...
      filters:
      - name: drop-filter
        type: drop 
    1
    
        drop: 
    2
    
        - test: 
    3
    
          - field: .kubernetes.labels."app.version-1.2/beta" 
    4
    
            matches: .+ 
    5
    
          - field: .kubernetes.pod_name
            notMatches: "my-pod" 
    6
    
      pipelines:
      - name: my-pipeline 
    7
    
        filterRefs:
        - drop-filter
      # ...
    Copy to Clipboard Toggle word wrap

    1
    フィルターのタイプを指定します。drop フィルターは、フィルター設定に一致するログレコードを破棄します。
    2
    drop フィルターの設定オプションを指定します。
    3
    フィルターがログレコードを破棄するかどうかを評価するテストの条件を指定します。
    4
    ログレコード内のフィールドへのドット区切りのパスを指定します。
    • 各パスセグメントには、英数字とアンダースコア (a-zA-Z0-9_) を含めることができます (例: .kubernetes.namespace_name)。
    • セグメントに異なる文字が含まれている場合は、セグメントを引用符で囲む必要があります (例: .kubernetes.labels."app.version-1.2/beta")。
    • 1 つの test 設定にいくつかのフィールドパスを含めることができますが、テストに合格して drop フィルターを適用するには、すべてのフィールドパスが true と評価される必要があります。
    5
    正規表現を指定します。ログレコードがこの正規表現と一致する場合は、破棄されます。
    6
    正規表現を指定します。ログレコードがこの正規表現に一致しない場合、破棄されます。
    7
    drop フィルターを使用するパイプラインを指定します。
    注記

    単一の field パスに対して matches または notMatches 条件のいずれかを設定できますが、両方を設定することはできません。

    優先度の高いログレコードのみを保持する設定例

    # ...
    filters:
    - name: important
      type: drop
      drop:
      - test:
        - field: .message
          notMatches: "(?i)critical|error"
        - field: .level
          matches: "info|warning"
    # ...
    Copy to Clipboard Toggle word wrap

    いくつかのテストを含む設定例

    # ...
    filters:
    - name: important
      type: drop
      drop:
      - test: 
    1
    
        - field: .kubernetes.namespace_name
          matches: "openshift.*"
      - test: 
    2
    
        - field: .log_type
          matches: "application"
        - field: .kubernetes.pod_name
          notMatches: "my-pod"
    # ...
    Copy to Clipboard Toggle word wrap

    1
    フィルターは、openshift で始まる namespace を含むログを破棄します。
    2
    フィルターは、Pod 名に my-pod が含まれないアプリケーションログを破棄します。
  3. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。

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

1.13.2. API 監査フィルターの概要

OpenShift API サーバーは、すべての API 呼び出しに対して監査イベントを生成します。これらのイベントには、リクエスト、応答、リクエスト元のアイデンティティーに関する詳細が含まれます。これにより、大量のデータが発生する可能性があります。

API 監査フィルターは、ルールを使用して重要でないイベントを除外し、イベントサイズを縮小することで、監査証跡の管理に役立ちます。ルールは順番にチェックされ、最初の一致でチェックが停止します。イベント内のデータの量は、level フィールドの値によって異なります。

  • None: イベントは破棄されます。
  • Metadata: イベントには監査メタデータが含まれ、要求本文と応答本文は除外されます。
  • Request: イベントには監査メタデータと要求本文が含まれ、応答本文は含まれません。
  • RequestResponse: イベントには、メタデータ、要求本文、応答本文など、すべてのデータが含まれます。レスポンス本文が非常に大きくなる可能性があります。たとえば、oc get pods -A はクラスター内のすべての Pod の YAML 記述を含むレスポンス本文を生成します。
注記

API 監査フィルター機能は、ロギングデプロイメントで Vector コレクターがセットアップされている場合にのみ使用できます。

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

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

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

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

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

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

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

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

監査ポリシーの例

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  serviceAccount:
    name: example-service-account
  pipelines:
    - name: my-pipeline
      inputRefs:
        - audit 
1

      filterRefs:
        - my-policy 
2

      outputRefs:
        - my-output
  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 を指定します。有効な値には、InNotInExistsDoesNotExist などがあります。
    3
    文字列値の配列を指定します。operator 値が Exists または DoesNotExist のいずれかの場合、値の配列は空である必要があります。
    4
    正確なキーまたは値のマッピングを指定します。
  2. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。

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

1.13.4. ログレコードをプルーニングするコンテンツフィルターの設定

prune フィルターを設定すると、ログコレクターは転送前にフィルターに対してログストリームを評価します。コレクターは、Pod アノテーションなどの値の低いフィールドを削除してログレコードをプルーニングします。

前提条件

  • Red Hat OpenShift Logging Operator がインストールされている。
  • 管理者権限がある。
  • ClusterLogForwarder カスタムリソース (CR) を作成した。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 既存の ClusterLogForwarder 設定を抽出し、ローカルファイルとして保存します。

    $ oc get clusterlogforwarder <name> -n <namespace> -o yaml > <filename>.yaml
    Copy to Clipboard Toggle word wrap

    詳細は、以下のようになります。

    • <name> は、設定する ClusterLogForwarder インスタンスの名前です。
    • <namespace> は、ClusterLogForwarder インスタンスを作成した namespace です (例: openshift-logging)。
    • <filename> は、設定を保存するローカルファイルの名前です。
  2. ClusterLogForwarder CR の filters spec にログレコードをプルーニングするための設定を追加します。

    重要

    innotIn の両方のパラメーターを指定した場合、プルーニング中に notIn 配列が in よりも優先されます。notIn 配列を使用してレコードがプルーニングされた後、続いて in 配列を使用してレコードがプルーニングされます。

    ClusterLogForwarder CR の例

    apiVersion: observability.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      serviceAccount:
        name: my-account
      filters:
      - name: prune-filter
        type: prune 
    1
    
        prune: 
    2
    
          in: [.kubernetes.annotations, .kubernetes.namespace_id] 
    3
    
          notIn: [.kubernetes,.log_type,.message,."@timestamp",.log_source] 
    4
    
      pipelines:
      - name: my-pipeline 
    5
    
        filterRefs: ["prune-filter"]
      # ...
    Copy to Clipboard Toggle word wrap

    1
    フィルターのタイプを指定します。prune フィルターでは、設定されたフィールドでログレコードをプルーニングします。
    2
    prune フィルターの設定オプションを指定します。
    • in フィールドと notIn フィールドは、ログレコード内のフィールドへのドットで区切られたパスの配列です。
    • 各パスセグメントには、英数字とアンダースコア (a-zA-Z0-9_) を含めることができます (例: .kubernetes.namespace_name)。
    • セグメントに異なる文字が含まれている場合は、セグメントを引用符で囲む必要があります (例: .kubernetes.labels."app.version-1.2/beta")。
    3
    オプション: ログレコードから削除するフィールドを指定します。ログコレクターが他のすべてのフィールドを保持します。
    4
    オプション: ログレコードに保持するフィールドを指定します。ログコレクターが他のすべてのフィールドを削除します。
    5
    prune フィルターを適用するパイプラインを指定します。
    重要
    • フィルターは、ログレコードから .log_type.log_source.message フィールドを削除できません。それらを notIn フィールドに含める必要があります。
    • googleCloudLogging 出力を使用する場合は、notIn フィールドに .hostname を含める必要があります。
  3. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。

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

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

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章 ロギングコレクターの設定

Red Hat OpenShift の Logging は、クラスターからオペレーションとアプリケーションログを収集し、Kubernetes Pod とプロジェクトメタデータでデータを拡充します。サポートされているログコレクターの変更は、すべて ClusterLogForwarder カスタムリソース (CR) の spec.collection スタンザを通じて行うことができます。

2.1. LogFileMetricExporter リソースの作成

実行中のコンテナーによって生成されたログからメトリクスを生成するには、LogFileMetricExporter カスタムリソース (CR) を手動で作成する必要があります。この CR はデフォルトでコレクターとともにデプロイされないためです。

注記

LogFileMetricExporter CR を作成しないと、OpenShift Container Platform Web コンソールダッシュボードの Produced Logs フィールドに No datapoints found というメッセージが表示されることがあります。

前提条件

  • 管理者権限がある。
  • Red Hat OpenShift Logging Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. LogFileMetricExporter CR を YAML ファイルとして作成します。

    LogFileMetricExporter CR の例

    apiVersion: logging.openshift.io/v1alpha1
    kind: LogFileMetricExporter
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      nodeSelector: {} 
    1
    
      resources: 
    2
    
        limits:
          cpu: 500m
          memory: 256Mi
        requests:
          cpu: 200m
          memory: 128Mi
      tolerations: [] 
    3
    
    # ...
    Copy to Clipboard Toggle word wrap

    1
    オプション: nodeSelector スタンザは、Pod がスケジュールされるノードを定義します。
    2
    resources スタンザは、LogFileMetricExporter CR のリソース要件を定義します。
    3
    オプション: tolerations スタンザは、Pod が受け入れる toleration を定義します。
  2. 次のコマンドを実行して、LogFileMetricExporter CR を適用します。

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

検証

  • 次のコマンドを実行して出力を確認し、LogFileMetricExporter CR を作成した namespace で logfilesmetricexporter Pod が実行されていることを確認します。

    $ oc get pods -l app.kubernetes.io/component=logfilesmetricexporter -n openshift-logging
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                           READY   STATUS    RESTARTS   AGE
    logfilesmetricexporter-9qbjj   1/1     Running   0          2m46s
    logfilesmetricexporter-cbc4v   1/1     Running   0          2m46s
    Copy to Clipboard Toggle word wrap

    logfilesmetricexporter Pod は、各ノードで collector Pod と同時に実行されます。

2.2. ログコレクター CPU およびメモリー制限の設定

ClusterLogForwarder カスタムリソース (CR) を編集することで、ログコレクターの CPU とメモリーの両方の制限を調整できます。

手順

  • openshift-logging プロジェクト内の ClusterLogForwarder CR を編集します。

    $ oc -n openshift-logging edit ClusterLogging instance
    Copy to Clipboard Toggle word wrap
    apiVersion: observability.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <clf_name> 
    1
    
      namespace: openshift-logging
    spec:
      collector:
        resources: 
    2
    
          requests:
            memory: 736Mi
          limits:
            cpu: 100m
            memory: 736Mi
    # ...
    Copy to Clipboard Toggle word wrap
    1
    ClusterLogForwarder CR の名前を指定します。
    2
    必要に応じて CPU、メモリー制限および要求を指定します。表示される値はデフォルト値です。

2.3. 入力レシーバーの設定

Red Hat OpenShift Logging Operator は、クライアントがコレクターに書き込めるように、設定された各入力レシーバー用のサービスをデプロイします。このサービスは、入力レシーバーに指定されたポートを公開します。ログフォワーダー ClusterLogForwarder CR デプロイメントの場合、サービス名は <clusterlogforwarder_resource_name>-<input_name> 形式になります。

2.3.1. 監査ログを HTTP サーバーとして受信するようにコレクターを設定する

ClusterLogForwarder カスタムリソース (CR) でレシーバー入力として http を指定することにより、ログコレクターが HTTP 接続をリッスンして監査ログのみを受信するように設定できます。

重要

HTTP レシーバー入力は、次のシナリオでのみサポートされます。

  • Hosted Control Plane にロギングがインストールされます。
  • ログが、Red Hat OpenShift Logging Operator と同じクラスターにインストールされている Red Hat 対応製品から生成された場合。以下に例を示します。

    • OpenShift Virtualization

前提条件

  • 管理者権限がある。
  • OpenShift CLI (oc) がインストールされている。
  • Red Hat OpenShift Logging Operator がインストールされている。

手順

  1. ClusterLogForwarder CR を変更して、http レシーバー入力の設定を追加します。

    ClusterLogForwarder CR の例

    apiVersion: observability.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <clusterlogforwarder_name> 
    1
    
      namespace: <namespace>
    # ...
    spec:
      serviceAccount:
        name: <service_account_name>
      inputs:
      - name: http-receiver 
    2
    
        type: receiver
        receiver:
          type: http 
    3
    
          port: 8443 
    4
    
          http:
            format: kubeAPIAudit 
    5
    
      outputs:
      - name: <output_name>
        type: http
        http:
          url: <url>
      pipelines: 
    6
    
        - name: http-pipeline
          inputRefs:
            - http-receiver
          outputRefs:
            - <output_name>
    # ...
    Copy to Clipboard Toggle word wrap

    1
    ClusterLogForwarder CR の名前を指定します。
    2
    入力レシーバーの名前を指定します。
    3
    入力レシーバー型を http に指定します。
    4
    オプション: 入力レシーバーがリッスンするポートを指定します。これは、1024 から 65535 までの値とします。指定されていない場合、デフォルト値は 8443 です。
    5
    現在、http 入力レシーバーでは kube-apiserver Webhook 形式のみがサポートされています。
    6
    入力レシーバーのパイプラインを設定します。
  2. 次のコマンドを実行して、ClusterLogForwarder CR に変更を適用します。

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、コレクターが <clusterlogforwarder_resource_name>-<input_name> 形式の名前を持つサービスでリッスンしていることを確認します。

    $ oc get svc
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                      TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)            AGE
    collector                 ClusterIP   172.30.85.239    <none>        24231/TCP          3m6s
    collector-http-receiver   ClusterIP   172.30.205.160   <none>        8443/TCP           3m6s
    Copy to Clipboard Toggle word wrap

    この例では、サービス名は collector-http-receiver です。

検証

  1. 次のコマンドを実行して、認証局 (CA) 証明書ファイルを抽出します。

    $ oc extract cm/openshift-service-ca.crt -n <namespace>
    Copy to Clipboard Toggle word wrap
    注記

    コレクターが実行されているクラスター内の CA が変更された場合は、CA 証明書ファイルを再度抽出する必要があります。

  2. たとえば、次のコマンドを実行して、curl コマンドを使用してログを送信します。

    $ curl --cacert <openshift_service_ca.crt> https://collector-http-receiver.<namespace>.svc:8443 -XPOST -d '{"<prefix>":"<message>"}'
    Copy to Clipboard Toggle word wrap

    <openshift_service_ca.crt> は、抽出した CA 証明書ファイルに置き換えます。

2.3.2. コレクターを syslog サーバーとして接続をリッスンするように設定する

ClusterLogForwarder カスタムリソース (CR) で syslog をレシーバー入力として指定することで、ジャーナル形式のインフラストラクチャーログを収集するようにログコレクターを設定できます。

重要

syslog レシーバー入力は、次のシナリオでのみサポートされます。

  • Hosted Control Plane にロギングがインストールされます。
  • ログが、Red Hat OpenShift Logging Operator と同じクラスターにインストールされている Red Hat 対応製品から生成された場合。以下に例を示します。

    • Red Hat OpenStack Services on OpenShift (RHOSO)
    • OpenShift Virtualization

前提条件

  • 管理者権限がある。
  • OpenShift CLI (oc) がインストールされている。
  • Red Hat OpenShift Logging Operator がインストールされている。

手順

  1. 次のコマンドを実行して、collect-infrastructure-logs クラスターのロールをサービスアカウントに付与します。

    バインドコマンドの例

    $ oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z logcollector
    Copy to Clipboard Toggle word wrap

  2. ClusterLogForwarder CR を変更して、syslog レシーバー入力の設定を追加します。

    ClusterLogForwarder CR の例

    apiVersion: observability.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <clusterlogforwarder_name> 
    1
    
      namespace: <namespace>
    # ...
    spec:
      serviceAccount:
        name: <service_account_name> 
    2
    
      inputs:
        - name: syslog-receiver 
    3
    
          type: receiver
          receiver:
            type: syslog 
    4
    
            port: 10514 
    5
    
      outputs:
      - name: <output_name>
        lokiStack:
          authentication:
            token:
              from: serviceAccount
          target:
            name: logging-loki
            namespace: openshift-logging
        tls: 
    6
    
          ca:
            key: service-ca.crt
            configMapName: openshift-service-ca.crt
        type: lokiStack
    # ...
      pipelines: 
    7
    
        - name: syslog-pipeline
          inputRefs:
            - syslog-receiver
          outputRefs:
            - <output_name>
    # ...
    Copy to Clipboard Toggle word wrap

    1 2
    前のステップで collect-infrastructure-logs 権限を付与したサービスアカウントを使用します。
    3
    入力レシーバーの名前を指定します。
    4
    入力レシーバー型を syslog に指定します。
    5
    オプション: 入力レシーバーがリッスンするポートを指定します。これは、1024 から 65535 までの値とします。
    6
    TLS 設定が設定されていない場合は、デフォルトの証明書が使用されます。詳細を確認するには、コマンド oc explain clusterlogforwarders.spec.inputs.receiver.tls を実行してください。
    7
    入力レシーバーのパイプラインを設定します。
  3. 次のコマンドを実行して、ClusterLogForwarder CR に変更を適用します。

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、コレクターが <clusterlogforwarder_resource_name>-<input_name> 形式の名前を持つサービスでリッスンしていることを確認します。

    $ oc get svc
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)            AGE
    collector                   ClusterIP   172.30.85.239    <none>        24231/TCP          33m
    collector-syslog-receiver   ClusterIP   172.30.216.142   <none>        10514/TCP          2m20s
    Copy to Clipboard Toggle word wrap

    この出力例では、サービス名は collector-syslog-receiver です。

検証

  1. 次のコマンドを実行して、認証局 (CA) 証明書ファイルを抽出します。

    $ oc extract cm/openshift-service-ca.crt -n <namespace>
    Copy to Clipboard Toggle word wrap
    注記

    コレクターが実行されているクラスター内の CA が変更された場合は、CA 証明書ファイルを再度抽出する必要があります。

  2. たとえば、次のコマンドを実行して、curl コマンドを使用してログを送信します。

    $ curl --cacert <openshift_service_ca.crt> collector-syslog-receiver.<namespace>.svc:10514  “test message”
    Copy to Clipboard Toggle word wrap

    <openshift_service_ca.crt> は、抽出した CA 証明書ファイルに置き換えます。

第3章 ログストアの設定

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

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

重要

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

3.1. Loki デプロイメントのサイズ

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

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

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

重要

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

Expand
表3.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

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

60 Gi

910 Gi

750 Gi

750 Gi

910 Gi

3.2. Loki オブジェクトストレージ

Loki Operator は、AWS S3 だけでなく、MinioOpenShift Data Foundation などの他の S3 互換オブジェクトストアもサポートしています。AzureGCS、および Swift もサポートされています。

Loki ストレージの推奨命名法は、logging-loki-<your_storage_provider> です。

次の表は、各ストレージプロバイダーの LokiStack カスタムリソース (CR) 内の type 値を示しています。詳細は、ストレージプロバイダーに関するセクションを参照してください。

Expand
表3.2 シークレットタイプのクイックリファレンス
ストレージプロバイダーシークレットの type

AWS

s3

Azure

azure

Google Cloud

gcs

Minio

s3

OpenShift Data Foundation

s3

Swift

swift

3.2.1. AWS ストレージ

前提条件

手順

  • 次のコマンドを実行して、logging-loki-aws という名前のオブジェクトストレージシークレットを作成します。

    $ oc create secret generic logging-loki-aws \
      --from-literal=bucketnames="<bucket_name>" \
      --from-literal=endpoint="<aws_bucket_endpoint>" \
      --from-literal=access_key_id="<aws_access_key_id>" \
      --from-literal=access_key_secret="<aws_access_key_secret>" \
      --from-literal=region="<aws_region_of_your_bucket>"
    Copy to Clipboard Toggle word wrap
3.2.1.1. STS 対応クラスターの AWS ストレージ

クラスターで STS が有効になっている場合、Cloud Credential Operator (CCO) によって AWS トークンを使用した短期認証がサポートされます。

次のコマンドを実行すると、Loki オブジェクトストレージシークレットを手動で作成できます。

$ oc -n openshift-logging create secret generic "logging-loki-aws" \
  --from-literal=bucketnames="<s3_bucket_name>" \
  --from-literal=region="<bucket_region>" \
  --from-literal=audience="<oidc_audience>" 
1
Copy to Clipboard Toggle word wrap
1
任意のアノテーション。デフォルト値は openshift です。

3.2.2. Azure ストレージ

前提条件

  • Loki Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。
  • Azure 上に バケット を作成している。

手順

  • 次のコマンドを実行して、logging-loki-azure という名前のオブジェクトストレージシークレットを作成します。

    $ oc create secret generic logging-loki-azure \
      --from-literal=container="<azure_container_name>" \
      --from-literal=environment="<azure_environment>" \ 
    1
    
      --from-literal=account_name="<azure_account_name>" \
      --from-literal=account_key="<azure_account_key>"
    Copy to Clipboard Toggle word wrap
    1
    サポートされている環境値は、AzureGlobalAzureChinaCloudAzureGermanCloudAzureUSGovernment です。
3.2.2.1. Microsoft Entra Workload ID 対応クラスター用の Azure ストレージ

クラスターで Microsoft Entra Workload ID が有効になっている場合、Cloud Credential Operator (CCO) は Workload ID を使用した短期認証をサポートします。

次のコマンドを実行すると、Loki オブジェクトストレージシークレットを手動で作成できます。

$ oc -n openshift-logging create secret generic logging-loki-azure \
--from-literal=environment="<azure_environment>" \
--from-literal=account_name="<storage_account_name>" \
--from-literal=container="<container_name>"
Copy to Clipboard Toggle word wrap

3.2.3. Google Cloud Platform ストレージ

前提条件

  • Loki Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。
  • Google Cloud Platform (GCP) 上に プロジェクト を作成している。
  • 同じプロジェクト内に バケット を作成している。
  • 同じプロジェクト内に GCP 認証用の サービスアカウント を作成している。

手順

  1. GCP から受け取ったサービスアカウントの認証情報を key.json という名前のファイルにコピーします。
  2. 次のコマンドを実行して、logging-loki-gcs という名前のオブジェクトストレージシークレットを作成します。

    $ oc create secret generic logging-loki-gcs \
      --from-literal=bucketname="<bucket_name>" \
      --from-file=key.json="<path/to/key.json>"
    Copy to Clipboard Toggle word wrap

3.2.4. Minio ストレージ

前提条件

  • Loki Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。
  • Minio がクラスターにデプロイされている。
  • Minio 上に バケット を作成している。

手順

  • 次のコマンドを実行して、logging-loki-minio という名前のオブジェクトストレージシークレットを作成します。

    $ oc create secret generic logging-loki-minio \
      --from-literal=bucketnames="<bucket_name>" \
      --from-literal=endpoint="<minio_bucket_endpoint>" \
      --from-literal=access_key_id="<minio_access_key_id>" \
      --from-literal=access_key_secret="<minio_access_key_secret>"
    Copy to Clipboard Toggle word wrap

3.2.5. OpenShift Data Foundation ストレージ

前提条件

手順

  1. openshift-logging namespace に ObjectBucketClaim カスタムリソースを作成します。

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: loki-bucket-odf
      namespace: openshift-logging
    spec:
      generateBucketName: loki-bucket-odf
      storageClassName: openshift-storage.noobaa.io
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、関連付けられた ConfigMap オブジェクトからバケットのプロパティーを取得します。

    BUCKET_HOST=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_HOST}')
    BUCKET_NAME=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_NAME}')
    BUCKET_PORT=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_PORT}')
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、関連付けられたシークレットからバケットアクセスキーを取得します。

    ACCESS_KEY_ID=$(oc get -n openshift-logging secret loki-bucket-odf -o jsonpath='{.data.AWS_ACCESS_KEY_ID}' | base64 -d)
    SECRET_ACCESS_KEY=$(oc get -n openshift-logging secret loki-bucket-odf -o jsonpath='{.data.AWS_SECRET_ACCESS_KEY}' | base64 -d)
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、logging-loki-odf という名前のオブジェクトストレージシークレットを作成します。

    $ oc create -n openshift-logging secret generic logging-loki-odf \
    --from-literal=access_key_id="<access_key_id>" \
    --from-literal=access_key_secret="<secret_access_key>" \
    --from-literal=bucketnames="<bucket_name>" \
    --from-literal=endpoint="https://<bucket_host>:<bucket_port>"
    Copy to Clipboard Toggle word wrap

3.2.6. Swift ストレージ:

前提条件

  • Loki Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。
  • Swift 上で バケット を作成している。

手順

  • 次のコマンドを実行して、logging-loki-swift という名前のオブジェクトストレージシークレットを作成します。

    $ oc create secret generic logging-loki-swift \
      --from-literal=auth_url="<swift_auth_url>" \
      --from-literal=username="<swift_usernameclaim>" \
      --from-literal=user_domain_name="<swift_user_domain_name>" \
      --from-literal=user_domain_id="<swift_user_domain_id>" \
      --from-literal=user_id="<swift_user_id>" \
      --from-literal=password="<swift_password>" \
      --from-literal=domain_id="<swift_domain_id>" \
      --from-literal=domain_name="<swift_domain_name>" \
      --from-literal=container_name="<swift_container_name>"
    Copy to Clipboard Toggle word wrap
  • 必要に応じて、次のコマンドを実行して、プロジェクト固有のデータ、リージョン、またはその両方を指定できます。

    $ oc create secret generic logging-loki-swift \
      --from-literal=auth_url="<swift_auth_url>" \
      --from-literal=username="<swift_usernameclaim>" \
      --from-literal=user_domain_name="<swift_user_domain_name>" \
      --from-literal=user_domain_id="<swift_user_domain_id>" \
      --from-literal=user_id="<swift_user_id>" \
      --from-literal=password="<swift_password>" \
      --from-literal=domain_id="<swift_domain_id>" \
      --from-literal=domain_name="<swift_domain_name>" \
      --from-literal=container_name="<swift_container_name>" \
      --from-literal=project_id="<swift_project_id>" \
      --from-literal=project_name="<swift_project_name>" \
      --from-literal=project_domain_id="<swift_project_domain_id>" \
      --from-literal=project_domain_name="<swift_project_domain_name>" \
      --from-literal=region="<swift_region>"
    Copy to Clipboard Toggle word wrap

3.2.7. 短期認証情報を使用するクラスターに Loki ログストアのデプロイ

一部のストレージプロバイダーでは、インストール時に Cloud Credential Operator ユーティリティー (ccoctl) を使用して、短期認証情報を実装できます。これらの認証情報は、OpenShift Container Platform クラスターの外部で作成および管理されます。詳細は、コンポーネントの短期認証情報を使用した手動モード を参照してください。

注記

この認証情報ストラテジーを使用するクラスターでは、Loki Operator の新規インストール中に短期認証情報の認証を設定する必要があります。この機能を使用するために、既存のクラスターが別のクレデンシャルストラテジーを使用するように設定することはできません。

3.2.7.1. クラウドベースのログストアにアクセスするために Workload Identity Federation で認証する

有効期間の短いトークンを使用した Workload Identity Federation を使用して、クラウドベースのログストアに対して認証を行うことができます。Workload Identity Federation を使用すると、長期間有効な認証情報をクラスターに保存する必要がなくなり、認証情報の漏洩のリスクが軽減され、シークレットの管理が簡素化されます。

前提条件

  • 管理者権限がある。

手順

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

    • OpenShift Container Platform Web コンソールを使用して Loki Operator をインストールした場合、システムは有効期間の短いトークンを使用するクラスターを自動的に検出します。プロンプトが表示され、ロールを作成するように求められます。また、Loki Operator が CredentialsRequest オブジェクトを作成するのに必要なデータを提供するように求められます。このオブジェクトにより、シークレットが設定されます。
    • OpenShift CLI (oc) を使用して Loki Operator をインストールした場合は、Subscription オブジェクトを手動で作成する必要があります。次のサンプルに示すように、ストレージプロバイダーに適したテンプレートを使用します。この認証ストラテジーは、サンプル内に示されているストレージプロバイダーのみをサポートします。

      Microsoft Azure サンプルサブスクリプション

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: loki-operator
        namespace: openshift-operators-redhat
      spec:
        channel: "stable-6.1"
        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

      Amazon Web Services (AWS) サンプルサブスクリプション

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

3.2.7.2. Web コンソールを使用して LokiStack カスタムリソースを作成する

OpenShift Container Platform Web コンソールを使用して、LokiStack カスタムリソース (CR) を作成できます。

前提条件

  • 管理者権限がある。
  • OpenShift Container Platform Web コンソールにアクセスできる。
  • Loki Operator がインストールされている。

手順

  1. OperatorsInstalled Operators ページに移動します。All instances タブをクリックします。
  2. Create new ドロップダウンリストから、LokiStack を選択します。
  3. YAML view を選択し、次のテンプレートを使用して LokiStack CR を作成します。

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: logging-loki 
    1
    
      namespace: openshift-logging
    spec:
      size: 1x.small 
    2
    
      storage:
        schemas:
          - effectiveDate: '2023-10-15'
            version: v13
        secret:
          name: logging-loki-s3 
    3
    
          type: s3 
    4
    
          credentialMode: 
    5
    
      storageClassName: <storage_class_name> 
    6
    
      tenants:
        mode: openshift-logging
    Copy to Clipboard Toggle word wrap
    1
    logging-loki という名前を使用します。
    2
    デプロイメントサイズを指定します。ロギング 5.8 以降のバージョンでは、Loki の実稼働インスタンスでサポートされているサイズオプションは 1x.extra-small1x.small、または 1x.medium です。
    3
    ログストレージに使用するシークレットを指定します。
    4
    対応するストレージタイプを指定します。
    5
    任意のフィールド、Logging 5.9 以降。サポートされているユーザー設定値は、次のとおりです。static は、シークレットに保存された認証情報を使用する、サポートされているすべてのオブジェクトストレージタイプで使用できるデフォルトの認証モードです。token は、認証情報ソースから取得される有効期間が短いトークンです。このモードでは、オブジェクトストレージに必要な認証情報が静的設定に格納されません。代わりに、実行時にサービスを使用して認証情報が生成されるため、有効期間が短い認証情報の使用と、よりきめ細かい制御が可能になります。この認証モードは、すべてのオブジェクトストレージタイプでサポートされているわけではありません。Loki がマネージド STS モードで実行されていて、STS/WIF クラスターで CCO を使用している場合、token-cco がデフォルト値です。
    6
    一時ストレージのストレージクラスの名前を入力します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。クラスターで使用可能なストレージクラスは、oc get storageclasses コマンドを使用してリスト表示できます。
3.2.7.3. CLI を使用して Loki オブジェクトストレージのシークレットを作成する

Loki オブジェクトストレージを設定するには、シークレットを作成する必要があります。これは、OpenShift CLI (oc) を使用して実行できます。

前提条件

  • 管理者権限がある。
  • Loki Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。

手順

  • 次のコマンドを使用して、証明書とキーファイルが含まれるディレクトリーにシークレットを作成できます。

    $ oc create secret generic -n openshift-logging <your_secret_name> \
     --from-file=tls.key=<your_key_file>
     --from-file=tls.crt=<your_crt_file>
     --from-file=ca-bundle.crt=<your_bundle_file>
     --from-literal=username=<your_username>
     --from-literal=password=<your_password>
    Copy to Clipboard Toggle word wrap
注記

最良の結果を得るには、generic または opaque シークレットを使用してください。

検証

  • 次のコマンドを実行して、シークレットが作成されたことを確認します。

    $ oc get secrets
    Copy to Clipboard Toggle word wrap

3.2.8. Loki ログへのアクセスの詳細設定

Red Hat OpenShift Logging Operator は、デフォルトではすべてのユーザーにログへのアクセスを付与しません。Operator のアップグレード後に以前の設定を適用していない限り、管理者はユーザーのアクセスを設定する必要があります。設定とニーズに応じて、以下を使用してログへのアクセスを細かく設定できます。

  • クラスター全体のポリシー
  • スコープ指定が namespace のポリシー
  • カスタム管理者グループの作成

管理者は、デプロイメントに適したロールバインディングとクラスターのロールバインディングを作成する必要があります。Red Hat OpenShift Logging Operator には、次のクラスターロールがあります。

  • cluster-logging-application-view は、アプリケーションログの読み取り権限を付与します。
  • cluster-logging-infrastructure-view は、インフラストラクチャーログの読み取り権限を付与します。
  • cluster-logging-audit-view は、監査ログの読み取り権限を付与します。

以前のバージョンからアップグレードした場合、追加のクラスターロール logging-application-logs-reader と関連するクラスターロールバインディング logging-all-authenticated-application-logs-reader により下位互換性が提供され、認証されたユーザーに namespace の読み取り権限が許可されます。

注記

namespace 単位でのアクセス権を持つユーザーは、アプリケーションログを照会する際に namespace を指定する必要があります。

3.2.8.1. クラスター全体のアクセス

クラスターロールバインディングリソースはクラスターロールを参照し、クラスター全体に権限を設定します。

ClusterRoleBinding の例

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: logging-all-application-logs-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-logging-application-view 
1

subjects: 
2

- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
Copy to Clipboard Toggle word wrap

1
cluster-logging-infrastructure-view および cluster-logging-audit-view は、追加の ClusterRoles です。
2
このオブジェクトが適用されるユーザーまたはグループを指定します。
3.2.8.2. namespace アクセス

RoleBinding リソースを ClusterRole オブジェクトと使用して、ユーザーまたはグループがログにアクセスできる namespace を定義できます。

RoleBinding の例

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: allow-read-logs
  namespace: log-test-0 
1

roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-logging-application-view
subjects:
- kind: User
  apiGroup: rbac.authorization.k8s.io
  name: testuser-0
Copy to Clipboard Toggle word wrap

1
この RoleBinding が適用される namespace を指定します。
3.2.8.3. カスタム管理者グループのアクセス権

多数のユーザーが広範な権限を必要とする大規模デプロイメントの場合は、adminGroup フィールドを使用してカスタムグループを作成できます。LokiStack CR の adminGroups フィールドで指定されたグループのメンバーであるユーザーは、管理者とみなされます。

cluster-logging-application-view ロールも割り当てられている管理者ユーザーは、すべての namespace のすべてのアプリケーションログにアクセスできます。

LokiStack CR の例

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

    openshift:
      adminGroups: 
2

      - cluster-admin
      - custom-admin-group 
3
Copy to Clipboard Toggle word wrap

1
カスタム管理者グループは、このモードでのみ使用できます。
2
このフィールドに空のリスト値 [] を入力すると、管理者グループが無効になります。
3
デフォルトのグループ (system:cluster-adminscluster-admindedicated-admin) をオーバーライドします。

3.2.9. cluster-admin ユーザーロールの新規グループの作成

重要

cluster-admin ユーザーとして複数の namespace のアプリケーションログを照会すると、クラスター内の全 namespace の合計文字数が 5120 を超え、Parse error: input size too long (XXXX > 5120) エラーが発生します。LokiStack のログへのアクセスをより適切に制御するには、cluster-admin ユーザーを cluster-admin グループのメンバーにします。cluster-admin グループが存在しない場合は、作成して必要なユーザーを追加します。

次の手順を使用して、cluster-admin 権限のあるユーザー用に、新しいグループを作成します。

手順

  1. 以下のコマンドを入力して新規グループを作成します。

    $ oc adm groups new cluster-admin
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを実行して、必要なユーザーを cluster-admin グループに追加します。

    $ oc adm groups add-users cluster-admin <username>
    Copy to Clipboard Toggle word wrap
  3. 以下のコマンドを実行して cluster-admin ユーザーロールをグループに追加します。

    $ oc adm policy add-cluster-role-to-group cluster-admin cluster-admin
    Copy to Clipboard Toggle word wrap

3.3. Loki の信頼性とパフォーマンスの向上

実稼働環境で Loki の信頼性と効率性を確保するには、次の設定を使用します。

3.3.1. 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
    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

3.3.2. ノードの障害を許容するための Loki の設定

Logging 5.8 以降のバージョンでは、Loki Operator は Pod アンチアフィニティールールの設定をサポートしています。このルールは、同じコンポーネントの Pod をクラスター内の別々の利用可能なノードにスケジュールすることを要求するためのものです。

アフィニティーは、Pod がスケジュールされるノードを制御する Pod のプロパティーです。アンチアフィニティーは、ノード上で Pod がスケジュールされるのを防ぐ Pod のプロパティーです。

OpenShift Container Platform では、Pod アフィニティーPod アンチアフィニティー を使用して、他の Pod のキー/値ラベルに基づいて、Pod のスケジュール対象とするノードを制限できます。

Operator は、すべての Loki コンポーネント (compactordistributorgatewayindexGatewayingesterquerierqueryFrontend、および 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
ルールを適用するために一致している必要のあるキー/値のペア (ラベル) です。

3.3.3. 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
      テナントごとの保持ポリシーを設定します。有効なテナントタイプは、applicationaudit、および infrastructure です。
      2
      ログストリームの定義に使用される LogQL クエリー が含まれています。
  2. LokiStack CR を適用します。

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

    これは、保存されたログの保持を管理するためのものではありません。保存されたログのグローバルな保持期間 (最大 30 日間までサポート) は、オブジェクトストレージで設定します。

3.3.4. メンバーリストの作成の失敗を許容する 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

3.3.5. クラスターの再起動中の LokiStack 動作

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

3.4. Loki の高度なデプロイメントとスケーラビリティー

Loki の高可用性、スケーラビリティー、およびエラー処理を設定できます。

3.4.1. ゾーン対応のデータレプリケーション

Loki Operator は、Pod トポロジーの分散制約を通じて、ゾーン対応のデータレプリケーションのサポートを提供します。この機能を有効にすると、信頼性が向上し、1 つのゾーンで障害が発生した場合のログ損失に対する保護が強化されます。デプロイメントサイズを 1x.extra-small1x.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
ノードラベルに対応するトポロジーキーの形式でゾーンを定義します。

3.4.2. 障害が発生したゾーンからの 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

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

3.4.2.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

3.4.3. 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

    このエラーは受信側にも表示されます。たとえば、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 単位) に対するソフト制限です。ログのレートが制限を超えているにもかかわらず、コレクターがログの送信を再試行すると、レート制限エラーが発生します。合計平均が制限よりも少ない場合に限り、システムは回復し、ユーザーの介入なしでエラーが解決されます。

3.5. Loki のログベースのアラート

AlertingRule カスタムリソース (CR) を作成することで、Loki のログベースのアラートを設定できます。

3.5.1. 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 リソースを読み取ることができます。既存のアラートルールの設定、ラベル、およびアノテーションを検査できますが、それらを変更することはできません。

3.5.1.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

3.5.2. Loki を使用したログベースのアラートルールの作成

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

  • AlertingRule CR に無効な interval 期間が含まれる場合、無効なアラートルールです。
  • AlertingRule CR に無効な for 期間が含まれる場合、無効なアラートルールです。
  • AlertingRule CR に無効な LogQL expr が含まれる場合、無効なアラートルールです。
  • AlertingRule CR に同じ名前のグループが 2 つ含まれる場合、無効なアラートルールです。
  • 上記のいずれも該当しない場合、アラートルールは有効とみなされます。
Expand
表3.3 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
    この必須フィールドの値は、criticalwarning、または 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
    この必須フィールドの値は、criticalwarning、または info である必要があります。
    5
    この必須フィールドの値は、ルールの概要です。
    6
    この必須フィールドの値は、ルールの詳細な説明です。
  2. AlertingRule CR を適用します。

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

第4章 Loki での OTLP データ取り込み

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

  • リソース
  • スコープ
  • ログ

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

4.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 は構造化メタデータを保存できるようになります。

4.2. 属性マッピング

Loki Operator を openshift-logging モードに設定すると、Loki Operator がデフォルトの属性マッピングのセットを自動的に適用します。このマッピングは、特定の OTLP 属性を、Loki のストリームラベルおよび構造化メタデータに対応付けるものです。

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

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

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

4.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 設定を通じて管理されます。次の LokiStack 設定の例を参照してください。

# ...
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 を設定して正規表現を使用します。

重要

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

4.2.2. OpenShift のデフォルトのカスタマイズ

openshift-logging モードでは、特定の属性が必須であり、OpenShift 機能でのロールのため、設定から削除できません。推奨 のラベルが付いているその他の属性は、パフォーマンスに影響がある場合は無効化されている可能性があります。

カスタム属性なしで openshift-logging モードを使用すると、即座に OpenShift ツールとの互換性が確保されます。ストリームラベルまたは構造化メタデータとして追加の属性が必要な場合は、カスタム設定を使用します。カスタム設定はデフォルト設定とマージできます。

第5章 OpenTelemetry データモデル

このドキュメントでは、Red Hat OpenShift Logging における OpenTelemetry サポートのプロトコルとセマンティック規約を概説します。

重要

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

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

5.1. 転送および取り込みプロトコル

Red Hat OpenShift Logging は、OTLP 仕様 を使用してログを収集し、OpenTelemetry エンドポイントに転送します。OTLP はテレメトリーデータをエンコード、転送、配信します。ログストリームを取り込むための OTLP エンドポイントを提供する Loki ストレージをデプロイすることもできます。このドキュメントでは、さまざまな OpenShift クラスターソースから収集されたログのセマンティック規約を定義します。

5.2. セマンティック規約

このソリューションのログコレクターは、次のログストリームを収集します。

  • コンテナーログ
  • クラスターノードジャーナルログ
  • クラスターノード監査ログ
  • Kubernetes および OpenShift API サーバーログ
  • OpenShift Virtual Network (OVN) ログ

これらのストリームは、OpenTelemetry セマンティック属性によって定義されたセマンティック規約に従って転送できます。OpenTelemetry のセマンティック規約では、リソースを属性によって識別される、テレメトリーを生成するエンティティーのイミュータブルな表現と定義しています。たとえばコンテナー内で実行されているプロセスには、container_namecluster_idpod_namenamespace などの属性が含まれ、場合によっては deployment または app_name も含まれます。これらの属性はリソースオブジェクトの下にグループ化されており、繰り返しを減らし、テレメトリーデータとしてのログ送信を最適化するのに役立ちます。

ログには、リソース属性に加え、計装ライブラリーに固有のスコープ属性と、各ログエントリーに固有のログ属性も含まれる場合があります。これらの属性は、各ログエントリーに関するより詳細な情報を提供し、ストレージ内のログを照会する際のフィルタリング機能を強化します。

次のセクションでは、一般的に転送される属性を定義しています。

5.2.1. ログエントリー構造

すべてのログストリームには、次の ログデータ フィールドが含まれます。

適用可能ソース 列は、各フィールドに適用するログソースを示しています。

  • all: このフィールドは、すべてのログに存在します。
  • container: このフィールドは、アプリケーションとインフラストラクチャーの両方の Kubernetes コンテナーログに存在します。
  • audit: このフィールドは、Kubernetes ログ、OpenShift API ログ、OVN ログに存在します。
  • auditd: このフィールドは、ノード監査ログに存在します。
  • journal: このフィールドは、ノードジャーナルログに存在します。
Expand
名前適用可能ソースコメント

body

all

 

observedTimeUnixNano

all

 

timeUnixNano

all

 

severityText

container、journal

 

attributes

all

(オプション) ストリーム固有の属性を転送する場合に存在します

5.2.2. 属性

次の表に示すとおり、ログエントリーにはソースに基づくリソース属性、スコープ属性、ログ属性のセットが含まれます。

ロケーション 列は属性のタイプを示しています。

  • resource: リソース属性を示します
  • scope: スコープ属性を示します
  • log: ログ属性を示します

ストレージ 列は、属性がデフォルトの openshift-logging モードを使用して LokiStack に保存されているか、および保存場所を示しています。

  • stream label:

    • 特定のラベルに基づく効率的なフィルタリングとクエリーを可能にします。
    • Loki Operator が設定でこの属性を強制する場合は、required としてラベル付けできます。
  • structured metadata:

    • キーと値のペアの詳細なフィルタリングと保存を可能にします。
    • JSON 解析を使用することなく、合理化されたクエリーに直接ラベルを使用できるようになります。

OTLP を使用すると、ユーザーは JSON 解析を使用するのではなく、ラベルで直接クエリーをフィルタリングできるため、クエリーの速度と効率が向上します。

Expand
名前Location適用可能ソースストレージ (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.namek8s_namespace_name になります。

法律上の通知

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat 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 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