ログ収集のベストプラクティス

概要概要

この記事では、Tencent Cloud Container Service TKEのログ機能を使用してログを収集、保存、クエリし、さまざまな機能の使用法とシナリオを分析し、いくつかのベストプラクティスの提案を行う方法を紹介します。

注：この記事はTKEクラスターにのみ適用されます。

すぐに始める方法は？

TKEロギングの入り口集群运维-日志规则、TKEクラスターのログ収集と使用基準を有効にする方法の詳細については、公式ドキュメントのログ収集を参照してください。

技術アーキテクチャとは何ですか？

TKEクラスターがログ収集を開始した後、tke-log-agentはDaemonSetとして各ノードにデプロイされ、収集ルールに従ってノード上のコンテナーのログを収集し、CLSログサービスにレポートします。CLSは統合されたストレージ、取得、および分析を実行します。

ログはどこで収集されますか？

TKEでログコレクションを使用する場合、ログコレクションに集群运维-日志规则新しいルールを作成する必要があります。最初に、どのデータソースが目標のコレクションであるかを判断する必要があります。ここでは、サポートされる3種類のデータソースとそれぞれの使用シナリオおよび提案を示します。

標準出力を収集する

最も簡単で最も推奨される方法は、ポッド内部コンテナのログを標準出力に出力することです。ログの内容は、コンテナランタイム（docker、containerd）によって管理されます。これには、次の利点があります。

1. 追加のボリュームは必要ありません。
2. kubectl logsログの内容を直接表示できます。
3. ビジネスではログのローテーションを気にする必要はありません。個々のポッドログが大量にあるためにディスクがいっぱいになるのを防ぐために、ログはコンテナの実行時に保存され、自動的にローテーションされます。
4. ログファイルのパスを気にする必要はありません。より統一された収集ルールを使用し、より少ない収集ルールを使用してより多くのワークロードをカバーし、操作と保守の複雑さを軽減できます。

サンプル取得構成：

コンテナにファイルを収集します

多くの場合、ビジネスはログファイルを書き込むことによってログを記録します。コンテナを使用してビジネスを実行すると、ログファイルはコンテナに書き込まれます。

1. ログファイルが配置されているパスがボリュームでマウントされていない場合、ログファイルはコンテナの書き込み可能レイヤーに書き込まれ、コンテナデータディスクに配置されます。通常のパスは/var/lib/docker（システムディスクとの混合を避けるために、このパスにマウントすることをお勧めします）。コンテナが停止した後。ログはクリアされます。
2. マウントボリュームのログファイルパスの場合、ログファイルはディスクタイプのストレージバックエンドに対応するドロップボリュームになります。通常はemptydirで、コンテナの停止後/var/lib/kubelet、パスのドロップのホストディスクへのログファイルの操作中にログがクリアされます。このパスには通常、個別のディスクはありません。つまり、システムディスクが使用されます。ログ収集機能と統合ストレージ機能を使用するため、ログファイルを保存するために他の永続ストレージ（クラウドハードディスクCBS、オブジェクトストレージCOSなど）をマウントすることはお勧めしません。共有ストレージ（CFS）。

多くのオープンソースログコレクターは、収集するためにポッドログファイルパスにボリュームをマウントする必要がありますが、TKEを使用したログ収集ではないため、コンテナー内のファイルにログを出力する場合、ボリュームをマウントするかどうかを気にする必要はありません。

サンプル取得構成：

ホストでファイルを収集する

ビジネスがログをログファイルに書き込み、コンテナが停止した後も元のログファイルを保持したい場合は、コレクションが異常なときにログが完全に失われないようにバックアップを作成しておくと、hostPathをログファイルパスにマウントできます。ログファイルは次のようになります。ディスクをホストの指定されたディレクトリにドロップすると、コンテナが停止した後、ログファイルはクリーンアップされません。

ログファイルは自動的にクリーンアップされないため、ログが繰り返し収集されることを心配する学生もいます。たとえば、ポッドが移動するようにスケジュールされてから戻るようにスケジュールされている場合、ログファイルは以前と同じパスに書き込まれます。コレクションが繰り返されるかどうかには、2つの状況があります。

1. 固定ファイルパスなど、ファイル名は同じです/data/log/nginx/access.log。コレクターは以前に収集されたログファイルの場所を記憶し、増分部分のみを収集するため、この時点では収集は繰り返されません。
2. ファイル名が異なります。通常、ビジネス用のログフレームワークは、特定の期間に従って、通常は日ごとにログを自動的にローテーションし、タイムスタンプサフィックスが付いた古いログファイルの名前を自動的に変更します。ログファイル名と一致するようにコレクションルールで「*」がワイルドカードとして使用されている場合、ログフレームワークがログファイルの名前を変更した後、コレクターは新しく書き込まれたログファイルと一致すると見なすため、コレクションが繰り返される可能性があります。コレクションを1回実行します。

