第7章 ログの外部のサードパーティーロギングシステムへの転送
デフォルトで、OpenShift Logging は ClusterLogging カスタムリソースに定義されるデフォルトの内部 Elasticsearch ログストアにコンテナーおよびインフラストラクチャーログを送信します。ただし、監査ログは内部ストアに送信しません。セキュアなストレージを提供しないためです。このデフォルト設定が要件を満たす場合には、クラスターログフォワーダーを設定する必要はありません。
ログを他のログアグリゲーターに送信するには、OpenShift Container Platform クラスターログフォワーダーを使用します。この API を使用すると、コンテナー、インフラストラクチャーおよび監査ログをクラスター内外の特定のエンドポイントに送信できます。さらに、異なるタイプのログをさまざまなシステムに送信できるため、さまざまなユーザーがそれぞれのタイプにアクセスできます。また、Transport Layer Security (TLS) のサポートを有効にして、組織の要件に合わせてログを安全に送信することもできます。
監査ログをデフォルトの内部 Elasticsearch ログストアに送信するには、監査ログのログストアへの転送 で説明されているようにクラスターログフォワーダーを使用します。
7.1. ログのサードパーティーシステムへの転送
クラスターログを外部サードパーティーシステムに転送するには、ClusterLogForwarder カスタムリソース (CR) に指定される 出力 および パイプライン を使用して、OpenShift Container Platform クラスター内外の特定のエンドポイントにログを送信します。入力 を使用して、特定のプロジェクトに関連付けられたアプリケーションログをエンドポイントに転送することもできます。
出力 は、定義するログデータの宛先、またはログの送信先です。出力は以下のいずれかのタイプになります。
-
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 用に予約されるため、エラーメッセージが送信されます。
出力 URL スキームに TLS(HTTPS、TLS、または UDPS) が必要な場合、TLS サーバー側の認証が有効になります。クライアント認証も有効にするには、出力で
openshift-loggingプロジェクトのシークレットに名前を指定する必要があります。シークレットには、tls.crt、 tls.key、および ca-bundle.crt のキーが含まれる必要があります。これらは、それぞれが表す証明書を参照します。-
パイプライン は、1 つのログタイプから 1 つまたは複数の出力への単純なルーティング、または送信するログを定義します。ログタイプは以下のいずれかになります。
-
application。クラスターで実行される、インフラストラクチャーコンテナーアプリケーションを除くユーザーアプリケーションによって生成されるコンテナーログ。 -
infrastructure。openshift*、kube*、またはdefaultプロジェクトで実行される Pod のコンテナーログおよびノードファイルシステムから取得されるジャーナルログ。 -
auditノード監査システム、auditd、Kubernetes API サーバー、OpenShift API サーバー、および OVN ネットワークで生成される監査ログ。
パイプラインで
key:valueペアを使用すると、アウトバウンドログメッセージにラベルを追加できます。たとえば、他のデータセンターに転送されるメッセージにラベルを追加したり、タイプ別にログにラベルを付けたりすることができます。オブジェクトに追加されるラベルもログメッセージと共に転送されます。-
- 入力 は、特定のプロジェクトに関連付けられるアプリケーションログをパイプラインに転送します。
パイプラインでは、inputRef パラメーターを使用して転送するログタイプと、outputRef パラメーターを使用してログを転送する場所を定義します。
次の点に注意してください。
-
ClusterLogForwarderCR オブジェクトが存在する場合に、default出力のあるパイプラインがない限り、ログはデフォルト Elasticsearch インスタンスに転送されません。 -
デフォルトで、OpenShift Logging は
ClusterLoggingカスタムリソースに定義されるデフォルトの内部 Elasticsearch ログストアにコンテナーおよびインフラストラクチャーログを送信します。ただし、監査ログは内部ストアに送信しません。セキュアなストレージを提供しないためです。このデフォルト設定が要件を満たす場合には、ログ転送 API を設定する必要はありません。 -
ログタイプのパイプラインを定義しない場合、未定義タイプのログはドロップされます。たとえば、
applicationおよびauditタイプのパイプラインを指定するものの、infrastructureタイプのパイプラインを指定しない場合、infrastructureログはドロップされます。 -
ClusterLogForwarderカスタムリソース (CR) で出力の複数のタイプを使用し、ログを複数の異なるプロトコルをサポートするサーバーに送信できます。 - 内部 OpenShift Container Platform Elasticsearch インスタンスは、監査ログのセキュアなストレージを提供しません。監査ログを転送するシステムが組織および政府の規制に準拠しており、適切にセキュリティーが保護されていることを確認することが推奨されています。OpenShift Logging はこれらの規制に準拠しません。
- キーやシークレット、サービスアカウント、ポートのオープン、またはグローバルプロキシー設定など、外部の宛先で必要となる可能性のある追加設定を作成し、維持する必要があります。
以下の例では、監査ログをセキュアな外部 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
ClusterLogForwarderCR の名前はinstanceである必要があります。- 2
ClusterLogForwarderCR の 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-projectnamespace からアプリケーションログをフィルターするための入力の設定。- 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>
最良の結果を得るには、一般的な秘密または不透明なシークレットをお勧めします。
