第7章 ログの外部のサードパーティーロギングシステムへの転送

デフォルトで、ロギングシステムは ClusterLogging カスタムリソースに定義されるデフォルトの内部 Elasticsearch ログストアにコンテナーおよびインフラストラクチャーログを送信します。ただし、監査ログは内部ストアに送信しません。セキュアなストレージを提供しないためです。このデフォルト設定が要件を満たす場合には、クラスターログフォワーダーを設定する必要はありません。

ログを他のログアグリゲーターに送信するには、OpenShift Container Platform クラスターログフォワーダーを使用します。この API を使用すると、コンテナー、インフラストラクチャーおよび監査ログをクラスター内外の特定のエンドポイントに送信できます。さらに、異なるタイプのログをさまざまなシステムに送信できるため、さまざまなユーザーがそれぞれのタイプにアクセスできます。また、Transport Layer Security (TLS) のサポートを有効にして、組織の要件に合わせてログを安全に送信することもできます。

注記

監査ログをデフォルトの内部 Elasticsearch ログストアに送信するには、監査ログのログストアへの転送 で説明されているようにクラスターログフォワーダーを使用します。

ログを外部に転送する場合、ログサブシステムは Fluentd 設定マップを作成または変更して、目的のプロトコルを使用してログを送信します。外部ログアグリゲーターでプロトコルを設定する必要があります。

重要

同じクラスターで設定マップのメソッドおよびクラスターログフォワーダーを使用することはできません。

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

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

output

定義するログデータの宛先、またはログの送信先です。出力は以下のいずれかのタイプになります。

  • elasticsearch。外部 Elasticsearch インスタンス。elasticsearch 出力では、TLS 接続を使用できます。
  • fluentdForward。Fluentd をサポートする外部ログ集計ソリューション。このオプションは Fluentd forward プロトコルを使用します。fluentForward 出力は TCP または TLS 接続を使用でき、シークレットに shared_key フィールドを指定して共有キーの認証をサポートします。共有キーの認証は、TLS の有無に関係なく使用できます。
  • syslog。syslog RFC3164 または RFC5424 プロトコルをサポートする外部ログ集計ソリューション。syslog 出力は、UDP、TCP、または TLS 接続を使用できます。
  • cloudwatch.Amazon Web Services (AWS) がホストするモニターリングおよびログストレージサービスである Amazon CloudWatch。
  • loki。Loki: 水平方向にスケーラブルで可用性の高いマルチテナントログ集計システム。
  • kafka。Kafka ブローカー。kafka 出力は TCP または TLS 接続を使用できます。
  • default。内部 OpenShift Container Platform Elasticsearch インスタンス。デフォルトの出力を設定する必要はありません。default 出力を設定する場合、default 出力は Red Hat OpenShift Logging Operator 用に予約されるため、エラーメッセージが送信されます。
パイプライン

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

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

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

input

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

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

Secret
ユーザー資格情報などの機密データを含む Key:Value マップ。

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

  • ClusterLogForwarder CR オブジェクトが存在する場合に、default 出力のあるパイプラインがない限り、ログはデフォルト Elasticsearch インスタンスに転送されません。
  • デフォルトで、ロギングシステムは ClusterLogging カスタムリソースに定義されるデフォルトの内部 Elasticsearch ログストアにコンテナーおよびインフラストラクチャーログを送信します。ただし、監査ログは内部ストアに送信しません。セキュアなストレージを提供しないためです。このデフォルト設定が要件を満たす場合には、ログ転送 API を設定する必要はありません。
  • ログタイプのパイプラインを定義しない場合、未定義タイプのログはドロップされます。たとえば、application および audit タイプのパイプラインを指定するものの、infrastructure タイプのパイプラインを指定しない場合、infrastructure ログはドロップされます。
  • ClusterLogForwarder カスタムリソース (CR) で出力の複数のタイプを使用し、ログを複数の異なるプロトコルをサポートするサーバーに送信できます。
  • 内部 OpenShift Container Platform Elasticsearch インスタンスは、監査ログのセキュアなストレージを提供しません。監査ログを転送するシステムが組織および政府の規制に準拠しており、適切にセキュリティーが保護されていることを確認することが推奨されています。ロギングサブシステムはこれらの規制に準拠していません。

