tencent cloud

Cloud Log Service

文档Cloud Log Service操作ガイドログ収集TKE K8sクラスタログの収集

TKE K8sクラスタログの収集

下载
聚焦模式
字号
最后更新时间： 2026-10-12 14:31:24
本文档由 AI 翻译
本ドキュメントでは、コンソールでTencent Kubernetes Engine（TKE）K8sクラスタのログ収集ルールを設定し、Tencent Cloud CLSに配信する方法を説明します。CRDを使用してTKEのK8sクラスタからログを配信する必要がある場合は、TKEシナリオでCRDを使用したログ収集設定ガイドを参照してください。

使用シナリオ

TKE K8sビジネスログ収集機能は、ユーザーに提供されるTencent Cloud TKE Kubernetesクラスタ内のビジネスログ収集ツールです。クラスタ内のビジネスログ、監査ログ、イベントログをTencent Cloud CLSに送信できます。 ログ収集機能を使用するには、クラスタにログ収集コンポーネントをインストールし、収集ルールを設定する必要があります。ログ収集コンポーネントのインストール後、ログ収集Agentはクラスタ内でDaemonSetとして実行され、ユーザーがログ収集ルールで設定した収集ソース、CLSログトピック、ログ解析方式に基づいて、収集ソースからログを収集し、ログ内容をログコンシューマーに送信します。以下の操作に従ってログ収集をインストールおよび設定できます。

前提条件

TKEコンソールでクラスタを作成済みです。CLSはTKEの標準クラスタ、弾性クラスタ、エッジクラスタのログ収集をサポートしています。

クラスタ業務ログの収集

ステップ1：クラスタを選択

1. CLSコンソールにログインします。
2. 左側のナビゲーションバーでコンテナクラスタ管理をクリックし、コンテナクラスタ管理ページに移動します。
3. ページ右上でTKEクラスタを選択します。

4. TKEクラスタが所在するリージョンを選択し、対象の収集クラスタを見つけます。
5. 収集コンポーネントの状態が未インストールの場合は、インストールをクリックして、ログ収集コンポーネントをインストールします。

注意：
ログ収集コンポーネントをインストールすると、クラスタのkube-system名前空間に、DaemonSetとしてtke-log-agentのpodとcls-provisionerのpodが1つずつデプロイされます。各ノードに少なくとも0.1コア、16Mib以上の利用可能なリソースを予約してください。
6. 収集コンポーネントの状態が最新の場合は、右側の新規収集設定をクリックし、クラスタログ収集設定フローに進みます。




ステップ2：ログトピックを設定

クラスタログ収集設定フローに進み、ログトピックの作成ステップで、ログを保存するための既存のログトピックを選択するか、新規に作成できます。ログトピックの詳細については、ログトピックを参照してください。


ステップ3：収集ルールを設定

ログトピックの選択を完了したら、次へをクリックして収集設定に進み、収集ルールを設定できます。設定情報は以下の通りです：
ログソース設定：

収集ルール名：ログ収集ルール名をカスタマイズできます。
収集タイプ：現在、収集タイプはコンテナ標準出力、コンテナファイルパス、ノードファイルパスをサポートしています。
コンテナ標準出力
コンテナファイルパス
ノードファイルパス
すべてのコンテナ、指定ワークロード、指定Pod Labelsの3つの方法で、コンテナ標準出力の収集ログソースを指定できます。
すべてのコンテナ：指定された名前空間内のすべてのコンテナの標準出力ログを収集することを表します。下図の通りです：

指定ワークロード：指定された名前空間内の指定ワークロードにある指定コンテナの標準出力ログを収集することを表します。下図の通りです：

指定Pod Labels：指定された名前空間内で、指定されたPod Labelsを持つすべてのコンテナの標準出力ログを収集することを表します。下図の通りです：

注意：
「コンテナファイルパス」はソフトリンクにすることはできません。そうしないと、ソフトリンクの実際のパスが収集器のコンテナ内に存在せず、ログ収集に失敗します。
ビジネスPodがHostPathを使用してログディレクトリをマウントし、かつ同一ノード上の複数のPodが最終的に同じホストの実ログファイルに書き込む場合、複数のコンテナ収集パスが同一の実ファイルに解決され、同一ファイルが重複して収集される可能性があります。ビジネスワークロードのマウント設定でKubernetes subPathExprを使用し、Pod名またはPod UIDに基づいて異なるPodごとにホストのサブディレクトリを分離することをお勧めします。また、ビジネス側で異なるPodが異なるログファイルに書き込むように変更することもできます。関連設定については、Kubernetes公式ドキュメントを参照してください。
指定ワークロード、指定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
ログが属するポッドのラベル（例えば、1つのポッドに2つのラベルがある場合：app=nginx、env=prod、アップロードされたログには2つのメタデータが付随します：pod_label_app:nginx、pod_label_env:prod）。
説明：
一部のpod labelを収集したい場合は、必要なlabel keyを手動で入力する必要があります（複数入力でき、1つ入力するごとにEnterキーで確定します）。一致した場合は収集されます。
解析ルールの設定：

