11.3. JSON ログ転送の有効化
ログ転送 API を設定して、構造化されたオブジェクトに対して JSON 文字列を解析できます。
11.3.1. JSON ログの解析
ClusterLogForwarder
オブジェクトを使用すると、JSON ログを解析して構造化オブジェクトにし、サポートされている出力に転送できます。
以下の構造化された JSON ログエントリーがあると想定して、これがどのように機能するか説明します。
構造化された JSON ログエントリーの例
{"level":"info","name":"fred","home":"bedrock"}
JSON ログの解析を有効にするには、以下の例のように、parse: json
を ClusterLogForwarder
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
フィールドは表示されません。
11.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=apache
とlogFormat=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
この場合は、以下の構造化ログレコードが 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 ログ形式と構造化タイプを使用します。
11.3.3. JSON ログの Elasticsearch ログストアへの転送
Elasticsearch ログストアの場合は、JSON ログエントリーが異なるスキーマに従う場合、各 JSON スキーマを 1 つの出力定義にグループ化するように ClusterLogForwarder
カスタムリソース (CR) を設定します。これにより、Elasticsearch はスキーマごとに個別のインデックスを使用します。
異なるスキーマを同じインデックスに転送するとタイプの競合やカーディナリティーの問題を引き起こす可能性があるため、データを Elasticsearch ストアに転送する前にこの設定を実行する必要があります。
インデックスが多すぎることが原因のパフォーマンスの問題を回避するには、共通のスキーマに標準化して使用できるスキーマの数を保持することを検討してください。
手順
以下のスニペットを
ClusterLogForwarder
CR YAML ファイルに追加します。outputDefaults: elasticsearch: structuredTypeKey: <log record field> structuredTypeName: <name> pipelines: - inputRefs: - application outputRefs: default parse: json
-
structuredTypeKey
フィールドを使用して、ログレコードフィールドの 1 つを指定します。 structuredTypeName
フィールドを使用して名前を指定します。重要JSON ログを解析するには、
structuredTypeKey
とstructuredTypeName
フィールドの両方を設定する必要があります。-
inputRefs
の場合は、application
、infrastructure
またはaudit
などのパイプラインを使用して転送するログタイプを指定します。 -
parse: json
要素をパイプラインに追加します。 CR オブジェクトを作成します。
$ oc create -f <filename>.yaml
Red Hat OpenShift Logging Operator がコレクター Pod を再デプロイします。ただし、再デプロイが完了しない場合は、コレクター Pod を削除して強制的に再デプロイします。
$ oc delete pod --selector logging-infra=collector
11.3.4. 同じ Pod 内のコンテナーから別のインデックスへの JSON ログの転送
構造化ログを、同じ Pod 内の異なるコンテナーから別のインデックスに転送できます。この機能を使用するには、複数コンテナーのサポートを使用してパイプラインを設定し、Pod にアノテーションを付ける必要があります。ログは接頭辞が app-
のインデックスに書き込まれます。これに対応するために、エイリアスを使用して Elasticsearch を設定することを推奨します。
ログの JSON 形式は、アプリケーションによって異なります。作成するインデックスが多すぎるとパフォーマンスに影響するため、この機能の使用は、互換性のない JSON 形式のログのインデックスの作成に限定してください。クエリーを使用して、さまざまな namespace または互換性のある JSON 形式のアプリケーションからログを分離します。
前提条件
- Red Hat OpenShift のロギング: 5.5
手順
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
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
この設定により、クラスター上のシャードの数が大幅に増加する可能性があります。
関連情報