3.3. ログ転送の設定

ClusterLogForwarder (CLF) を使用すると、ユーザーはさまざまな宛先へのログの転送を設定できます。さまざまなソースからログメッセージを選択し、それらを変換またはフィルタリングできるパイプラインを介して送信して、1 つ以上の出力に転送する柔軟な方法を提供します。

ClusterLogForwarder の主な機能

入力を使用してログメッセージを選択する
出力を使用してログを外部の宛先に転送する
フィルターを使用してログメッセージをフィルタリング、変換、およびドロップする
入力、フィルター、出力を接続するログ転送パイプラインを定義する

3.3.1. ログ収集のセットアップ

このリリースの Cluster Logging では、管理者が ClusterLogForwarder に関連付けられたサービスアカウントにログ収集権限を明示的に付与する必要があります。これは、ClusterLogging およびオプションで ClusterLogForwarder.logging.openshift.io リソースで構成されるレガシーロギングシナリオでは、以前のリリースでは必要ありませんでした。

Red Hat OpenShift Logging Operator は、collect-audit-logs、collect-application-logs、collect-infrastructure-logs クラスターロールを提供します。これにより、コレクターは監査ログ、アプリケーションログ、およびインフラストラクチャーログをそれぞれ収集できます。

必要なクラスターロールをサービスアカウントにバインドして、ログ収集をセットアップします。

3.3.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

3.3.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>

3.3.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 が配置されている namespace を示します。

3.3.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.

3.3.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: API グループ loki.grafana.com を指定します。
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: 新しい監査ログを作成する権限を付与します。

3.3.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: ルール: この ClusterRole が付与する権限を指定します。
2: apiGroups: Loki 関連リソースの API グループを指定します。
3: loki.grafana.com: Loki ロギングシステムを管理する API グループ。
4: resources: このロールが対話できるリソースタイプを定義します。
5: infrastructure: このロールが管理するインフラストラクチャー関連のリソースを指します。
6: resourceNames: このロールが管理できるリソースの名前を指定します。
7: logs: インフラストラクチャーに関連するログリソースを指します。
8: verbs: このロールによって許可されるアクションです。
9: create: Loki システムにインフラストラクチャーログを作成する権限を付与します。

3.3.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: ルール: この 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: すべての ClusterLogForwarders のリスト表示を許可します。
11: patch: ClusterLogForwarders を部分的に変更する権限を付与します。
12: update: 既存の ClusterLogForwarders を更新する権限を付与します。
13: watch: ClusterLogForwarders への変更を監視する権限を付与します。

3.3.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
# ...

3.3.3. Operator の管理

ClusterLogForwarder リソースには、Operator がリソースをアクティブに管理するか、管理対象外のままにするかを制御する managementState フィールドがあります。

Managed: (デフォルト) Operator は、CLF 仕様の目的の状態に一致するようにロギングリソースを駆動します。
管理対象外: Operator は、ロギングコンポーネントに関連するアクションを一切実行しません。

これにより、管理者は managementState を Unmanaged に設定して、ログ転送を一時的に停止できます。

3.3.4. ClusterLogForwarder の構造

CLF には、次の主要コンポーネントを含む spec セクションがあります。

Inputs: 転送するログメッセージを選択します。組み込みの入力タイプである application、infrastructure、および audit は、クラスターのさまざまな部分からログを転送します。カスタム入力を定義することもできます。
出力: ログを転送する宛先を定義します。各出力には、一意の名前とタイプ固有の設定があります。
Pipelines: ログが入力からフィルターを経由して出力されるまでのパスを定義します。パイプラインには一意の名前があり、入力名、出力名、フィルター名のリストで構成されます。
Filters: パイプライン内のログメッセージを変換またはドロップします。ユーザーは、特定のログフィールドに一致するフィルターを定義し、メッセージをドロップまたは変更できます。フィルターはパイプラインで指定された順序で適用されます。

3.3.4.1. Inputs

入力は spec.inputs の下の配列で設定されます。組み込みの入力タイプは 3 つあります。

application: default、openshift などのインフラストラクチャー namespace や、kube- または openshift- の接頭辞を持つ namespace 内のログを除いた、すべてのアプリケーションコンテナーからログを選択します。
infrastructure: default および openshift namespace とノードログで実行されているインフラストラクチャーコンポーネントからログを選択します。
audit: OpenShift API サーバー監査ログ、Kubernetes API サーバー監査ログ、ovn 監査ログ、および auditd からのノード監査ログからログを選択します。

