9.5. ロギングコレクターの設定

Red Hat OpenShift のロギングは、クラスターからオペレーションとアプリケーションログを収集し、Kubernetes Pod とプロジェクトメタデータでデータを拡充します。ログコレクターに対するサポートされるすべての変更は、ClusterLogging カスタムリソース (CR) の spec.collection スタンザを使用して実行できます。

9.5.1. ログコレクターの設定

ClusterLogging カスタムリソース (CR) を変更することで、ロギングで使用するログコレクターのタイプを設定できます。

注記

Fluentd は非推奨となっており、今後のリリースで削除される予定です。Red Hat は、現在のリリースのライフサイクル中にこの機能のバグ修正とサポートを提供しますが、この機能は拡張されなくなりました。Fluentd の代わりに、Vector を使用できます。

前提条件

  • 管理者権限がある。
  • OpenShift CLI (oc) がインストールされている。
  • Red Hat OpenShift Logging Operator がインストールされている。
  • ClusterLogging CR が作成されている。

手順

  1. ClusterLogging CR の collection 仕様を変更します。

    ClusterLogging CR の例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
    # ...
    spec:
    # ...
      collection:
        type: <log_collector_type> 1
        resources: {}
        tolerations: {}
    # ...

    1
    ロギングに使用するログコレクターのタイプ。これは、vector または fluentd にすることができます。
  2. 次のコマンドを実行して、ClusterLogging CR を適用します。

    $ oc apply -f <filename>.yaml

9.5.2. LogFileMetricExporter リソースの作成

ロギングバージョン 5.8 以降のバージョンでは、LogFileMetricExporter はデフォルトでコレクターを使用してデプロイされなくなりました。実行中のコンテナーによって生成されたログからメトリクスを生成するには、LogFileMetricExporter カスタムリソース (CR) を手動で作成する必要があります。

LogFileMetricExporter CR を作成しない場合、OpenShift Container Platform Web コンソールのダッシュボードの Produced LogsNo datapoints found というメッセージが表示される場合があります。

前提条件

  • 管理者権限がある。
  • Red Hat OpenShift Logging Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. LogFileMetricExporter CR を YAML ファイルとして作成します。

    LogFileMetricExporter CR の例

    apiVersion: logging.openshift.io/v1alpha1
    kind: LogFileMetricExporter
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      nodeSelector: {} 1
      resources: 2
        limits:
          cpu: 500m
          memory: 256Mi
        requests:
          cpu: 200m
          memory: 128Mi
      tolerations: [] 3
    # ...

    1
    オプション: nodeSelector スタンザは、Pod がスケジュールされるノードを定義します。
    2
    resources スタンザは、LogFileMetricExporter CR のリソース要件を定義します。
    3
    オプション: tolerations スタンザは、Pod が受け入れる許容範囲を定義します。
  2. 次のコマンドを実行して、LogFileMetricExporter CR を適用します。

    $ oc apply -f <filename>.yaml

検証

logfilesmetricexporter Pod は、各ノードで collector Pod と同時に実行されます。

  • 次のコマンドを実行して出力を確認し、LogFilesmetricExporter CR を作成した namespace で logfilesmetricexporter Pod が実行されていることを確認します。

    $ oc get pods -l app.kubernetes.io/component=logfilesmetricexporter -n openshift-logging

    出力例

    NAME                           READY   STATUS    RESTARTS   AGE
    logfilesmetricexporter-9qbjj   1/1     Running   0          2m46s
    logfilesmetricexporter-cbc4v   1/1     Running   0          2m46s

9.5.3. ログコレクター CPU およびメモリー制限の設定

ログコレクターは、CPU とメモリー制限の両方への調整を許可します。

手順

  • openshift-logging プロジェクトで ClusterLogging カスタムリソース (CR) を編集します。

    $ oc -n openshift-logging edit ClusterLogging instance
    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      collection:
        type: fluentd
        resources:
          limits: 1
            memory: 736Mi
            requests:
              cpu: 100m
              memory: 736Mi
    # ...
    1
    必要に応じて CPU、メモリー制限および要求を指定します。表示される値はデフォルト値です。

9.5.4. 入力レシーバーの設定

Red Hat OpenShift Logging Operator は、クライアントがコレクターに書き込めるように、設定された各入力レシーバー用のサービスをデプロイします。このサービスは、入力レシーバーに指定されたポートを公開します。サービス名は、以下に基づいて生成されます。

  • マルチログフォワーダー ClusterLogForwarder CR のデプロイメントの場合、サービス名は <ClusterLogForwarder_CR_name>-<input_name> という形式になります。たとえば、example-http-receiver などです。
  • 従来の ClusterLogForwarder CR のデプロイメント (instance という名前が付けられ、openshift-logging namespace に配置されているデプロイメント) の場合、サービス名は collector-<input_name> という形式になります。たとえば、collector-http-receiver です。

9.5.4.1. 監査ログを HTTP サーバーとして受信するようにコレクターを設定する

