openshiftはjsonログをどのように出力しますか

記事ディレクトリ

1.JSONロギング

RedHat®OpenShift®ContainerPlatformのバージョン4.8には、JSONロギングのサポートが含まれており、ロギングソリューションに戻っています。
お客様は、どのコンテナログがjson形式であるかを正確に制御できるようになりました。ログ管理システム（Red Hatまたはサードパーティシステムによって管理されるElasticsearchシステム）がそれらのログをどう処理するかを正確に把握できるように、一般的なJSONスキーマにタグを付けることができます。

カスタムリソースのパイプラインにparse: jsonフィールドが追加されるとClusterLogForwarder、最上位のフィールドが追加され、structured接頭辞として。が付けられます。
それらを使用して統合Elasticsearchクラスターにログデータを保存すると、新しいパイプラインごとに新しいElasticsearchインデックスが作成されます。翻訳ページに移動します

クラスターのローカルElasticsearchサーバーは、新しいインデックスが作成されるたびにパフォーマンスが大幅に低下します

目標：

構造化されたJSONロギングを示す
dev-coffeeshopプロジェクト用にカスタマイズされたClusterLoggingリソースを確認してください
Kibanaを使用した構造化ログの表示
構造化ログを他のログコレクターに送信する方法を説明する

2.dev-coffeeshop名前空間のログを追加します

この演習でClusterLogForwarderは、クラスターに既にデプロイされている次の構成を使用します。
ClusterLogForwarder構成を表示するには：

OpenShift Container Platform Webコンソールで、「プロジェクト：すべてのプロジェクト」を選択します。パースペクティブスイッチャーを使用して管理者
パースペクティブに切り替え、[検索]をクリックします。[リソース]ドロップダウンリストで、[ ClusterLogForwarder]を選択します。表示されるページでCLFインスタンスをクリックしてからYAMLをクリックします。この構成をチェックして、JSONログを作成するときの新機能を確認してください。

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  inputs:
 - application:
      namespaces:
      - dev-coffeeshop 
    name: dev-coffeeshop-input-example
  outputDefaults: 
    elasticsearch:
      structuredTypeKey:  kubernetes.namespace_name 
        # OR
      structuredTypeName: dev-coffeeshop-index-name 
  pipelines:
 - inputRefs: 
    - dev-coffeeshop-input-example
    name: pipeline-dev-coffeeshop
    outputRefs:
    - default
    parse: json
 - inputRefs: 
    - infrastructure
    - application
    - audit
    outputRefs:
    - default

dev-coffeeshop名前空間からログをブートストラップするためのカスタム入力。
デフォルトの出力はクラスターのElasticsearchであり、リモートサーバーではありません。
これにより、名前空間に基づいてElasticsearchに構造化ログインデックスが設定されます。
インデックスに名前を付けるユーザー定義の文字列。存在する場合は1の前に付けますstructuredTypeKey。
JSON解析を有効にするパイプライン。
JSON解析なしのすべての一般的な入力のパイプライン。

Elasticsearchの新しいJSONログパイプラインはすべて、Elasticsearchに新しいインデックスを作成します。コマンドラインから、ESインデックスのクイックリストを取得できます。oc exec $es_pod -c elasticsearch -- indices

後で、dev-coffeshop名前空間のcafeアプリケーションで利用可能な構造化ログが表示されます。

Kibanaでクエリを作成し、そこからログメッセージstructured.messageのみを取得します。

3.Kibanaで構造化ログを確認します

この演習でopenshift-loggingは、名前空間のKibanaルートを介してKibana Webコンソールにアクセスし、構造化ログを照会します。

3.1オープンキバナルート

1. OpenShift Container Platform Webコンソール管理者の観点からルートとしてKibanaURLを見つけ、それがチェックされていることを確認しますProject: OpenShift -logging。
2.ナビゲーションメニューで、「Network → Routes」に移動します。
Kibanaサービスがどこにあるかを見るのを楽しみにしています。
3.場所をクリックして開きます。

3.2ビルドインデックスモード

Kibana Webコンソールで、をクリックしますManagement.
をクリックしIndex Patternsます。
をクリックしCreate index patternます。
Index patternフィールドにと入力しapp-dev-coffeeshop-*、をクリックしますNext Step。
Time Filterフィールドで、を選択します@timestamp。
をクリックしCreate index patternます。

3.3Kibanaを使用したElasticsearchのクエリ

をクリックしDiscoverます。
まだ選択されていない場合はapp-dev-coffeeshop-*、左側のドロップダウンリストを使用して選択しますapp-dev-coffeeshop-*。
最初に見つかったログエントリで、右矢印▶ログの詳細を表示をクリックします。
リストの一番下で、structuredエントリを見つけます。をelements,含むstructured.hostName
structured.message,structured.level

ここに画像の説明を挿入
異なるJSON形式の各ログ入力タイプは、Elasticsearchデータベースに新しいインデックスを作成して、異なるstructured.*データを処理します。「Apache」、「Google」などの標準のJSON形式でログを整理して、リソースを節約します。

4.トラブルシューティングを容易にするためにログクエリをクリーンアップします

アプリケーションは常にメッセージを送信しているため、混乱を解消し、状況に適したメッセージとクエリ結果のみを表示する方法が必要です。構造化されたJSONロギングにより、これが簡単になります。

まず、データが明確でなく、検索できない厄介なメッセージを見てください。

Available Field以下を見つけ*t* messageてクリックしてくださいadd。
ログ出力がどのように読みやすいかを観察しますが、メッセージはまだあいまいです-これは、出力を見るときに一般的です

照合された情報：

Selected fields検索の下*t* messageでクリックしますremove。
検索の下で* 、、、およびAvailable fieldsをクリックしますaddt* structured.message*t* structured.origin*t* structured.type
ここには、決定を下すために必要な主要なデータのみが表示されていることに注意してください。

orderIDオリジンとタイプの注文の詳細をとFINISHEDの注文ステータスと相関させる何らかの方法があればCOLLECTEDいいのにと思います。この目標を達成するために、開発者にどのようなコード変更を依頼しますか？

このコースの後半で、prod-coffeshop名前空間をこのロギングパイプラインに追加し、クエリを更新します。
それでは、OpenShift ContainerPlatform4.8のもう1つの重要な機能であるCertifiedHelmChartsを見てみましょう。