11.4. ログ転送の設定


ロギングデプロイメントでは、デフォルトでコンテナーおよびインフラストラクチャーのログは ClusterLogging カスタムリソース (CR) に定義された内部ログストアに転送されます。

セキュアなストレージを提供しないため、監査ログはデフォルトで内部ログストアに転送されません。お客様の責任において、監査ログを転送するシステムが組織および政府の規制に準拠し、適切に保護されていることを確認してください。

このデフォルト設定が要件を満たす場合、ClusterLogForwarder CR を設定する必要はありません。ClusterLogForwarder CR が存在する場合、default 出力を含むパイプラインが定義されている場合を除き、ログは内部ログストアに転送されません。

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

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

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 インスタンスに転送し、インフラストラクチャーログをセキュアでない外部 Elasticsearch インスタンスに、アプリケーションログを Kafka ブローカーに転送し、アプリケーションログを my-apps-logs プロジェクトから内部 Elasticsearch インスタンスに転送します。

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

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name> 1
  namespace: <log_forwarder_namespace> 2
spec:
  serviceAccountName: <service_account_name> 3
  outputs:
   - name: elasticsearch-secure 4
     type: "elasticsearch"
     url: https://elasticsearch.secure.com:9200
     secret:
        name: elasticsearch
   - name: elasticsearch-insecure 5
     type: "elasticsearch"
     url: http://elasticsearch.insecure.com:9200
   - name: kafka-app 6
     type: "kafka"
     url: tls://kafka.secure.com:9093/app-topic
  inputs: 7
   - name: my-app-logs
     application:
        namespaces:
        - my-project
  pipelines:
   - name: audit-logs 8
     inputRefs:
      - audit
     outputRefs:
      - elasticsearch-secure
      - default
     labels:
       secure: "true" 9
       datacenter: "east"
   - name: infrastructure-logs 10
     inputRefs:
      - infrastructure
     outputRefs:
      - elasticsearch-insecure
     labels:
       datacenter: "west"
   - name: my-app 11
     inputRefs:
      - my-app-logs
     outputRefs:
      - default
   - inputRefs: 12
      - application
     outputRefs:
      - kafka-app
     labels:
       datacenter: "south"

1
レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。
2
レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。
3
サービスアカウントの名前。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。
4
シークレットとセキュアな URL を使用したセキュアな Elasticsearch 出力の設定。
  • 出力を記述する名前。
  • 出力のタイプ: elasticsearch
  • 接頭辞を含む、有効な絶対 URL としての Elasticsearch インスタンスのセキュアな URL およびポート。
  • TLS 通信のエンドポイントで必要なシークレット。シークレットは openshift-logging プロジェクトに存在する必要があります。
5
非セキュアな Elasticsearch 出力の設定:
  • 出力を記述する名前。
  • 出力のタイプ: elasticsearch
  • 接頭辞を含む、有効な絶対 URL として Elasticsearch インスタンスのセキュアではない URL およびポート。
6
セキュアな URL を介したクライアント認証 TLS 通信を使用した Kafka 出力の設定:
  • 出力を記述する名前。
  • 出力のタイプ: kafka
  • Kafka ブローカーの URL およびポートを、接頭辞を含む有効な絶対 URL として指定します。
7
my-project namespace からアプリケーションログをフィルターするための入力の設定。
8
監査ログをセキュアな外部 Elasticsearch インスタンスに送信するためのパイプラインの設定。
  • パイプラインを説明する名前。
  • inputRefs はログタイプです (例: audit)。
  • outputRefs は使用する出力の名前です。この例では、elasticsearch-secure はセキュアな Elasticsearch インスタンスに転送され、default は内部 Elasticsearch インスタンスに転送されます。
  • オプション: ログに追加する複数のラベル。
9
オプション: 文字列。ログに追加する 1 つまたは複数のラベル。"true" などの引用値は、ブール値としてではなく、文字列値として認識されるようにします。
10
インフラストラクチャーログをセキュアでない外部 Elasticsearch インスタンスに送信するためのパイプラインの設定。
11
my-project プロジェクトから内部 Elasticsearch インスタンスにログを送信するためのパイプラインの設定。
  • パイプラインを説明する名前。
  • inputRefs は特定の入力 my-app-logs です。
  • outputRefsdefault です。
  • オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
12
パイプライン名がない場合にログを Kafka ブローカーに送信するためのパイプラインの設定。
  • inputRefs はログタイプです (例: application)。
  • outputRefs は使用する出力の名前です。
  • オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
外部ログアグリゲーターが利用できない場合の Fluentd のログの処理

外部ロギングアグリゲーターが利用できず、ログを受信できない場合、Fluentd は継続してログを収集し、それらをバッファーに保存します。ログアグリゲーターが利用可能になると、バッファーされたログを含む、ログの転送が再開されます。バッファーが完全に一杯になると、Fluentd はログの収集を停止します。OpenShift Container Platform はログをローテーションし、それらを削除します。バッファーサイズを調整したり、永続ボリューム要求 (PVC) を Fluentd デーモンセットまたは Pod に追加したりすることはできません。

サポート対象の認証キー

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

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

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

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

11.4.1.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>
注記

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

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

ログフォワーダーを作成するには、サービスアカウントが収集できるログ入力の種類を指定する ClusterLogForwarder CR を作成する必要があります。ログを転送できる出力を指定することもできます。マルチログフォワーダー機能を使用している場合は、ClusterLogForwarder CR でサービスアカウントも参照する必要があります。

クラスターでマルチログフォワーダー機能を使用している場合は、任意の名前を使用して、任意の namespace に ClusterLogForwarder カスタムリソース (CR) を作成できます。レガシー実装を使用している場合は、ClusterLogForwarder CR の名前を instance にし、openshift-logging namespace に作成する必要があります。

重要

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

ClusterLogForwarder リソースの例

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name> 1
  namespace: <log_forwarder_namespace> 2
spec:
  serviceAccountName: <service_account_name> 3
  pipelines:
   - inputRefs:
     - <log_type> 4
     outputRefs:
     - <output_name> 5
  outputs:
  - name: <output_name> 6
    type: <output_type> 7
    url: <log_output_url> 8
# ...

1
レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。
2
レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。
3
サービスアカウントの名前。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。
4
収集されるログのタイプ。このフィールドの値は、監査ログの場合は audit、アプリケーションログの場合は application、インフラストラクチャーログの場合は infrastructure、またはアプリケーションに定義された指定の入力になります。
5 7
ログの転送先の出力のタイプ。このフィールドの値は、defaultlokikafkaelasticsearchfluentdForwardsyslog、または cloudwatch です。
注記

default の出力タイプは、複数のログフォワーダーの実装ではサポートされていません。

6
ログの転送先の出力の名前。
8
ログの転送先の出力の URL。

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

Logging 5.9 以降のバージョンでは、ClusterLogForwarder カスタムリソース (CR) の tuning 仕様により、ログのスループットまたは耐久性のいずれかを優先するようにデプロイメントを設定する手段が提供されます。

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

重要

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

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

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

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  tuning:
    delivery: AtLeastOnce 1
    compression: none 2
    maxWrite: <integer> 3
    minRetryDuration: 1s 4
    maxRetryDuration: 1s 5
# ...

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

    

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

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

警告

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

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

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)

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

ClusterLogForwarder CR の例

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  pipelines:
    - name: my-app-logs
      inputRefs:
        - application
      outputRefs:
        - default
      detectMultilineErrors: true

