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


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

重要

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

構造化タイプ

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

  • structuredTypeKey (string, optional) は、メッセージフィールドの名前です。このフィールドの値 (ある場合) はインデックス名の作成に使用されます。

    • kubernetes.labels.<key> は、インデックス名の作成に使用される Kubernetes pod ラベルの値です。
    • openshift.labels.<key> は、インデックス名の作成に使用される ClusterLogForwarder CR の pipeline.label.<key&gt; 要素です。
    • kubernetes.container_name はコンテナー名を使用してインデックス名を作成します。
  • structuredTypeName:(文字列、オプション) structuredTypeKey が設定されておらず、そのキーが存在しない場合、OpenShift Logging は structuredTypeName の値を構造化型として使用します。structuredTypeKey and structuredTypeName の両方を使用する場合に、structuredTypeName は、構造化された TypeKey のキーが JSON ログデータにない場合にフォールバックインデックス名を指定します。
注記

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

structuredTypeKey: kubernetes.labels.<key> の例

以下と仮定します。

  • クラスターが、apache および google という 2 つの異なる形式で JSON ログを生成するアプリケーション Pod を実行している。
  • ユーザーはこれらのアプリケーション Pod に logFormat=apachelogFormat=google のラベルを付ける。
  • 以下のスニペットを ClusterLogForwarder CR YAML ファイルで使用する。
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 ログ形式と構造化タイプを使用します。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.