したがって、通常は繰り返し収集されません。ログフレームワークがログを自動的にローテーションする場合、収集ルールでワイルドカード「*」を使用してログファイルを照合しないことをお勧めします。

サンプル取得構成：

ログはどこで嘔吐しましたか？

データを収集する場所を知った後、収集したログをどこに保存するかも知る必要があります。上記の技術アーキテクチャによれば、TKEログ収集はクラウド上のCLSログサービスと統合されており、ログデータもログサービスに一律に報告されます。ログサービスは、ログセットとログトピックを介してログを管理します。ログセットはCLSのプロジェクト管理ユニットであり、複数のログトピックを含めることができます。通常、同じビジネスのログは同じログセット、同じビジネスの同じカテゴリに配置されます。アプリケーションまたはサービスは同じログテーマを使用します。TKEでは、ログ収集ルールとログトピックは1対1で対応します。TKEがログ収集ルールを作成するときに、コンシューマー側を選択し、ログセットとログサブジェクトを指定する必要があります。ログセットは通常、事前に作成されます。 、ログテーマは通常自動的に作成されます。

作成後、状況に応じて自動的に作成されたログサブジェクトの名前を変更できるため、以降の取得時にログのログサブジェクトを見つけることができます。

ログ形式の解析を構成するにはどうすればよいですか？

ログの元のデータを使用して、ログサービスにログを解析して後続の取得を容易にする方法を指示する必要もあります。ログ収集ルールを作成するときは、ログ解析形式を構成する必要があります。構成ごとに、次の分析と提案が示されています。

どのクロールモードを使用しますか？

まず、ログキャプチャモードを決定する必要があります。これは、単一行テキスト、JSON、区切り文字、複数行テキスト、および完全な正規化の5つのタイプをサポートします。

JSON形式自体がログを構成するため、JSONの使用をお勧めします。ログサービスは、フィールド名としてJSONのキーを抽出し、対応するフィールド値として値を抽出できます。ビジネスログの出力形式に従って複雑なマッチングルールを構成する必要がなくなりました。ログの例：

{"remote_ip":"10.135.46.111","time_local":"22/Jan/2019:19:19:34 +0800","body_sent":23,"responsetime":0.232,"upstreamtime":"0.232","upstreamhost":"unix:/tmp/php-cgi.sock","http_host":"127.0.0.1","method":"POST","url":"/event/dispatch","request":"POST /event/dispatch HTTP/1.1","xff":"-","referer":"http://127.0.0.1/my/course/4","agent":"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Firefox/64.0","response_code":"200"}

JSONキャプチャモードを使用する前提は、ビジネスログ自体がJSON形式で出力されることです。JSON形式ではないが、JSON形式への切り替えに費用がかからない場合は、切り替えることをお勧めします。切り替えが簡単でない場合は、他のキャプチャを検討してください。パターンを取ります。

ログの内容が固定形式の1行のテキスト出力である場合は、「区切り文字」または「完全に通常の」キャプチャモードの使用を検討してください。「Separator」は単純な形式を適用します。ログの各フィールド値は、「:::」などの固定文字列で区切られます。ログの内容は次のとおりです。

10.20.20.10 ::: [Tue Jan 22 14:49:45 CST 2019 +0800] ::: GET /online/sample HTTP/1.1 ::: 127.0.0.1 ::: 200 ::: 647 ::: 35 ::: http://127.0.0.1/

「:::」を構成してセパレーターをカスタマイズし、各フィールドのフィールド名を順番に構成できます（例：

「完全正規」は複雑な形式に適用され、ログ形式と一致するように正規式を使用します。たとえば、ログの内容は次のとおりです。

10.135.46.111 - - [22/Jan/2019:19:19:30 +0800] "GET /my/course/1 HTTP/1.1" 127.0.0.1 200 782 9703 "http://127.0.0.1/course/explore?filter%5Btype%5D=all&filter%5Bprice%5D=all&filter%5BcurrentLevelId%5D=all&orderBy=studentNum" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Firefox/64.0"  0.354 0.354

正規式は次のように設定できます。

(\S+)[^\[]+(\[[^:]+:\d+:\d+:\d+\s\S+)\s"(\w+)\s(\S+)\s([^"]+)"\s(\S+)\s(\d+)\s(\d+)\s(\d+)\s"([^"]+)"\s"([^"]+)"\s+(\S+)\s(\S+).*

ログサービスは()キャプチャグループを使用して各フィールドを区別します。また、各フィールドのフィールド名を設定する必要があります。構成例：

ログの出力形式が固定されていない場合は、「単一行テキスト」または「複数行テキスト」キャプチャモードの使用を検討してください。これら2つのモードを使用すると、ログコンテンツ自体は構造化されず、ログフィールドは抽出されません。各ログのタイムスタンプもログ収集時に固定され、取得時に実行できるのは単純なファジークエリのみです。これら2つのモードの違いは、ログの内容が1行か複数行かです。1行の場合は、一致条件を設定するのが最も簡単です。各行は個別のログです。複数行の場合は、最初の行の正規式を設定する必要があります。つまり、各ログの最初の行に一致する正規式。行が事前設定された最初の行の正規式に一致する場合、ログの開始と見なされ、次の行の開始がログの終了識別子として表示されます。複数行ログの内容が次の場合：