11.4.4.1. 詳細

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

表11.10 各コレクターでサポートされている言語
言語FluentdVector

Java

JS

Ruby

Python

golang

PHP

Dart

11.4.4.2. トラブルシューティング

有効にすると、コレクター設定には detect_exceptions タイプの新しいセクションが含まれます。

vector 設定セクションの例

[transforms.detect_exceptions_app-logs]
 type = "detect_exceptions"
 inputs = ["application"]
 languages = ["All"]
 group_by = ["kubernetes.namespace_name","kubernetes.pod_name","kubernetes.container_name"]
 expire_after_ms = 2000
 multiline_flush_interval_ms = 1000

fluentd 設定セクションの例

<label @MULTILINE_APP_LOGS>
  <match kubernetes.**>
    @type detect_exceptions
    remove_tag_prefix 'kubernetes'
    message message
    force_line_breaks true
    multiline_flush_interval .2
  </match>
</label>

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

内部のデフォルトの OpenShift Container Platform ログストアに加えて、またはその代わりに、ログを Google Cloud Logging に転送できます。

注記

この機能を Fluentd で使用することはサポートされていません。

前提条件

  • Red Hat OpenShift Logging Operator 5.5.1 以降

手順

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

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

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name> 1
      namespace: <log_forwarder_namespace> 2
    spec:
      serviceAccountName: <service_account_name> 3
      outputs:
        - name: gcp-1
          type: googleCloudLogging
          secret:
            name: gcp-secret
          googleCloudLogging:
            projectId : "openshift-gce-devel" 4
            logId : "app-gcp" 5
      pipelines:
        - name: test-app
          inputRefs: 6
            - application
          outputRefs:
            - gcp-1
    1
    レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。
    2
    レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。
    3
    サービスアカウントの名前。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。
    4
    ログを保存する GCP リソース階層 の場所に応じて、projectIdfolderIdorganizationId、または billingAccountId フィールドとそれに対応する値を設定します。
    5
    Log EntrylogName フィールドに追加する値を設定します。
    6
    パイプラインを使用して転送するログタイプ (applicationinfrastructure、または audit) を指定します。

11.4.6. ログの Splunk への転送

内部のデフォルトの OpenShift Container Platform ログストアに加えて、またはその代わりに、Splunk HTTP Event Collector (HEC) にログを転送できます。

注記

この機能を Fluentd で使用することはサポートされていません。

前提条件

  • Red Hat OpenShift Logging Operator 5.6 以降
  • コレクターとして vector が指定された ClusterLogging インスタンス
  • Base64 でエンコードされた Splunk HEC トークン

手順

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

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

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name> 1
      namespace: <log_forwarder_namespace> 2
    spec:
      serviceAccountName: <service_account_name> 3
      outputs:
        - name: splunk-receiver 4
          secret:
            name: vector-splunk-secret 5
          type: splunk 6
          url: <http://your.splunk.hec.url:8088> 7
      pipelines: 8
        - inputRefs:
            - application
            - infrastructure
          name: 9
          outputRefs:
            - splunk-receiver 10
    1
    レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。
    2
    レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。
    3
    サービスアカウントの名前。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。
    4
    出力の名前を指定します。
    5
    HEC トークンが含まれるシークレットの名前を指定します。
    6
    出力タイプを splunk として指定します。
    7
    Splunk HEC の URL (ポートを含む) を指定します。
    8
    パイプラインを使用して転送するログタイプ (applicationinfrastructure、または audit) を指定します。
    9
    オプション: パイプラインの名前を指定します。
    10
    このパイプラインでログを転送する時に使用する出力の名前を指定します。

11.4.7. HTTP 経由でのログ転送

HTTP 経由でのログ転送は、Fluentd と Vector ログコレクターの両方でサポートされています。有効にするには、ClusterLogForwarder カスタムリソース (CR) の出力タイプを http に指定します。

手順

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

    ClusterLogForwarder CR の例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name> 1
      namespace: <log_forwarder_namespace> 2
    spec:
      serviceAccountName: <service_account_name> 3
      outputs:
        - name: httpout-app
          type: http
          url: 4
          http:
            headers: 5
              h1: v1
              h2: v2
            method: POST
          secret:
            name: 6
          tls:
            insecureSkipVerify: 7
      pipelines:
        - name:
          inputRefs:
            - application
          outputRefs:
            - 8

    1
    レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。
    2
    レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。
    3
    サービスアカウントの名前。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。
    4
    ログの宛先アドレス。
    5
    ログレコードと送信する追加のヘッダー。
    6
    宛先認証情報のシークレット名。
    7
    値は true または false です。
    8
    この値は、出力名と同じである必要があります。

11.4.8. Azure Monitor ログへの転送

Logging 5.9 以降では、デフォルトのログストアに加えて、またはデフォルトのログストアの代わりに、Azure Monitor Logs にログを転送できます。この機能は、Vector Azure Monitor Logs sink によって提供されます。

前提条件

  • ClusterLogging カスタムリソース (CR) インスタンスを管理および作成する方法を熟知している。
  • ClusterLogForwarder CR インスタンスを管理および作成する方法を熟知している。
  • ClusterLogForwarder CR 仕様を理解している。
  • Azure サービスに関する基本的な知識がある。
  • Azure Portal または Azure CLI アクセス用に設定された Azure アカウントがある。
  • Azure Monitor Logs のプライマリーセキュリティーキーまたはセカンダリーセキュリティーキーを取得している。
  • 転送するログの種類を決定している。

HTTP データコレクター API 経由で Azure Monitor Logs へのログ転送を有効にするには、以下を実行します。

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

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: openshift-logging
type: Opaque
data:
  shared_key: <your_shared_key> 1
1
要求を行う Log Analytics ワークスペース のプライマリーキーまたはセカンダリーキーを含める必要があります。

共有キー を取得するには、Azure CLI で次のコマンドを使用します。

Get-AzOperationalInsightsWorkspaceSharedKey -ResourceGroupName "<resource_name>" -Name "<workspace_name>”

選択したログに一致するテンプレートを使用して、ClusterLogForwarder CR を作成または編集します。

すべてのログの転送

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogForwarder"
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: azure-monitor
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id 1
      logType: my_log_type 2
    secret:
       name: my-secret
  pipelines:
  - name: app-pipeline
    inputRefs:
    - application
    outputRefs:
    - azure-monitor

1
Log Analytics ワークスペースの一意の識別子。必須フィールド。
2
送信されるデータの Azure レコードタイプ。文字、数字、アンダースコア (_) のみを含めることができ、100 文字を超えることはできません。

アプリケーションログおよびインフラストラクチャーログの転送

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogForwarder"
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: azure-monitor-app
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id
      logType: application_log 1
    secret:
      name: my-secret
  - name: azure-monitor-infra
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id
      logType: infra_log #
    secret:
      name: my-secret
  pipelines:
    - name: app-pipeline
      inputRefs:
      - application
      outputRefs:
      - azure-monitor-app
    - name: infra-pipeline
      inputRefs:
      - infrastructure
      outputRefs:
      - azure-monitor-infra

1
送信されるデータの Azure レコードタイプ。文字、数字、アンダースコア (_) のみを含めることができ、100 文字を超えることはできません。

高度な設定オプション

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogForwarder"
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: azure-monitor
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id
      logType: my_log_type
      azureResourceId: "/subscriptions/111111111" 1
      host: "ods.opinsights.azure.com" 2
    secret:
       name: my-secret
  pipelines:
  - name: app-pipeline
    inputRefs:
    - application
    outputRefs:
    - azure-monitor

