tencent cloud

Tencent Kubernetes Engine

YAMLによってログのキャプチャを設定します

PDF
フォーカスモード
フォントサイズ
最終更新日: 2025-09-29 14:35:16
ここでは、YAML形式によりCRDを使用してTKE Serverlessクラスターのログキャプチャ機能を設定する方法についてご説明します。

前提条件

TKEコンソールにログインし、Serverlessクラスターのログキャプチャ機能を有効にします。操作の詳細については、ログキャプチャ機能の有効化をご参照ください。

CRDの作成

LogConfig CRDを定義するだけで、キャプチャ設定を作成することができます。キャプチャコンポーネントは、LogConfig CRDの変更に応じて対応するCloud Log Service(CLS)ログトピックを変更し、バインドされたマシングループを設定します。CRDの形式は次のとおりです。

clsDetailフィールドの説明

注意:
topic指定後の変更はできません。
選択したキャプチャタイプが「コンテナファイルパス」の場合、対応する「コンテナファイルパス」をソフトリンクにすることはできず、これを行った場合はソフトリンクの実際のパスがキャプチャツール内のコンテナに存在しなくなり、ログキャプチャに失敗します。
clsDetail:
## ログトピックを自動作成します。ログセットおよびトピックのnameを同時に指定する必要があります
logsetName: test ## CLSログセットのname。このnameのログセットがなければ自動的に作成し、ある場合は、このログセットの下にログトピックを作成します
topicName: test   ## CLSログトピックのname。このnameのログトピックがなければ自動的に作成します

# 既存のログセットとログトピックを選択します。ログセットが指定されていて、ログトピックが指定されていない場合は、自動的にログトピックが作成されます
logsetId: xxxxxx-xx-xx-xx-xxxxxxxx  ## CLSログセットのID。ログセットはCLS内にあらかじめ作成しておく必要があります
topicId: xxxxxx-xx-xx-xx-xxxxxxxx   ## CLSログトピックのID。ログトピックはCLS内にあらかじめ作成し、かつ他のキャプチャ設定に占有されていないことが必要です

logType: json_log  ## ログキャプチャの形式。json_logはjson形式を表し、delimiter_logは区切り文字形式を表します。minimalist_logはシングルライン全文形式を、multiline_logはマルチライン全文形式を、fullregex_logは完全正規表現形式をそれぞれ表します。デフォルトではminimalist_logです
logFormat: xxx ## ログのフォーマット方法
period: 30 ## ライフサイクル。単位は日、可能な値の範囲は1~3600です。値が3640の場合は永久保存を表します
partitionCount: ## Integerタイプで、ログトピックのパーティション数です。デフォルトでは1個作成し、最大で10個のパーティションを作成できます。
tags: ## タグ記述リスト。このパラメータを指定することで、タグを同時に対応するログトピックにバインドできます。最大9個のタグキーバリューペアを作成できますが、同一のリソースは同一のタグキーにしかバインドできません。
- key: xxx  ## タグkey
value: xxx  ## タグvalue
autoSplit: false ## booleanタイプ、自動分割を有効にするかどうか。デフォルト値はtrueです
maxSplitPartitions:
storageType: hot ## ログトピックのStorageタイプ。オプション値はhot(標準Storage)、cold(低頻度Storage)で、デフォルトではhotです。
excludePaths: ## ブラックリストパスリストのキャプチャ
- type: File ## タイプ、オプションはFileまたはPathです 
value: /xx/xx/xx/xx.log   ## typeの対応する値
indexs:  ## topic作成時にカスタマイズ可能なインデックス方式およびフィールド
- indexName:  ## キー値またはメタフィールドインデックスのフィールドを設定する必要があります。メタフィールドKeyにはプレフィックス__TAG__.を追加する必要がなく、ログをアップロードする際に対応するフィールドKeyが一致することで設定できます。Tencent Cloudコンソールで表示する際はプレフィックス__TAG__.が自動的に追加されます
indexType:  ## フィールドタイプ。現在はlong、text、doubleタイプをサポートしています
tokenizer:  ## フィールドの区切り文字。この中のそれぞれの文字が区切り文字を表します。英字記号および\\n\\t\\rのみをサポートしています。longおよびdoubleタイプのフィールドは空にしておきます。textタイプのフィールドでは @&?|#()='",;:<>[]{}/ \\n\\t\\r\\ を区切り文字として使用することを推奨します。
sqlFlag:  ## boolean フィールドで分析機能を有効にしているかどうか
containZH:  ## boolean 中国語が含まれるかどうか
region: ap-xxx   ## topicの所在リージョン。クロスリージョン配信に使用します
userDefineRule: xxxxxx   ## ユーザー定義キャプチャルール。Json形式でシリアライズした文字列です
extractRule: {}  ## 抽出、フィルタリングルール。ExtractRuleを設定した場合は、LogTypeを設定する必要があります


