10.3. JSON ログ転送の有効化
ログ転送 API を設定して、構造化されたオブジェクトに対して JSON 文字列を解析できます。
10.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 フィールドは表示されません。
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>は、インデックス名の作成に使用されるClusterLogForwarderCR の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のラベルを付ける。 -
以下のスニペットを
ClusterLogForwarderCR 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 ログ形式と構造化タイプを使用します。
10.3.3. JSON ログの Elasticsearch ログストアへの転送
Elasticsearch ログストアの場合は、JSON ログエントリーが異なるスキーマに従う場合、各 JSON スキーマを 1 つの出力定義にグループ化するように ClusterLogForwarder カスタムリソース (CR) を設定します。これにより、Elasticsearch はスキーマごとに個別のインデックスを使用します。
異なるスキーマを同じインデックスに転送するとタイプの競合やカーディナリティーの問題を引き起こす可能性があるため、データを Elasticsearch ストアに転送する前にこの設定を実行する必要があります。
インデックスが多すぎることが原因のパフォーマンスの問題を回避するには、共通のスキーマに標準化して使用できるスキーマの数を保持することを検討してください。
手順
以下のスニペットを
ClusterLogForwarderCR 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
10.3.4. 同じ Pod 内のコンテナーから別のインデックスへの JSON ログの転送
構造化ログを、同じ Pod 内の異なるコンテナーから別のインデックスに転送できます。この機能を使用するには、複数コンテナーのサポートを使用してパイプラインを設定し、Pod にアノテーションを付ける必要があります。ログは接頭辞が app- のインデックスに書き込まれます。これに対応するために、エイリアスを使用して Elasticsearch を設定することを推奨します。
ログの JSON 形式は、アプリケーションによって異なります。作成するインデックスが多すぎるとパフォーマンスに影響するため、この機能の使用は、互換性のない JSON 形式のログのインデックスの作成に限定してください。クエリーを使用して、さまざまな namespace または互換性のある JSON 形式のアプリケーションからログを分離します。
前提条件
- Red Hat OpenShift のロギング: 5.5
手順
ClusterLogForwarderCR オブジェクトを定義する 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: jsonPodCR オブジェクトを定義する 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
この設定により、クラスター上のシャードの数が大幅に増加する可能性があります。
関連情報