1
データの関連付けが必要な Azure リソースのリソース ID。オプションフィールド。
2
専用 Azure リージョンの代替ホスト。オプションフィールド。デフォルト値は ods.opinsights.azure.com です。Azure Government のデフォルト値は ods.opinsights.azure.us です。

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

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

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

前提条件

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

手順

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

    ClusterLogForwarder CR の例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: instance 1
      namespace: openshift-logging 2
    spec:
      outputs:
       - name: fluentd-server-secure 3
         type: fluentdForward 4
         url: 'tls://fluentdserver.security.example.com:24224' 5
         secret: 6
            name: fluentd-secret
       - name: fluentd-server-insecure
         type: fluentdForward
         url: 'tcp://fluentdserver.home.example.com:24224'
      inputs: 7
       - name: my-app-logs
         application:
            namespaces:
            - my-project 8
      pipelines:
       - name: forward-to-fluentd-insecure 9
         inputRefs: 10
         - my-app-logs
         outputRefs: 11
         - fluentd-server-insecure
         labels:
           project: "my-project" 12
       - name: forward-to-fluentd-secure 13
         inputRefs:
         - application 14
         - audit
         - infrastructure
         outputRefs:
         - fluentd-server-secure
         - default
         labels:
           clusterId: "C1234"

    1
    ClusterLogForwarder CR の名前は instance である必要があります。
    2
    ClusterLogForwarder CR の namespace は openshift-logging である必要があります。
    3
    出力の名前。
    4
    出力タイプ: elasticsearchfluentdForwardsyslog、または kafka
    5
    有効な絶対 URL としての外部ログアグリゲーターの URL とポート。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。
    6
    tls 接頭辞を使用する場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットは openshift-logging プロジェクトに存在し、tls.crttls.key、および ca-bundle.crt キーが含まれる必要があります。これらは、それぞれが表す証明書を参照します。
    7
    指定されたプロジェクトからアプリケーションログをフィルターするための入力の設定。
    8
    namespace が指定されていない場合、ログはすべての namespace から収集されます。
    9
    パイプライン設定は、名前付き入力から名前付き出力にログを送信します。この例では、forward-to-fluentd-insecure という名前のパイプラインは、my-app-logs という名前の入力から fluentd-server-insecure という名前の出力にログを転送します。
    10
    入力のリスト。
    11
    使用する出力の名前。
    12
    オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
    13
    ログを他のログアグリゲーターに送信するためのパイプラインの設定。
    • オプション: パイプラインの名前を指定します。
    • パイプラインを使用して転送するログタイプ (applicationinfrastructure または audit) を指定します。
    • このパイプラインでログを転送する時に使用する出力の名前を指定します。
    • オプション: デフォルトのログストアにログを転送するための default 出力を指定します。
    • オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
    14
    この設定を使用すると、すべての namespace からのアプリケーションログが収集されることに注意してください。
  2. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。

    $ oc apply -f <filename>.yaml

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

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

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

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

手順

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

    ClusterLogForwarder CR YAML ファイルのサンプル

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name> 1
      namespace: <log_forwarder_namespace> 2
    spec:
      pipelines:
        - inputRefs: [ myAppLogData ] 3
          outputRefs: [ default ] 4
      inputs: 5
        - name: myAppLogData
          application:
            selector:
              matchLabels: 6
                environment: production
                app: nginx
            namespaces: 7
            - app1
            - app2
      outputs: 8
        - <output_name>
        ...

    1
    レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。
    2
    レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。
    3
    inputs[].name から 1 つ以上のコンマ区切りの値を指定します。
    4
    outputs[] から 1 つ以上のコンマ区切りの値を指定します。
    5
    Pod ラベルの一意のセットを持つ各アプリケーションの一意の inputs[].name を定義します。
    6
    収集するログデータを持つ Pod ラベルのキー/値のペアを指定します。キーだけではなく、キーと値の両方を指定する必要があります。Pod を選択するには、Pod はすべてのキーと値のペアと一致する必要があります。
    7
    オプション: namespace を 1 つ以上指定します。
    8
    ログデータを転送する 1 つ以上の出力を指定します。
  2. オプション: ログデータの収集を特定の namespace に制限するには、前述の例のように inputs[].name.application.namespaces を使用します。
  3. オプション: 異なる Pod ラベルを持つ追加のアプリケーションから同じパイプラインにログデータを送信できます。

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

      - inputRefs: [ myAppLogData, myOtherAppLogData ]
  4. CR オブジェクトを作成します。

    $ oc create -f <file-name>.yaml

関連情報

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

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

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

この機能は、ロギングのデプロイメントで Vector コレクターが設定されている場合にのみ使用できます。

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

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

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

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

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

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

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

注記

提供されている例は、監査ポリシーで可能なルールの範囲を示すことを目的としており、推奨される設定ではありません。

監査ポリシーの例

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  pipelines:
    - name: my-pipeline
      inputRefs: audit 1
      filterRefs: my-policy 2
      outputRefs: default
  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

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

関連情報

11.4.12. 外部 Loki ロギングシステムへのログ転送

デフォルトのログストアに加えて、またはその代わりに、外部の Loki ロギングしすてむにログを転送できます。

Loki へのログ転送を設定するには、Loki の出力と、出力を使用するパイプラインで ClusterLogForwarder カスタムリソース (CR) を作成する必要があります。Loki への出力は HTTP (セキュアでない) または HTTPS (セキュアな HTTP) 接続を使用できます。

前提条件

  • CR の url フィールドで指定する URL で Loki ロギングシステムが実行されている必要がある。