inputDetailフィールドの説明

inputDetail:
type: container_stdout  ## ログキャプチャのタイプ。container_stdout(コンテナ標準出力)、container_file(コンテナファイル)、host_file(ホストファイル)が含まれます

containerStdout:  ## コンテナ標準出力
namespace: default   ## キャプチャコンテナのkubernetesネームスペース。複数のネームスペースをサポートしており、複数のネームスペースがある場合は「,」で区切ります(例:default,namespace)。指定しない場合は、すべてのネームスペースを表します。注意:excludeNamespaceとは同時に指定できません
excludeNamespace: nm1,nm2  ## キャプチャコンテナのkubernetesネームスペースを除外します。複数のネームスペースをサポートしており、複数のネームスペースがある場合は「,」で区切ります(例:nm1,nm2)。指定しない場合は、すべてのネームスペースを表します。注意:namespaceとは同時に指定できません
nsLabelSelector: environment in (production),tier in (frontend) ## ネームスペースlabelに基づくフィルタリングで合致したnamespace
allContainers: false  ## 指定のネームスペース内のすべてのコンテナの標準出力をキャプチャするかどうか。注意:allContainers=trueの場合はworkloa、includeLabels、excludeLabelsを同時に指定することはできません
container: xxx   ## ログをキャプチャするコンテナ名。空の場合は、コンテナに合致するログ名をすべてキャプチャすることを表します。注意: 
excludeLabels:  ## キャプチャに指定のlabelを含むPodを含めません。workload、namespace、excludeNamespaceとは同時に指定できません
key2: value2  ## 同一のkey下にある複数のvalue値のpodのマッチングをサポートします。例えばenviroment = production,qaと入力した場合、keyがenviroment、value値がproductionまたはqaの場合はすべて除外されることを表します。複数のvalue値を入力する場合はコンマで区切ることにご注意ください。includeLabelsを同時に指定すると、includeLabelsとの共通部分のpodがマッチします

includeLabels:  ## 指定のlabelを含むPodをキャプチャします。workload、namespace、excludeNamespaceとは同時に指定できません
key: value1  ## キャプチャルールでキャプチャされたログにはmetadataが含まれ、コンシューマー側にレポートされます。同一のkey下にある複数のvalue値のpodのマッチングをサポートします。例えばenviroment = production,qaと入力した場合、keyがenviroment、value値がproductionまたはqaの場合はすべてマッチングされることを表します。複数のvalue値を入力する場合はコンマで区切ることにご注意ください。excludeLabelsを同時に指定すると、excludeLabelsとの共通部分のpodがマッチします

metadataLabels:  ## 具体的にどのpod labelがメタデータとしてキャプチャされるかを指定します。指定しない場合は、すべてのpod labelがメタデータとしてキャプチャされます
- label1
customLabels:  ## ユーザー定義のmetadata
label: l1

workloads:
- container: xxx  ## キャプチャするコンテナ名。指定しない場合は、workload Pod内のすべてのコンテナを表します
kind: deployment  ## workloadタイプ。deployment、daemonset、statefulset、job、cronjobをサポートします
name: sample-app  ## workloadの名前
namespace: prod  ## workloadのネームスペース

containerFile:  ## コンテナ内のファイル
namespace: default   ## キャプチャコンテナのkubernetesネームスペース。1つのネームスペースを必ず指定する必要があります
excludeNamespace: nm1,nm2   ## キャプチャコンテナのkubernetesネームスペースを除外します。複数のネームスペースをサポートしており、複数のネームスペースがある場合は「,」で区切ります(例:nm1,nm2)。指定しない場合は、すべてのネームスペースを表します。注意:namespaceとは同時に指定できません
nsLabelSelector: environment in (production),tier in (frontend) ## ネームスペースlabelに基づくフィルタリングで合致したnamespace
container: xxx   ## ログをキャプチャするコンテナ名。*の場合は、コンテナに合致するログ名をすべてキャプチャすることを表します
logPath: /var/logs   ## ログフォルダ。ワイルドカードはサポートしていません
filePattern: app_*.log  ## ログファイル名。ワイルドカード*と?をサポートしています。*は複数の任意の文字をマッチングすることを表し、?は単一の任意の文字をマッチングすることを表します
customLabels:  ## ユーザー定義のmetadata
key: value
excludeLabels:  ## キャプチャに指定のlabelを含むPodを含めません。workloadとは同時に指定できません
key2: value2  ## 同一のkey下にある複数のvalue値のpodのマッチングをサポートします。例えばenviroment = production,qaと入力した場合、keyがenviroment、value値がproductionまたはqaの場合はすべて除外されることを表します。複数のvalue値を入力する場合はコンマで区切ることにご注意ください。includeLabelsを同時に指定すると、includeLabelsとの共通部分のpodがマッチします

