9.4. ログ転送の設定
デフォルトで、ロギングは ClusterLogging
カスタムリソースで定義されているデフォルトの内部ログストアにコンテナーとインフラストラクチャーのログを送信します。ただし、監査ログは内部ストアに送信しません。セキュアなストレージを提供しないためです。このデフォルト設定が要件を満たす場合は、クラスターログフォワーダーを設定する必要はありません。
監査ログを内部 Elasticsearch ログストアに送信するには、監査ログのログストアへの転送 で説明されているように、クラスターログフォワーダーを使用します。
9.4.1. ログのサードパーティーシステムへの転送
OpenShift Container Platform クラスターの内外の特定のエンドポイントにログを送信するには、 ClusterLogForwarder
カスタムリソース (CR) で出力とパイプラインの組み合わせを指定します。入力 を使用して、特定のプロジェクトに関連付けられたアプリケーションログをエンドポイントに転送することもできます。認証は Kubernetesシークレットオブジェクトによって提供されます。
- パイプライン
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 labels: secure: "true" 8 datacenter: "east" - name: infrastructure-logs 9 inputRefs: - infrastructure outputRefs: - elasticsearch-insecure labels: datacenter: "west" - name: my-app 10 inputRefs: - my-app-logs outputRefs: - default - inputRefs: 11 - 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
- オプション: 文字列。ログに追加する 1 つまたは複数のラベル。"true" などの引用値は、ブール値としてではなく、文字列値として認識されるようにします。
- 9
- インフラストラクチャーログをセキュアでない外部 Elasticsearch インスタンスに送信するためのパイプラインの設定。
- 10
my-project
プロジェクトから内部 Elasticsearch インスタンスにログを送信するためのパイプラインの設定。- パイプラインを説明する名前。
-
inputRefs
は特定の入力my-app-logs
です。 -
outputRefs
はdefault
です。 - オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
- 11
- パイプライン名がない場合にログを 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 機能が有効になります。-
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 です。
-
9.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 シークレットを使用することを推奨します。
9.4.2. ログフォワーダーの作成
ログフォワーダーを作成するには、サービスアカウントが収集できるログ入力の種類を指定する ClusterLogForwarder
CR を作成する必要があります。ログを転送できる出力を指定することもできます。ClusterLogForwarder
CR は、instance
という名前で openshift-logging
namespace に作成する必要があります。
openshift-logging
namespace に対する管理者権限が必要です。
ClusterLogForwarder リソースの例
apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: <log_forwarder_name> 1 namespace: <log_forwarder_namespace> 2 spec: # ... pipelines: - inputRefs: - <log_type> 3 outputRefs: - <output_name> 4 outputs: - name: <output_name> 5 type: <output_type> 6 url: <log_output_url> 7 # ...
- 1
- CR の名前は
instance
である必要があります。 - 2
- CR namespace は
openshift-logging
である必要があります。 - 3
- 収集されるログのタイプ。このフィールドの値は、監査ログの場合は
audit
、アプリケーションログの場合はapplication
、インフラストラクチャーログの場合はinfrastructure
、またはアプリケーションに定義された指定の入力になります。 - 4 5
- ログの転送先の出力の名前。
- 6
- ログの転送先の出力のタイプ。このフィールドの値は、
default
、loki
、kafka
、elasticsearch
、fluentdForward
、syslog
、またはCloudwatch
です。 - 7
- ログの転送先の出力の URL。
9.4.3. 複数行の例外検出の有効化
コンテナーログの複数行のエラー検出を有効にします。
この機能を有効にすると、パフォーマンスに影響が出る可能性があり、追加のコンピューティングリソースや代替のロギングソリューションが必要になる場合があります。
ログパーサーは頻繁に、同じ例外の個別の行を別々の例外として誤って識別します。その結果、余分なログエントリーが発生し、トレースされた情報が不完全または不正確な状態で表示されます。
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) に、値がtrue
のdetectMultilineErrors
フィールドが含まれていることを確認します。
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
9.4.3.1. 詳細
ログメッセージが例外スタックトレースを形成する連続したシーケンスとして表示される場合、それらは単一の統合ログレコードに結合されます。最初のログメッセージの内容は、シーケンス内のすべてのメッセージフィールドの連結コンテンツに置き換えられます。
言語 | Fluentd | Vector |
---|---|---|
Java | ✓ | ✓ |
JS | ✓ | ✓ |
Ruby | ✓ | ✓ |
Python | ✓ | ✓ |
golang | ✓ | ✓ |
PHP | ✓ | |
Dart | ✓ | ✓ |
9.4.3.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>
9.4.4. ログの Google Cloud Platform (GCP) への転送
内部のデフォルトの OpenShift Container Platform ログストアに加えて、またはその代わりに、ログを Google Cloud Logging に転送できます。
この機能を Fluentd で使用することはサポートされていません。
前提条件
- Red Hat OpenShift Logging Operator 5.5.1 以降
手順
Google サービスアカウントキー を使用してシークレットを作成します。
$ oc -n openshift-logging create secret generic gcp-secret --from-file google-application-credentials.json=<your_service_account_key_file.json>
以下のテンプレートを使用して、
ClusterLogForwarder
カスタムリソース YAML を作成します。apiVersion: "logging.openshift.io/v1" kind: "ClusterLogForwarder" metadata: name: "instance" namespace: "openshift-logging" spec: outputs: - name: gcp-1 type: googleCloudLogging secret: name: gcp-secret googleCloudLogging: projectId : "openshift-gce-devel" 1 logId : "app-gcp" 2 pipelines: - name: test-app inputRefs: 3 - application outputRefs: - gcp-1
- 1
- ログを保存する GCP リソース階層 の場所に応じて、
projectId
、folderId
、organizationId
、またはbillingAccountId
フィールドとそれに対応する値を設定します。 - 2
- Log Entry の
logName
フィールドに追加する値を設定します。 - 3
- パイプラインを使用して転送するログタイプ (
application
、infrastructure
、またはaudit
) を指定します。
9.4.5. ログの Splunk への転送
内部のデフォルトの OpenShift Container Platform ログストアに加えて、またはその代わりに、Splunk HTTP Event Collector (HEC) にログを転送できます。
この機能を Fluentd で使用することはサポートされていません。
前提条件
- Red Hat OpenShift Logging Operator 5.6 以降
-
コレクターとして
vector
が指定されたClusterLogging
インスタンス - Base64 でエンコードされた Splunk HEC トークン
手順
Base64 でエンコードされた Splunk HEC トークンを使用してシークレットを作成します。
$ oc -n openshift-logging create secret generic vector-splunk-secret --from-literal hecToken=<HEC_Token>
以下のテンプレートを使用して、
ClusterLogForwarder
カスタムリソース (CR) を作成または編集します。apiVersion: "logging.openshift.io/v1" kind: "ClusterLogForwarder" metadata: name: "instance" 1 namespace: "openshift-logging" 2 spec: outputs: - name: splunk-receiver 3 secret: name: vector-splunk-secret 4 type: splunk 5 url: <http://your.splunk.hec.url:8088> 6 pipelines: 7 - inputRefs: - application - infrastructure name: 8 outputRefs: - splunk-receiver 9
- 1
- ClusterLogForwarder CR の名前は
instance
である必要があります。 - 2
- ClusterLogForwarder CR の namespace は
openshift-logging
である必要があります。 - 3
- 出力の名前を指定します。
- 4
- HEC トークンが含まれるシークレットの名前を指定します。
- 5
- 出力タイプを
splunk
として指定します。 - 6
- Splunk HEC の URL (ポートを含む) を指定します。
- 7
- パイプラインを使用して転送するログタイプ (
application
、infrastructure
、またはaudit
) を指定します。 - 8
- オプション: パイプラインの名前を指定します。
- 9
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
9.4.6. HTTP 経由でのログ転送
HTTP 経由でのログ転送は、Fluentd と Vector ログコレクターの両方でサポートされています。有効にするには、ClusterLogForwarder
カスタムリソース (CR) の出力タイプを http
に指定します。
手順
以下のテンプレートを使用して、
ClusterLogForwarder
CR を作成または編集します。ClusterLogForwarder CR の例
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogForwarder" metadata: name: "instance" namespace: "openshift-logging" spec: outputs: - name: httpout-app type: http url: 1 http: headers: 2 h1: v1 h2: v2 method: POST secret: name: 3 tls: insecureSkipVerify: 4 pipelines: - name: inputRefs: - application outputRefs: - 5
9.4.7. 特定のプロジェクトからのアプリケーションログの転送
内部ログストアの使用に加えて、またはその代わりに、アプリケーションログのコピーを特定のプロジェクトから外部ログアグリゲータに転送できます。また、外部ログアグリゲーターを OpenShift Container Platform からログデータを受信できるように設定する必要もあります。
アプリケーションログのプロジェクトからの転送を設定するには、プロジェクトから少なくとも 1 つの入力で ClusterLogForwarder
カスタムリソース (CR) を作成し、他のログアグリゲーターのオプション出力、およびそれらの入出力を使用するパイプラインを作成する必要があります。
前提条件
- 指定されたプロトコルまたは形式を使用してロギングデータを受信するように設定されたロギングサーバーが必要です。
手順
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
- 出力タイプ:
elasticsearch
、fluentdForward
、syslog
、またはkafka
。 - 5
- 有効な絶対 URL としての外部ログアグリゲーターの URL とポート。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。
- 6
tls
接頭辞を使用する場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットはopenshift-logging
プロジェクトに存在し、 tls.crt、 tls.key、 および ca-bundle.crt キーが含まれる必要があります。これらは、それぞれが表す証明書を参照します。- 7
- 指定されたプロジェクトからアプリケーションログをフィルターするための入力の設定。
- 8
- namespace が指定されていない場合、ログはすべての namespace から収集されます。
- 9
- パイプライン設定は、名前付き入力から名前付き出力にログを送信します。この例では、
forward-to-fluentd-insecure
という名前のパイプラインは、my-app-logs
という名前の入力からfluentd-server-insecure
という名前の出力にログを転送します。 - 10
- 入力のリスト。
- 11
- 使用する出力の名前。
- 12
- オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
- 13
- ログを他のログアグリゲーターに送信するためのパイプラインの設定。
- オプション: パイプラインの名前を指定します。
-
パイプラインを使用して転送するログタイプ (
application
、infrastructure
またはaudit
) を指定します。 - このパイプラインでログを転送する時に使用する出力の名前を指定します。
-
オプション: デフォルトのログストアにログを転送するための
default
出力を指定します。 - オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
- 14
- この設定を使用すると、すべての namespace からのアプリケーションログが収集されることに注意してください。
次のコマンドを実行して、
ClusterLogForwarder
CR を適用します。$ oc apply -f <filename>.yaml
9.4.8. 特定の Pod からのアプリケーションログの転送
クラスター管理者は、Kubernetes Pod ラベルを使用して特定の Pod からログデータを収集し、これをログコレクターに転送できます。
アプリケーションがさまざまな namespace の他の Pod と共に実行される Pod で設定されるとします。これらの Pod にアプリケーションを識別するラベルがある場合は、それらのログデータを収集し、特定のログコレクターに出力できます。
Pod ラベルを指定するには、1 つ以上の matchLabels
のキー/値のペアを使用します。複数のキー/値のペアを指定する場合、Pod は選択されるそれらすべてに一致する必要があります。
手順
ClusterLogForwarder
CR オブジェクトを定義する YAML ファイルを作成または編集します。ファイルで、以下の例が示すようにinputs[].name.application.selector.matchLabels
の下で単純な等価ベース (Equality-based) のセレクターを使用して Pod ラベルを指定します。ClusterLogForwarder
CR YAML ファイルのサンプルapiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 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 - default ...
- 1
ClusterLogForwarder
CR の名前はinstance
である必要があります。- 2
ClusterLogForwarder
CR の namespace はopenshift-logging
である必要があります。- 3
inputs[].name
から 1 つ以上のコンマ区切りの値を指定します。- 4
outputs[]
から 1 つ以上のコンマ区切りの値を指定します。- 5
- Pod ラベルの一意のセットを持つ各アプリケーションの一意の
inputs[].name
を定義します。 - 6
- 収集するログデータを持つ Pod ラベルのキー/値のペアを指定します。キーだけではなく、キーと値の両方を指定する必要があります。Pod を選択するには、Pod はすべてのキーと値のペアと一致する必要があります。
- 7
- オプション: namespace を 1 つ以上指定します。
- 8
- ログデータを転送する 1 つ以上の出力を指定します。ここで表示されるオプションの
default
出力はログデータを内部 Elasticsearch インスタンスに送信します。
-
オプション: ログデータの収集を特定の namespace に制限するには、前述の例のように
inputs[].name.application.namespaces
を使用します。 オプション: 異なる Pod ラベルを持つ追加のアプリケーションから同じパイプラインにログデータを送信できます。
-
Pod ラベルの一意の組み合わせごとに、表示されるものと同様の追加の
inputs[].name
セクションを作成します。 -
このアプリケーションの Pod ラベルに一致するように、
selectors
を更新します。 新規の
inputs[].name
値をinputRefs
に追加します。以下に例を示します。- inputRefs: [ myAppLogData, myOtherAppLogData ]
-
Pod ラベルの一意の組み合わせごとに、表示されるものと同様の追加の
CR オブジェクトを作成します。
$ oc create -f <file-name>.yaml
関連情報
-
Kubernetes の
matchLabels
の詳細は、セットベースの要件をサポートするリソース を参照してください。
9.4.9. 外部 Loki ロギングシステムへのログ転送
デフォルトのログストアに加えて、またはその代わりに、外部の Loki ロギングしすてむにログを転送できます。
Loki へのログ転送を設定するには、Loki の出力と、出力を使用するパイプラインで ClusterLogForwarder
カスタムリソース (CR) を作成する必要があります。Loki への出力は HTTP (セキュアでない) または HTTPS (セキュアな HTTP) 接続を使用できます。
前提条件
-
CR の
url
フィールドで指定する URL で Loki ロギングシステムが実行されている必要がある。
手順
ClusterLogForwarder
CR オブジェクトを定義する YAML ファイルを作成または編集します。apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: loki-insecure 3 type: "loki" 4 url: http://loki.insecure.com:3100 5 loki: tenantKey: kubernetes.namespace_name labelKeys: - kubernetes.labels.foo - name: loki-secure 6 type: "loki" url: https://loki.secure.com:3100 secret: name: loki-secret 7 loki: tenantKey: kubernetes.namespace_name 8 labelKeys: - kubernetes.labels.foo 9 pipelines: - name: application-logs 10 inputRefs: 11 - application - audit outputRefs: 12 - loki-secure
- 1
ClusterLogForwarder
CR の名前はinstance
である必要があります。- 2
ClusterLogForwarder
CR の namespace はopenshift-logging
である必要があります。- 3
- 出力の名前を指定します。
- 4
- タイプを
loki
として指定します。 - 5
- Loki システムの URL およびポートを有効な絶対 URL として指定します。
http
(セキュアでない) プロトコルまたはhttps
(セキュアな HTTP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。HTTP(S) 通信用の Loki のデフォルトポートは 3100 です。 - 6
- セキュアな接続では、
シークレット
を指定して、認証するhttps
またはhttp
URL を指定できます。 - 7
https
接頭辞の場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定します。シークレットはopenshift-logging
プロジェクトに存在する必要があり、それが表す証明書を指すca-bundle.crt
鍵が含まれている必要があります。それ以外の場合、http
およびhttps
接頭辞の場合は、ユーザー名とパスワードを含むシークレットを指定できます。詳細は、Example: Setting secret that contains a username and password.を参照してください。- 8
- オプション: メタデータキーフィールドを指定して、Loki の
TenantID
フィールドの値を生成します。たとえば、tenantKey: kubernetes.namespace_name
を設定すると、Kubernetes namespace の名前を Loki のテナント ID の値として使用します。他にどのログレコードフィールドを指定できるかを確認するには、以下の Additional resources セクションの Log Record Fields リンクを参照してください。 - 9
- オプション: デフォルトの Loki ラベルを置き換えるメタデータフィールドキーのリストを指定します。loki ラベル名は、正規表現
[a-zA-Z_:][a-zA-Z0-9_:]*
と一致する必要があります。ラベル名を形成するため、メタデータキーの無効な文字は_
に置き換えられます。たとえば、kubernetes.labels.foo
meta-data キーは Loki ラベルkubernetes_labels_foo
になります。labelKeys
を設定しないと、デフォルト値は[log_type, kubernetes.namespace_name, kubernetes.pod_name, kubernetes_host]
です。Loki で指定可能なラベルのサイズと数に制限があるため、ラベルのセットを小さくします。Configuring Loki, limits_config を参照してください。クエリーフィルターを使用して、ログレコードフィールドに基づいてクエリーを実行できます。 - 10
- オプション: パイプラインの名前を指定します。
- 11
- パイプラインを使用して転送するログタイプ (
application
、infrastructure
またはaudit
) を指定します。 - 12
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
注記Loki ではログストリームを正しくタイムスタンプで順序付ける必要があるため、
labelKeys
には指定しなくてもkubernetes_host
ラベルセットが常に含まれます。このラベルセットが含まれることで、各ストリームが 1 つのホストから発信されるので、ホストのクロック間の誤差が原因でタイムスタンプの順番が乱れないようになります。次のコマンドを実行して、
ClusterLogForwarder
CR オブジェクトを適用します。$ oc apply -f <filename>.yaml
関連情報
9.4.10. 外部 Elasticsearch インスタンスへのログの送信
内部ログストアに加えて、またはその代わりに外部の Elasticsearch インスタンスにログを転送できます。外部ログアグリゲーターを OpenShift Container Platform からログデータを受信するように設定する必要があります。
外部 Elasticsearch インスタンスへのログ転送を設定するには、そのインスタンスへの出力および出力を使用するパイプラインで ClusterLogForwarder
カスタムリソース (CR) を作成する必要があります。外部 Elasticsearch 出力では、HTTP(セキュアでない) または HTTPS(セキュアな HTTP) 接続を使用できます。
外部 Elasticsearch インスタンスと内部 Elasticsearch インスタンスの両方にログを転送するには、出力および外部インスタンスへのパイプライン、および default
出力を使用してログを内部インスタンスに転送するパイプラインを作成します。
ログを内部 Elasticsearch インスタンスのみに転送する必要がある場合は、ClusterLogForwarder
CR を作成する必要はありません。
前提条件
- 指定されたプロトコルまたは形式を使用してロギングデータを受信するように設定されたロギングサーバーが必要です。
手順
ClusterLogForwarder
CR を定義する YAML ファイルを作成または編集します。ClusterLogForwarder
CR の例apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: elasticsearch-example 3 type: elasticsearch 4 elasticsearch: version: 8 5 url: http://elasticsearch.example.com:9200 6 secret: name: es-secret 7 pipelines: - name: application-logs 8 inputRefs: 9 - application - audit outputRefs: - elasticsearch-example 10 - default 11 labels: myLabel: "myValue" 12 # ...
- 1
ClusterLogForwarder
CR の名前はinstance
である必要があります。- 2
ClusterLogForwarder
CR の namespace はopenshift-logging
である必要があります。- 3
- 出力の名前を指定します。
- 4
elasticsearch
タイプを指定します。- 5
- Elasticsearch バージョンを指定します。これは
6
、7
、または8
のいずれかになります。 - 6
- 外部 Elasticsearch インスタンスの URL およびポートを有効な絶対 URL として指定します。
http
(セキュアでない) プロトコルまたはhttps
(セキュアな HTTP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。 - 7
https
接頭辞の場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定します。シークレットには、それが表す証明書を指すca-bundle.crt
鍵が含まれている必要があります。それ以外の場合、http
およびhttps
接頭辞の場合は、ユーザー名とパスワードを含むシークレットを指定できます。シークレットはopenshift-logging
プロジェクトに存在する必要があります。詳細は、「例: ユーザー名とパスワードを含むシークレットの設定」を参照してください。- 8
- オプション: パイプラインの名前を指定します。
- 9
- パイプラインを使用して転送するログタイプ (
application
、infrastructure
またはaudit
) を指定します。 - 10
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
- 11
- オプション: ログを内部 Elasticsearch インスタンスに送信するために
default
出力を指定します。 - 12
- オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
ClusterLogForwarder
CR を適用します。$ oc apply -f <filename>.yaml
例: ユーザー名とパスワードを含むシークレットの設定
ユーザー名とパスワードを含むシークレットを使用して、外部 Elasticsearch インスタンスへのセキュアな接続を認証できます。
たとえば、サードパーティーが Elasticsearch インスタンスを操作するため、相互 TLS (mTLS) キーを使用できない場合に、HTTP または HTTPS を使用してユーザー名とパスワードを含むシークレットを設定できます。
以下の例のような
Secret
YAML ファイルを作成します。username
およびpassword
フィールドに base64 でエンコードされた値を使用します。シークレットタイプはデフォルトで opaque です。apiVersion: v1 kind: Secret metadata: name: openshift-test-secret data: username: <username> password: <password> # ...
シークレットを作成します。
$ oc create secret -n openshift-logging openshift-test-secret.yaml
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
になります。CR オブジェクトを適用します。
$ oc apply -f <filename>.yaml
9.4.11. Fluentd 転送プロトコルを使用したログの転送
Fluentd forward プロトコルを使用して、デフォルトの Elasticsearch ログストアの代わり、またはこれに加えてプロトコルを受け入れるように設定された外部ログアグリゲーターにログのコピーを送信できます。外部ログアグリゲーターを OpenShift Container Platform からログを受信するように設定する必要があります。
forward プロトコルを使用してログ転送を設定するには、Fluentd サーバーに対する 1 つ以上の出力およびそれらの出力を使用するパイプラインと共に ClusterLogForwarder
カスタムリース (CR) を作成します。Fluentd の出力は TCP(セキュアでない) または TLS(セキュアな TCP) 接続を使用できます。
前提条件
- 指定されたプロトコルまたは形式を使用してロギングデータを受信するように設定されたロギングサーバーが必要です。
手順
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
- パイプラインを使用して転送するログタイプ (
application
、infrastructure
またはaudit
) を指定します。 - 9
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
- 10
- オプション: ログを内部 Elasticsearch インスタンスに転送するために
default
出力を指定します。 - 11
- オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
- 12
- オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。
- パイプラインを説明する名前。
-
inputRefs
は、そのパイプラインを使用して転送するログタイプです (application
、infrastructure
、またはaudit
)。 -
outputRefs
は使用する出力の名前です。 - オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
CR オブジェクトを作成します。
$ oc create -f <file-name>.yaml
9.4.11.1. Logstash が fluentd からデータを取り込むためのナノ秒精度の有効化
Logstash が fluentd からログデータを取り込むには、Logstash 設定ファイルでナノ秒精度を有効にする必要があります。
手順
-
Logstash 設定ファイルで、
nanosecond_precision
をtrue
に設定します。
Logstash 設定ファイルの例
input { tcp { codec => fluent { nanosecond_precision => true } port => 24114 } } filter { } output { stdout { codec => rubydebug } }
9.4.12. syslog プロトコルを使用したログの転送
syslog RFC3164 または RFC5424 プロトコルを使用して、デフォルトの Elasticsearch ログストアの代わり、またはこれに加えてプロトコルを受け入れるように設定された外部ログアグリゲーターにログのコピーを送信できます。syslog サーバーなど、外部ログアグリゲーターを OpenShift Container Platform からログを受信するように設定する必要があります。
syslog プロトコルを使用してログ転送を設定するには、syslog サーバーに対する 1 つ以上の出力およびそれらの出力を使用するパイプラインと共に ClusterLogForwarder
カスタムリース (CR) を作成します。syslog 出力では、UDP、TCP、または TLS 接続を使用できます。
前提条件
- 指定されたプロトコルまたは形式を使用してロギングデータを受信するように設定されたロギングサーバーが必要です。
手順
ClusterLogForwarder
CR オブジェクトを定義する YAML ファイルを作成または編集します。apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: rsyslog-east 3 type: syslog 4 syslog: 5 facility: local0 rfc: RFC3164 payloadKey: message severity: informational url: 'tls://rsyslogserver.east.example.com:514' 6 secret: 7 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 8 inputRefs: 9 - audit - application outputRefs: 10 - rsyslog-east - default 11 labels: secure: "true" 12 syslog: "east" - name: syslog-west 13 inputRefs: - infrastructure outputRefs: - rsyslog-west - default labels: syslog: "west"
- 1
ClusterLogForwarder
CR の名前はinstance
である必要があります。- 2
ClusterLogForwarder
CR の namespace はopenshift-logging
である必要があります。- 3
- 出力の名前を指定します。
- 4
syslog
タイプを指定します。- 5
- オプション: 以下にリスト表示されている syslog パラメーターを指定します。
- 6
- 外部 syslog インスタンスの URL およびポートを指定します。
udp
(セキュアでない)、tcp
(セキュアでない) プロトコル、またはtls
(セキュアな TCP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。 - 7
tls
接頭辞を使用する場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットはopenshift-logging
プロジェクトに存在する必要があり、それが表す証明書を指すca-bundle.crt
鍵が含まれている必要があります。- 8
- オプション: パイプラインの名前を指定します。
- 9
- パイプラインを使用して転送するログタイプ (
application
、infrastructure
またはaudit
) を指定します。 - 10
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
- 11
- オプション: ログを内部 Elasticsearch インスタンスに転送するために
default
出力を指定します。 - 12
- オプション: 文字列。ログに追加する 1 つまたは複数のラベル。"true" などの引用値は、ブール値としてではなく、文字列値として認識されるようにします。
- 13
- オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。
- パイプラインを説明する名前。
-
inputRefs
は、そのパイプラインを使用して転送するログタイプです (application
、infrastructure
、またはaudit
)。 -
outputRefs
は使用する出力の名前です。 - オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
CR オブジェクトを作成します。
$ oc create -f <filename>.yaml
9.4.12.1. メッセージ出力へのログソース情報の追加
AddLogSource
フィールドを ClusterLogForwarder
カスタムリソース (CR) に追加することで、namespace_name
、pod_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}
9.4.12.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 の場合は、
16
–23
またはlocal0
–local7
-
カーネルメッセージの場合は、
オプション:
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: 指定された接頭辞をタグから削除します。
9.4.12.3. 追加の RFC5424 syslog パラメーター
以下のパラメーターは RFC5424 に適用されます。
-
appName: APP-NAME は、ログを送信したアプリケーションを識別するフリーテキストの文字列です。
RFC5424
に対して指定する必要があります。 -
msgID: MSGID は、メッセージのタイプを識別するフリーテキスト文字列です。
RFC5424
に対して指定する必要があります。 -
procID: PROCID はフリーテキスト文字列です。値が変更される場合は、syslog レポートが中断していることを示します。
RFC5424
に対して指定する必要があります。
9.4.13. ログの Kafka ブローカーへの転送
デフォルトのログストアに加えて、またはその代わりに、外部の Kafka ブローカーにログを転送できます。
外部 Kafka インスタンスへのログ転送を設定するには、そのインスタンスへの出力を含む ClusterLogForwarder
カスタムリソース (CR) と、その出力を使用するパイプラインを作成する必要があります。出力に特定の Kafka トピックを追加するか、デフォルトを使用できます。Kafka の出力は TCP(セキュアでない) または TLS(セキュアな TCP) 接続を使用できます。
手順
ClusterLogForwarder
CR オブジェクトを定義する YAML ファイルを作成または編集します。apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: app-logs 3 type: kafka 4 url: tls://kafka.example.devlab.com:9093/app-topic 5 secret: name: kafka-secret 6 - name: infra-logs type: kafka url: tcp://kafka.devlab2.example.com:9093/infra-topic 7 - name: audit-logs type: kafka url: tls://kafka.qelab.example.com:9093/audit-topic secret: name: kafka-secret-qe pipelines: - name: app-topic 8 inputRefs: 9 - application outputRefs: 10 - app-logs labels: logType: "application" 11 - name: infra-topic 12 inputRefs: - infrastructure outputRefs: - infra-logs labels: logType: "infra" - name: audit-topic inputRefs: - audit outputRefs: - audit-logs - default 13 labels: logType: "audit"
- 1
ClusterLogForwarder
CR の名前はinstance
である必要があります。- 2
ClusterLogForwarder
CR の namespace はopenshift-logging
である必要があります。- 3
- 出力の名前を指定します。
- 4
kafka
タイプを指定します。- 5
- Kafka ブローカーの URL およびポートを有効な絶対 URL として指定し、オプションで特定のトピックで指定します。
tcp
(セキュアでない) プロトコルまたはtls
(セキュアな TCP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。 - 6
tls
接頭辞を使用する場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットはopenshift-logging
プロジェクトに存在する必要があり、それが表す証明書を指すca-bundle.crt
鍵が含まれている必要があります。- 7
- オプション: 非セキュアな出力を送信するには、URL の前に
tcp
の接頭辞を使用します。また、この出力のsecret
キーとそのname
を省略します。 - 8
- オプション: パイプラインの名前を指定します。
- 9
- パイプラインを使用して転送するログタイプ (
application
、infrastructure
またはaudit
) を指定します。 - 10
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
- 11
- オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
- 12
- オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。
- パイプラインを説明する名前。
-
inputRefs
は、そのパイプラインを使用して転送するログタイプです (application
、infrastructure
、またはaudit
)。 -
outputRefs
は使用する出力の名前です。 - オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
- 13
- オプション: ログを内部 Elasticsearch インスタンスに転送するために
default
を指定します。
オプション: 単一の出力を複数の 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 # ...
次のコマンドを実行して、
ClusterLogForwarder
CR を適用します。$ oc apply -f <filename>.yaml
9.4.14. ログの Amazon CloudWatch への転送
Amazon Web Services (AWS) がホストするモニタリングおよびログストレージサービスである Amazon CloudWatch にログを転送できます。デフォルトのログストアに加えて、またはログストアの代わりに、CloudWatch にログを転送できます。
CloudWatch へのログ転送を設定するには、CloudWatch の出力および出力を使用するパイプラインで ClusterLogForwarder
カスタムリソース (CR) を作成する必要があります。
手順
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=
シークレットを作成します。以下に例を示します。
$ oc apply -f cw-secret.yaml
ClusterLogForwarder
CR オブジェクトを定義する YAML ファイルを作成または編集します。このファイルに、シークレットの名前を指定します。以下に例を示します。apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: cw 3 type: cloudwatch 4 cloudwatch: groupBy: logType 5 groupPrefix: <group prefix> 6 region: us-east-2 7 secret: name: cw-secret 8 pipelines: - name: infra-logs 9 inputRefs: 10 - infrastructure - audit - application outputRefs: - cw 11
- 1
ClusterLogForwarder
CR の名前はinstance
である必要があります。- 2
ClusterLogForwarder
CR の namespace はopenshift-logging
である必要があります。- 3
- 出力の名前を指定します。
- 4
cloudwatch
タイプを指定します。- 5
- オプション: ログをグループ化する方法を指定します。
-
logType
は、ログタイプごとにロググループを作成します。 -
namespaceName
は、アプリケーションの namespace ごとにロググループを作成します。また、インフラストラクチャーおよび監査ログ用の個別のロググループも作成します。 -
namespaceUUID
は、アプリケーション namespace UUID ごとに新しいロググループを作成します。また、インフラストラクチャーおよび監査ログ用の個別のロググループも作成します。
-
- 6
- オプション: ロググループの名前に含まれるデフォルトの
infrastructureName
接頭辞を置き換える文字列を指定します。 - 7
- AWS リージョンを指定します。
- 8
- AWS 認証情報が含まれるシークレットの名前を指定します。
- 9
- オプション: パイプラインの名前を指定します。
- 10
- パイプラインを使用して転送するログタイプ (
application
、infrastructure
またはaudit
) を指定します。 - 11
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
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-7977k
は demo-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
groupBy
を namespaceName
に設定すると、アプリケーションロググループのみが影響を受けます。これは、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 オブジェクトを引き継ぐ予定の場合は、この例で説明されている方法を使用します。それ以外の場合は、前述の例: Naming log groups for application namespace name のセクションを参照してください。
アプリケーション 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
のロググループには影響しません。
9.4.15. STS 対応クラスターから Amazon CloudWatch へのログ転送
AWS Security Token Service (STS) が有効になっているクラスターの場合に、AWS サービスアカウントを手動で作成するか、Cloud Credential Operator (CCO) ユーティリティー ccoctl
を使用してクレデンシャルのリクエストを作成できます。
前提条件
- Red Hat OpenShift のロギング: 5.5 以降
手順
以下のテンプレートを使用して、
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
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 クラスターのインストール中に使用される名前と一致する必要があります。
作成したシークレットを適用します。
$ oc apply -f output/manifests/openshift-logging-<your_role_name>-credentials.yaml
ClusterLogForwarder
カスタムリソースを作成または編集します。apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: cw 3 type: cloudwatch 4 cloudwatch: groupBy: logType 5 groupPrefix: <group prefix> 6 region: us-east-2 7 secret: name: <your_role_name> 8 pipelines: - name: to-cloudwatch 9 inputRefs: 10 - infrastructure - audit - application outputRefs: - cw 11
- 1
ClusterLogForwarder
CR の名前はinstance
である必要があります。- 2
ClusterLogForwarder
CR の namespace はopenshift-logging
である必要があります。- 3
- 出力の名前を指定します。
- 4
cloudwatch
タイプを指定します。- 5
- オプション: ログをグループ化する方法を指定します。
-
logType
は、ログタイプごとにロググループを作成します。 -
namespaceName
は、アプリケーションの namespace ごとにロググループを作成します。インフラストラクチャーおよび監査ログは影響を受けず、logType
によってグループ化されたままになります。 -
namespaceUUID
は、アプリケーション namespace UUID ごとに新しいロググループを作成します。また、インフラストラクチャーおよび監査ログ用の個別のロググループも作成します。
-
- 6
- オプション: ロググループの名前に含まれるデフォルトの
infrastructureName
接頭辞を置き換える文字列を指定します。 - 7
- AWS リージョンを指定します。
- 8
- AWS 認証情報が含まれるシークレットの名前を指定します。
- 9
- オプション: パイプラインの名前を指定します。
- 10
- パイプラインを使用して転送するログタイプ (
application
、infrastructure
またはaudit
) を指定します。 - 11
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
9.4.16. 既存の AWS ロールを使用した AWS CloudWatch のシークレット作成
AWS の既存のロールがある場合は、oc create secret --from-literal
コマンドを使用して、STS で 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
関連情報