10.3. JSON ログ転送の有効化


ログ転送 API を設定して、構造化されたオブジェクトに対して JSON 文字列を解析できます。

10.3.1. JSON ログの解析

ClusterLogForwarder オブジェクトを使用すると、JSON ログを解析して構造化オブジェクトにし、サポートされている出力に転送できます。

以下の構造化された JSON ログエントリーがあると想定して、これがどのように機能するか説明します。

構造化された JSON ログエントリーの例

{"level":"info","name":"fred","home":"bedrock"}

JSON ログの解析を有効にするには、以下の例のように、parse: jsonClusterLogForwarder CR のパイプラインに追加します。

parse: json を示すスニペット例

pipelines:
- inputRefs: [ application ]
  outputRefs: myFluentd
  parse: json

parse: json を使用して JSON ログの解析を有効にすると、CR は以下の例のように構造化された JSON ログエントリーを structured フィールドにコピーします。

構造化された JSON ログエントリーを含む 構造化された 出力例

{"structured": { "level": "info", "name": "fred", "home": "bedrock" },
 "more fields..."}

重要

ログエントリーに有効な構造化された JSON がない場合、structured フィールドは表示されません。

10.3.2. Elasticsearch の JSON ログデータの設定

JSON ログが複数のスキーマに従う場合は、それらを 1 つのインデックスに保存すると、タイプの競合やカーディナリティーの問題が発生する可能性があります。これを回避するには、1 つの出力定義に、各スキーマをグループ化するように ClusterLogForwarder カスタムリソース (CR) を設定する必要があります。これにより、各スキーマが別のインデックスに転送されます。

重要

JSON ログを OpenShift Logging によって管理されるデフォルトの Elasticsearch インスタンスに転送する場合に、設定に基づいて新規インデックスが生成されます。インデックスが多すぎることが原因のパフォーマンスの問題を回避するには、共通のスキーマに標準化して使用できるスキーマの数を保持することを検討してください。

構造化タイプ

ClusterLogForwarder CR で以下の構造タイプを使用し、Elasticsearch ログストアのインデックス名を作成できます。

  • structuredTypeKey はメッセージフィールドの名前です。このフィールドの値はインデックス名の作成に使用されます。

    • kubernetes.labels.<key> は、インデックス名の作成に使用される Kubernetes pod ラベルの値です。
    • openshift.labels.<key> は、インデックス名の作成に使用される ClusterLogForwarder CR の pipeline.label.<key> 要素です。
    • kubernetes.container_name はコンテナー名を使用してインデックス名を作成します。
  • structuredTypeName: structuredTypeKey フィールドが設定されていない場合、またはそのキーが存在しない場合、structuredTypeName 値が構造化タイプとして使用されます。structuredTypeKey フィールドと structuredTypeName フィールドの両方を一緒に使用すると、structuredTypeKey フィールドのキーが JSON ログデータにない場合に、structuredTypeName 値によってフォールバックインデックス名が提供されます。
注記

structuredTypeKey の値を "Log Record Fields" トピックに記載されている任意のフィールドに設定できますが、構造タイプの前に来るリストに最も便利なフィールドが表示されます。

structuredTypeKey: kubernetes.labels.<key> の例

以下と仮定します。

  • クラスターが、"apache" および "google" という 2 つの異なる形式で JSON ログを生成するアプリケーション Pod を実行している。
  • ユーザーはこれらのアプリケーション Pod に logFormat=apachelogFormat=google のラベルを付ける。
  • 以下のスニペットを ClusterLogForwarder CR YAML ファイルで使用する。
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
# ...
  outputDefaults:
    elasticsearch:
      structuredTypeKey: kubernetes.labels.logFormat 1
      structuredTypeName: nologformat
  pipelines:
  - inputRefs:
    - application
    outputRefs:
    - default
    parse: json 2
1
Kubernetes logFormat ラベルで形成される key-value ペアの値を使用します。
2
JSON ログの解析を有効にします。

この場合は、以下の構造化ログレコードが app-apache-write インデックスに送信されます。

{
  "structured":{"name":"fred","home":"bedrock"},
  "kubernetes":{"labels":{"logFormat": "apache", ...}}
}

また、以下の構造化ログレコードは app-google-write インデックスに送信されます。

{
  "structured":{"name":"wilma","home":"bedrock"},
  "kubernetes":{"labels":{"logFormat": "google", ...}}
}

A structuredTypeKey: openshift.labels.<key> の例

以下のスニペットを ClusterLogForwarder CR YAML ファイルで使用すると仮定します。

outputDefaults:
 elasticsearch:
    structuredTypeKey: openshift.labels.myLabel 1
    structuredTypeName: nologformat
pipelines:
 - name: application-logs
   inputRefs:
   - application
   - audit
   outputRefs:
   - elasticsearch-secure
   - default
   parse: json
   labels:
     myLabel: myValue 2