10.20.20.10 - - [Tue Jan 22 14:24:03 CST 2019 +0800] GET /online/sample HTTP/1.1 127.0.0.1 200 628 35 http://127.0.0.1/group/1 
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Firefox/64.0 0.310 0.310

次に、正規表現の最初の行を次のように設定できます。 \d+\.\d+\.\d+\.\d+\s-\s.*

不要なコンテンツを除外するにはどうすればよいですか？

重要でないログや関係のないログの一部は、コストを削減するために除外できます。

「JSON」、「separator」、または「complete regular」クロールモードを使用する場合、ログコンテンツは構造化され、次のフィールドを指定することで、保持するログを照合できます。

「単一行テキスト」および「複数行テキスト」キャプチャモードの場合、ログコンテンツは構造化されていないため、フィルタリングするフィールドを指定することはできません。通常、正規化を直接使用して、保持するログコンテンツ全体をファジーマッチングします。

コンテンツが完全に一致するのではなく通常の一致を使用することを念頭に置いて一致する必要があることに注意してください。たとえば、a.test.comログドメインのみを保持したい場合、式の一致はa\.test\.com代わりに書き込む必要がありますa.test.com。

ログのタイムスタンプをカスタマイズする方法は？

各ログにはタイムスタンプが必要です。このタイムスタンプは主に取得に使用され、取得時に時間範囲を選択できます。デフォルトでは、ログのタイムスタンプは収集時間によって決定されます。カスタマイズすることもできます。タイムスタンプとしてフィールドを選択します。これは、場合によってはより正確な場合があります。たとえば、収集ルールが作成される前にサービスが実行されている場合などです。一定期間、カスタムの時間形式を設定しないと、前の古いログのタイムスタンプが収集中に現在の時刻に設定され、不正確な時刻になります。

それをカスタマイズする方法は？「1行テキスト」と「複数行テキスト」のキャプチャモードはログコンテンツを構成しないため、タイムスタンプとして指定できるフィールドがなく、時間形式の分析をカスタマイズすることはできません。他のキャプチャモードもサポートできます。特定の方法については、[取得時間を使用する]をオフにしてから、タイムスタンプとして使用するフィールド名を選択し、時間形式を構成します。

ログtimeフィールドをタイムスタンプとして使用し、ログtime値を2020-09-22 18:18:18時間形式として設定できる場合%Y-%m-%d %H:%M:%S、例：

その他の時間形式の構成ログは、公式ドキュメントサービスのプロビジョニング時間形式を参照してください。

ログサービスのタイムスタンプは当面は秒単位でしか正確ではありません。つまり、ビジネスログのタイムスタンプフィールドがミリ秒単位で正確である場合、カスタムタイムスタンプは使用できず、デフォルトの収集時刻はタイムスタンプとしてのみ使用できますが、時刻はミリ秒単位の正確なスタンプは後でサポートされます。

ログを照会する方法は？

設備の整ったログ収集ルールにより、コレクターは自動的にログの収集を開始し、ログサービスに報告します。その後日志服务-检索分析、クエリをログに記録し、Lucene構文をサポートできますが、インデックスを開く必要があることが前提です。インデックスには次の3つのカテゴリがあります。

1. フルテキストインデックス。フィールドを指定せずにファジー検索に使用されます。
   
2. キー値インデックス。構造化された処理済みログコンテンツにインデックスを付けます。取得するログフィールドを指定できます。
   
3. メタフィールドインデックス。ポッド名、名前名など、ログが報告されるときにいくつかの追加フィールドが自動的に追加されるため、検索時に取得するこれらのフィールドを指定できます。

クエリの例：

ログを他の場所に投稿するにはどうすればよいですか？

ログサービスは、COSオブジェクトストレージおよびCkafka（Tencent CloudによってホストされるKafka）へのログの配信をサポートし、配信はログトピックで設定できます。

次のシナリオで使用できます。

1. ログデータの長期アーカイブストレージ。ログセットにはデフォルトで7日間のログデータが保存され、期間を調整できますが、データ量が多いほどコストが高くなります。通常、保持されるデータは数日のみです。ログを長期間保存する必要がある場合は、低コストの保存のためにCOSに配信できます。 。
2. ログはさらに処理する必要があり（オフライン計算など）、COSまたはCkafkaに配信して、他のプログラムで処理できます。

参照

• TKEログコレクションの使用ガイドライン：https：//cloud.tencent.com/document/product/457/36771
• ログサービスの構成時間形式：https：//cloud.tencent.com/document/product/614/38614
• ログサービス配信COS：https：//cloud.tencent.com/document/product/614/37908
• ログサービスの配信Ckafka：https：//cloud.tencent.com/document/product/614/33342