収集ポリシー。 全量または増分を選択できます。
全量：全量収集とは、ログファイルの先頭から収集を開始することを指します。
増分：増分収集とは、ファイル内で新しく追加されたコンテンツのみを収集することを指します。
エンコードモード：UTF-8およびGBKをサポートします。
抽出モード：複数のタイプの抽出モードをサポートしています。詳細は以下の通りです：
単一行フルテキスト形式
複数行フルテキスト形式
単一行-完全正規表現形式
複数行-完全正規表現形式
JSON形式
区切り文字
組み合わせ解析
単一行フルテキストログとは、1行のログ内容が1つの完全なログであることを指します。CLSは収集時に、改行文字\\\\nを1つのログの終了文字として使用します。構造化管理を統一するために、各ログにはデフォルトのキー値__CONTENT__が存在しますが、ログデータ自体に対してログ構造化処理は行われず、ログフィールドも抽出されません。ログ属性の時間項目は、ログ収集の時間によって決定されます。
あるログの元のデータが以下の通りであると仮定します：
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__が設定されますが、ログデータ自体に対してログ構造化処理は行われず、ログフィールドも抽出されません。ログ属性の時間項目は、ログ収集の時間によって決定されます。
ある複数行ログの元のデータが以下の通りであると仮定します：
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を抽出するログ解析モードを指します。
あるログの元のデータが以下の通りであると仮定します：
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
あるログの元のデータが以下の通りであると仮定します：
[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)
ある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: -
あるログの元のデータが以下の通りであると仮定します：
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]
あるログの元のデータが以下の通りであると仮定します：
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
ログタイムスタンプのソースを設定します。ログのタイムスタンプとして、ログ収集時間または指定ログフィールドの2種類の時間を選択できます。
フィルター：LogListenerはフィルタールールに一致するログのみを収集します。Keyは完全一致をサポートし、フィルタールールは正規表現一致をサポートします。例えば、ErrorCode = 404のログのみを収集します。必要に応じてフィルターを有効にしてルールを設定できます。
アップロード解析失敗ログの設定：アップロード解析失敗ログを有効にすることをお勧めします。有効にすると、LogListenerはさまざまな解析失敗ログをアップロードします。アップロード解析失敗ログを無効にすると、失敗したログは破棄されます。
詳細設定：チェックを入れることで、定義する詳細設定を選択します。

複数行-完全正規表現抽出モードでは、以下の詳細設定を設定できます（他のモードでは最初の2種類のみサポートされます）：
名前
説明
設定項目
タイムアウト属性
この設定はログファイルのタイムアウト時間を制御します。ログファイルが指定時間内に更新されない場合、タイムアウトとみなされます。タイムアウトしたログファイルは、LogListenerによって収集されなくなります。ログファイルの数が多い
大きい場合は、タイムアウト時間を短縮し、LogListenerのパフォーマンス浪費を回避することをお勧めします。
タイムアウトなし：ログファイルがタイムアウトすることはありません。
カスタム：ログファイルのタイムアウト時間をカスタマイズします。
最大ディレクトリ深度
この設定はログ収集の最大ディレクトリ深度を制御します。LogListenerは、所在ディレクトリ階層が指定された最大ディレクトリ深度を超えるログファイルを収集しません。対象収集パスにワイルドカードが含まれる場合は、適切な最大ディレクトリ深度を設定し、LogListenerのパフォーマンス浪費を回避することをお勧めします。
0より大きい整数です。0はサブディレクトリの下位走査を行わないことを表します。
解析失敗ログの結合
注意：
LogListener 2.8.8以降のバージョンでのみ、マージ解析失敗ログを設定できます。
この設定は、収集時に対象ログファイル内で連続して解析に失敗したログを1つのログに結合してアップロードすることをサポートします。先頭行の正規表現ですべての複数行ログをカバーできない場合は、この設定を有効にして、先頭行のマッチングに失敗した単一の複数行ログが複数のログに分割されるのを防ぐことをお勧めします。
有効/無効
収集したCLSログを構造化、マスキング、フィルタリングなどでさらに処理してからログトピックに書き込む必要がある場合は、ページ下部のデータ加工をクリックしてデータ加工を追加し、最後にインデックスを設定します。