ユーザーは、特定の namespace からログを選択するか、または Pod ラベルを使用してログを選択する application のカスタム入力を定義できます。

3.3.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 プロトコルを使用してログを転送します。
splunk: ログを Splunk に転送します。
syslog: ログを外部の syslog サーバーに転送します。

各出力タイプには独自の設定フィールドがあります。

3.3.5. OTLP 出力の設定

クラスター管理者は、OpenTelemetry Protocol (OTLP) 出力を使用してログを収集し、OTLP レシーバーに転送できます。OTLP 出力は、OpenTelemetry Observability フレームワークで定義された仕様を使用して、HTTP を介して JSON エンコーディングでデータを送信します。

重要

OpenTelemetry Protocol (OTLP) 出力ログフォワーダーは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲を参照してください。

手順

OTLP を使用した転送を有効にするには、次のアノテーションを追加して ClusterLogForwarder カスタムリソース (CR) を作成または編集します。

ClusterLogForwarder CR の例

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  annotations:
    observability.openshift.io/tech-preview-otlp-output: "enabled" 1
  name: clf-otlp
spec:
  serviceAccount:
    name: <service_account_name>
  outputs:
  - name: otlp
    type: otlp
    otlp:
      tuning:
        compression: gzip
        deliveryMode: AtLeastOnce
        maxRetryDuration: 20
        maxWrite: 10M
        minRetryDuration: 5
      url: <otlp_url> 2
  pipelines:
  - inputRefs:
    - application
    - infrastructure
    - audit
    name: otlp-logs
    outputRefs:
    - otlp

1: このアノテーションを使用して OpenTelemetry Protocol (OTLP) 出力を有効にします。これはテクノロジープレビュー機能です。
2: これは絶対 URL でなければならず、ログの送信先である OTLP エンドポイントのプレースホルダーです。

注記

OTLP 出力では OpenTelemetry データモデルが使用されますが、これは他の出力タイプで使用される ViaQ データモデルとは異なります。これは、OpenTelemetry Observability フレームワークで定義された OpenTelemetry Semantic Conventions を使用することで OTLP に準拠しています。

3.3.5.1. Pipelines

パイプラインは spec.pipelines の下の配列で設定されます。各パイプラインには一意の名前があり、次の要素で構成される必要があります。

inputRefs: このパイプラインにログを転送する入力の名前。
outputRefs: ログを送信する出力の名前。
filterRefs: (オプション) 適用するフィルターの名前。

filterRef の順序は、順次適用されるため重要です。以前のフィルターは、後のフィルターで処理されないメッセージをドロップする可能性があります。

3.3.5.2. Filters

フィルターは spec.filters の下の配列で設定されます。構造化フィールドの値に基づいて受信ログメッセージを照合し、変更または削除できます。

管理者は次のタイプのフィルターを設定できます。

3.3.5.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) に .spec.filters の下の 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>

3.3.5.3.1. 詳細

ログメッセージが例外スタックトレースを形成する連続したシーケンスとして表示される場合、それらは単一の統合ログレコードに結合されます。最初のログメッセージの内容は、シーケンス内のすべてのメッセージフィールドの連結コンテンツに置き換えられます。

コレクターは次の言語をサポートしています。

Java
JS
Ruby
Python
golang
PHP
Dart

3.3.5.4. 不要なログレコードを削除するコンテンツフィルターの設定

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"
# ...

3.3.5.5. API 監査フィルターの概要

OpenShift API サーバーは、API 呼び出しごとに、リクエスト、レスポンス、リクエスターの ID の詳細を示す監査イベントを生成するため、大量のデータが生成されます。API 監査フィルターはルールを使用して、重要でないイベントを除外してイベントサイズを減少できるようにし、監査証跡をより管理しやすくします。ルールは順番にチェックされ、最初の一致でチェックが停止します。イベントに含まれるデータの量は、level フィールドの値によって決まります。

