12.4. ログ転送の設定
ロギングデプロイメントでは、デフォルトでコンテナーおよびインフラストラクチャーのログは ClusterLogging カスタムリソース (CR) に定義された内部ログストアに転送されます。
セキュアなストレージを提供しないため、監査ログはデフォルトで内部ログストアに転送されません。お客様の責任において、監査ログを転送するシステムが組織および政府の規制に準拠し、適切に保護されていることを確認してください。
このデフォルト設定が要件を満たす場合、ClusterLogForwarder CR を設定する必要はありません。ClusterLogForwarder CR が存在する場合、default 出力を含むパイプラインが定義されている場合を除き、ログは内部ログストアに転送されません。
12.4.1. ログのサードパーティーシステムへの転送 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターの内外の特定のエンドポイントにログを送信するには、ClusterLogForwarder カスタムリソース (CR) で 出力 と パイプライン の組み合わせを指定します。入力 を使用して、特定のプロジェクトに関連付けられたアプリケーションログをエンドポイントに転送することもできます。認証は Kubernetes シークレット オブジェクトによって提供されます。
- pipeline
1 つのログタイプから 1 つまたは複数の出力への単純なルーティング、または送信するログを定義します。ログタイプは以下のいずれかになります。
-
application。クラスターで実行される、インフラストラクチャーコンテナーアプリケーションを除くユーザーアプリケーションによって生成されるコンテナーログ。 -
infrastructure。openshift*、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>
namespace: <log_forwarder_namespace>
spec:
serviceAccountName: <service_account_name>
outputs:
- name: elasticsearch-secure
type: "elasticsearch"
url: https://elasticsearch.secure.com:9200
secret:
name: elasticsearch
- name: elasticsearch-insecure
type: "elasticsearch"
url: http://elasticsearch.insecure.com:9200
- name: kafka-app
type: "kafka"
url: tls://kafka.secure.com:9093/app-topic
inputs:
- name: my-app-logs
application:
namespaces:
- my-project
pipelines:
- name: audit-logs
inputRefs:
- audit
outputRefs:
- elasticsearch-secure
- default
labels:
secure: "true"
datacenter: "east"
- name: infrastructure-logs
inputRefs:
- infrastructure
outputRefs:
- elasticsearch-insecure
labels:
datacenter: "west"
- name: my-app
inputRefs:
- my-app-logs
outputRefs:
- default
- inputRefs:
- application
outputRefs:
- kafka-app
labels:
datacenter: "south"
- 1
- レガシー実装では、CR 名は
instanceである必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。 - 2
- レガシー実装では、CR namespace は
openshift-loggingである必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。 - 3
- サービスアカウントの名前。サービスアカウントは、ログフォワーダーが
openshift-loggingnamespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。 - 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-projectnamespace からアプリケーションログをフィルターするための入力の設定。- 8
- 監査ログをセキュアな外部 Elasticsearch インスタンスに送信するためのパイプラインの設定。
- パイプラインを説明する名前。
-
inputRefsはログタイプです (例:audit)。 -
outputRefsは使用する出力の名前です。この例では、elasticsearch-secureはセキュアな Elasticsearch インスタンスに転送され、defaultは内部 Elasticsearch インスタンスに転送されます。 - オプション: ログに追加する複数のラベル。
- 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)
シークレットなしで 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 です。
-
12.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 シークレットを使用することを推奨します。