4.2. ロギングデプロイメントの設定

各 Operator によって実装されたカスタムリソース (CR) YAML ファイルを使用して、ロギングサブシステムのデプロイメントを設定できます。

Red Hat Openshift Logging Operator:

  • ClusterLogging (CL) - コレクターとフォワーダーをデプロイします。現在、どちらも各ノードで実行されているデーモンセットによって実装されています。
  • ClusterLogForwarder (CLF)- ユーザー設定ごとにログを転送するためのコレクター設定を生成します。

Loki Operator:

  • LokiStack - Loki クラスターをログストアとして制御し、OpenShift Container Platform 認証統合を使用して Web プロキシーを制御して、マルチテナンシーを強制します。

OpenShift Elasticsearch Operator:

注記

これらの CR は ClusterLogging Operator によって生成および管理され、手動で変更すると必ず Operator によって上書きされます。

  • Elasticsearch - Elasticsearch インスタンスをデフォルトのログストアとして設定し、デプロイします。
  • Kibana - ログの検索、クエリー、表示を実行するために Kibana インスタンスを設定し、デプロイします。

このドキュメントで説明されている設定オプションのみがログサブシステムでサポートされています。

他の設定オプションはサポートされていないため、使用しないでください。設定のパラダイムが OpenShift Container Platform リリース間で変更される可能性があり、このような変更は、設定のすべての可能性が制御されている場合のみ適切に対応できます。Operator は相違点を調整するように設計されているため、このドキュメントで説明されている以外の設定を使用すると、変更は上書きされます。

注記

OpenShift Container Platform ドキュメントで説明されていない設定を実行する必要がある場合は、Red Hat OpenShift Logging Operator を Unmanaged に設定する必要があります。Red Hat OpenShift のアンマネージドロギングサブシステムはサポートされていないため、ステータスを Managed に戻すまで更新は受信されません。

4.2.1. Loki でストリームベースの保持の有効化

Logging バージョン 5.6 以降では、ログストリームに基づいて保持ポリシーを設定できます。これらのルールは、グローバル、テナントごと、またはその両方で設定できます。両方で設定すると、グローバルルールの前にテナントルールが適用されます。

  1. ストリームベースの保持を有効にするには、LokiStack カスタムリソース (CR) を作成します。

    グローバルなストリームベースの保持の例

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: logging-loki
      namespace: openshift-logging
    spec:
      limits:
        global: 1
          retention: 2
            days: 20
            streams:
            - days: 4
              priority: 1
              selector: '{kubernetes_namespace_name=~"test.+"}' 3
            - days: 1
              priority: 1
              selector: '{log_type="infrastructure"}'
      managementState: Managed
      replicationFactor: 1
      size: 1x.small
      storage:
        schemas:
        - effectiveDate: "2020-10-11"
          version: v11
        secret:
          name: logging-loki-s3
          type: aws
      storageClassName: standard
      tenants:
        mode: openshift-logging

    1
    すべてのログストリームの保持ポリシーを設定します。注記: このフィールドは、オブジェクトストレージに保存されたログの保持期間には影響しません。
    2
    このブロックが CR に追加されると、クラスターで保持が有効になります。
    3
    ログストリームの定義に使用される LogQL クエリー が含まれています。

    テナントごとのストリームベースの保持の例

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: logging-loki
      namespace: openshift-logging
    spec:
      limits:
        global:
          retention:
            days: 20
        tenants: 1
          application:
            retention:
              days: 1
              streams:
                - days: 4
                  selector: '{kubernetes_namespace_name=~"test.+"}' 2
          infrastructure:
            retention:
              days: 5
              streams:
                - days: 1
                  selector: '{kubernetes_namespace_name=~"openshift-cluster.+"}'
      managementState: Managed
      replicationFactor: 1
      size: 1x.small
      storage:
        schemas:
        - effectiveDate: "2020-10-11"
          version: v11
        secret:
          name: logging-loki-s3
          type: aws
      storageClassName: standard
      tenants:
        mode: openshift-logging

    1
    テナントごとの保持ポリシーを設定します。有効なテナントタイプは、applicationaudit、および infrastructure です。
    2
    ログストリームの定義に使用される LogQL クエリー が含まれています。
  2. LokiStack CR を適用します。

    $ oc apply -f <filename>.yaml
注記

これは、保存されたログの保持を管理するためのものではありません。保存されたログのグローバルな保持期間 (最大 30 日間までサポート) は、オブジェクトストレージで設定します。

4.2.2. 複数行の例外検出の有効化

コンテナーログの複数行のエラー検出を有効にします。

警告

この機能を有効にすると、パフォーマンスに影響が出る可能性があり、追加のコンピューティングリソースや代替のロギングソリューションが必要になる場合があります。

ログパーサーは頻繁に、同じ例外の個別の行を別々の例外として誤って識別します。その結果、余分なログエントリーが発生し、トレースされた情報が不完全または不正確な状態で表示されます。

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: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  pipelines:
    - name: my-app-logs
      inputRefs:
        - application
      outputRefs:
        - default
      detectMultilineErrors: true

4.2.2.1. 詳細

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

表4.1 各コレクターでサポートされている言語:

言語FluentdVector

Java

JS

Ruby

Python

golang

PHP

 

Dart

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