コンソールでの自社構築K8sクラスターログ収集の設定
ダウンロード
フォーカスモード
フォントサイズ
使用シナリオ
自社構築K8sログ収集機能は、ユーザーに提供されるTencent Cloud以外のKubernetesクラスタ内のログ収集ツールです。クラスタ内のサービスやクラスタノードの特定パスにあるファイルのログをTencent Cloud CLSに送信できます。ログ収集機能は、Kubernetesクラスタ内のサービスログを保存・分析する必要があるユーザーに適しています。
ログ収集機能は、クラスタごとに手動で有効化し、収集ルールを設定する必要があります。ログ収集機能を有効化すると、ログ収集Agentはクラスタ内でDaemonSetとして動作し、ユーザーがログ収集ルールで設定した収集ソース、CLSログトピック、ログ解析方式に基づいて、収集ソースからログを収集し、ログ内容をログコンシューマーに送信します。以下の操作に従ってログ収集機能を有効化できます。
前提条件
自社構築のK8sクラスタに収集ツールLogListenerをインストールしてデプロイします。LogListenerのインストールについては、自社構築K8sクラスタへのLogListenerのインストールを参照してください。
対応するログアップロード権限を設定します。権限の設定については、自社構築K8sを使用したデータのアップロードを参照してください。
操作手順
ステップ1：クラスターの選択
1. CLSコンソールにログインします。
2. 左側のナビゲーションバーでコンテナクラスタ管理をクリックし、コンテナクラスタ管理ページに入ります。
3. ページ右上で自社構築K8sクラスタを選択します。
4. 自社構築K8sクラスタへのLogListenerのインストールが完了している場合、CLSはインストール時に指定したCLSリージョンにクラスタを自動的に作成します。
5. 右侧の収集設定を新規作成をクリックし、クラスタログ収集設定プロセスに入ります。
ステップ2：ログトピックの設定
クラスタログ収集設定プロセスに入り、ログトピック作成ステップで、既存のログトピックを選択するか、ログ保存用のログトピックを作成できます。ログトピックの関連情報については、ログトピックを参照してください。
ステップ3：収集ルールの設定
ログトピックの設定が完了したら、次へをクリックして収集設定に進み、収集ルールを設定できます。設定情報は以下の通りです：
ログソース設定：
収集ルール名：ログ収集ルール名をカスタマイズできます。
収集タイプ：現在、収集タイプはコンテナ標準出力、コンテナファイルパス、ノードファイルパスをサポートしています。
すべてのコンテナ、指定ワークロード、指定Podラベルの3つの方法でコンテナ標準出力のログ収集ソースを指定することをサポートしています。
すべてのコンテナ：指定した名前空間内のすべてのコンテナの標準出力ログを収集することを表します。下図の通りです：
指定ワークロード：指定した名前空間、指定したワークロード、指定したコンテナの標準出力ログを収集することを表します。下図の通りです：
指定Podラベル：指定した名前空間内で、指定したPodラベルを持つすべてのコンテナの標準出力ログを収集することを表します。下図の通りです：
注意：
「コンテナファイルパス」はシンボリックリンクにすることはできません。そうでない場合、シンボリックリンクの実際のパスがコレクターのコンテナ内に存在せず、ログ収集に失敗します。
指定ワークロード、指定Podラベルの2つの方法でコンテナファイルパスのログ収集ソースを指定することをサポートしています。
指定ワークロード：指定した名前空間、指定したワークロード、指定したコンテナ内のコンテナファイルパスを収集することを表します。下図の通りです：
指定Podラベル：指定した名前空間内で、指定したPodラベルを持つすべてのコンテナ内のコンテナファイルパスを収集することを表します。下図の通りです：
コンテナファイルパスはログディレクトリとファイル名で構成されます。ログディレクトリプレフィックスは/で始まり、ファイル名は/以外で始まります。プレフィックスとファイル名はどちらもワイルドカード?と*の使用をサポートし、カンマはサポートしません。/**/は、ログ収集コンポーネントが指定されたプレフィックスディレクトリ配下のすべての階層で一致するログファイルを監視することを表します。複数ファイルパス間はOR関係です。例えば、コンテナファイルパスが
/opt/logs/*.logの場合、ディレクトリプレフィックスを/opt/logs、ファイル名を*.logとするログを指定できます。注意：
バージョン1.1.12以降のコンテナ収集コンポーネントのみが、複数の収集パスをサポートしています。
1.1.12以降のバージョンにアップグレードした後に作成された収集設定のみが、複数の収集パスの定義をサポートしています。
バージョン1.1.12より前に作成された収集設定は、1.1.12へアップグレードした後も複数の収集パスの設定をサポートしません。収集設定を再作成する必要があります。
収集パスの拒否リスト。有効にすると、収集時に指定したディレクトリパスまたは完全なファイルパスを無視できます。ディレクトリパスとファイルパスは完全一致にすることも、ワイルドカードパターンマッチングをサポートすることもできます。
収集拒否リストは2種類のフィルタリングタイプに分かれており、同時に使用できます：
ファイルパス：収集パス配下で、収集を無視する必要がある完全なファイルパスです。ワイルドカード*または？をサポートし、**によるパスのあいまい一致をサポートします。
ディレクトリパス：収集パス配下で、収集を無視する必要があるディレクトリプレフィックスです。ワイルドカード*または？をサポートし、**によるパスのあいまい一致をサポートします。
注意：
コンテナログ収集コンポーネント1.1.2以降のバージョンが必要です。
収集拒否リストは収集パス配下で除外を行うため、ファイルパスモードであっても、ディレクトリパスモードであっても、指定するパスは収集パスのサブセットである必要があります。
ノードファイルパスはログディレクトリとファイル名で構成されます。ログディレクトリプレフィックスは/で始まり、ファイル名は/以外で始まります。プレフィックスとファイル名はどちらもワイルドカード?と*の使用をサポートし、カンマはサポートしません。/**/は、ログ収集コンポーネントが指定されたプレフィックスディレクトリ配下のすべての階層で一致するログファイルを監視することを表します。複数ファイルパス間はOR関係です。例えば、ノードファイルパスが
/opt/logs/*.logの場合、ディレクトリプレフィックスを/opt/logs、ファイル名を*.logとするログを指定できます。注意：
バージョン1.1.12以降の収集コンポーネントのみが、複数の収集パスをサポートしています。
1.1.12以降のバージョンにアップグレードした後に作成された収集設定のみが、複数の収集パスの定義をサポートしています。
バージョン1.1.12より前に作成された収集設定は、1.1.12へアップグレードした後も複数の収集パスの設定をサポートしません。収集設定を再作成する必要があります。
収集パスの拒否リスト。有効にすると、収集時に指定したディレクトリパスまたは完全なファイルパスを無視できます。ディレクトリパスとファイルパスは完全一致にすることも、ワイルドカードパターンマッチングをサポートすることもできます。
収集拒否リストは2種類のフィルタリングタイプに分かれており、同時に使用できます：
ファイルパス：収集パス配下で、収集を無視する必要がある完全なファイルパスです。ワイルドカード*または？をサポートし、**によるパスのあいまい一致をサポートします。
ディレクトリパス：収集パス配下で、収集を無視する必要があるディレクトリプレフィックスです。ワイルドカード*または？をサポートし、**によるパスのあいまい一致をサポートします。
注意：
コンテナログ収集コンポーネント1.1.2以降のバージョンが必要です。
収集拒否リストは収集パス配下で除外を行うため、ファイルパスモードであっても、ディレクトリパスモードであっても、指定するパスは収集パスのサブセットである必要があります。
メタデータ設定：
元のログ内容に加えて、CLSはコンテナまたはkubernetes関連のメタデータ（例：ログを生成したコンテナID）を一緒にCLSへアップロードします。これにより、ユーザーはログ確認時にソースを追跡したり、コンテナ識別子や特徴（例：コンテナ名、labels）に基づいて検索したりできます。これらのメタデータをアップロードするかどうかはお客様自身で選択でき、必要に応じてチェックしてアップロードしてください。コンテナまたはkubernetes関連のメタデータについては、下記の表を参照してください：
フィールド名 | 意味 |
container_id | ログが属するコンテナID。 |
container_name | ログが属するコンテナ名。 |
image_name | ログが属するコンテナのイメージ名のIP。 |
namespace | ログが属するポッドのnamespace。 |
pod_uid | ログが属するポッドのUID。 |
pod_name | ログが属するポッドの名前。 |
pod_ip | ログが属するポッドのIPアドレス。 |
pod_lable_{label name} | ログが属するポッドのラベル（例えば、あるポッドに2つのラベル app=nginx、env=prod が付いている場合、アップロードされるログには2つのメタデータ pod_label_app:nginx、pod_label_env:prod が付随します）。 |
説明：
一部のpodラベルのみを収集する場合は、必要なラベルキーを手動で入力する必要があります（複数入力できます。1つ入力するごとにEnterキーで確定します）。一致した場合に収集されます。
解析ルールの設定：
収集ポリシー。全量または増分を選択できます。
全量：全量収集とは、ログファイルの先頭から収集を開始することです。
增量：增量収集とは、ファイル内に新しく追加されたコンテンツのみを収集することです。
エンコードモード：UTF-8およびGBKをサポートします。
抽出モード：複数のタイプの抽出モードをサポートします。詳細は以下の通りです：
単行全文ログとは、1行のログ内容が1本の完全なログであることを指します。CLSは収集時に、改行文字\\nを1本のログの終了文字として使用します。構造化管理を統一するために、各ログにはデフォルトのキー値__CONTENT__が存在しますが、ログデータ自体はログ構造化処理を行わず、ログフィールドも抽出しません。ログ属性の時間項目はログ収集の時間によって決定されます。
1本のログの元データが以下であると仮定します：
Tue Jan 22 12:08:15 CST 2019 Installed: libjpeg-turbo-static-1.2.90-6.el7.x86_64
CLSに収集されたデータは以下の通りです：
__CONTENT__:Tue Jan 22 12:08:15 CST 2019 Installed: libjpeg-turbo-static-1.2.90-6.el7.x86_64
複数行全文ログとは、1本の完全なログデータが複数行にまたがる場合があることです（例えばJava stacktrace）。この場合、改行文字\\nをログの終了識別子とすることは不合理です。ログシステムが各ログを明確に区別できるようにするために、先頭行正規表現でマッチングを行います。ある行のログが事前に設定された正規表現にマッチした場合、その行を1本のログの先頭とみなし、次の行頭が出現した時点をそのログの終了識別子とします。
複数行全文にもデフォルトのキー値__CONTENT__が設定されますが、ログデータ自体はログ構造化処理を行わず、ログフィールドも抽出しません。ログ属性の時間項目はログ収集の時間によって決定されます。
1本の複数行ログの元データが以下であると仮定します：
2019-12-15 17:13:06,043 [main] ERROR com.test.logging.FooFactory:java.lang.NullPointerExceptionat com.test.logging.FooFactory.createFoo(FooFactory.java:15)at com.test.logging.FooFactoryTest.test(FooFactoryTest.java:11)
行頭正規表現は以下の通りです：
\\d{4}-\\d{2}-\\d{2}\\s\\d{2}:\\d{2}:\\d{2},\\d{3}\\s.+
CLSに収集されたデータは以下の通りです：
__CONTENT__:2019-12-15 17:13:06,043 [main] ERROR com.test.logging.FooFactory:\\njava.lang.NullPointerException\\n at com.test.logging.FooFactory.createFoo(FooFactory.java:15)\\n at com.test.logging.FooFactoryTest.test(FooFactoryTest.java:11)
単一行完全正規表現形式は通常、構造化されたログの処理に使用され、1本の完全なログを正規表現で複数のkey-valueに抽出するログ解析モードを指します。
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+).*
CLSに収集されたデータは以下の通りです：
body_bytes_sent: 9703http_host: 127.0.0.1http_protocol: HTTP/1.1http_referer: http://127.0.0.1/course/explore?filter%5Btype%5D=all&filter%5Bprice%5D=all&filter%5BcurrentLevelId%5D=all&orderBy=studentNumhttp_user_agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Firefox/64.0remote_addr: 10.135.46.111request_length: 782request_method: GETrequest_time: 0.354request_url: /my/course/1status: 200time_local: [22/Jan/2019:19:19:30 +0800]upstream_response_time: 0.354
1本のログの元データが以下であると仮定します：
[2018-10-01T10:30:01,000] [INFO] java.lang.Exception: exception happenedat TestPrintStackTrace.f(TestPrintStackTrace.java:3)at TestPrintStackTrace.g(TestPrintStackTrace.java:7)at TestPrintStackTrace.main(TestPrintStackTrace.java:16)
行頭正規表現は以下の通りです：
\\[\\d+-\\d+-\\w+:\\d+:\\d+,\\d+]\\s\\[\\w+]\\s.*
設定したカスタム正規表現は以下の通りです：
\\[(\\d+-\\d+-\\w+:\\d+:\\d+,\\d+)\\]\\s\\[(\\w+)\\]\\s(.*)
システムが
()キャプチャグループに基づいて対応するkey-valueを抽出した後、各グループのkey名を以下のようにカスタマイズできます：time： 2018-10-01T10:30:01,000`level： INFO`msg：java.lang.Exception: exception happenedat TestPrintStackTrace.f(TestPrintStackTrace.java:3)at TestPrintStackTrace.g(TestPrintStackTrace.java:7)at TestPrintStackTrace.main(TestPrintStackTrace.java:16)
お客様の1本の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"}
CLSによる構造化処理後、このログは以下のようになります：
agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Firefox/64.0body_sent: 23http_host: 127.0.0.1method: POSTreferer: http://127.0.0.1/my/course/4remote_ip: 10.135.46.111request: POST /event/dispatch HTTP/1.1response_code: 200responsetime: 0.232time_local: 22/Jan/2019:19:19:34 +0800upstreamhost: unix:/tmp/php-cgi.sockupstreamtime: 0.232url: /event/dispatchxff: -
1本のログの元データが以下であると仮定します：
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/
ログ解析のセパレータを
:::に指定すると、このログは8つのフィールドに分割され、これら8つのフィールドに一意のkeyが定義されます。以下に示します：IP: 10.20.20.10 -bytes: 35host: 127.0.0.1length: 647referer: http://127.0.0.1/request: GET /online/sample HTTP/1.1status: 200time: [Tue Jan 22 14:49:45 CST 2019 +0800]
お客様の1本のログの元データが以下であると仮定します：
1571394459、http://127.0.0.1/my/course/4|10.135.46.111|200、status:DEAD,
カスタムプラグインの内容は以下の通りです：
{"processors": [{"type": "processor_split_delimiter","detail": {"Delimiter": ",","ExtractKeys": [ "time", "msg1","msg2"]},"processors": [{"type": "processor_timeformat","detail": {"KeepSource": true,"TimeFormat": "%s","SourceKey": "time"}},{"type": "processor_split_delimiter","detail": {"KeepSource": false,"Delimiter": "|","SourceKey": "msg1","ExtractKeys": [ "submsg1","submsg2","submsg3"]},"processors": []},{"type": "processor_split_key_value","detail": {"KeepSource": false,"Delimiter": "：","SourceKey": "msg2"}}]}]}
CLSによる構造化処理後、このログは以下のようになります：
time: 1571394459submsg1: http://127.0.0.1/my/course/4submsg2: 10.135.46.111submsg3: 200status: DEAD
フィルター：LogListenerはフィルタールールに一致するログのみを収集します。Keyは完全一致をサポートし、フィルタールールは正規表現一致をサポートします。例えば、
ErrorCode = 404のログのみを収集します。お客様は必要に応じてフィルターを有効化し、ルールを設定できます。データ加工
収集したCLSログをさらに処理（構造化、脱敏、フィルタリングなど）してからログトピックに書き込む必要がある場合は、ページ下部のデータ加工をクリックしてデータ加工を追加し、最後にインデックスを設定します。
説明：
データ加工に関する操作については、加工タスクの作成ドキュメントの【前置データ加工】タブページを参照してください。
データ加工スクリプトの作成については、データ加工関数の概要、または加工実践事例を参照してください。
データ加工には費用が発生します。詳細は課金概要をご覧ください。
ステップ4：インデックスの設定
収集ルールの設定が完了したら、次へをクリックしてインデックス設定に進みます。設定ページでは、推奨設定を直接使用して、インデックスを自動設定することをお勧めします。
ステップ5：ログの検索
フィードバック