includeLabels:  ## 指定のlabelを含むPodをキャプチャします。workloadとは同時に指定できません
key: value1  ## キャプチャルールでキャプチャされたログにはmetadataが含まれ、コンシューマー側にレポートされます。同一のkey下にある複数のvalue値のpodのマッチングをサポートします。例えばenviroment = production,qaと入力した場合、keyがenviroment、value値がproductionまたはqaの場合はすべてマッチングされることを表します。複数のvalue値を入力する場合はコンマで区切ることにご注意ください。excludeLabelsを同時に指定すると、excludeLabelsとの共通部分のpodがマッチします
metadataLabels:  ## 具体的にどのpod labelがメタデータとしてキャプチャされるかを指定します。指定しない場合は、すべてのpod labelがメタデータとしてキャプチャされます
- label1   ## pod label
workload:
container: xxx   ## キャプチャするコンテナ名。指定しない場合はworkload Pod内のすべてのコンテナを表します
name: sample-app  ## workloadの名前

ログ解析形式

シングルライン全文形式
マルチライン全文形式
シングルライン-完全な正規表現形式
マルチライン-完全な正規表現形式
JSON形式
区切り文字形式
シングルライン全文ログとは、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
LogConfigの設定の参照例は次のとおりです。
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
clsDetail:
topicId: xxxxxx-xx-xx-xx-xxxxxxxx
# シングルラインログ
logType: minimalist_log
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を使用することはできません。ログシステムが各ログを明確に区別するために、最初の行の正規表現が使用されてマッチングが行われます。特定の行のログがあらかじめ設定された正規表現にマッチする場合、それがログの先頭になり、次の行に最初に出現したものがそのログの終了識別子となります。マルチライン全文でも、デフォルトのキー値__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)

LogConfigの設定の参照は次のとおりです。
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
clsDetail:
topicId: xxxxxx-xx-xx-xx-xxxxxxxx
#マルチラインログ
logType: multiline_log
extractRule:
#日時で始まる行のみを新しい1行のログの先頭とみなし、それ以外は改行文字\\nを加え、現在のログの末尾に追加します
beginningRegex: \\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

LogConfigの設定の参照は次のとおりです。
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
clsDetail:
topicId: xxxxxx-xx-xx-xx-xxxxxxxx
# 完全な正規表現形式
logType: fullregex_log
extractRule:
# 正規表現、()のキャプチャグループに基づき、対応するvalueを抽出します
logRegex: (\\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+).*
beginningRegex: (\\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+).*
# 抽出されたkeyリスト、抽出されたvalueと逐一対応します
keys: ['remote_addr','time_local','request_method','request_url','http_protocol','http_host','status','request_length','body_bytes_sent','http_referer','http_user_agent','request_time','upstream_response_time']

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行の完全なログデータ(例:Javaプログラムログ)に適した、正規表現によって複数のkey-valueキー値として抽出できるログ解析モードです。key-valueの抽出が不要な場合は、マルチライン全文形式を参照して設定を行ってください。詳細については、マルチライン-完全な正規表現形式をご参照ください。
次のような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)

LogConfigの設定の参照は次のとおりです。
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
clsDetail:
topicId: xxxxxx-xx-xx-xx-xxxxxxxx
#マルチライン-完全な正規表現形式
logType: multiline_fullregex_log
extractRule:
#行頭の完全な正規表現です。日時で始まる行のみを新しい1行のログの先頭とみなし、それ以外は改行文字\\nを加え、現在のログの末尾に追加します
beginningRegex: \\[\\d+-\\d+-\\w+:\\d+:\\d+,\\d+\\]\\s\\[\\w+\\]\\s.*
#正規表現、()のキャプチャグループに基づき、対応するvalueを抽出します
logRegex: \\[(\\d+-\\d+-\\w+:\\d+:\\d+,\\d+)\\]\\s\\[(\\w+)\\]\\s(.*)
# 抽出されたkeyリスト、抽出されたvalueと逐一対応します
keys:
- time
- level
- msg

