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>は、インデックス名の作成に使用されるClusterLogForwarderCR のpipeline.label.<key> 要素です。 -
kubernetes.container_nameはコンテナー名を使用してインデックス名を作成します。
-
-
structuredTypeName:(文字列、オプション)structuredTypeKeyが設定されておらず、そのキーが存在しない場合、OpenShift Logging はstructuredTypeNameの値を構造化型として使用します。structuredTypeKeyandstructuredTypeNameの両方を使用する場合に、structuredTypeNameは、構造化されたTypeKeyのキーが JSON ログデータにない場合にフォールバックインデックス名を指定します。
structuredTypeKey の値を Log Record Fields トピックに記載されている任意のフィールドに設定できますが、構造タイプの前に来る一覧に最も便利なフィールドが表示されます。
structuredTypeKey: kubernetes.labels.<key> の例
以下と仮定します。
- クラスターが、apache および google という 2 つの異なる形式で JSON ログを生成するアプリケーション Pod を実行している。
-
ユーザーはこれらのアプリケーション Pod に
logFormat=apacheとlogFormat=googleのラベルを付ける。 -
以下のスニペットを
ClusterLogForwarderCR YAML ファイルで使用する。
outputDefaults:
- elasticsearch:
structuredTypeKey: kubernetes.labels.logFormat 1
structuredTypeName: nologformat
pipelines:
- inputRefs: <application>
outputRefs: default
parse: json 2
この場合、以下の構造化ログレコードが 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
この場合、以下の構造化ログレコードが app-myValue-write インデックスに送信されます。
{
"structured":{"name":"fred","home":"bedrock"},
"openshift":{"labels":{"myLabel": "myValue", ...}}
}その他の考慮事項
- 構造化されたレコードの Elasticsearch インデックス は、構造化型の前に app-を、後ろに-write を追加して設定されます。
- 非構造化レコードは、構造化されたインデックスに送信されません。これらは、通常アプリケーション、インフラストラクチャー、または監査インデックスでインデックス化されます。
-
空でない構造化タイプがない場合は、unstructured レコードを
structuredフィールドなしで転送します。
過剰なインデックスで Elasticsearch を読み込まないようにすることが重要です。各アプリケーションや namespace ごとにではなく、個別のログ形式 のみに特定の構造化タイプを使用します。たとえば、ほとんどの Apache アプリケーションは、LogApache などの同じ JSON ログ形式と構造化タイプを使用します。
