検索

2.4. ログ転送の設定

download PDF

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

ClusterLogForwarder の主要な機能

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

2.4.1. ログコレクションの設定

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

Logging 5.8 以降では、Red Hat OpenShift Operator は collect-audit-logscollect-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 にインストールされている。
  • 管理者権限がある。

手順

  1. コレクターのサービスアカウントを作成します。認証にトークンを必要とするストレージにログを書き込む場合は、サービスアカウントにトークンを含める必要があります。
  2. 適切なクラスターロールをサービスアカウントにバインドします。

    バインドコマンドの例

    $ 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 アノテーションを tracedebuginfowarnerror、および 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 はロギングコンポーネントに関連するアクションを実行しません。

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

2.4.4. ClusterLogForwarder の構造

CLF には、以下の主要なコンポーネントが含まれる spec セクションがあります。

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

2.4.4.1. Inputs

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

application
すべてのアプリケーションコンテナーからログを選択します。ただし、デフォルト、openshift、または kube- または openshift - の接頭辞が付いた namespace などのインフラストラクチャー namespace にあるログを除外します。
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) に、値が truedetectMultilineErrors フィールドが含まれていることを確認します。

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 フィルターが設定されている場合、ログコレクターは転送する前にフィルターに従ってログストリームを評価します。コレクターは、指定された設定に一致する不要なログレコードを削除します。

手順

  1. フィルターの設定を 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 フィルターが適用されるパイプラインを指定します。
  2. 次のコマンドを実行して、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 と一致します。
デフォルトのルール

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

  • getlistwatch などの読み取り専用システムイベントは破棄されます。
  • サービスアカウントと同じ 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

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

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

input セレクターを使用して、ラベル式または一致するラベルキーとその値に基づいてアプリケーションログを含めることができます。

手順

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

    $ oc apply -f <filename>.yaml

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

prune フィルターが設定されると、ログコレクターは転送前にフィルターをもとにログレベルを評価します。コレクターは、Pod アノテーションなどの値の低いフィールドを削除してログレコードを整理します。

手順

  1. フィルターの設定を 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 フィールドを使用します。

  2. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。

    $ oc apply -f <filename>.yaml

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

input セレクターを使用して、ログを収集する audit および infrastructure ソースのリストを定義できます。

手順

  1. 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: オープン仮想ネットワークサービスからのログ
  2. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。

    $ oc apply -f <filename>.yaml

2.4.6. namespace またはコンテナー名を含めるか除外して入力時にアプリケーションログをフィルタリングする手順

input セレクターを使用して、namespace とコンテナー名に基づいてアプリケーションログを含めたり除外したりできます。

手順

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

    1
    ログがこれらの namespace からのみ収集されることを指定します。
    2
    ログがこれらのコンテナーからのみ収集されることを指定します。
    3
    ログを収集するときに無視する namespace のパターンを指定します。
    4
    ログを収集するときに無視するコンテナーのセットを指定します。
    注記

    excludes フィールドは includes フィールドよりも優先さ ます。

  2. 次のコマンドを実行して、ClusterLogForwarder CR を適用します。

    $ oc apply -f <filename>.yaml
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.