|
この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。 |
ログ記録のベストプラクティス
このガイドでは、クラスター全体のログ記録とアプリケーションのログ記録に関するベストプラクティスを推奨します。
Rancher v2.5以前は、Rancherのログ記録は歴史的にかなり静的な統合でした。選択できる集約器の固定リスト（Elasticsearch、Splunk、Kafka、Fluentd、Syslog）があり、選択できる構成ポイントは2つ（クラスター全体とプロジェクトレベル）だけでした。
Rancherは、ログ集約の柔軟な体験を提供します。ログ記録機能を使用することで、管理者とユーザーは、細かい収集基準を満たすログ記録をデプロイでき、より多くの宛先と設定オプションを提供します。
「内部的には」、Rancherのログ記録は ログオペレーターを使用しています。このオペレーター（およびそのリソース）の管理性を提供し、その体験をRancherクラスターの管理と結びつけます。
クラスター全体のログ記録
クラスター全体のスクレイピング
一部のユーザーにとって、クラスター内で実行されているすべてのコンテナからログをスクレイピングすることが望ましいです。これは通常、すべての実行ポイントからすべてのログを収集するというセキュリティチームの要求（または要件）と一致します。
このシナリオでは、少なくとも2つの_ClusterOutput_オブジェクトを作成することをお勧めします - 1つはセキュリティチーム用（その要件がある場合）、もう1つはクラスター管理者である自分たち用です。これらのオブジェクトを作成する際は、クラスター全体からの大量のログトラフィックを処理できる出力エンドポイントを選択するように注意してください。また、これらのすべてのログを受信するための適切なインデックスを選択することを確認してください。
これらの_ClusterOutput_オブジェクトを作成したら、すべてのログを収集するために_ClusterFlow_を作成します。このフローに_Include_または_Exclude_ルールを定義しないでください。これにより、クラスター全体からのすべてのログが収集されることが保証されます。_ClusterOutputs_が2つある場合は、両方にログを送信するようにしてください。
アプリケーションのログ記録
Kubernetesだけでなく、すべてのコンテナベースのアプリケーションにおけるベストプラクティスは、アプリケーションログを`stdout`/`stderr`に向けることです。コンテナランタイムはこれらのログを捕捉し、*何か*を行います - 通常はファイルに書き込みます。コンテナランタイム（およびその設定）によっては、これらのログはさまざまな場所に保存される可能性があります。
ログをファイルに書き込む場合、Kubernetesは各ホストに`/var/log/containers`ディレクトリを作成することで支援します。このディレクトリは、ログファイルを実際の宛先にシンボリックリンクします（これは設定やコンテナランタイムによって異なる場合があります）。
Rancherログは`/var/log/containers`内のすべてのログエントリを読み取り、すべてのコンテナからのすべてのログエントリ（デフォルト設定を前提とする）を収集して処理する機会を確保します。
特定のログファイル
ログ収集は、Kubernetesのポッドから`stdout`/`stderr`ログのみを取得します。しかし、アプリケーションによって生成された他のファイルからログを収集したい場合はどうでしょうか？ここで、ログストリーミングサイドカー（または2つ）が役立つかもしれません。
ストリーミングサイドカーを設定する目的は、ディスクに書き込まれたログファイルを取得し、その内容を`stdout`にストリーミングすることです。このようにして、ログオペレーターはそれらのログを取得し、適切な出力に送信できます。
これを設定するには、ワークロードリソース（例：Deployment）を編集し、次のサイドカード定義を追加します。
...
containers:
- args:
- -F
- /path/to/your/log/file.log
command:
- tail
image: busybox
name: stream-log-file-[name]
volumeMounts:
- mountPath: /path/to/your/log
name: mounted-log
...これにより、(この例では)`/path/to/your/log/file.log`の内容を`stdout`にストリーミングするワークロード定義にコンテナが追加されます。
このログストリームは、設定した_Flows_または_ClusterFlows_に従って自動的に収集されます。このログファイルのために、コンテナの名前をターゲットにして特定の_Flow_を作成することを検討することもできます。例を参照してください：
...
spec:
match:
- select:
container_names:
- stream-log-file-name
...一般的なベストプラクティス
-
可能な限り、構造化されたログエントリ（例：
syslog、JSON）を出力してください。これにより、これらの形式用にすでに作成されたパーサーがあるため、ログエントリの処理が容易になります。 -
ログエントリ内に、ログエントリを作成しているアプリケーションの名前を提供するようにしてください。Kubernetesオブジェクトは常にアプリケーションの名前をオブジェクト名として持っているわけではないため、トラブルシューティングが容易になります。例えば、Pod IDは`myapp-098kjhsdf098sdf98`のようなものであり、コンテナ内で実行されているアプリケーションに関する情報はあまり提供されません。
-
すべてのログをクラスター全体で収集する場合を除き、_Flow_および_ClusterFlow_オブジェクトのスコープをできるだけ限定してください。これにより、問題が発生した際のトラブルシューティングが容易になり、無関係なログエントリがアグリゲーターに表示されないようにするのにも役立ちます。厳密なスコーピングの例としては、名前空間内の単一の_デプロイメント_に_Flow_を制約するか、あるいは_Pod_内の単一のコンテナに制約することが考えられます。
-
トラブルシューティングを行う場合を除き、ログの冗長性を抑えてください。高いログの冗長性は多くの問題を引き起こしますが、その中でも主なものは*noise*です：重要なイベントが`DEBUG`メッセージの海の中で埋もれてしまう可能性があります。これは自動アラートやスクリプトによってある程度軽減されますが、高度に冗長なログは依然としてログインフラストラクチャに過度のストレスをかけます。
-
可能な限り、ログエントリにトランザクションまたはリクエストIDを提供するようにしてください。これにより、特に分散アプリケーションを扱う際に、複数のログソースにわたるアプリケーションのアクティビティを追跡しやすくなります。