None: イベントはドロップされます。
Metadata: 監査メタデータが含まれ、リクエストおよびレスポンスの本文は削除されます。
Request: 監査メタデータとリクエスト本文が含まれ、レスポンス本文は削除されます。
RequestResponse: メタデータ、リクエスト本文、レスポンス本文のすべてのデータが含まれます。レスポンス本文が非常に大きくなる可能性があります。たとえば、oc get pods -A はクラスター内のすべての Pod の YAML 記述を含むレスポンス本文を生成します。

ClusterLogForwarder カスタムリソース (CR) は、以下の追加機能を提供しますが、標準の Kubernetes 監査ポリシーと同じ形式を使用します。

ワイルドカード

ユーザー、グループ、namespace、およびリソースの名前には、先頭または末尾に * アスタリスク文字を付けることができます。たとえば、namespace openshift-\* は openshift-apiserver または openshift-authentication に一致します。リソース \*/status は、Pod/status または Deployment/status と一致します。

デフォルトのルール

ポリシーのルールに一致しないイベントは、以下のようにフィルターされます。

get、list、watch などの読み取り専用システムイベントは削除されます。
サービスアカウントと同じ namespace 内で発生するサービスアカウント書き込みイベントはドロップされます。
他のすべてのイベントは、設定されたレート制限に従って転送されます。

これらのデフォルトを無効にするには、level フィールドのみが含まれるルールでルールリストを終了するか、空のルールを追加します。

応答コードが省略される: 省略する整数ステータスコードのリスト。イベントが作成されない HTTP ステータスコードをリストする OmitResponseCodes フィールドを使用して、応答で HTTP ステータスコードに基づいてイベントをドロップできます。デフォルト値は [404, 409, 422, 429] です。値が空のリスト [] の場合、ステータスコードは省略されません。

ClusterLogForwarder CR の監査ポリシーは、OpenShift Container Platform の監査ポリシーに加えて動作します。ClusterLogForwarder CR 監査フィルターは、ログコレクターが転送する内容を変更し、verb、user、group、namespace、または resource でフィルタリングする機能を提供します。複数のフィルターを作成して、同じ監査ストリームの異なるサマリーを異なる場所に送信できます。たとえば、詳細なストリームをローカルクラスターログストアに送信し、詳細度の低いストリームをリモートサイトに送信できます。

注記

監査ログを収集するには、クラスターロール 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

1: 収集されるログのタイプ。このフィールドの値は、監査ログの場合は audit、アプリケーションログの場合は application、インフラストラクチャーログの場合は infrastructure、またはアプリケーションに定義された指定の入力になります。
2: 監査ポリシーの名前。

3.3.5.6. ラベル式または一致するラベルキーと値を含む入力時でのアプリケーションログのフィルタリング

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
# ...
```
1
照合するラベルキーを指定します。
2
Operator を指定します。有効な値には、In、NotIn、Exists、DoesNotExist などがあります。
3
文字列値の配列を指定します。Operator 値が Exists または DoesNotExist のいずれかの場合、値の配列は空である必要があります。
4
正確なキーまたは値のマッピングを指定します。
次のコマンドを実行して、ClusterLogForwarder CR を適用します。
```
$ oc apply -f <filename>.yaml
```

3.3.5.7. ログレコードを削除するコンテンツフィルターの設定

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
```

3.3.6. ソースによる監査およびインフラストラクチャーログ入力のフィルタリング

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
# ...
```
1
収集するインフラストラクチャーソースのリストを指定します。有効なソースには以下が含まれます。
node: ノードからのジャーナルログ
container: namespace にデプロイされたワークロードからのログ
2
収集する audit ソースのリストを指定します。有効なソースには以下が含まれます。
kubeAPI: Kubernetes API サーバーからのログ
openshiftAPI: OpenShift API サーバーからのログ
auditd: ノードの auditd サービスからのログ
ovn: オープン仮想ネットワークサービスからのログ
次のコマンドを実行して、ClusterLogForwarder CR を適用します。
```
$ oc apply -f <filename>.yaml
```

3.3.7. 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
      type: application
# ...
```
1
ログがこれらの namespace からのみ収集されることを指定します。
2
ログがこれらのコンテナーからのみ収集されることを指定します。
3
ログを収集するときに無視する namespace のパターンを指定します。
4
ログを収集するときに無視するコンテナーのセットを指定します。
注記
excludes フィールドは includes フィールドよりも優先されます。
次のコマンドを実行して、ClusterLogForwarder CR を適用します。
```
$ oc apply -f <filename>.yaml
```