TKE クラウドプロダクトセンターは、TKEビジネスログ、監査ログ、イベントログのワンストップ収集・検索分析を提供します。また、監査ログとイベントログに基づいて、すぐに利用できる監査・イベント分析ダッシュボードを提供し、TKEアクセス分析の可観測性を迅速に構築することを支援します。
機能特性
すぐに利用できるTKEクラスタ監査・イベント分析ダッシュボードです。
TKEクラスタ監査・イベントログ検索分析の入口を統一します。
TKEクラスタのビジネス、監査、イベントログの収集を一括で有効にします。
前提条件
操作手順
クラスタ業務ログ収集の有効化
ステップ1：クラスタの選択
2. 左側のナビゲーションバーで、クラウドプロダクトセンターをクリックし、クラウドプロダクトセンターページに移動します。
3. クラウドプロダクトログで、TKEを選択してクリックします。
4. TKEセンターで、接続管理>インスタンス接続を選択します。
5. TKEクラスタの所在地域を選択し、クラスタリストで対象の収集クラスタを見つけます。
収集コンポーネントの状態が未インストールの場合、インストールをクリックして、ログ収集コンポーネントをインストールします。
注意：
ログ収集コンポーネントをインストールすると、クラスタのkube-system名前空間に、DaemonSetとしてtke-log-agentのpodとcls-provisionerのpodが1つずつデプロイされます。各ノードに少なくとも0.1コア、16Mib以上の利用可能なリソースを予約してください。
TKEクラスタにログ収集コンポーネントをインストールするには、クラスタにアクセスするためのRBAC権限が必要です。ない場合は、クラスタ管理者に連絡して追加を依頼してください。
6. 収集コンポーネントの状態が最新の場合、右側の収集設定を新規作成をクリックし、クラスタログ収集設定フローに進みます。
注意：
TKEクラスタにログ収集設定を構成するには、クラスタにアクセスするためのRBAC権限が必要です。ない場合は、クラスタ管理者に連絡して追加を依頼してください。
ステップ2：ログトピックの設定
クラスタログ収集設定フローに進み、ログトピックの作成ステップで、ログを保存するための既存のログトピックを選択するか、新規作成できます。ログトピックについては、ログトピックを参照してください。 ステップ3：収集ルールの設定
ログトピックの選択を完了した後、次へをクリックして収集設定に進むと、収集ルールを設定できます。設定情報は以下の通りです：
ログソース設定：
収集ルール名：ログ収集ルール名をカスタマイズできます。
収集タイプ：現在、収集タイプはコンテナ標準出力、コンテナファイルパス、およびノードファイルパスをサポートしています。
すべてのコンテナ、指定ワークロード、指定Pod Labelsの3つの方法で、コンテナ標準出力の収集ログソースを指定することをサポートしています。
すべてのコンテナ：指定された名前空間内のすべてのコンテナの標準出力ログを収集することを意味します。
指定ワークロード：指定された名前空間内の指定ワークロードにある指定コンテナの標準出力ログを収集することを意味します。
指定Pod Labels：指定された名前空間内で、指定されたPod Labelを持つすべてのコンテナの標準出力ログを収集することを意味します。
注意：
「コンテナファイルパス」はソフトリンクにすることはできません。そうでない場合、ソフトリンクの実際のパスが収集コンポーネントのコンテナ内に存在せず、ログ収集に失敗します。
指定ワークロード、指定Pod Labelsの2つの方法で、コンテナファイルパスの収集ログソースを指定することをサポートしています。
指定ワークロード：指定された名前空間内の指定ワークロードにある指定コンテナのコンテナファイルパスを収集することを意味します。
指定Pod Labels：指定された名前空間内で、指定されたPod Labelを持つすべてのコンテナ内のコンテナファイルパスを収集することを意味します。
コンテナファイルパスはログディレクトリとファイル名で構成されます。ログディレクトリのプレフィックスは / で始まり、ファイル名は / 以外で始まります。プレフィックスとファイル名はどちらもワイルドカード ? と * の使用をサポートしており、カンマはサポートしていません。/**/は、ログ収集コンポーネントが指定されたプレフィックスディレクトリ配下のすべての階層でマッチしたログファイルを監視することを表します。複数のファイルパス間は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_label_{label name} | ログが属するポッドのラベル（例えば、1つのポッドに2つのラベルがある場合：app=nginx、env=prod、アップロードされたログには2つのメタデータが付随します：pod_label_app:nginx、pod_label_env:prod）。 |
説明：
一部のpodlabelを収集する場合は、必要なlabel keyを手動で入力する必要があります（複数入力でき、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.NullPointerException
at 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: 9703
http_host: 127.0.0.1
http_protocol: HTTP/1.1
http_referer: http://127.0.0.1/course/explore?filter%5Btype%5D=all&filter%5Bprice%5D=all&filter%5BcurrentLevelId%5D=all&orderBy=studentNum
http_user_agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Firefox/64.0
remote_addr: 10.135.46.111
request_length: 782
request_method: GET
request_time: 0.354
request_url: /my/course/1
status: 200
time_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 happened
at 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 happened
at 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.0
body_sent: 23
http_host: 127.0.0.1
method: POST
referer: http://127.0.0.1/my/course/4
remote_ip: 10.135.46.111
request: POST /event/dispatch HTTP/1.1
response_code: 200
responsetime: 0.232
time_local: 22/Jan/2019:19:19:34 +0800
upstreamhost: unix:/tmp/php-cgi.sock
upstreamtime: 0.232
url: /event/dispatch
xff: -
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: 35
host: 127.0.0.1
length: 647
referer: http://127.0.0.1/
request: GET /online/sample HTTP/1.1
status: 200
time: [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: 1571394459
submsg1: http://127.0.0.1/my/course/4
submsg2: 10.135.46.111
submsg3: 200
status: DEAD
フィルター：LogListenerはフィルタールールに一致するログのみを収集します。Keyは完全一致をサポートし、フィルタールールは正規表現マッチングをサポートします。例えば、ErrorCode = 404のログのみを収集します。必要に応じてフィルターを有効化し、ルールを設定できます。
ログタイムスタンプのソース：ログ収集時間または指定ログフィールドの2つの時間をログのタイムスタンプとして選択できます：
解析失敗ログのアップロード：解析失敗ログのアップロードを有効にすることをお勧めします。有効にすると、LogListenerはさまざまな解析失敗ログをアップロードします。解析失敗ログのアップロードを無効にすると、失敗したログは破棄されます。
詳細設定：チェックを入れることで、定義する必要がある詳細設定を選択します。
マルチライン-完全正規表現抽出モードでは、以下の詳細設定を設定できます（その他のモードは最初の2種類のみサポートします）：
|
タイムアウト属性 | この設定はログファイルのタイムアウト時間を制御します。ログファイルが指定時間内に更新されない場合、タイムアウトとなります。タイムアウトしたログファイルはLogListenerによって収集されなくなります。ログファイル数が多い場合 大きい場合は、タイムアウト時間を短縮し、LogListenerのパフォーマンス浪費を回避することをお勧めします。 | タイムアウトなし：ログファイルがタイムアウトすることはありません。 カスタム：ログファイルのタイムアウト時間をカスタマイズします。 |
最大ディレクトリ深度 | この設定はログ収集の最大ディレクトリ深度を制御します。LogListenerは、所在ディレクトリ階層が指定された最大ディレクトリ深度を超えるログファイルを収集しません。対象収集パスにワイルドカードが含まれる場合は、適切な最大ディレクトリ深度を設定し、LogListenerのパフォーマンス浪費を回避することをお勧めします。 | 0より大きい整数です。0はサブディレクトリを掘り下げないことを表します。 |
解析失敗ログの結合 | 注意： LogListener 2.8.8以降のバージョンでのみ、マージ解析失敗ログを設定できます。 この設定は、収集時に対象ログファイル内で連続して解析に失敗したログを1つのログに結合してアップロードすることをサポートします。先頭行の正規表現がすべての複数行ログをカバーできない場合は、この設定を有効にして、先頭行のマッチングに失敗した単一の複数行ログが複数のログに分割されるのを回避することをお勧めします。 | 有効/無効 |
収集したCLSログを構造化、マスキング、フィルタリングなどでさらに処理してからログトピックに書き込む必要がある場合は、ページ下部のデータ加工をクリックし、データ加工を追加して、最後にインデックスを設定します。
説明：
データ加工に関する操作については、加工タスクの作成ドキュメントの【前置データ加工】タブページを参照してください。 データ加工には料金が発生します。詳細については課金概要を参照してください。 ステップ4：インデックスを設定する
1. 次へをクリックし、「インデックス設定」ページに進みます。
2. 「インデックス設定」ページで、以下の情報を設定します。設定の詳細については、インデックス設定を参照してください。 注意：
検索にはインデックス設定を有効にする必要があります。有効にしない場合、検索できません。
ステップ5：ログを検索する
これで、TKE K8sクラスタのビジネスログ収集に関するすべてのデプロイが完了しました。CLSコンソール > 検索分析に移動して、収集されたログを確認できます。 業務ログ収集設定の管理
1. アクセス管理>インスタンスアクセスで、対象のTKEクラスタを見つけ、クラスタ名をクリックして、クラスタ詳細ページに進みます。
2. クラスタ詳細ページで、ログ管理>クラスタビジネスログから、クラスタビジネスログ収集設定を表示および管理できます。
クラスタ監査・イベントログ収集を有効にする
説明：
クラスタ監査ログは、kube-apiserverへのアクセスイベントを記録し、各ユーザー、管理者、またはシステムコンポーネントがクラスタに影響を与えるアクティビティを順番に記録します。
クラスタイベントログは、クラスタの稼働状況と各種リソースのスケジューリング状況を記録します。
ステップ1：クラスタの選択
1. 収集コンポーネントの状態が未インストールの場合、インストールをクリックして、ログ収集コンポーネントをインストールします。
注意：
ログ収集コンポーネントをインストールすると、クラスタのkube-system名前空間に、DaemonSetとしてtke-log-agentのpodとcls-provisionerのpodが1つずつデプロイされます。各ノードに少なくとも0.1コア、16Mib以上の利用可能なリソースを予約してください。
2. 収集コンポーネントの状態が最新の場合、クラスタ名をクリックしてクラスタ詳細ページに進み、ログ管理 - クラスタビジネスログでクラスタ監査ログまたはクラスタイベントログを見つけます。
3. 有効化クラスタ監査またはイベントログをクリックし、クラスタ監査ログまたはクラスタイベントログの設定フローに進みます。
ステップ2：ログトピックの選択
監査またはイベントログの設定フローに進み、ログトピックの作成ステップで、ログを保存するための既存のログトピックを選択するか、新規作成できます。ログトピックの詳細については、ログトピックを参照してください。 ステップ3：インデックス設定
1. 次へをクリックし、「インデックス設定」ページに進みます。
2. 「インデックス設定」ページで、以下の情報を設定します。設定の詳細については、インデックス設定を参照してください。 注意：
検索にはインデックス設定を有効にする必要があります。有効にしない場合、検索できません。
ステップ4：監査・イベントログの検索
これで、TKE K8sクラスタの監査またはイベントビジネスログ収集に関するすべてのデプロイが完了しました。ログ検索をクリックし、検索するログタイプ（監査またはイベント）を選択し、同時にターゲットクラスタを選択すると、選択したクラスタに関連する監査またはイベントログを検索できます。
TKEクラスタ監査・イベント分析ダッシュボードの表示
1. TKEクラスタの監査またはイベントログ収集を有効にした後、上部のタブバーでダッシュボードを選択します。
2. 上部のセカンダリタブで、目的の監査またはイベントダッシュボードを選択します。
3. TKEクラスタのドロップダウンリストで、監査またはイベントログの配信が有効になっているターゲットTKEクラスタを選択します。
4. クラスタを選択すると、選択したクラスタに関連するイベントまたは監査分析ダッシュボードを表示できます。
ログ収集コンポーネントのアップグレード
アクセス管理ページで、ターゲットTKEクラスタを見つけます。収集コンポーネントのステータスにアップグレード可能と表示されている場合、アップグレードをクリックして、ログ収集コンポーネントを最新バージョンにアップグレードできます。
ログ収集コンポーネントのアンインストール
アクセス管理ページで、ターゲットTKEクラスタを見つけ、操作列の詳細をクリックし、ドロップダウンメニューでログ収集コンポーネントのアンインストールをクリックします。