9.4. ログ転送の設定
ロギングデプロイメントでは、デフォルトでコンテナーおよびインフラストラクチャーのログは ClusterLogging
カスタムリソース (CR) に定義された内部ログストアに転送されます。
セキュアなストレージを提供しないため、監査ログはデフォルトで内部ログストアに転送されません。お客様の責任において、監査ログを転送するシステムが組織および政府の規制に準拠し、適切に保護されていることを確認してください。
このデフォルト設定が要件を満たす場合、ClusterLogForwarder
CR を設定する必要はありません。ClusterLogForwarder
CR が存在する場合、default
出力を含むパイプラインが定義されている場合を除き、ログは内部ログストアに転送されません。
9.4.1. ログのサードパーティーシステムへの転送
Red Hat OpenShift Service on AWS クラスターの内外の特定のエンドポイントにログを送信するには、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> 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
です。 -
outputRefs
はdefault
です。 - オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
- 12
- パイプライン名がない場合にログを Kafka ブローカーに送信するためのパイプラインの設定。
-
inputRefs
はログタイプです (例:application
)。 -
outputRefs
は使用する出力の名前です。 - オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
-
外部ログアグリゲーターが利用できない場合の Fluentd のログの処理
外部ロギングアグリゲーターが利用できず、ログを受信できない場合、Fluentd は継続してログを収集し、それらをバッファーに保存します。ログアグリゲーターが利用可能になると、バッファーされたログを含む、ログの転送が再開されます。バッファーが完全に一杯になると、Fluentd はログの収集を停止します。Red Hat OpenShift Service on AWS はログをローテーションし、それらを削除します。バッファーサイズを調整したり、永続ボリューム要求 (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 です。
-
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 でサービスアカウントも参照する必要があります。
クラスターでマルチログフォワーダー機能を使用している場合は、任意の名前を使用して、任意の 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
- ログの転送先の出力のタイプ。このフィールドの値は、
default
、loki
、kafka
、elasticsearch
、fluentdForward
、syslog
、またはcloudwatch
です。注記default
の出力タイプは、複数のログフォワーダーの実装ではサポートされていません。 - 6
- ログの転送先の出力の名前。
- 8
- ログの転送先の出力の URL。
9.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
(圧縮なし)、gzip
、snappy
、zlib
、またはzstd
です。Kafka の出力を使用している場合は、lz4
圧縮も使用できます。詳細は、「チューニング出力でサポートされる圧縮タイプ」の表を参照してください。- 3
- 出力への単一の送信操作の最大ペイロードの制限を指定します。
- 4
- 配信が失敗した後に次に再試行するまでの最小待機時間を指定します。この値は文字列であり、ミリ秒 (
ms
)、秒 (s
)、または分 (m
) を指定できます。 - 5
- 配信が失敗した後に次に再試行するまでの最大待機時間を指定します。この値は文字列であり、ミリ秒 (
ms
)、秒 (s
)、または分 (m
) を指定できます。
圧縮アルゴリズム | Splunk | Amazon Cloudwatch | Elasticsearch 8 | LokiStack | Apache Kafka | HTTP | Syslog | Google Cloud | Microsoft Azure Monitoring |
---|---|---|---|---|---|---|---|---|---|
| X | X | X | X | X | ||||
| X | X | X | X | |||||
| X | X | X | ||||||
| X | X | X | ||||||
| X |
9.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) に、値が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.4.1. 詳細
ログメッセージが例外スタックトレースを形成する連続したシーケンスとして表示される場合、それらは単一の統合ログレコードに結合されます。最初のログメッセージの内容は、シーケンス内のすべてのメッセージフィールドの連結コンテンツに置き換えられます。
言語 | Fluentd | Vector |
---|---|---|
Java | ✓ | ✓ |
JS | ✓ | ✓ |
Ruby | ✓ | ✓ |
Python | ✓ | ✓ |
golang | ✓ | ✓ |
PHP | ✓ | ✓ |
Dart | ✓ | ✓ |
9.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>
9.4.5. ログの Splunk への転送
内部のデフォルトの Red Hat OpenShift Service on AWS ログストアに加えて、またはその代わりに、ログを 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: <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
- パイプラインを使用して転送するログタイプ (
application
、infrastructure
、またはaudit
) を指定します。 - 9
- オプション: パイプラインの名前を指定します。
- 10
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
9.4.6. 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
- この値は、出力名と同じである必要があります。
9.4.7. 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
9.4.8. 特定のプロジェクトからのアプリケーションログの転送
内部ログストアの使用に加えて、またはその代わりに、アプリケーションログのコピーを特定のプロジェクトから外部ログアグリゲータに転送できます。また、外部ログアグリゲーターを Red Hat OpenShift Service on AWS からログデータを受信できるように設定する必要もあります。
アプリケーションログのプロジェクトからの転送を設定するには、プロジェクトから少なくとも 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.9. 特定の 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: <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 つ以上の出力を指定します。
-
オプション: ログデータの収集を特定の 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.10. API 監査フィルターの概要
OpenShift API サーバーは、API 呼び出しごとに、リクエスト、レスポンス、リクエスターの ID の詳細を示す監査イベントを生成するため、大量のデータが生成されます。API 監査フィルターはルールを使用して、重要でないイベントを除外してイベントサイズを減少できるようにし、監査証跡をより管理しやすくします。ルールは順番にチェックされ、最初の一致で停止をチェックします。イベントに含まれるデータ量は、level
フィールドの値によって決定されます。
-
None
: イベントはドロップされます。 -
Metadata
: 監査メタデータが含まれ、リクエストおよびレスポンスの本文は削除されます。 -
Request
: 監査メタデータとリクエスト本文が含まれ、レスポンス本文は削除されます。 -
RequestResponse
: メタデータ、リクエスト本文、レスポンス本文のすべてのデータが含まれます。レスポンス本文が非常に大きくなる可能性があります。たとえば、oc get pods -A
はクラスター内のすべての Pod の YAML 記述を含むレスポンス本文を生成します。
この機能は、ロギングのデプロイメントで Vector コレクターが設定されている場合にのみ使用できます。
ロギング 5.8 以降では、ClusterLogForwarder
カスタムリソース (CR) は標準の Kubernetes 監査ポリシー と同じ形式を使用しますが、次の追加機能を提供します。
- ワイルドカード
-
ユーザー、グループ、namespace、およびリソースの名前には、先頭または末尾に
*
アスタリスク文字を付けることができます。たとえば、namespaceopenshift-\*
はopenshift-apiserver
またはopenshift-authentication
と一致します。リソース\*/status
は、Pod/status
またはDeployment/status
と一致します。 - デフォルトのルール
ポリシーのルールに一致しないイベントは、以下のようにフィルターされます。
-
get
、list
、watch
などの読み取り専用システムイベントは破棄されます。 - サービスアカウントと同じ namespace 内で発生するサービスアカウント書き込みイベントはドロップされます。
- 他のすべてのイベントは、設定されたレート制限に従って転送されます。
-
これらのデフォルトを無効にするには、level
フィールドのみが含まれるルールでルールリストを終了するか、空のルールを追加します。
- 応答コードが省略される
-
省略する整数ステータスコードのリスト。
OmitResponseCodes
フィールドを使用して、イベントが作成されない HTTP ステータスコードのリストを使用して、応答の HTTP ステータスコードに基づいてイベントを削除できます。デフォルト値は[404, 409, 422, 429]
です。値が空のリスト[]
の場合、ステータスコードは省略されません。
ClusterLogForwarder
CR の監査ポリシーは、Red Hat OpenShift Service on AWS の監査ポリシーに加えて動作します。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
9.4.11. 外部 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: <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
- パイプラインを使用して転送するログタイプ (
application
、infrastructure
またはaudit
) を指定します。 - 13
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
注記Loki ではログストリームを正しくタイムスタンプで順序付ける必要があるため、
labelKeys
には指定しなくてもkubernetes_host
ラベルセットが常に含まれます。このラベルセットが含まれることで、各ストリームが 1 つのホストから発信されるので、ホストのクロック間の誤差が原因でタイムスタンプの順番が乱れないようになります。次のコマンドを実行して、
ClusterLogForwarder
CR オブジェクトを適用します。$ oc apply -f <filename>.yaml
関連情報
9.4.12. 外部 Elasticsearch インスタンスへのログの送信
内部ログストアに加えて、またはその代わりに外部の Elasticsearch インスタンスにログを転送できます。外部ログアグリゲーターを Red Hat OpenShift Service on AWS からログデータを受信するように設定する必要があります。
外部 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: <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 バージョンを指定します。これは
6
、7
、または8
のいずれかになります。 - 7
- 外部 Elasticsearch インスタンスの URL およびポートを有効な絶対 URL として指定します。
http
(セキュアでない) プロトコルまたはhttps
(セキュアな HTTP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。 - 8
https
接頭辞の場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定します。シークレットには、それが表す証明書を指すca-bundle.crt
鍵が含まれている必要があります。それ以外の場合、http
およびhttps
接頭辞の場合は、ユーザー名とパスワードを含むシークレットを指定できます。レガシー実装では、シークレットはopenshift-logging
プロジェクトに存在する必要があります。詳細は、「例: ユーザー名とパスワードを含むシークレットの設定」を参照してください。- 9
- オプション: パイプラインの名前を指定します。
- 10
- パイプラインを使用して転送するログタイプ (
application
、infrastructure
またはaudit
) を指定します。 - 11
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
- 12
- オプション: ログを内部 Elasticsearch インスタンスに送信するために
default
出力を指定します。 - 13
- オプション: 文字列。ログに追加する 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.13. Fluentd 転送プロトコルを使用したログの転送
Fluentd forward プロトコルを使用して、デフォルトの Elasticsearch ログストアの代わり、またはこれに加えてプロトコルを受け入れるように設定された外部ログアグリゲーターにログのコピーを送信できます。外部ログアグリゲーターを Red Hat OpenShift Service on AWS からログを受信するように設定する必要があります。
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.13.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.14. syslog プロトコルを使用したログの転送
syslog RFC3164 または RFC5424 プロトコルを使用して、デフォルトの Elasticsearch ログストアの代わり、またはこれに加えてプロトコルを受け入れるように設定された外部ログアグリゲーターにログのコピーを送信できます。syslog サーバーなど、外部ログアグリゲーターを Red Hat OpenShift Service on AWS からログを受信するように設定する必要があります。
syslog プロトコルを使用してログ転送を設定するには、syslog サーバーに対する 1 つ以上の出力およびそれらの出力を使用するパイプラインと共に ClusterLogForwarder
カスタムリース (CR) を作成します。syslog 出力では、UDP、TCP、または TLS 接続を使用できます。
前提条件
- 指定されたプロトコルまたは形式を使用してロギングデータを受信するように設定されたロギングサーバーが必要です。
手順
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
- パイプラインを使用して転送するログタイプ (
application
、infrastructure
またはaudit
) を指定します。 - 11
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
- 12
- オプション: ログを内部 Elasticsearch インスタンスに転送するために
default
出力を指定します。 - 13
- オプション: 文字列。ログに追加する 1 つまたは複数のラベル。"true" などの引用値は、ブール値としてではなく、文字列値として認識されるようにします。
- 14
- オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。
- パイプラインを説明する名前。
-
inputRefs
は、そのパイプラインを使用して転送するログタイプです (application
、infrastructure
、またはaudit
)。 -
outputRefs
は使用する出力の名前です。 - オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
CR オブジェクトを作成します。
$ oc create -f <filename>.yaml
9.4.14.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.14.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.14.3. 追加の RFC5424 syslog パラメーター
以下のパラメーターは RFC5424 に適用されます。
-
appName: APP-NAME は、ログを送信したアプリケーションを識別するフリーテキストの文字列です。
RFC5424
に対して指定する必要があります。 -
msgID: MSGID は、メッセージのタイプを識別するフリーテキスト文字列です。
RFC5424
に対して指定する必要があります。 -
procID: PROCID はフリーテキスト文字列です。値が変更される場合は、syslog レポートが中断していることを示します。
RFC5424
に対して指定する必要があります。
9.4.15. ログの Kafka ブローカーへの転送
デフォルトのログストアに加えて、またはその代わりに、外部の Kafka ブローカーにログを転送できます。
外部 Kafka インスタンスへのログ転送を設定するには、そのインスタンスへの出力を含む ClusterLogForwarder
カスタムリソース (CR) と、その出力を使用するパイプラインを作成する必要があります。出力に特定の Kafka トピックを追加するか、デフォルトを使用できます。Kafka の出力は TCP(セキュアでない) または TLS(セキュアな TCP) 接続を使用できます。
手順
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
- パイプラインを使用して転送するログタイプ (
application
、infrastructure
またはaudit
) を指定します。 - 11
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
- 12
- オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
- 13
- オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。
- パイプラインを説明する名前。
-
inputRefs
は、そのパイプラインを使用して転送するログタイプです (application
、infrastructure
、またはaudit
)。 -
outputRefs
は使用する出力の名前です。 - オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
オプション: 単一の出力を複数の 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.16. ログの 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: <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
- パイプラインを使用して転送するログタイプ (
application
、infrastructure
またはaudit
) を指定します。 - 12
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
CR オブジェクトを作成します。
$ oc create -f <file-name>.yaml
例: Amazon CloudWatch での ClusterLogForwarder の使用
ここでは、ClusterLogForwarder
カスタムリソース (CR) のサンプルと、Amazon CloudWatch に出力するログデータが表示されます。
mycluster
という名前の ROSA クラスターを実行しているとします。以下のコマンドは、クラスターの 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 オブジェクトを引き継ぐ予定の場合は、この例で説明されている方法を使用します。それ以外の場合は、前述の例: "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
のロググループには影響しません。
9.4.17. 既存の 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
9.4.18. STS 対応クラスターから Amazon CloudWatch へのログ転送
AWS Security Token Service (STS) が有効になっているクラスターの場合、ログ転送を可能にする AWS IAM ロールとポリシー、および CloudWatch の出力を含む ClusterLogForwarder
カスタムリソース (CR) を作成する必要があります。
前提条件
- Red Hat OpenShift のロギング: 5.5 以降
手順
AWS アカウントを準備します。
以下の内容を含む IAM ポリシー JSON ファイルを作成します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:DescribeLogGroups", "logs:DescribeLogStreams", "logs:PutLogEvents", "logs:PutRetentionPolicy" ], "Resource": "arn:aws:logs:*:*:*" } ] }
以下の内容で IAM 信頼 JSON ファイルを作成します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::<your_aws_account_id>:oidc-provider/<openshift_oidc_provider>" 1 }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "<openshift_oidc_provider>:sub": "system:serviceaccount:openshift-logging:logcollector" 2 } } } ] }
IAM ロールを作成します。
$ aws iam create-role --role-name “<your_rosa_cluster_name>-RosaCloudWatch” \ --assume-role-policy-document file://<your_trust_file_name>.json \ --query Role.Arn \ --output text
出力を保存します。これは次のステップで使用します。
IAM ポリシーを作成します。
$ aws iam create-policy \ --policy-name "RosaCloudWatch" \ --policy-document file:///<your_policy_file_name>.json \ --query Policy.Arn \ --output text
出力を保存します。これは次のステップで使用します。
IAM ポリシーを IAM ロールに割り当てます。
$ aws iam attach-role-policy \ --role-name “<your_rosa_cluster_name>-RosaCloudWatch” \ --policy-arn <policy_ARN> 1
- 1
policy_ARN
は、ポリシーの作成時に保存した出力に置き換えます。
Red Hat OpenShift Logging Operator の
Secret
YAML ファイルを作成します。apiVersion: v1 kind: Secret metadata: name: cloudwatch-credentials namespace: openshift-logging stringData: credentials: |- [default] sts_regional_endpoints = regional role_arn: <role_ARN> 1 web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
- 1
role_ARN
は、ロールの作成時に保存した出力に置き換えます。
シークレットを作成します。
$ oc apply -f cloudwatch-credentials.yaml
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 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
- サービスアカウントの名前。サービスアカウントは、ログフォワーダーが
openshift-logging
namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。 - 4
- 出力の名前を指定します。
- 5
cloudwatch
タイプを指定します。- 6
- オプション: ログをグループ化する方法を指定します。
-
logType
は、ログタイプごとにロググループを作成します。 -
namespaceName
は、アプリケーションの namespace ごとにロググループを作成します。インフラストラクチャーおよび監査ログは影響を受けず、logType
によってグループ化されたままになります。 -
namespaceUUID
は、アプリケーション namespace UUID ごとに新しいロググループを作成します。また、インフラストラクチャーおよび監査ログ用の個別のロググループも作成します。
-
- 7
- オプション: ロググループの名前に含まれるデフォルトの
infrastructureName
接頭辞を置き換える文字列を指定します。 - 8
- AWS リージョンを指定します。
- 9
- 以前に作成したシークレットの名前を指定します。
- 10
- オプション: パイプラインの名前を指定します。
- 11
- パイプラインを使用して転送するログタイプ (
application
、infrastructure
またはaudit
) を指定します。 - 12
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
関連情報