2.4. ログ転送の設定
ClusterLogForwarder
(CLF)を使用すると、ユーザーは各種の宛先へのログの転送を設定できます。さまざまなソースからログメッセージを選択し、それらを変換またはフィルタリングできるパイプラインを介して送信し、それらを 1 つ以上の出力に転送する柔軟な方法を提供します。
ClusterLogForwarder の主要な機能
- 入力を使用してログメッセージを選択します。
- 出力を使用した外部の宛先へのログの転送
- フィルターを使用し、ログメッセージをフィルター、変換、およびドロップします。
- 入力、フィルター、および出力を接続するログ転送パイプラインを定義します。
2.4.1. ログコレクションの設定
本リリースのクラスターロギングでは、管理者は、ClusterLogForwarder に関連付けられたサービスアカウントにログ収集パーミッションを明示的に付与する必要があります。これは、ClusterLogging およびオプションで ClusterLogForwarder.logging.openshift.io リソースで設定されるレガシーロギングシナリオでは以前のリリースでは必要ありませんでした。
Logging 5.8 以降では、Red Hat OpenShift Operator は collect-audit-logs
、collect-application-logs
、および collect-infrastructural-logs
クラスターロールを提供するため、コレクターは監査ログ、アプリケーションログ、インフラストラクチャーログをそれぞれ収集できます。
必要なクラスターロールをサービスアカウントにバインドして、ログの収集を設定します。
2.4.1.1. レガシーサービスアカウント
既存のレガシーサービスアカウント logcollector
を使用するには、以下の ClusterRoleBinding を作成します。
$ oc adm policy add-cluster-role-to-user collect-application-logs system:serviceaccount:openshift-logging:logcollector $ oc adm policy add-cluster-role-to-user collect-infrastructure-logs system:serviceaccount:openshift-logging:logcollector
さらに、監査ログを収集する場合は、以下の ClusterRoleBinding を作成します。
$ oc adm policy add-cluster-role-to-user collect-audit-logs system:serviceaccount:openshift-logging:logcollector
2.4.1.2. サービスアカウントの作成
前提条件
-
Red Hat OpenShift Logging Operator が
openshift-logging
namespace にインストールされている。 - 管理者権限がある。
手順
- コレクターのサービスアカウントを作成します。認証にトークンを必要とするストレージにログを書き込む場合は、サービスアカウントにトークンを含める必要があります。
適切なクラスターロールをサービスアカウントにバインドします。
バインドコマンドの例
$ oc adm policy add-cluster-role-to-user <cluster_role_name> system:serviceaccount:<namespace_name>:<service_account_name>
2.4.1.2.1. サービスアカウントのクラスターロールバインディング
role_binding.yaml ファイルは ClusterLogging Operator の ClusterRole を特定の ServiceAccount にバインドし、Kubernetes リソースをクラスター全体で管理できるようにします。
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: manager-rolebinding roleRef: 1 apiGroup: rbac.authorization.k8s.io 2 kind: ClusterRole 3 name: cluster-logging-operator 4 subjects: 5 - kind: ServiceAccount 6 name: cluster-logging-operator 7 namespace: openshift-logging 8
- 1
- roleRef: バインディングが適用される ClusterRole を参照します。
- 2
- apiGroup: RBAC API グループを示し、ClusterRole が Kubernetes の RBAC システムの一部であることを指定します。
- 3
- kind: 参照されたロールが ClusterRole であることを指定し、クラスター全体に適用されるように指定します。
- 4
- Name: ServiceAccount にバインドされている ClusterRole の名前(cluster-logging-operator)。
- 5
- subjects: ClusterRole からのパーミッションが付与されているエンティティー(ユーザーまたはサービスアカウント)を定義します。
- 6
- kind: サブジェクトが ServiceAccount であることを指定します。
- 7
- name: パーミッションが付与されている ServiceAccount の名前。
- 8
- namespace: ServiceAccount が配置されている名前空間を示します。
2.4.1.2.2. アプリケーションログの書き込み
write-application-logs-clusterrole.yaml ファイルは、アプリケーションログを Loki ロギングアプリケーションに書き込むパーミッションを付与する ClusterRole を定義します。
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cluster-logging-write-application-logs rules: 1 - apiGroups: 2 - loki.grafana.com 3 resources: 4 - application 5 resourceNames: 6 - logs 7 verbs: 8 - create 9 Annotations <1> rules: Specifies the permissions granted by this ClusterRole. <2> apiGroups: Refers to the API group loki.grafana.com, which relates to the Loki logging system. <3> loki.grafana.com: The API group for managing Loki-related resources. <4> resources: The resource type that the ClusterRole grants permission to interact with. <5> application: Refers to the application resources within the Loki logging system. <6> resourceNames: Specifies the names of resources that this role can manage. <7> logs: Refers to the log resources that can be created. <8> verbs: The actions allowed on the resources. <9> create: Grants permission to create new logs in the Loki system.
2.4.1.2.3. 監査ログの作成
write-audit-logs-clusterrole.yaml ファイルは、Loki ログシステムで監査ログを作成するパーミッションを付与する ClusterRole を定義します。
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cluster-logging-write-audit-logs rules: 1 - apiGroups: 2 - loki.grafana.com 3 resources: 4 - audit 5 resourceNames: 6 - logs 7 verbs: 8 - create 9
- 1 1
- rules: この ClusterRole によって付与されるパーミッションを定義します。
- 2 2
- apiGroups: loki.grafana.com の API グループを指定します。
- 3 3
- loki.grafana.com: Loki ログリソースを担当する API グループ。
- 4 4
- Resources: このロールが管理するリソースタイプ(この場合は audit)を参照します。
- 5 5
- audit: ロールが Loki 内で監査ログを管理することを指定します。
- 6 6
- resourceNames: ロールがアクセスできる特定のリソースを定義します。
- 7 7
- Logs: このロールで管理できるログを参照します。
- 8 8
- verbs: リソースで許可されるアクション。
- 9 9
- create: 新規監査ログを作成する権限を付与します。
2.4.1.2.4. インフラストラクチャーログの作成
write-infrastructure-logs-clusterrole.yaml ファイルは、Loki ロギングシステムでインフラストラクチャーログを作成するパーミッションを付与する ClusterRole を定義します。
YAML 例
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cluster-logging-write-infrastructure-logs rules: 1 - apiGroups: 2 - loki.grafana.com 3 resources: 4 - infrastructure 5 resourceNames: 6 - logs 7 verbs: 8 - create 9
- 1
- rules: この ClusterRole が付与するパーミッションを指定します。
- 2
- apiGroups: Loki 関連のリソースの API グループを指定します。
- 3
- loki.grafana.com: Loki ロギングシステムを管理する API グループ。
- 4
- resources: このロールが対話できるリソースタイプを定義します。
- 5
- infrastructure: このロールが管理するインフラストラクチャー関連のリソースを参照します。
- 6
- resourceNames: このロールが管理できるリソースの名前を指定します。
- 7
- Logs: インフラストラクチャーに関連するログリソースを参照します。
- 8
- Verbs: このロールで許可されたアクション。
- 9
- create: Loki システムでインフラストラクチャーログを作成する権限を付与します。
2.4.1.2.5. ClusterLogForwarder エディターロール
clusterlogforwarder-editor-role.yaml ファイルは、ユーザーが OpenShift で ClusterLogForwarders を管理できるようにする ClusterRole を定義します。
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: clusterlogforwarder-editor-role rules: 1 - apiGroups: 2 - observability.openshift.io 3 resources: 4 - clusterlogforwarders 5 verbs: 6 - create 7 - delete 8 - get 9 - list 10 - patch 11 - update 12 - watch 13
- 1
- rules: この ClusterRole が付与するパーミッションを指定します。
- 2
- apiGroups: OpenShift 固有の API グループを参照してください。
- 3
- obervability.openshift.io: ロギングなどの可観測性リソースを管理するための API グループ。
- 4
- resources: このロールが管理できるリソースを指定します。
- 5
- Clusterlogforwarders: OpenShift のログ転送リソースを参照します。
- 6
- Verbs: ClusterLogForwarders で許可されるアクションを指定します。
- 7
- create: 新規 ClusterLogForwarders を作成するためのパーミッションを付与します。
- 8
- delete: 既存の ClusterLogForwarders を削除するためのパーミッションを付与します。
- 9
- get: 特定の ClusterLogForwarders についての情報を取得するためのパーミッションを付与します。
- 10
- list: すべての ClusterLogForwarder の一覧表示を許可します。
- 11
- patch: ClusterLogForwarders の一部を変更する権限を付与します。
- 12
- update: 既存の ClusterLogForwarders を更新するためのパーミッションを付与します。
- 13
- watch: ClusterLogForwarders への変更をモニターするパーミッションを付与します。
2.4.2. コレクターのログレベルの変更
コレクターでログレベルを変更するには、observability.openshift.io/log-level
アノテーションを trace
、debug
、info
、warn
、error
、および off
に設定します。
ログレベルアノテーションの例
apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder metadata: name: collector annotations: observability.openshift.io/log-level: debug # ...
2.4.3. Operator の管理
ClusterLogForwarder
リソースには、Operator がそのリソースをアクティブに管理するか、または管理外にするかを制御する managementState
フィールドがあります。
- Managed
- (デフォルト)Operator はロギングリソースを CLF 仕様の必要な状態に一致するように促進します。
- 管理対象外
- Operator はロギングコンポーネントに関連するアクションを実行しません。
これにより、管理者は managementState
を Unmanaged
に設定して、ログ転送を一時的に一時停止できます。
2.4.4. ClusterLogForwarder の構造
CLF には、以下の主要なコンポーネントが含まれる spec
セクションがあります。
- Inputs
-
転送するログメッセージを選択します。クラスターの異なる部分からの組み込み入力タイプ
アプリケーション
、インフラストラクチャー
、および監査
転送ログ。カスタム入力を定義することもできます。 - 出力
- ログ転送先の宛先を定義します。各出力には、一意の名前とタイプ固有の設定があります。
- Pipelines
- フィルターを介して入力から出力までのパスログを定義します。パイプラインには一意の名前があり、入力、出力、およびフィルター名のリストで設定されます。
- Filters
- パイプラインでログメッセージを変換またはドロップする。ユーザーは、特定のログフィールドに一致するフィルターを定義し、メッセージをドロップまたは変更できます。フィルターは、パイプラインで指定された順序で適用されます。
2.4.4.1. Inputs
入力は spec.inputs
の下の配列で設定されます。組み込み入力タイプは 3 つあります。
- application
-
すべてのアプリケーションコンテナーからログを選択します。ただし、
デフォルト
、openshift、またはkube-
または
の接頭辞が付いた namespace などのインフラストラクチャー namespace にあるログを除外します。openshift
- - infrastructure
-
デフォルト
およびopenshift
namespace およびノードログで実行されているインフラストラクチャーコンポーネントからログを選択します。 - audit
- OpenShift API サーバー監査ログ、Kubernetes API サーバー監査ログ、ovn 監査ログ、および auditd からノード監査ログを選択します。
ユーザーは、特定の namespace からログを選択するか、または Pod ラベルを使用してログを選択する application
のカスタム入力を定義できます。
2.4.4.2. 出力
出力は spec.outputs
の下の配列で設定されます。各出力には、一意の名前とタイプが必要です。サポートされているタイプは次のとおりです。
- azureMonitor
- ログを Azure Monitor に転送します。
- cloudwatch
- ログを AWS CloudWatch に転送します。
- elasticsearch
- ログを外部 Elasticsearch インスタンスに転送します。
- googleCloudLogging
- ログを Google Cloud Logging に転送します。
- http
- ログを汎用 HTTP エンドポイントに転送します。
- kafka
- ログを Kafka ブローカーに転送します。
- loki
- ログを Loki ロギングバックエンドに転送します。
- lokistack
- OpenShift Container Platform 認証統合により、Loki と Web プロキシーのロギングでサポートされている組み合わせにログを転送します。LokiStack のプロキシーは、OpenShift Container Platform 認証を使用してマルチテナンシーを適用します。
- otlp.
- OpenTelemetry Protocol を使用してログを転送します。
- splunk
- ログを Splunk に転送します。
- syslog
- ログを外部 syslog サーバーに転送する。
各出力タイプには、独自の設定フィールドがあります。
2.4.4.3. Pipelines
パイプラインは、spec.pipelines
の下の配列で設定されます。各パイプラインには一意の名前が必要であり、以下で設定されます。
- inputRefs
- ログがこのパイプラインに転送される必要がある入力の名前。
- outputRefs
- ログの送信先となる出力の名前。
- filterRefs
- (オプション)適用するフィルターの名前。
filterRef の順序は、順次適用されるため重要です。以前のフィルターは、後のフィルターで処理されないメッセージをドロップできます。
2.4.4.4. Filters
フィルターは spec.filters
下の配列で設定されます。構造化されたフィールドの値に基づいて、入力ログメッセージを照合し、それらを変更またはドロップできます。
管理者は、次のタイプのフィルターを設定できます。
2.4.4.5. 複数行の例外検出の有効化
コンテナーログの複数行のエラー検出を有効にします。
この機能を有効にすると、パフォーマンスに影響が出る可能性があり、追加のコンピューティングリソースや代替のロギングソリューションが必要になる場合があります。
ログパーサーは頻繁に、同じ例外の個別の行を別々の例外として誤って識別します。その結果、余分なログエントリーが発生し、トレースされた情報が不完全または不正確な状態で表示されます。
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: "observability.openshift.io/v1" kind: ClusterLogForwarder metadata: name: <log_forwarder_name> namespace: <log_forwarder_namespace> spec: serviceAccount: name: <service_account_name> filters: - name: <name> type: detectMultilineException pipelines: - inputRefs: - <input-name> name: <pipeline-name> filterRefs: - <filter-name> outputRefs: - <output-name>
2.4.4.5.1. 詳細
ログメッセージが例外スタックトレースを形成する連続したシーケンスとして表示される場合、それらは単一の統合ログレコードに結合されます。最初のログメッセージの内容は、シーケンス内のすべてのメッセージフィールドの連結コンテンツに置き換えられます。
コレクターは次の言語をサポートしています。
- Java
- JS
- Ruby
- Python
- golang
- PHP
- Dart
2.4.4.6. 不要なログレコードを削除するコンテンツフィルターの設定
drop
フィルターが設定されている場合、ログコレクターは転送する前にフィルターに従ってログストリームを評価します。コレクターは、指定された設定に一致する不要なログレコードを削除します。
手順
フィルターの設定を
ClusterLogForwarder
CR のfilters
仕様に追加します。以下の例は、正規表現に基づいてログレコードを削除するように
ClusterLogForwarder
CR を設定する方法を示しています。ClusterLogForwarder
CR の例apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder metadata: # ... spec: serviceAccount: name: <service_account_name> filters: - name: <filter_name> type: drop 1 drop: 2 - test: 3 - field: .kubernetes.labels."foo-bar/baz" 4 matches: .+ 5 - field: .kubernetes.pod_name notMatches: "my-pod" 6 pipelines: - name: <pipeline_name> 7 filterRefs: ["<filter_name>"] # ...
- 1
- フィルターの種類を指定します。
drop
フィルターは、フィルター設定に一致するログレコードをドロップします。 - 2
drop
フィルターを適用するための設定オプションを指定します。- 3
- ログレコードが削除されるかどうかを評価するために使用されるテストの設定を指定します。
- テストに指定されたすべての条件が true の場合、テストは合格し、ログレコードは削除されます。
-
drop
フィルター設定に複数のテストが指定されている場合、いずれかのテストに合格すると、レコードは削除されます。 - 条件の評価中にエラーが発生した場合 (たとえば、評価対象のログレコードにフィールドがない場合)、その条件は false と評価されます。
- 4
- ドットで区切られたフィールドパス (ログレコード内のフィールドへのパス) を指定します。パスには、英数字とアンダースコア (
a-zA-Z0-9_
) を含めることができます (例:.kubernetes.namespace_name
)。セグメントにこの範囲外の文字が含まれている場合、セグメントを引用符で囲む必要があります (例:.kubernetes.labels."foo.bar-bar/baz")
。1 つのtest
設定に複数のフィールドパスを含めることができますが、テストに合格してdrop
フィルターを適用するには、すべてのフィールドパスが true と評価される必要があります。 - 5
- 正規表現を指定します。ログレコードがこの正規表現と一致する場合は、破棄されます。単一の
field
パスに対してmatches
またはnotMatches
条件のいずれかを設定できますが、両方を設定することはできません。 - 6
- 正規表現を指定します。ログレコードがこの正規表現に一致しない場合、破棄されます。単一の
field
パスに対してmatches
またはnotMatches
条件のいずれかを設定できますが、両方を設定することはできません。 - 7
drop
フィルターが適用されるパイプラインを指定します。
次のコマンドを実行して、
ClusterLogForwarder
CR を適用します。$ oc apply -f <filename>.yaml
追加例
次の例は、優先度の高いログレコードのみを保持するように drop
フィルターを設定する方法を示しています。
apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder metadata: # ... spec: serviceAccount: name: <service_account_name> filters: - name: important type: drop drop: - test: - field: .message notMatches: "(?i)critical|error" - field: .level matches: "info|warning" # ...
単一の test
設定に複数のフィールドパスを追加する以外に、OR チェックとして扱われる追加のテストも追加できます。次の例では、いずれかの test
設定が true と評価されるとレコードが削除されます。ただし、2 番目の test
設定では、true と評価されるためには、両方のフィールド仕様が true である必要があります。
apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder metadata: # ... spec: serviceAccount: name: <service_account_name> filters: - name: important type: drop drop: - test: - field: .kubernetes.namespace_name matches: "^open" - test: - field: .log_type matches: "application" - field: .kubernetes.pod_name notMatches: "my-pod" # ...
2.4.4.7. API 監査フィルターの概要
OpenShift API サーバーは、API 呼び出しごとに、リクエスト、レスポンス、リクエスターの ID の詳細を示す監査イベントを生成するため、大量のデータが生成されます。API 監査フィルターはルールを使用して、重要でないイベントを除外してイベントサイズを減少できるようにし、監査証跡をより管理しやすくします。ルールは順番にチェックされ、最初の一致で停止をチェックします。イベントに含まれるデータの量は、level
フィールドの値によって決定されます。
-
None
: イベントはドロップされます。 -
Metadata
: 監査メタデータが含まれ、リクエストおよびレスポンスの本文は削除されます。 -
Request
: 監査メタデータとリクエスト本文が含まれ、レスポンス本文は削除されます。 -
RequestResponse
: メタデータ、リクエスト本文、レスポンス本文のすべてのデータが含まれます。レスポンス本文が非常に大きくなる可能性があります。たとえば、oc get pods -A
はクラスター内のすべての Pod の YAML 記述を含むレスポンス本文を生成します。
ロギング 5.8 以降では、ClusterLogForwarder
カスタムリソース (CR) は標準の Kubernetes 監査ポリシー と同じ形式を使用しますが、次の追加機能を提供します。
- ワイルドカード
-
ユーザー、グループ、namespace、およびリソースの名前には、先頭または末尾に
*
アスタリスク文字を付けることができます。たとえば、namespace openshift-\* はopenshift-apiserver
またはopenshift-authentication
と一致します。リソース\*/status
は、Pod/status
またはDeployment/status
と一致します。 - デフォルトのルール
ポリシーのルールに一致しないイベントは、以下のようにフィルターされます。
-
get
、list
、watch
などの読み取り専用システムイベントは破棄されます。 - サービスアカウントと同じ namespace 内で発生するサービスアカウント書き込みイベントはドロップされます。
- 他のすべてのイベントは、設定されたレート制限に従って転送されます。
-
これらのデフォルトを無効にするには、level
フィールドのみが含まれるルールでルールリストを終了するか、空のルールを追加します。
- 応答コードが省略される
-
省略する整数ステータスコードのリスト。
OmitResponseCodes
フィールドを使用して、イベントが作成されない HTTP ステータスコードのリストを使用して、応答の HTTP ステータスコードに基づいてイベントを削除できます。デフォルト値は[404, 409, 422, 429]
です。値が空のリスト[]
の場合、ステータスコードは省略されません。
ClusterLogForwarder
CR の監査ポリシーは、OpenShift Container Platform の監査ポリシーに加えて動作します。ClusterLogForwarder CR 監査フィルターは、ログコレクターが転送する内容を変更し、動詞、ユーザー、グループ、namespace、またはリソースでフィルタリングする機能を提供します。複数のフィルターを作成して、同じ監査ストリームの異なるサマリーを異なる場所に送信できます。たとえば、詳細なストリームをローカルクラスターログストアに送信し、詳細度の低いストリームをリモートサイトに送信できます。
監査ログを収集するには、クラスターロール collect-audit-logs
が必要です。提供されている例は、監査ポリシーで可能なルールの範囲を示すことを目的としており、推奨される設定ではありません。
監査ポリシーの例
apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder metadata: name: <log_forwarder_name> namespace: <log_forwarder_namespace> spec: serviceAccount: name: <service_account_name> pipelines: - name: my-pipeline inputRefs: audit 1 filterRefs: my-policy 2 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
2.4.4.8. ラベル式または一致するラベルキーと値を含む入力時でのアプリケーションログのフィルタリング
input
セレクターを使用して、ラベル式または一致するラベルキーとその値に基づいてアプリケーションログを含めることができます。
手順
ClusterLogForwarder
CR のinput
仕様にフィルターの設定を追加します。以下の例は、ラベル式または一致したラベルキー/値に基づいてログを組み込むように
ClusterLogForwarder
CR を設定する方法を示しています。ClusterLogForwarder
CR の例apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder # ... spec: serviceAccount: name: <service_account_name> inputs: - name: mylogs application: selector: matchExpressions: - key: env 1 operator: In 2 values: ["prod", "qa"] 3 - key: zone operator: NotIn values: ["east", "west"] matchLabels: 4 app: one name: app1 type: application # ...
次のコマンドを実行して、
ClusterLogForwarder
CR を適用します。$ oc apply -f <filename>.yaml
2.4.4.9. ログレコードを削除するコンテンツフィルターの設定
prune
フィルターが設定されると、ログコレクターは転送前にフィルターをもとにログレベルを評価します。コレクターは、Pod アノテーションなどの値の低いフィールドを削除してログレコードを整理します。
手順
フィルターの設定を
ClusterLogForwarder
CR のprune
仕様に追加します。次の例は、フィールドパスに基づいてログレコードを削除するように
ClusterLogForwarder
CR を設定する方法を示しています。重要両方が指定されている場合、最初に
notIn
配列に基づいてレコードが整理され、in
配列よりも優先されます。notIn
配列を使用してレコードが整理された後、in
配列を使用してレコードが整理されます。ClusterLogForwarder
CR の例apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder metadata: # ... spec: serviceAccount: name: <service_account_name> filters: - name: <filter_name> type: prune 1 prune: 2 in: [.kubernetes.annotations, .kubernetes.namespace_id] 3 notIn: [.kubernetes,.log_type,.message,."@timestamp"] 4 pipelines: - name: <pipeline_name> 5 filterRefs: ["<filter_name>"] # ...
- 1
- フィルターのタイプを指定します。
prune
フィルターでは、設定されたフィールドでログレコードをプルーニングします。 - 2
prune
フィルターを適用するための設定オプションを指定します。in
フィールドとnotIn
フィールドは、ログレコード内のフィールドへのパスであるドット区切りのフィールドパスの配列として指定されます。これらのパスには、英数字とアンダースコア (a-zA-Z0-9_
) を含めることができます (例:.kubernetes.namespace_name
)。セグメントにこの範囲外の文字が含まれている場合、セグメントを引用符で囲む必要があります (例:.kubernetes.labels."foo.bar-bar/baz")
。- 3
- オプション: この配列で指定されたフィールドはすべてログレコードから削除されます。
- 4
- オプション: この配列で指定されていないフィールドはログレコードから削除されます。
- 5
prune
フィルターを適用するパイプラインを指定します。
注記フィルターは、
log_type
フィールド、.log_source
フィールド、および.message
フィールドを使用します。次のコマンドを実行して、
ClusterLogForwarder
CR を適用します。$ oc apply -f <filename>.yaml
2.4.5. ソースによる監査およびインフラストラクチャーログ入力のフィルタリング
input
セレクターを使用して、ログを収集する audit
および infrastructure
ソースのリストを定義できます。
手順
ClusterLogForwarder
CR にaudit
およびinfrastructure
ソースを定義する設定を追加します。次の例は、
ClusterLogForwarder
CR を設定してaudit
およびinfrastructure
ソースを定義する方法を示しています。ClusterLogForwarder
CR の例apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder # ... spec: serviceAccount: name: <service_account_name> inputs: - name: mylogs1 type: infrastructure infrastructure: sources: 1 - node - name: mylogs2 type: audit audit: sources: 2 - kubeAPI - openshiftAPI - ovn # ...
次のコマンドを実行して、
ClusterLogForwarder
CR を適用します。$ oc apply -f <filename>.yaml
2.4.6. namespace またはコンテナー名を含めるか除外して入力時にアプリケーションログをフィルタリングする手順
input
セレクターを使用して、namespace とコンテナー名に基づいてアプリケーションログを含めたり除外したりできます。
手順
ClusterLogForwarder
CR に namespace とコンテナー名を含めるか除外するかの設定を追加します。以下の例は、namespace およびコンテナー名を含めるか、除外するように
ClusterLogForwarder
CR を設定する方法を示しています。ClusterLogForwarder
CR の例apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder # ... spec: serviceAccount: name: <service_account_name> inputs: - name: mylogs application: includes: - namespace: "my-project" 1 container: "my-container" 2 excludes: - container: "other-container*" 3 namespace: "other-namespace" 4 # ...
注記excludes
フィールドは includes フィールドよりも優先され
ます。次のコマンドを実行して、
ClusterLogForwarder
CR を適用します。$ oc apply -f <filename>.yaml