手順

  1. ClusterLogForwarder CR オブジェクトを定義する YAML ファイルを作成または編集します。

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name> 1
      namespace: <log_forwarder_namespace> 2
    spec:
      serviceAccountName: <service_account_name> 3
      outputs:
      - name: loki-insecure 4
        type: "loki" 5
        url: http://loki.insecure.com:3100 6
        loki:
          tenantKey: kubernetes.namespace_name
          labelKeys:
          - kubernetes.labels.foo
      - name: loki-secure 7
        type: "loki"
        url: https://loki.secure.com:3100
        secret:
          name: loki-secret 8
        loki:
          tenantKey: kubernetes.namespace_name 9
          labelKeys:
          - kubernetes.labels.foo 10
      pipelines:
      - name: application-logs 11
        inputRefs:  12
        - application
        - audit
        outputRefs: 13
        - loki-secure
    1
    レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。
    2
    レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。
    3
    サービスアカウントの名前。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。
    4
    出力の名前を指定します。
    5
    タイプを "loki" と指定します。
    6
    Loki システムの URL およびポートを有効な絶対 URL として指定します。http (セキュアでない) プロトコルまたは https (セキュアな HTTP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。HTTP(S) 通信用の Loki のデフォルトポートは 3100 です。
    7
    セキュアな接続では、シークレット を指定して、認証する https または http URL を指定できます。
    8
    https 接頭辞の場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定します。シークレットには、それが表す証明書を指す ca-bundle.crt 鍵が含まれている必要があります。それ以外の場合、http および https 接頭辞の場合は、ユーザー名とパスワードを含むシークレットを指定できます。レガシー実装では、シークレットは openshift-logging プロジェクトに存在する必要があります。詳細は、「例: ユーザー名とパスワードを含むシークレットの設定」を参照してください。
    9
    オプション: メタデータキーフィールドを指定して、Loki の TenantID フィールドの値を生成します。たとえば、tenantKey: kubernetes.namespace_name を設定すると、Kubernetes namespace の名前を Loki のテナント ID の値として使用します。他にどのログレコードフィールドを指定できるかを確認するには、以下の「関連情報」セクションの「Log Record Fields」リンクを参照してください。
    10
    オプション: デフォルトの Loki ラベルを置き換えるメタデータフィールドキーのリストを指定します。loki ラベル名は、正規表現 [a-zA-Z_:][a-zA-Z0-9_:]* と一致する必要があります。ラベル名を形成するため、メタデータキーの無効な文字は _ に置き換えられます。たとえば、kubernetes.labels.foo メタデータキーは、Loki ラベル kubernetes_labels_foo になります。labelKeys を設定しないと、デフォルト値は [log_type, kubernetes.namespace_name, kubernetes.pod_name, kubernetes_host] です。Loki で指定可能なラベルのサイズと数に制限があるため、ラベルのセットを小さくします。Configuring Loki, limits_config を参照してください。クエリーフィルターを使用して、ログレコードフィールドに基づいてクエリーを実行できます。
    11
    オプション: パイプラインの名前を指定します。
    12
    パイプラインを使用して転送するログタイプ (applicationinfrastructure または audit) を指定します。
    13
    このパイプラインでログを転送する時に使用する出力の名前を指定します。
    注記

    Loki ではログストリームを正しくタイムスタンプで順序付ける必要があるため、labelKeys には指定しなくても kubernetes_host ラベルセットが常に含まれます。このラベルセットが含まれることで、各ストリームが 1 つのホストから発信されるので、ホストのクロック間の誤差が原因でタイムスタンプの順番が乱れないようになります。

  2. 次のコマンドを実行して、ClusterLogForwarder CR オブジェクトを適用します。

    $ oc apply -f <filename>.yaml

11.4.13. 外部 Elasticsearch インスタンスへのログの送信

内部ログストアに加えて、またはその代わりに外部の Elasticsearch インスタンスにログを転送できます。外部ログアグリゲーターを OpenShift Container Platform からログデータを受信するように設定する必要があります。

外部 Elasticsearch インスタンスへのログ転送を設定するには、そのインスタンスへの出力および出力を使用するパイプラインで ClusterLogForwarder カスタムリソース (CR) を作成する必要があります。外部 Elasticsearch 出力では、HTTP(セキュアでない) または HTTPS(セキュアな HTTP) 接続を使用できます。

外部 Elasticsearch インスタンスと内部 Elasticsearch インスタンスの両方にログを転送するには、出力および外部インスタンスへのパイプライン、および default 出力を使用してログを内部インスタンスに転送するパイプラインを作成します。

注記

ログを内部 Elasticsearch インスタンスのみに転送する必要がある場合は、ClusterLogForwarder CR を作成する必要はありません。

前提条件

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

手順

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

    ClusterLogForwarder CR の例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name> 1
      namespace: <log_forwarder_namespace> 2
    spec:
      serviceAccountName: <service_account_name> 3
      outputs:
       - name: elasticsearch-example 4
         type: elasticsearch 5
         elasticsearch:
           version: 8 6
         url: http://elasticsearch.example.com:9200 7
         secret:
           name: es-secret 8
      pipelines:
       - name: application-logs 9
         inputRefs: 10
         - application
         - audit
         outputRefs:
         - elasticsearch-example 11
         - default 12
         labels:
           myLabel: "myValue" 13
    # ...

    1
    レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。
    2
    レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。
    3
    サービスアカウントの名前。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。
    4
    出力の名前を指定します。
    5
    elasticsearch タイプを指定します。
    6
    Elasticsearch バージョンを指定します。これは 67、または 8 のいずれかになります。
    7
    外部 Elasticsearch インスタンスの URL およびポートを有効な絶対 URL として指定します。http (セキュアでない) プロトコルまたは https (セキュアな HTTP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。
    8
    https 接頭辞の場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定します。シークレットには、それが表す証明書を指す ca-bundle.crt 鍵が含まれている必要があります。それ以外の場合、http および https 接頭辞の場合は、ユーザー名とパスワードを含むシークレットを指定できます。レガシー実装では、シークレットは openshift-logging プロジェクトに存在する必要があります。詳細は、「例: ユーザー名とパスワードを含むシークレットの設定」を参照してください。
    9
    オプション: パイプラインの名前を指定します。
    10
    パイプラインを使用して転送するログタイプ (applicationinfrastructure または audit) を指定します。
    11
    このパイプラインでログを転送する時に使用する出力の名前を指定します。
    12
    オプション: ログを内部 Elasticsearch インスタンスに送信するために default 出力を指定します。
    13
    オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
  2. ClusterLogForwarder CR を適用します。

    $ oc apply -f <filename>.yaml

例: ユーザー名とパスワードを含むシークレットの設定

ユーザー名とパスワードを含むシークレットを使用して、外部 Elasticsearch インスタンスへのセキュアな接続を認証できます。

たとえば、サードパーティーが Elasticsearch インスタンスを操作するため、相互 TLS (mTLS) キーを使用できない場合に、HTTP または HTTPS を使用してユーザー名とパスワードを含むシークレットを設定できます。

  1. 以下の例のような Secret YAML ファイルを作成します。username および password フィールドに base64 でエンコードされた値を使用します。シークレットタイプはデフォルトで opaque です。

    apiVersion: v1
    kind: Secret
    metadata:
      name: openshift-test-secret
    data:
      username: <username>
      password: <password>
    # ...
  2. シークレットを作成します。

    $ oc create secret -n openshift-logging openshift-test-secret.yaml
  3. ClusterLogForwarder CR にシークレットの名前を指定します。

    kind: ClusterLogForwarder
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      outputs:
       - name: elasticsearch
         type: "elasticsearch"
         url: https://elasticsearch.secure.com:9200
         secret:
            name: openshift-test-secret
    # ...
    注記

    url フィールドの値では、接頭辞は http または https になります。

  4. CR オブジェクトを適用します。

    $ oc apply -f <filename>.yaml

11.4.14. Fluentd 転送プロトコルを使用したログの転送

Fluentd forward プロトコルを使用して、デフォルトの Elasticsearch ログストアの代わり、またはこれに加えてプロトコルを受け入れるように設定された外部ログアグリゲーターにログのコピーを送信できます。外部ログアグリゲーターを OpenShift Container Platform からログを受信するように設定する必要があります。

forward プロトコルを使用してログ転送を設定するには、Fluentd サーバーに対する 1 つ以上の出力およびそれらの出力を使用するパイプラインと共に ClusterLogForwarder カスタムリース (CR) を作成します。Fluentd の出力は TCP(セキュアでない) または TLS(セキュアな TCP) 接続を使用できます。

前提条件

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

手順

  1. ClusterLogForwarder CR オブジェクトを定義する YAML ファイルを作成または編集します。

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: instance 1
      namespace: openshift-logging 2
    spec:
      outputs:
       - name: fluentd-server-secure 3
         type: fluentdForward 4
         url: 'tls://fluentdserver.security.example.com:24224' 5
         secret: 6
            name: fluentd-secret
       - name: fluentd-server-insecure
         type: fluentdForward
         url: 'tcp://fluentdserver.home.example.com:24224'
      pipelines:
       - name: forward-to-fluentd-secure 7
         inputRefs:  8
         - application
         - audit
         outputRefs:
         - fluentd-server-secure 9
         - default 10
         labels:
           clusterId: "C1234" 11
       - name: forward-to-fluentd-insecure 12
         inputRefs:
         - infrastructure
         outputRefs:
         - fluentd-server-insecure
         labels:
           clusterId: "C1234"
    1
    ClusterLogForwarder CR の名前は instance である必要があります。
    2
    ClusterLogForwarder CR の namespace は openshift-logging である必要があります。
    3
    出力の名前を指定します。
    4
    fluentdForward タイプを指定します。
    5
    外部 Fluentd インスタンスの URL およびポートを有効な絶対 URL として指定します。tcp (セキュアでない) プロトコルまたは tls (セキュアな TCP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。
    6
    tls を接頭辞として使用している場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットは openshift-logging プロジェクトに存在する必要があり、それが表す証明書を指す ca-bundle.crt 鍵が含まれている必要があります。
    7
    オプション: パイプラインの名前を指定します。
    8
    パイプラインを使用して転送するログタイプ (applicationinfrastructure または audit) を指定します。
    9
    このパイプラインでログを転送する時に使用する出力の名前を指定します。
    10
    オプション: ログを内部 Elasticsearch インスタンスに転送するために default 出力を指定します。
    11
    オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
    12
    オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。
    • パイプラインを説明する名前。
    • inputRefs は、そのパイプラインを使用して転送するログタイプです (applicationinfrastructure、または audit)。
    • outputRefs は使用する出力の名前です。
    • オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
  2. CR オブジェクトを作成します。

    $ oc create -f <file-name>.yaml

11.4.14.1. Logstash が fluentd からデータを取り込むためのナノ秒精度の有効化

Logstash が fluentd からログデータを取り込むには、Logstash 設定ファイルでナノ秒精度を有効にする必要があります。

手順

  • Logstash 設定ファイルで、nanosecond_precisiontrue に設定します。

Logstash 設定ファイルの例

input { tcp { codec => fluent { nanosecond_precision => true } port => 24114 } }
filter { }
output { stdout { codec => rubydebug } }

11.4.15. syslog プロトコルを使用したログの転送

syslog RFC3164 または RFC5424 プロトコルを使用して、デフォルトの Elasticsearch ログストアの代わり、またはこれに加えてプロトコルを受け入れるように設定された外部ログアグリゲーターにログのコピーを送信できます。syslog サーバーなど、外部ログアグリゲーターを OpenShift Container Platform からログを受信するように設定する必要があります。

syslog プロトコルを使用してログ転送を設定するには、syslog サーバーに対する 1 つ以上の出力およびそれらの出力を使用するパイプラインと共に ClusterLogForwarder カスタムリース (CR) を作成します。syslog 出力では、UDP、TCP、または TLS 接続を使用できます。

前提条件

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

手順

  1. ClusterLogForwarder CR オブジェクトを定義する YAML ファイルを作成または編集します。

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name> 1
      namespace: <log_forwarder_namespace> 2
    spec:
      serviceAccountName: <service_account_name> 3
      outputs:
       - name: rsyslog-east 4
         type: syslog 5
         syslog: 6
           facility: local0
           rfc: RFC3164
           payloadKey: message
           severity: informational
         url: 'tls://rsyslogserver.east.example.com:514' 7
         secret: 8
            name: syslog-secret
       - name: rsyslog-west
         type: syslog
         syslog:
          appName: myapp
          facility: user
          msgID: mymsg
          procID: myproc
          rfc: RFC5424
          severity: debug
         url: 'tcp://rsyslogserver.west.example.com:514'
      pipelines:
       - name: syslog-east 9
         inputRefs: 10
         - audit
         - application
         outputRefs: 11
         - rsyslog-east
         - default 12
         labels:
           secure: "true" 13
           syslog: "east"
       - name: syslog-west 14
         inputRefs:
         - infrastructure
         outputRefs:
         - rsyslog-west
         - default
         labels:
           syslog: "west"
    1
    レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。
    2
    レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。
    3
    サービスアカウントの名前。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。
    4
    出力の名前を指定します。
    5
    syslog タイプを指定します。
    6
    オプション: 以下にリスト表示されている syslog パラメーターを指定します。
    7
    外部 syslog インスタンスの URL およびポートを指定します。udp (セキュアでない)、tcp (セキュアでない) プロトコル、または tls (セキュアな TCP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。
    8
    tls 接頭辞を使用する場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットには、それが表す証明書を指す ca-bundle.crt 鍵が含まれている必要があります。レガシー実装では、シークレットは openshift-logging プロジェクトに存在する必要があります。
    9
    オプション: パイプラインの名前を指定します。
    10
    パイプラインを使用して転送するログタイプ (applicationinfrastructure または audit) を指定します。
    11
    このパイプラインでログを転送する時に使用する出力の名前を指定します。
    12
    オプション: ログを内部 Elasticsearch インスタンスに転送するために default 出力を指定します。
    13
    オプション: 文字列。ログに追加する 1 つまたは複数のラベル。"true" などの引用値は、ブール値としてではなく、文字列値として認識されるようにします。
    14
    オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。
    • パイプラインを説明する名前。
    • inputRefs は、そのパイプラインを使用して転送するログタイプです (applicationinfrastructure、または audit)。
    • outputRefs は使用する出力の名前です。
    • オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
  2. CR オブジェクトを作成します。

    $ oc create -f <filename>.yaml

11.4.15.1. メッセージ出力へのログソース情報の追加

AddLogSource フィールドを ClusterLogForwarder カスタムリソース (CR) に追加することで、namespace_namepod_name、および container_name 要素をレコードの メッセージ フィールドに追加できます。

  spec:
    outputs:
    - name: syslogout
      syslog:
        addLogSource: true
        facility: user
        payloadKey: message
        rfc: RFC3164
        severity: debug
        tag: mytag
      type: syslog
      url: tls://syslog-receiver.openshift-logging.svc:24224
    pipelines:
    - inputRefs:
      - application
      name: test-app
      outputRefs:
      - syslogout
注記

この設定は、RFC3164 と RFC5424 の両方と互換性があります。

AddLogSource を使用しない場合の syslog メッセージ出力の例

<15>1 2020-11-15T17:06:14+00:00 fluentd-9hkb4 mytag - - -  {"msgcontent"=>"Message Contents", "timestamp"=>"2020-11-15 17:06:09", "tag_key"=>"rec_tag", "index"=>56}

AddLogSource を使用した syslog メッセージ出力の例

<15>1 2020-11-16T10:49:37+00:00 crc-j55b9-master-0 mytag - - -  namespace_name=clo-test-6327,pod_name=log-generator-ff9746c49-qxm7l,container_name=log-generator,message={"msgcontent":"My life is my message", "timestamp":"2020-11-16 10:49:36", "tag_key":"rec_tag", "index":76}

11.4.15.2. syslog パラメーター

syslog 出力には、以下を設定できます。詳細は、syslog の RFC3164 または RFC5424 RFC を参照してください。

  • facility: syslog ファシリティー。値には 10 進数の整数または大文字と小文字を区別しないキーワードを使用できます。

    • カーネルメッセージの場合は、0 または kern
    • ユーザーレベルのメッセージの場合は、1 または user。デフォルトです。
    • メールシステムの場合は、2 または mail
    • システムデーモンの場合は、3 または daemon
    • セキュリティー/認証メッセージの場合は、4 または auth
    • syslogd によって内部に生成されるメッセージの場合は、5 または syslog
    • ラインプリンターサブシステムの場合は、6 または lpr
    • ネットワーク news サブシステムの場合は、7 または news
    • UUCP サブシステムの場合は、8 または uucp
    • クロックデーモンの場合は、9 または cron
    • セキュリティー認証メッセージの場合は、10 または authpriv
    • FTP デーモンの場合は、11 または ftp
    • NTP サブシステムの場合は、12 または ntp
    • syslog 監査ログの場合は、13 または security
    • syslog アラートログの場合は、14 または console
    • スケジューリングデーモンの場合は、15 または solaris-cron
    • ローカルに使用される facility の場合は、1623 または local0local7
  • オプション: payloadKey: syslog メッセージのペイロードとして使用するレコードフィールド。

    注記

    payloadKey パラメーターを設定すると、他のパラメーターが syslog に転送されなくなります。

  • rfc: syslog を使用してログを送信するために使用される RFC。デフォルトは RFC5424 です。
  • severity: 送信 syslog レコードに設定される syslog の重大度。値には 10 進数の整数または大文字と小文字を区別しないキーワードを使用できます。

    • システムが使用不可であることを示すメッセージの場合は、0 または Emergency
    • 即時にアクションを実行する必要があることを示すメッセージの場合は、1 または Alert
    • 重大な状態を示すメッセージの場合は、2 または Critical
    • エラーの状態を示すメッセージの場合は、3 または Error
    • 警告状態を示すメッセージの場合は、4 または Warning
    • 正常であるが重要な状態を示すメッセージの場合は、5 または Notice
    • 情報を提供するメッセージの場合は、6 または Informational
    • デバッグレベルのメッセージを示唆するメッセージの場合は、7 または Debug。デフォルトです。
  • tag: タグは、syslog メッセージでタグとして使用するレコードフィールドを指定します。
  • trimPrefix: 指定された接頭辞をタグから削除します。

11.4.15.3. 追加の RFC5424 syslog パラメーター

以下のパラメーターは RFC5424 に適用されます。

  • appName: APP-NAME は、ログを送信したアプリケーションを識別するフリーテキストの文字列です。RFC5424 に対して指定する必要があります。
  • msgID: MSGID は、メッセージのタイプを識別するフリーテキスト文字列です。RFC5424 に対して指定する必要があります。
  • procID: PROCID はフリーテキスト文字列です。値が変更される場合は、syslog レポートが中断していることを示します。RFC5424 に対して指定する必要があります。

11.4.16. ログの Kafka ブローカーへの転送

デフォルトのログストアに加えて、またはその代わりに、外部の Kafka ブローカーにログを転送できます。

外部 Kafka インスタンスへのログ転送を設定するには、そのインスタンスへの出力を含む ClusterLogForwarder カスタムリソース (CR) と、その出力を使用するパイプラインを作成する必要があります。出力に特定の Kafka トピックを追加するか、デフォルトを使用できます。Kafka の出力は TCP(セキュアでない) または TLS(セキュアな TCP) 接続を使用できます。

手順

  1. ClusterLogForwarder CR オブジェクトを定義する YAML ファイルを作成または編集します。

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name> 1
      namespace: <log_forwarder_namespace> 2
    spec:
      serviceAccountName: <service_account_name> 3
      outputs:
       - name: app-logs 4
         type: kafka 5
         url: tls://kafka.example.devlab.com:9093/app-topic 6
         secret:
           name: kafka-secret 7
       - name: infra-logs
         type: kafka
         url: tcp://kafka.devlab2.example.com:9093/infra-topic 8
       - name: audit-logs
         type: kafka
         url: tls://kafka.qelab.example.com:9093/audit-topic
         secret:
            name: kafka-secret-qe
      pipelines:
       - name: app-topic 9
         inputRefs: 10
         - application
         outputRefs: 11
         - app-logs
         labels:
           logType: "application" 12
       - name: infra-topic 13
         inputRefs:
         - infrastructure
         outputRefs:
         - infra-logs
         labels:
           logType: "infra"
       - name: audit-topic
         inputRefs:
         - audit
         outputRefs:
         - audit-logs
         labels:
           logType: "audit"
    1
    レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。
    2
    レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。
    3
    サービスアカウントの名前。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。
    4
    出力の名前を指定します。
    5
    kafka タイプを指定します。
    6
    Kafka ブローカーの URL およびポートを有効な絶対 URL として指定し、オプションで特定のトピックで指定します。tcp (セキュアでない) プロトコルまたは tls (セキュアな TCP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。
    7
    tls を接頭辞として使用している場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットには、それが表す証明書を指す ca-bundle.crt 鍵が含まれている必要があります。レガシー実装では、シークレットは openshift-logging プロジェクトに存在する必要があります。
    8
    オプション: 非セキュアな出力を送信するには、URL の前に tcp の接頭辞を使用します。また、この出力の secret キーとその name を省略します。
    9
    オプション: パイプラインの名前を指定します。
    10
    パイプラインを使用して転送するログタイプ (applicationinfrastructure または audit) を指定します。
    11
    このパイプラインでログを転送する時に使用する出力の名前を指定します。
    12
    オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
    13
    オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。
    • パイプラインを説明する名前。
    • inputRefs は、そのパイプラインを使用して転送するログタイプです (applicationinfrastructure、または audit)。
    • outputRefs は使用する出力の名前です。
    • オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
  2. オプション: 単一の出力を複数の Kafka ブローカーに転送するには、次の例に示すように Kafka ブローカーの配列を指定します。

    # ...
    spec:
      outputs:
      - name: app-logs
        type: kafka
        secret:
          name: kafka-secret-dev
        kafka:  1
          brokers: 2
            - tls://kafka-broker1.example.com:9093/
            - tls://kafka-broker2.example.com:9093/
          topic: app-topic 3
    # ...
    1
    brokers および topic キーを持つ kafka キーを指定します。
    2
    brokers キーを指定して、1 つ以上のブローカーを指定します。
    3
    トピック キーを使用して、ログを受信するターゲットトピックを指定します。
  3. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。

    $ oc apply -f <filename>.yaml

11.4.17. ログの Amazon CloudWatch への転送

Amazon Web Services (AWS) がホストするモニタリングおよびログストレージサービスである Amazon CloudWatch にログを転送できます。デフォルトのログストアに加えて、またはログストアの代わりに、CloudWatch にログを転送できます。

CloudWatch へのログ転送を設定するには、CloudWatch の出力および出力を使用するパイプラインで ClusterLogForwarder カスタムリソース (CR) を作成する必要があります。

手順

  1. aws_access_key_id および aws_secret_access_key フィールドを使用する Secret YAML ファイルを作成し、base64 でエンコードされた AWS 認証情報を指定します。以下に例を示します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: cw-secret
      namespace: openshift-logging
    data:
      aws_access_key_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEUK
      aws_secret_access_key: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo=
  2. シークレットを作成します。以下に例を示します。

    $ oc apply -f cw-secret.yaml
  3. ClusterLogForwarder CR オブジェクトを定義する YAML ファイルを作成または編集します。このファイルに、シークレットの名前を指定します。以下に例を示します。

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name> 1
      namespace: <log_forwarder_namespace> 2
    spec:
      serviceAccountName: <service_account_name> 3
      outputs:
       - name: cw 4
         type: cloudwatch 5
         cloudwatch:
           groupBy: logType 6
           groupPrefix: <group prefix> 7
           region: us-east-2 8
         secret:
            name: cw-secret 9
      pipelines:
        - name: infra-logs 10
          inputRefs: 11
            - infrastructure
            - audit
            - application
          outputRefs:
            - cw 12
    1
    レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。
    2
    レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。
    3
    サービスアカウントの名前。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。
    4
    出力の名前を指定します。
    5
    cloudwatch タイプを指定します。
    6
    オプション: ログをグループ化する方法を指定します。
    • logType は、ログタイプごとにロググループを作成します。
    • namespaceName は、アプリケーションの namespace ごとにロググループを作成します。また、インフラストラクチャーおよび監査ログ用の個別のロググループも作成します。
    • namespaceUUID は、アプリケーション namespace UUID ごとに新しいロググループを作成します。また、インフラストラクチャーおよび監査ログ用の個別のロググループも作成します。
    7
    オプション: ロググループの名前に含まれるデフォルトの infrastructureName 接頭辞を置き換える文字列を指定します。
    8
    AWS リージョンを指定します。
    9
    AWS 認証情報が含まれるシークレットの名前を指定します。
    10
    オプション: パイプラインの名前を指定します。
    11
    パイプラインを使用して転送するログタイプ (applicationinfrastructure または audit) を指定します。
    12
    このパイプラインでログを転送する時に使用する出力の名前を指定します。
  4. CR オブジェクトを作成します。

    $ oc create -f <file-name>.yaml

例: Amazon CloudWatch での ClusterLogForwarder の使用

ここでは、ClusterLogForwarder カスタムリソース (CR) のサンプルと、Amazon CloudWatch に出力するログデータが表示されます。

mycluster という名前の OpenShift Container Platform クラスターを実行しているとします。以下のコマンドは、クラスターの infrastructureName を返します。これは、後で aws コマンドの作成に使用します。

$ oc get Infrastructure/cluster -ojson | jq .status.infrastructureName
"mycluster-7977k"

この例のログデータを生成するには、app という名前の namespace で busybox pod を実行します。busybox pod は、3 秒ごとに stdout にメッセージを書き込みます。

$ oc run busybox --image=busybox -- sh -c 'while true; do echo "My life is my message"; sleep 3; done'
$ oc logs -f busybox
My life is my message
My life is my message
My life is my message
...

busybox pod が実行される app namespace の UUID を検索できます。

$ oc get ns/app -ojson | jq .metadata.uid
"794e1e1a-b9f5-4958-a190-e76a9b53d7bf"

ClusterLogForwarder カスタムリソース (CR) で、インフラストラクチャー監査、および アプリケーションログ タイプを all-logs パイプラインへの入力として設定します。また、このパイプラインを cw 出力に接続し、us-east-2 リージョンの CloudWatch インスタンスに転送します。

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
   - name: cw
     type: cloudwatch
     cloudwatch:
       groupBy: logType
       region: us-east-2
     secret:
        name: cw-secret
  pipelines:
    - name: all-logs
      inputRefs:
        - infrastructure
        - audit
        - application
      outputRefs:
        - cw

CloudWatch の各リージョンには、3 つのレベルのオブジェクトが含まれます。

  • ロググループ

    • ログストリーム

      • ログイベント

ClusterLogForwarding CR の groupBy: logType の場合に、inputRefs にある 3 つのログタイプで Amazon Cloudwatch に 3 つのロググループを生成します。

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"mycluster-7977k.application"
"mycluster-7977k.audit"
"mycluster-7977k.infrastructure"

各ロググループにはログストリームが含まれます。

$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.application | jq .logStreams[].logStreamName
"kubernetes.var.log.containers.busybox_app_busybox-da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76.log"
$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.audit | jq .logStreams[].logStreamName
"ip-10-0-131-228.us-east-2.compute.internal.k8s-audit.log"
"ip-10-0-131-228.us-east-2.compute.internal.linux-audit.log"
"ip-10-0-131-228.us-east-2.compute.internal.openshift-audit.log"
...
$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.infrastructure | jq .logStreams[].logStreamName
"ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-69f9fd9b58-zqzw5_openshift-oauth-apiserver_oauth-apiserver-453c5c4ee026fe20a6139ba6b1cdd1bed25989c905bf5ac5ca211b7cbb5c3d7b.log"
"ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-797774f7c5-lftrx_openshift-apiserver_openshift-apiserver-ce51532df7d4e4d5f21c4f4be05f6575b93196336be0027067fd7d93d70f66a4.log"
"ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-797774f7c5-lftrx_openshift-apiserver_openshift-apiserver-check-endpoints-82a9096b5931b5c3b1d6dc4b66113252da4a6472c9fff48623baee761911a9ef.log"
...

各ログストリームにはログイベントが含まれます。busybox Pod からログイベントを表示するには、application ロググループからログストリームを指定します。

$ aws logs get-log-events --log-group-name mycluster-7977k.application --log-stream-name kubernetes.var.log.containers.busybox_app_busybox-da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76.log
{
    "events": [
        {
            "timestamp": 1629422704178,
            "message": "{\"docker\":{\"container_id\":\"da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76\"},\"kubernetes\":{\"container_name\":\"busybox\",\"namespace_name\":\"app\",\"pod_name\":\"busybox\",\"container_image\":\"docker.io/library/busybox:latest\",\"container_image_id\":\"docker.io/library/busybox@sha256:0f354ec1728d9ff32edcd7d1b8bbdfc798277ad36120dc3dc683be44524c8b60\",\"pod_id\":\"870be234-90a3-4258-b73f-4f4d6e2777c7\",\"host\":\"ip-10-0-216-3.us-east-2.compute.internal\",\"labels\":{\"run\":\"busybox\"},\"master_url\":\"https://kubernetes.default.svc\",\"namespace_id\":\"794e1e1a-b9f5-4958-a190-e76a9b53d7bf\",\"namespace_labels\":{\"kubernetes_io/metadata_name\":\"app\"}},\"message\":\"My life is my message\",\"level\":\"unknown\",\"hostname\":\"ip-10-0-216-3.us-east-2.compute.internal\",\"pipeline_metadata\":{\"collector\":{\"ipaddr4\":\"10.0.216.3\",\"inputname\":\"fluent-plugin-systemd\",\"name\":\"fluentd\",\"received_at\":\"2021-08-20T01:25:08.085760+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-20T01:25:04.178986+00:00\",\"viaq_index_name\":\"app-write\",\"viaq_msg_id\":\"NWRjZmUyMWQtZjgzNC00MjI4LTk3MjMtNTk3NmY3ZjU4NDk1\",\"log_type\":\"application\",\"time\":\"2021-08-20T01:25:04+00:00\"}",
            "ingestionTime": 1629422744016
        },
...

例: ロググループ名の接頭辞のカスタマイズ

ロググループ名では、デフォルトの infrastructureName 接頭辞 mycluster-7977kdemo-group-prefix のように任意の文字列に置き換えることができます。この変更を加えるには、ClusterLogForwarding CR の groupPrefix フィールドを更新します。

cloudwatch:
    groupBy: logType
    groupPrefix: demo-group-prefix
    region: us-east-2

groupPrefix の値は、デフォルトの infrastructureName 接頭辞を置き換えます。

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"demo-group-prefix.application"
"demo-group-prefix.audit"
"demo-group-prefix.infrastructure"

例: アプリケーションの namespace 名をもとにロググループの命名

クラスター内のアプリケーション namespace ごとに、名前がアプリケーション namespace 名をもとにする CloudWatch にロググループを作成できます。

アプリケーションの namespace オブジェクトを削除して、同じ名前の新しいオブジェクトを作成する場合は、CloudWatch は以前と同じロググループを使用し続けます。

相互に名前が同じアプリケーション namespace オブジェクトを引き継ぐ予定の場合は、この例で説明されている方法を使用します。それ以外で、生成されるログメッセージを相互に区別する必要がある場合は、代わりに "Naming log groups for application namespace UUIDs" のセクションを参照してください。

アプリケーション namespace 名を基にした名前を指定してアプリケーションロググループを作成するには、ClusterLogForwarder CR で groupBy フィールドの値を namespaceName に設定します。

cloudwatch:
    groupBy: namespaceName
    region: us-east-2

groupBynamespaceName に設定すると、アプリケーションロググループのみが影響を受けます。これは、audit および infrastructure のロググループには影響しません。

Amazon Cloudwatch では、namespace 名が各ロググループ名の最後に表示されます。アプリケーション namespace ("app") が 1 つであるため、以下の出力は mycluster-7977k.application ではなく、新しい mycluster-7977k.app ロググループを示しています。

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"mycluster-7977k.app"
"mycluster-7977k.audit"
"mycluster-7977k.infrastructure"

この例のクラスターに複数のアプリケーション namespace が含まれる場合は、出力には namespace ごとに複数のロググループが表示されます。

groupBy フィールドは、アプリケーションロググループだけに影響します。これは、audit および infrastructure のロググループには影響しません。

例: アプリケーション namespace UUID をもとにロググループの命名

クラスター内のアプリケーション namespace ごとに、名前がアプリケーション namespace の UUID をもとにする CloudWatch にロググループを作成できます。

アプリケーションの namespace オブジェクトを削除して新規のロググループを作成する場合は、CloudWatch で新しいロググループを作成します。

相互に名前が異なるアプリケーション namespace オブジェクトを引き継ぐ予定の場合は、この例で説明されている方法を使用します。それ以外の場合は、前述の例: "Example: Naming log groups for application namespace names" のセクションを参照してください。

アプリケーション namespace UUID をもとにログエントリーに名前を付けるには、ClusterLogForwarder CR で groupBy フィールドの値を namespaceUUID に設定します。

cloudwatch:
    groupBy: namespaceUUID
    region: us-east-2

Amazon Cloudwatch では、namespace UUID が各ロググループ名の最後に表示されます。アプリケーション namespace ("app") が 1 つであるため、以下の出力は mycluster-7977k.application ではなく、新しい mycluster-7977k.794e1e1a-b9f5-4958-a190-e76a9b53d7bf ロググループを示しています。

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"mycluster-7977k.794e1e1a-b9f5-4958-a190-e76a9b53d7bf" // uid of the "app" namespace
"mycluster-7977k.audit"
"mycluster-7977k.infrastructure"

groupBy フィールドは、アプリケーションロググループだけに影響します。これは、audit および infrastructure のロググループには影響しません。

11.4.18. 既存の AWS ロールを使用した AWS CloudWatch のシークレット作成

AWS の既存のロールがある場合は、oc create secret --from-literal コマンドを使用して、STS で AWS のシークレットを作成できます。

手順

  • CLI で次のように入力して、AWS のシークレットを生成します。

    $ oc create secret generic cw-sts-secret -n openshift-logging --from-literal=role_arn=arn:aws:iam::123456789012:role/my-role_with-permissions

    シークレットの例

    apiVersion: v1
    kind: Secret
    metadata:
      namespace: openshift-logging
      name: my-secret-name
    stringData:
      role_arn: arn:aws:iam::123456789012:role/my-role_with-permissions

11.4.19. STS 対応クラスターから Amazon CloudWatch へのログ転送

AWS Security Token Service (STS) が有効になっているクラスターの場合、AWS サービスアカウントを手動で作成するか、Cloud Credential Operator (CCO) ユーティリティー ccoctl を使用してクレデンシャルのリクエストを作成できます。

前提条件

  • Red Hat OpenShift のロギング: 5.5 以降

手順

  1. 以下のテンプレートを使用して、CredentialsRequest カスタムリソース YAML を作成します。

    CloudWatch クレデンシャルリクエストのテンプレート

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <your_role_name>-credrequest
      namespace: openshift-cloud-credential-operator
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
          - action:
              - logs:PutLogEvents
              - logs:CreateLogGroup
              - logs:PutRetentionPolicy
              - logs:CreateLogStream
              - logs:DescribeLogGroups
              - logs:DescribeLogStreams
            effect: Allow
            resource: arn:aws:logs:*:*:*
      secretRef:
        name: <your_role_name>
        namespace: openshift-logging
      serviceAccountNames:
        - logcollector

  2. ccoctl コマンドを使用して、CredentialsRequest CR を使用して AWS のロールを作成します。CredentialsRequestオブジェクトでは、この ccoctl コマンドを使用すると、特定の OIDC アイデンティティープロバイダーに紐付けされたトラストポリシーと、CloudWatch リソースでの操作実行パーミッションを付与するパーミッションポリシーを指定して IAM ロールを作成します。このコマンドは、/<path_to_ccoctl_output_dir>/manifests/openshift-logging-<your_role_name>-credentials.yaml に YAML 設定ファイルも作成します。このシークレットファイルには、AWS IAM ID プロバイダーでの認証中に使用される role_arn キー/値が含まれています。

    $ ccoctl aws create-iam-roles \
    --name=<name> \
    --region=<aws_region> \
    --credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequests \
    --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com 1
    1
    <name> は、クラウドリソースのタグ付けに使用される名前であり、STS クラスターのインストール中に使用される名前と一致する必要があります。
  3. 作成したシークレットを適用します。

    $ oc apply -f output/manifests/openshift-logging-<your_role_name>-credentials.yaml
  4. ClusterLogForwarder カスタムリソースを作成または編集します。

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name> 1
      namespace: <log_forwarder_namespace> 2
    spec:
      serviceAccountName: clf-collector 3
      outputs:
       - name: cw 4
         type: cloudwatch 5
         cloudwatch:
           groupBy: logType 6
           groupPrefix: <group prefix> 7
           region: us-east-2 8
         secret:
            name: <your_secret_name> 9
      pipelines:
        - name: to-cloudwatch 10
          inputRefs: 11
            - infrastructure
            - audit
            - application
          outputRefs:
            - cw 12
    1
    レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。
    2
    レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。
    3
    clf-collector サービスアカウントを指定します。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。
    4
    出力の名前を指定します。
    5
    cloudwatch タイプを指定します。
    6
    オプション: ログをグループ化する方法を指定します。
    • logType は、ログタイプごとにロググループを作成します。
    • namespaceName は、アプリケーションの namespace ごとにロググループを作成します。インフラストラクチャーおよび監査ログは影響を受けず、logType によってグループ化されたままになります。
    • namespaceUUID は、アプリケーション namespace UUID ごとに新しいロググループを作成します。また、インフラストラクチャーおよび監査ログ用の個別のロググループも作成します。
    7
    オプション: ロググループの名前に含まれるデフォルトの infrastructureName 接頭辞を置き換える文字列を指定します。
    8
    AWS リージョンを指定します。
    9
    AWS 認証情報が含まれるシークレットの名前を指定します。
    10
    オプション: パイプラインの名前を指定します。
    11
    パイプラインを使用して転送するログタイプ (applicationinfrastructure または audit) を指定します。
    12
    このパイプラインでログを転送する時に使用する出力の名前を指定します。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.