ClusterLogForwarder カスタムリソース (CR) で http をレシーバー入力として指定すると、HTTP 接続をリッスンして監査ログを HTTP サーバーとして受信するようにログコレクターを設定できます。これにより、OpenShift Container Platform クラスターの内部と外部の両方から収集された監査ログに共通のログストアを使用できるようになります。

前提条件

  • 管理者権限がある。
  • OpenShift CLI (oc) がインストールされている。
  • Red Hat OpenShift Logging Operator がインストールされている。
  • ClusterLogForwarder CR が作成されている。

手順

  1. ClusterLogForwarder CR を変更して、http レシーバー入力の設定を追加します。

    マルチログフォワーダーデプロイメントを使用している場合の ClusterLogForwarder CR の例

    apiVersion: logging.openshift.io/v1beta1
    kind: ClusterLogForwarder
    metadata:
    # ...
    spec:
      serviceAccountName: <service_account_name>
      inputs:
        - name: http-receiver 1
          receiver:
            type: http 2
            http:
              format: kubeAPIAudit 3
              port: 8443 4
      pipelines: 5
        - name: http-pipeline
          inputRefs:
            - http-receiver
    # ...

    1
    入力レシーバーの名前を指定します。
    2
    入力レシーバー型を http に指定します。
    3
    現在、HTTP 入力レシーバーでは kube-apiserver Webhook 形式のみがサポートされています。
    4
    オプション: 入力レシーバーがリッスンするポートを指定します。これは、1024 から 65535 までの値とします。指定されていない場合、デフォルト値は 8443 です。
    5
    入力レシーバーのパイプラインを設定します。

    従来のデプロイメントを使用している場合の ClusterLogForwarder CR の例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      inputs:
        - name: http-receiver 1
          receiver:
            type: http 2
            http:
              format: kubeAPIAudit 3
              port: 8443 4
      pipelines: 5
      - inputRefs:
        - http-receiver
        name: http-pipeline
    # ...

    1
    入力レシーバーの名前を指定します。
    2
    入力レシーバー型を http に指定します。
    3
    現在、HTTP 入力レシーバーでは kube-apiserver Webhook 形式のみがサポートされています。
    4
    オプション: 入力レシーバーがリッスンするポートを指定します。これは、1024 から 65535 までの値とします。指定されていない場合、デフォルト値は 8443 です。
    5
    入力レシーバーのパイプラインを設定します。
  2. 次のコマンドを実行して、ClusterLogForwarder CR に変更を適用します。

    $ oc apply -f <filename>.yaml

9.5.5. Fluentd ログフォワーダーの高度な設定

注記

Fluentd は非推奨となっており、今後のリリースで削除される予定です。Red Hat は、現在のリリースのライフサイクル中にこの機能のバグ修正とサポートを提供しますが、この機能は拡張されなくなりました。Fluentd の代わりに、Vector を使用できます。

ロギングには、Fluentd ログフォワーダーのパフォーマンスチューニングに使用できる複数の Fluentd パラメーターが含まれます。これらのパラメーターを使用すると、以下の Fluentd の動作を変更できます。

  • チャンクおよびチャンクのバッファーサイズ
  • チャンクのフラッシュ動作
  • チャンク転送の再試行動作

Fluentd は、チャンク という単一の Blob でログデータを収集します。Fluentd がチャンクを作成する際に、チャンクは ステージ にあると見なされます。ここでチャンクはデータで一杯になります。チャンクが一杯になると、Fluentd はチャンクを キュー に移動します。ここでチャンクはフラッシュされる前か、送信先に書き込まれるまで保持されます。Fluentd は、ネットワークの問題や送信先での容量の問題などのさまざまな理由でチャンクをフラッシュできない場合があります。チャンクをフラッシュできない場合、Fluentd は設定通りにフラッシュを再試行します。

OpenShift Container Platform のデフォルトで、Fluentd は 指数関数的バックオフ 方法を使用してフラッシュを再試行します。この場合、Fluentd はフラッシュを再試行するまで待機する時間を 2 倍にします。これは、送信先への接続要求を減らすのに役立ちます。指数バックオフを無効にし、代わりに 定期的な 再試行方法を使用できます。これは、指定の間隔でチャンクのフラッシュを再試行します。

これらのパラメーターは、待ち時間とスループット間のトレードオフを判断するのに役立ちます。

  • Fluentd のスループットを最適化するには、これらのパラメーターを使用して、より大きなバッファーおよびキューを設定し、フラッシュを遅延し、再試行の間隔の長く設定することで、ネットワークパケット数を減らすことができます。より大きなバッファーにはノードのファイルシステムでより多くの領域が必要になることに注意してください。
  • 待機時間が低い場合に最適化するには、パラメーターを使用してすぐにデータを送信し、バッチの蓄積を回避し、キューとバッファーが短くして、より頻繁にフラッシュおよび再試行を使用できます。

ClusterLogging カスタムリソース (CR) で以下のパラメーターを使用して、チャンクおよびフラッシュ動作を設定できます。次に、パラメーターは Fluentd で使用するために Fluentd 設定マップに自動的に追加されます。

注記