以下の例では、監査ログをセキュアな外部 Elasticsearch インスタンスに転送し、インフラストラクチャーログをセキュアでない外部 Elasticsearch インスタンスに、アプリケーションログを Kafka ブローカーに転送し、アプリケーションログを my-apps-logs プロジェクトから内部 Elasticsearch インスタンスに転送します。

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

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance 1
  namespace: openshift-logging 2
spec:
  outputs:
   - name: elasticsearch-secure 3
     type: "elasticsearch"
     url: https://elasticsearch.secure.com:9200
     secret:
        name: elasticsearch
   - name: elasticsearch-insecure 4
     type: "elasticsearch"
     url: http://elasticsearch.insecure.com:9200
   - name: kafka-app 5
     type: "kafka"
     url: tls://kafka.secure.com:9093/app-topic
  inputs: 6
   - name: my-app-logs
     application:
        namespaces:
        - my-project
  pipelines:
   - name: audit-logs 7
     inputRefs:
      - audit
     outputRefs:
      - elasticsearch-secure
      - default
     parse: json 8
     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
ClusterLogForwarder CR の名前は instance である必要があります。
2
ClusterLogForwarder CR の namespace は openshift-logging である必要があります。
3
シークレットとセキュアな URL を使用したセキュアな Elasticsearch 出力の設定。
  • 出力を記述する名前。
  • 出力のタイプ: elasticsearch。
  • 接頭辞を含む、有効な絶対 URL としての Elasticsearch インスタンスのセキュアな URL およびポート。
  • TLS 通信のエンドポイントで必要なシークレット。シークレットは openshift-logging プロジェクトに存在する必要があります。
4
非セキュアな Elasticsearch 出力の設定:
  • 出力を記述する名前。
  • 出力のタイプ: elasticsearch。
  • 接頭辞を含む、有効な絶対 URL として Elasticsearch インスタンスのセキュアではない URL およびポート。
5
セキュアな URL を介したクライアント認証 TLS 通信を使用した Kafka 出力の設定
  • 出力を記述する名前。
  • 出力のタイプ: kafka。
  • Kafka ブローカーの URL およびポートを、接頭辞を含む有効な絶対 URL として指定します。
6
my-project namespace からアプリケーションログをフィルターするための入力の設定。
7
監査ログをセキュアな外部 Elasticsearch インスタンスに送信するためのパイプラインの設定。
  • パイプラインを説明する名前。
  • inputRefs はログタイプです (例: audit)。
  • outputRefs は使用する出力の名前です。この例では、elasticsearch-secure はセキュアな Elasticsearch インスタンスに転送され、default は内部 Elasticsearch インスタンスに転送されます。
  • オプション: ログに追加する複数のラベル。
8
オプション: 構造化された JSON ログエントリーを structured フィールドの JSON オブジェクトとして転送するかどうかを指定します。ログエントリーに有効な構造化された JSON が含まれる必要があります。そうでない場合は、OpenShift Logging は 構造化 フィールドを削除し、代わりにログエントリーをデフォルトのインデックス app-00000x に送信します。
9
オプション: 文字列。ログに追加する 1 つまたは複数のラベル。"true" などの引用値は、ブール値としてではなく、文字列値として認識されるようにします。
10
インフラストラクチャーログをセキュアでない外部 Elasticsearch インスタンスに送信するためのパイプラインの設定。
11
my-project プロジェクトから内部 Elasticsearch インスタンスにログを送信するためのパイプラインの設定。
  • パイプラインを説明する名前。
  • inputRefs は特定の入力 my-app-logs です。
  • outputRefs は default です。
  • オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
12
パイプライン名がない場合にログを Kafka ブローカーに送信するためのパイプラインの設定。
  • inputRefs はログタイプです (例: application)。
  • outputRefs は使用する出力の名前です。
  • オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

外部ログアグリゲーターが利用できない場合の Fluentd のログの処理

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

サポート対象の認証キー

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

Transport Layer Security (TLS)

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

  • tls.crt:(文字列) クライアント証明書を含むファイル名。相互認証を有効にします。tls.key が必要です。
  • tls.key:(文字列) クライアント証明書のロックを解除するための秘密鍵を含むファイル名。tls.crt が必要です。
  • 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 です。

7.1.1. シークレットの作成

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

$ oc create secret generic -n openshift-logging <my-secret> \
 --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>
注記

最良の結果を得るには、一般的な秘密または不透明なシークレットをお勧めします。