1
OpenShift myLabel ラベルによって形成されるキーと値のペアの値を使用します。
2
myLabel 要素は、文字列の値 myValue を構造化ログレコードに提供します。

この場合は、以下の構造化ログレコードが app-myValue-write インデックスに送信されます。

{
  "structured":{"name":"fred","home":"bedrock"},
  "openshift":{"labels":{"myLabel": "myValue", ...}}
}

その他の考慮事項

  • 構造化レコードの Elasticsearch インデックス は、構造化タイプの前に "app-" を、後ろに "-write" を追加することによって形成されます。
  • 非構造化レコードは、構造化されたインデックスに送信されません。これらは、通常アプリケーション、インフラストラクチャー、または監査インデックスでインデックス化されます。
  • 空でない構造化タイプがない場合は、unstructured レコードを structured フィールドなしで転送します。

過剰なインデックスで Elasticsearch を読み込まないようにすることが重要です。各アプリケーションや namespace ごとにではなく、個別のログ形式 のみに特定の構造化タイプを使用します。たとえば、ほとんどの Apache アプリケーションは、LogApache などの同じ JSON ログ形式と構造化タイプを使用します。

10.3.3. JSON ログの Elasticsearch ログストアへの転送

Elasticsearch ログストアの場合は、JSON ログエントリーが異なるスキーマに従う場合、各 JSON スキーマを 1 つの出力定義にグループ化するように ClusterLogForwarder カスタムリソース (CR) を設定します。これにより、Elasticsearch はスキーマごとに個別のインデックスを使用します。

重要

異なるスキーマを同じインデックスに転送するとタイプの競合やカーディナリティーの問題を引き起こす可能性があるため、データを Elasticsearch ストアに転送する前にこの設定を実行する必要があります。

インデックスが多すぎることが原因のパフォーマンスの問題を回避するには、共通のスキーマに標準化して使用できるスキーマの数を保持することを検討してください。

手順

  1. 以下のスニペットを ClusterLogForwarder CR YAML ファイルに追加します。

    outputDefaults:
     elasticsearch:
        structuredTypeKey: <log record field>
        structuredTypeName: <name>
    pipelines:
    - inputRefs:
      - application
      outputRefs: default
      parse: json
  2. structuredTypeKey フィールドを使用して、ログレコードフィールドの 1 つを指定します。
  3. structuredTypeName フィールドを使用して名前を指定します。

    重要

    JSON ログを解析するには、structuredTypeKeystructuredTypeName フィールドの両方を設定する必要があります。

  4. inputRefs の場合は、applicationinfrastructure または audit などのパイプラインを使用して転送するログタイプを指定します。
  5. parse: json 要素をパイプラインに追加します。
  6. CR オブジェクトを作成します。

    $ oc create -f <filename>.yaml

    Red Hat OpenShift Logging Operator がコレクター Pod を再デプロイします。ただし、再デプロイが完了しない場合は、コレクター Pod を削除して強制的に再デプロイします。

    $ oc delete pod --selector logging-infra=collector

10.3.4. 同じ Pod 内のコンテナーから別のインデックスへの JSON ログの転送

構造化ログを、同じ Pod 内の異なるコンテナーから別のインデックスに転送できます。この機能を使用するには、複数コンテナーのサポートを使用してパイプラインを設定し、Pod にアノテーションを付ける必要があります。ログは接頭辞が app- のインデックスに書き込まれます。これに対応するために、エイリアスを使用して Elasticsearch を設定することを推奨します。

重要

ログの JSON 形式は、アプリケーションによって異なります。作成するインデックスが多すぎるとパフォーマンスに影響するため、この機能の使用は、互換性のない JSON 形式のログのインデックスの作成に限定してください。クエリーを使用して、さまざまな namespace または互換性のある JSON 形式のアプリケーションからログを分離します。

前提条件

  • Red Hat OpenShift のロギング: 5.5

手順

  1. ClusterLogForwarder CR オブジェクトを定義する YAML ファイルを作成または編集します。

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      outputDefaults:
        elasticsearch:
          structuredTypeKey: kubernetes.labels.logFormat 1
          structuredTypeName: nologformat
          enableStructuredContainerLogs: true 2
      pipelines:
      - inputRefs:
        - application
        name: application-logs
        outputRefs:
        - default
        parse: json
    1
    Kubernetes logFormat ラベルで形成される key-value ペアの値を使用します。
    2
    マルチコンテナー出力を有効にします。
  2. Pod CR オブジェクトを定義する YAML ファイルを作成または編集します。

    apiVersion: v1
    kind: Pod
    metadata:
      annotations:
        containerType.logging.openshift.io/heavy: heavy 1
        containerType.logging.openshift.io/low: low
    spec:
      containers:
      - name: heavy 2
        image: heavyimage
      - name: low
        image: lowimage
    1
    形式: containerType.logging.openshift.io/<container-name>: <index>
    2
    アノテーション名はコンテナー名と同じでなければなりません。
警告

この設定により、クラスター上のシャードの数が大幅に増加する可能性があります。

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.