説明：
データ加工関連の操作については、加工タスクの作成ドキュメントの【前置データ加工】タブページを参照してください。
データ加工スクリプトの作成については、データ加工関数の概要または加工実践事例を参照してください。
データ加工には料金が発生します。詳細は課金概要をご覧ください。

ステップ4：インデックスを設定する

1. 次へをクリックし、「インデックス設定」ページに進みます。
2. 「インデックス設定」ページで、以下の情報を設定します。設定の詳細については、インデックス設定を参照してください。

注意：
検索にはインデックス設定を有効にする必要があります。有効にしない場合、検索できません。

ステップ5：ログを検索する

これで、TKE K8sクラスタのビジネスログ収集に関するすべてのデプロイが完了しました。CLSコンソール > 検索分析に移動して、収集されたログを確認できます。

クラスタ監査/イベントログ収集

説明：
クラスタ監査ログは、kube-apiserverへのアクセスイベントを記録し、各ユーザー、管理者、またはシステムコンポーネントがクラスタに影響を与えるアクティビティを順番に記録します。
クラスタイベントログは、クラスタの稼働状況と各種リソースのスケジューリング状況を記録します。

ステップ1：クラスタを選択

1. CLSコンソールにログインします。
2. 左側のナビゲーションバーでコンテナクラスタ管理を選択し、コンテナクラスタ管理ページに移動します。
3. ページ右上でTKEクラスタを選択します。

4. TKEクラスタが所在するリージョンを選択し、対象の収集クラスタを見つけます。
5. 収集コンポーネントの状態が未インストールの場合は、インストールをクリックして、ログ収集コンポーネントをインストールします。

注意：
ログ収集コンポーネントをインストールすると、クラスタのkube-system名前空間に、DaemonSetとしてtke-log-agentのpodとcls-provisionerのpodが1つずつデプロイされます。各ノードに少なくとも0.1コア、16Mib以上の利用可能なリソースを予約してください。
6. 収集コンポーネントの状態が最新の場合は、クラスタ名をクリックしてクラスタ詳細ページに移動し、クラスタ詳細ページでクラスタ監査ログまたはクラスタイベントログを見つけます。



7. 有効化をクリックしてクラスタ監査またはイベントログを有効にし、クラスタ監査またはイベントログ設定フローに進みます。

ステップ2：ログトピックを選択

監査またはイベントログ設定フローに進み、ログトピックの作成ステップで、ログを保存するための既存のログトピックを選択するか、新規に作成できます。ログトピックの詳細については、ログトピックを参照してください。


ステップ3：インデックス設定

1. 次へをクリックし、「インデックス設定」ページに進みます。
2. 「インデックス設定」ページで、以下の情報を設定します。設定の詳細については、インデックス設定を参照してください。

注意：
検索にはインデックス設定を有効にする必要があります。有効にしない場合、検索できません。

ステップ4：ログを検索する

これで、TKE K8sクラスタの監査またはイベントビジネスログ収集に関するすべてのデプロイが完了しました。CLSコンソール > 検索分析に移動して、収集されたログを確認できます。

その他の操作

業務ログ収集設定の管理

1. コンテナクラスタ管理ページで、対象のTKEクラスタを見つけ、クラスタ名をクリックして、クラスタ詳細ページに移動します。
2. クラスタ詳細ページで、クラスタビジネスログからクラスタビジネスログ収集設定を表示および管理できます。


ログ収集コンポーネントのアップグレード

コンテナクラスタ管理ページで、対象のTKEクラスタを見つけます。収集コンポーネントの状態にアップグレード可能と表示されている場合は、アップグレードをクリックして、ログ収集コンポーネントを最新バージョンにアップグレードできます。



ログ収集コンポーネントのアンインストール

コンテナクラスタ管理ページで、対象のTKEクラスタを見つけ、操作列のその他をクリックし、ドロップダウンメニューでログ収集コンポーネントのアンインストールをクリックします。



上一篇: CRDを使用した自建K8Sクラスターログ収集の設定下一篇: Syslogの収集

帮助和支持

本页内容是否解决了您的问题？

填写满意度调查问卷，共创更好文档体验。

文档反馈

搜索
    请输入关键词搜索文档