これらのパラメーターの特徴は以下の通りです。

  • ほとんどのユーザーには関連性がありません。デフォルト設定で、全般的に良いパフォーマンスが得られるはずです。
  • Fluentd 設定およびパフォーマンスに関する詳しい知識を持つ上級ユーザーのみが対象です。
  • パフォーマンスチューニングのみを目的とします。ロギングの機能面に影響を与えることはありません。

表9.10 高度な Fluentd 設定パラメーター

パラメーター説明デフォルト

chunkLimitSize

各チャンクの最大サイズ。Fluentd はこのサイズに達するとデータのチャンクへの書き込みを停止します。次に、Fluentd はチャンクをキューに送信し、新規のチャンクを開きます。

8m

totalLimitSize

ステージおよびキューの合計サイズであるバッファーの最大サイズ。バッファーサイズがこの値を超えると、Fluentd はデータのチャンクへの追加を停止し、エラーを出して失敗します。チャンクにないデータはすべて失われます。

ノードディスクの約 15% がすべての出力に分散されます。

flushInterval

チャンクのフラッシュの間隔。s (秒)、m (分)、 h (時間)、または d (日) を使用できます。

1s

flushMode

フラッシュを実行する方法:

  • lazy: timekey パラメーターに基づいてチャンクをフラッシュします。timekey パラメーターを変更することはできません。
  • interval: flushInterval パラメーターに基づいてチャンクをフラッシュします。
  • immediate: データをチャンクに追加後すぐにチャンクをフラッシュします。

interval

flushThreadCount

チャンクのフラッシュを実行するスレッドの数。スレッドの数を増やすと、フラッシュのスループットが改善し、ネットワークの待機時間が非表示になります。

2

overflowAction

キューが一杯になると、チャンク動作は以下のようになります。

  • throw_exception: ログに表示される例外を発生させます。
  • block: 詳細のバッファーの問題が解決されるまでデータのチャンクを停止します。
  • drop_oldest_chunk: 新たな受信チャンクを受け入れるために最も古いチャンクをドロップします。古いチャンクの値は新しいチャンクよりも小さくなります。

block

retryMaxInterval

exponential_backoff 再試行方法の最大時間 (秒単位)。

300s

retryType

フラッシュに失敗する場合の再試行方法:

  • exponential_backoff: フラッシュの再試行の間隔を増やします。Fluentd は、retry_max_interval パラメーターに達するまで、次の試行までに待機する時間を 2 倍にします。
  • periodic: retryWait パラメーターに基づいてフラッシュを定期的に再試行します。

exponential_backoff

retryTimeOut

レコードが破棄される前に再試行を試みる最大時間間隔。

60m

retryWait

次のチャンクのフラッシュまでの時間 (秒単位)。

1s

Fluentd チャンクのライフサイクルの詳細は、Fluentd ドキュメントの Buffer Plugins を参照してください。

手順

  1. openshift-logging プロジェクトで ClusterLogging カスタムリソース (CR) を編集します。

    $ oc edit ClusterLogging instance
  2. 以下のパラメーターを追加または変更します。

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      collection:
        fluentd:
          buffer:
            chunkLimitSize: 8m 1
            flushInterval: 5s 2
            flushMode: interval 3
            flushThreadCount: 3 4
            overflowAction: throw_exception 5
            retryMaxInterval: "300s" 6
            retryType: periodic 7
            retryWait: 1s 8
            totalLimitSize: 32m 9
    # ...
    1
    各チャンクの最大サイズを指定してから、フラッシュ用にキューに入れます。
    2
    チャンクのフラッシュの間隔を指定します。
    3
    チャンクのフラッシュを実行する方法を指定します ( lazyinterval、または immediate)。
    4
    チャンクのフラッシュに使用するスレッドの数を指定します。
    5
    キューが一杯になる場合のチャンクの動作を指定します (throw_exceptionblock、または drop_oldest_chunk)。
    6
    exponential_backoff チャンクのフラッシュ方法について最大の間隔 (秒単位) を指定します。
    7
    チャンクのフラッシュが失敗する場合の再試行タイプ (exponential_backoff または periodic) を指定します。
    8
    次のチャンクのフラッシュまでの時間 (秒単位) を指定します。
    9
    チャンクバッファーの最大サイズを指定します。
  3. Flunentd Pod が再デプロイされていることを確認します。

    $ oc get pods -l component=collector -n openshift-logging
  4. 新規の値が fluentd 設定マップにあることを確認します。

    $ oc extract configmap/collector-config --confirm

    fluentd.conf の例

    <buffer>
      @type file
      path '/var/lib/fluentd/default'
      flush_mode interval
      flush_interval 5s
      flush_thread_count 3
      retry_type periodic
      retry_wait 1s
      retry_max_interval 300s
      retry_timeout 60m
      queued_chunks_limit_size "#{ENV['BUFFER_QUEUE_LIMIT'] || '32'}"
      total_limit_size "#{ENV['TOTAL_LIMIT_SIZE_PER_BUFFER'] || '8589934592'}"
      chunk_limit_size 8m
      overflow_action throw_exception
      disable_chunk_backup true
    </buffer>