抽出されたkeyに基づき、CLSにキャプチャされたデータは次のとおりです
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形式のログは、第1階層のkeyを対応するフィールド名として自動的に抽出します。第1階層のvalueは対応するフィールドの値とします。このような方法によりログ全体の構造化処理を行い、それぞれの完全なログは改行文字\\nを終了識別子とします。詳細については、JSON形式をご参照ください。
次のような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"}

LogConfigの設定の参照は次のとおりです。
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
clsDetail:
topicId: xxxxxx-xx-xx-xx-xxxxxxxx
# JSON形式ログ
logType: json_log

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行のログデータを指定された区切り文字に従ってログ全体の構造化処理を行い、それぞれの行の完全なログは、改行文字\\nを終了識別子とするログのことです。CLSが区切り文字ログ処理を行う場合、各区切りのフィールドに固有のkeyを定義する必要があります。詳細については、区切り文字形式をご参照ください。
次のようなオリジナルログがあると仮定します。
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/

LogConfigの設定の参照は次のとおりです。
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
clsDetail:
topicId: xxxxxx-xx-xx-xx-xxxxxxxx
#区切り文字ログ
logType: delimiter_log
extractRule:
#区切り文字
delimiter: ':::'
#抽出されたkeyリスト、分割されたフィールドと逐一対応します
keys: ['IP','time','request','host','status','length','bytes','referer']

CLSにキャプチャされるデータは次のとおりです。
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:defaultのネームスペースにあるすべてのコンテナの標準出力をキャプチャします

apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
inputDetail:
type: container_stdout
containerStdout:
namespace: default
allContainers: true
...

例2:productionのネームスペースのingress-gateway deploymentに属するpodのコンテナの標準出力をキャプチャします

apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
inputDetail:
type: container_stdout
containerStdout:
allContainers: false
workloads:
- namespace: production
name: ingress-gateway
kind: deployment
...

例3:productionのネームスペースにおけるpodタグに「k8s-app=nginx」を含むpodのコンテナの標準出力をキャプチャします

apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
inputDetail:
type: container_stdout
containerStdout:
namespace: production
allContainers: false
includeLabels:
k8s-app: nginx
...

コンテナファイル

例1:productionネームスペースにおけるingress-gateway deploymentに属するpodのnginxコンテナの/data/nginx/log/パスの下にあるaccess.logというファイルをキャプチャします

apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
topicId: xxxxxx-xx-xx-xx-xxxxxxxx
inputDetail:
type: container_file
containerFile:
namespace: production
workload:
name: ingress-gateway
type: deployment
container: nginx
logPath: /data/nginx/log
filePattern: access.log
...

例2:productionネームスペースのpodタグに「k8s-app=ingress-gateway」が含まれるpodのnginxコンテナの/data/nginx/log/パスの下にあるaccess.logというファイルをキャプチャします

apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
inputDetail:
type: container_file
containerFile:
namespace: production
includeLabels:
k8s-app: ingress-gateway
container: nginx
logPath: /data/nginx/log
filePattern: access.log
...

メタデータ(Metadata)

コンテナ標準出力(container_stdout)およびコンテナファイル(container_file)は、オリジナルのログ内容のほか、コンテナシナリオに関するメタデータ(ログを生成したコンテナIDなど)とともにCLSへレポートする必要があります。これにより、ユーザーがログを確認する際、ソースを追跡したり、コンテナのマーカーや特性(コンテナ名やlabelsなど)に基づいて検索しやすくなります。
メタデータは下表のとおりです
フィールド名
意味
cluster_id
ログが属するクラスターIDです。
container_name
ログが属するコンテナ名です。
image_name
ログが属するコンテナのイメージ名IPです。
namespace
ログが属するpodのnamespaceです。
pod_uid
ログが属するpodのユーザーIDです。
pod_name
ログが属するpod名です。
pod_ip
ログが属するpodのIPです。
pod_lable_{label name}
ログが属するpodのlabelです(例えば1つのpodに、app=nginx、env=prodという2つのlabelがある場合、アップロードされたログにはpod_label_app:nginx、pod_label_env:prodという2つのmetedataが添付されます)。


ヘルプとサポート

この記事はお役に立ちましたか?

フィードバック