tencent cloud

Cloud Log Service

CRDを使用した自建K8Sクラスターログ収集の設定

ダウンロード
フォーカスモード
フォントサイズ
最終更新日: 2026-10-12 14:31:24
AI翻訳

操作シナリオ

CLS(Cloud Log Service)は、自社構築のK8Sクラスタ上のログ収集をサポートしています。ログ収集を行う前に、K8S自社構築クラスタ上でCRDを使用してログ収集設定(LogConfig)を定義し、Log-Provisioner、Log-Agent、およびLogListenerをデプロイしてインストールする必要があります。Tencent Kubernetes Engine(TKE)を使用しているユーザーは、TKE K8Sクラスタログの収集ドキュメントを参照して、コンソールからCLSをすばやく利用開始できます。

前提条件

1. 自建K8sクラスタにログ収集コンポーネントをインストールします。インストール方法については、自建K8sクラスタへのLogListenerのインストールを参照してください。コンポーネントをアップグレードする必要がある場合は、LogListenerアップグレードガイドの「自建K8sクラスタログ収集コンポーネントのアップグレード」を参照してください。
2. 対応するログアップロード権限を設定します。権限の設定については、自建K8Sを使用したデータのアップロードを参照してください。
3. ログトピックが存在するリージョン(region)を取得しました。詳細なCLSリージョンリストについては、利用可能なリージョンを参照してください。

K8Sログ収集の原理

K8Sクラスタ上でのログ収集のデプロイには、主にLog-Provisioner、Log-Agent、LogListenerの3つのコンポーネントと、1つのLogConfig収集設定が含まれます。
LogConfig:ログ収集設定です。ログがどこで収集されるか、収集後にどのように解析されるか、そして解析後にどのCLSログトピックに配信されるかを定義します。
Log-Agent:LogConfigとノード上のコンテナの変更を監視し、コンテナ内のログファイルのノードホスト上での実際の位置を動的に計算します。
Log-Provisioner:LogConfigで定義されたログ収集設定情報をCLSに同期します。
LogListener:ノードホスト上の対応するログファイルの内容を収集し、解析してCLSにアップロードします。

操作手順

操作手順

ステップ1:自建K8SクラスターへのLogListenerのインストール

まず、自建KubernetesクラスタにLogListenerコンポーネントをインストールして、ログをCLSに収集する必要があります。詳細については、自建K8SクラスタへのLogListenerのインストールを参照してください。

ステップ2:LogConfigオブジェクトの定義

CRDを使用してLogConfigオブジェクト内のログ収集設定を定義します。Masterノードのパス/usr/local/を例に、wgetコマンドを使用してLogConfig.yaml CRD宣言ファイルをダウンロードします。
wget https://mirrors.tencent.com/install/cls/k8s/LogConfig.yaml
LogConfig.yaml宣言ファイルは主に以下の2つの部分に分かれています:
clsDetail:ログ収集設定です。
inputDetail:ログソース設定です。
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig ## デフォルト値
metadata:
name: test ## CRDリソース名、クラスタ内で一意です。
spec:
clsDetail: ## CLSへ配信するための設定です。
...
inputDetail: ## ログソース設定です。
...

clsDetail(CLS収集設定)フィールドの説明

clsDetail:
### ログセットとログトピックの指定
logsetName: test ## CLSログセットのnameです。必須ではありません。該当するlogsetNameのログセットが存在しない場合は自動的に作成され、存在する場合はそのログセットの下にログトピックが作成されます。
topicName: test ## CLSログトピックのnameです。必須ではありません。logsetNameの下に該当するnameのログトピックが存在しない場合は、自動的に作成されます。
## logsetNameとtopicNameを指定した後、logsetIdとtopicIdを指定しない場合、ログトピックの自動作成が試行されます。それ以外の場合、topicは作成されません。
logsetId: xxxxxx-xx-xx-xx-xxxxxxxx ## CLSログセットのIDです。必須ではありません。
topicId: xxxxxx-xx-xx-xx-xxxxxxxx ## CLSログトピックのIDです。必須ではありません。topicIdを入力しない場合、logsetNameとtopicNameを入力する必要があります。また、topicの自動作成が試行され、作成されたtopicのtopicIdがこのフィールドに入力されます。
### ログトピックを自動作成する際に、ログトピック設定を定義します。定義後は変更できません。変更しても有効になりません。
period: 30 ## 必須ではありません。ライフサイクル、単位は日、有効範囲は1~3600、低頻度ストレージの有効範囲は7~3600日です。値が3640の場合は永久保存を表します。
storageType: hot ## 必須ではありません。ログトピックのストレージタイプです。選択可能な値はhot(標準ストレージ)、cold(低頻度ストレージ)です。デフォルトはhotです。
hotPeriod: 7 ## 必須ではありません。沉降サイクル、単位は日です。有効範囲は7~3600です。storageType:hotの場合のみ有効です。hotPeriodはperiodより大きい必要があります。沉降のサイクルはPeriod-hotPeriodです。
partitionCount: 1 ## 必須ではありません。ログトピックのパーティション数です。デフォルトでは1個作成され、最大10個のパーティションを作成できます。
autoSplit: "true" ## 必須ではありません。自動分割を有効にするかどうかです。デフォルト値はtrueです。値は二重引用符\\"\\"で囲む必要があります。
maxSplitPartitions: 50 ## 必須ではありません。自動分割を有効にした後の最大分割数です。デフォルト値は50です。
tags: ## 必須ではありません。Tag説明リストです。このパラメータを指定することで、Tagを対応するログトピックに同時にバインドできます。最大9個のTagキーと値のペアをサポートします。同じリソースは同じTagキーにのみバインドできます。
- key: xxx ## Tag key
value: xxx ## Tag value
### 収集ルールを定義します。
logType: json_log ## ログ解析形式です。json_logはjson形式、delimiter_logは区切り文字形式、minimalist_logは単行全文形式、multiline_logは複数行全文形式、fullregex_logは単行完全正規表現形式、multiline_fullregex_logは複数行完全正規表現形式、user_define_logは組み合わせ解析を表します。デフォルトはminimalist_logです。
excludePaths: ## 必須ではありません。収集拒否リストのパスリストです。inputDetailがcontainerFileまたはhostFileの場合のみ有効です。
- type: File ## タイプです。FileまたはPathを選択できます。
value: /xx/xx/xx/xx.log ## typeに対応する値です。
userDefineRule: xxxxxx ## 必須ではありません。ユーザー定義の収集ルールです。Json形式でシリアル化された文字列です。
### 抽出、フィルタリングルール
extractRule: ## 必須ではありません。抽出、フィルタリングルールです。ExtractRuleを設定した場合は、LogTypeを設定する必要があります。詳細はextractRuleオブジェクトの説明を参照してください。
timeKey: xxx ## 時間フィールドのkey名です。time_keyとtime_formatは必ずペアで指定する必要があります。
timeFormat: xxx ## 時間フィールドの形式です。c言語のstrftime関数の時刻形式に関する説明を参照してパラメータを出力します。
delimiter: xxx ## 区切り文字タイプのログの区切り文字です。log_typeがdelimiter_logの場合のみ有効です。
logRegex: xxx ## ログ全体のマッチングルールです。log_typeがfullregex_logの場合のみ有効です。
beginningRegex: xxx ## 行頭の正規表現マッチングルールです。log_typeがmultiline_logまたはfullregex_logの場合のみ有効です。
keys: ## 取得する各フィールドのkey名です。空のkeyはこのフィールドを破棄することを表します。log_typeがdelimiter_logの場合のみ有効です。
- a
- b
filterKeys: ## filterRegexと対応する必要があります。filterKeysは配列で、フィルタリングするログのkeyを表します。
- a
- b
filterRegex: ## filterKeysと対応する必要があります。filterRegexは正規表現文字列の配列で、keyに対応するフィルタリングルールのregexです。
- aRegx
- bRegx
advancedFilters: ## 高度なフィルタリングルールです。このフィールドはv1.1.15以降の収集コンポーネントバージョンにのみ適用されます。v1.1.15より前のバージョンではfilterKeysとfilterRegexを使用してください。
- key: level ## フィルタリングするKey
rule: 0 ## フィルタリングルールです。サポートされる数値列挙は、0(等しい)、1(フィールドが存在する)、2(フィールドが存在しない)、3(等しくない)です。
value: info ## フィルタリングする値valueです。ruleが1または2の場合、valueを指定する必要はありません。
unMatchUpload: "false" ## 解析失敗ログをアップロードするかどうかです。trueはアップロードすることを表し、falseはアップロードしないことを表します。デフォルトではアップロードしません。
unMatchedKey: "parseFailed" ## 解析に失敗したログをCLSにアップロードする際のkey名です。
backtracking: "-1" ## 「-1」または「0」です。-1は全量収集を表し、0は増分収集を表します。0より大きいその他の数字は増分収集モードでの遡及データ量を表します。デフォルトは全量です。
isGBK: "true" ## 「true」または「false」です。デフォルトは「false」で、jbkではありません。
jsonStandard: "true" ## 「true」または「false」です。デフォルトは「true」で、標準jsonです。
### 高度な収集設定
advancedConfig: ## 必須ではありません。
ClsAgentMaxDepth: 1 ## 収集器が収集する最大ディレクトリ深度です。0以上の整数で、0は現在のディレクトリを表します。
ClsAgentFileTimeout: 60 ## ファイルタイムアウト属性です。指定時間を超えてもログファイルが変更されない場合、収集器は監視を行いません。このパラメータは0以上の整数で指定する必要があります。単位は秒です。0はタイムアウトなしで、すべて収集します。
ClsAgentParseFailMerge: true ## 解析失敗ログを結合します。値の範囲はtrueまたはfalseです。

### topicを作成する際に全文インデックスをカスタマイズできます。
### ログトピックを自動作成する場合のみ定義をサポートします。既存のログトピックのインデックス変更はサポートされません。
fullTextIndex: ## 必須ではありません。全文インデックス設定です。
status: "on" ## 全文インデックススイッチです。設定しない場合、デフォルトで全文インデックスが有効になります。onに設定して有効にし、他のパラメータを設定しない場合、caseSensitiveとtokenizerはどちらもデフォルト値になります。offに設定して無効にした場合、全文インデックスは有効になりません。
tokenizer: "@&()='\\",;:<>[]{}/ \\n\\t\\r" ## 全文インデックスのトークナイザです。全文インデックススイッチが有効な場合、tokenizerを設定する必要があります。「"@&()='\\",;:<>[]{}/ \\n\\t\\r"」に設定できます。これはデフォルト設定です。
caseSensitive: false ## 大文字と小文字を区別するかどうかです。
containZH: false ## 中国語を含むかどうかです。
### topicを作成する際にTAGとキーバリューインデックス設定をカスタマイズできます。
indexStatus: "on" ## 必須ではありません。TAGインデックスとキーバリューインデックス設定のスイッチです。設定しない場合、デフォルトでpod_name/namespace/container_nameの3つのTAGインデックスが作成されます。offの場合はキーバリューインデックスを設定しないことを示します。
autoIndex: "off" ## 必須ではありません。offの場合は自動設定インデックスを設定しないことを示し、onの場合は自動設定インデックスを有効にすることを示します。
indexs: ## 必須ではありません。
- indexName: xxx ## キーバリューインデックスまたはTAGインデックスを設定する必要があるフィールドです。Pod関連のnamespace/pod_name/pod_ip/pod_uid/container_id/container_name/image_name/cluster_idの8つのメタデータフィールドとpod_label_プレフィックスフィールドはTAGインデックスとして設定され、その他のフィールドはキーバリューインデックスとして設定されます。
indexType: "text" ## 必須ではありません。フィールドタイプです。現在サポートされているタイプはlong、text、doubleです。必須ではありません。
tokenizer: "@&()='\\",;:<>[]{}/ \\n\\t\\r" ## 必須ではありません。フィールドのトークナイザです。その中の各文字は1つのトークナイザを表します。英数字記号と\\n\\t\\rのみをサポートします。longおよびdoubleタイプのフィールドは空にする必要があります。
## textタイプのフィールドでは、@&?|#()='",;:<>[]{}/ \\n\\t\\r\\ をトークナイザとして使用することを推奨します。
sqlFlag: true ## 必須ではありません。フィールドが分析機能を有効にするかどうかです。true/false フィールドが分析機能を有効にするかどうかです。ログトピックが低頻度ログトピックの場合、sqlFlagオプションを有効にすることはできません。
containZH: false ## 必須ではありません。中国語を含むかどうかです。

ログ収集ルール設定例

単一行フルテキスト形式
複数行フルテキスト形式
単一行-完全正規表現形式
複数行-完全正規表現形式
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
LogConfigの設定参考例は以下の通りです:
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
metadata:
name: test ## 収集設定名
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をログの終了識別子とすることはやや不合理です。ログシステムが各ログを明確に区別できるようにするために、先頭行の正規表現方式でマッチングを行います。ある行のログが事前に設定された正規表現にマッチした場合、その行を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)
LogConfig設定の参考は以下の通りです:
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
metadata:
name: test ## 収集設定名
spec:
clsDetail:
topicId: xxxxxx-xx-xx-xx-xxxxxxxx
# 複数行ログ
logType: multiline_log
extractRule:
# 日付と時刻で始まる行のみが新しいログの先頭と見なされます。それ以外の場合は、改行文字\\\\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を抽出するログ解析モードを指します。
あるログの元のデータが以下の通りであると仮定します:
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
metadata:
name: test ## 収集設定名
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を抽出する必要がない場合は、複数行全文形式を参照して設定してください。
あるログの元のデータが以下の通りであると仮定します:
[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
metadata:
name: test ## 収集設定名
spec:
clsDetail:
topicId: xxxxxx-xx-xx-xx-xxxxxxxx
#複数行-完全正規表現形式
logType: multiline_fullregex_log
extractRule:
#行首完全正規表現。日付と時刻で始まる行のみが新しいログの先頭と見なされます。それ以外の場合は、改行文字\\\\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: ajava.lang.Exception: exception happened
at TestPrintStackTrace.f(TestPrintStackTrace.java:3)
at TestPrintStackTrace.g(TestPrintStackTrace.java:7)
at TestPrintStackTrace.main(TestPrintStackTrace.java:16)
JSON形式のログは、最上位層のkeyを対応するフィールド名として自動的に抽出し、最上位層のvalueを対応するフィールド値として自動的に抽出します。この方法でログ全体を構造化処理し、各完全なログは改行文字\\\\nを終了識別子とします。
ある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
metadata:
name: test ## 収集設定名
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
metadata:
name: test ## 収集設定名
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]
あるログの元のデータが以下の通りであると仮定します:
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"
}
}
]
}
]
}
LogConfig設定の参考は以下の通りです:
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
metadata:
name: test ## 収集設定名
spec:
clsDetail:
topicId: xxxxxx-xx-xx-xx-xxxxxxxx
# 区切り文字ログ
logType: user_define_log
userDefineRule:"{ \\"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

inputDetail(ログソース)フィールドの説明

inputDetail:
type: container_stdout ## 収集するログのタイプを指定します。container_stdout(コンテナ標準出力)、container_file(コンテナファイル)、host_file(ホストファイル)が含まれます。
containerStdout: ## コンテナ標準出力設定。type:container_stdoutの場合のみ有効です。
namespace: default ## 収集コンテナのkubernetes名前空間。複数の名前空間をサポートします。複数の名前空間がある場合は「,」で区切ります。例:default,namespace。指定しない場合は、すべての名前空間を表します。注意:excludeNamespaceと同時に指定することはできません。
excludeNamespace: nm1,nm2 ## 収集コンテナのkubernetes名前空間を除外します。複数の名前空間をサポートします。複数の名前空間がある場合は「,」で区切ります。例:nm1,nm2。指定しない場合は、すべての名前空間を表します。注意:namespaceと同時に指定することはできません。
nsLabelSelector: environment in (production),tier in (frontend) ## 名前空間ラベルに基づいて、条件を満たすnamespaceをフィルタリングします。
allContainers: false ## 指定された名前空間内のすべてのコンテナの標準出力を収集するかどうか。注意:allContainers=trueの場合、workload、includeLabels、excludeLabelsを同時に指定することはできません。
containerOperator: in ## container選択方式。含める場合はin、除外する場合はnotinを入力します。
container: xxx ## ログを収集する、または収集しないコンテナ名を指定します。複数指定でき、カンマで区切ります。containerOperatorがinの場合、*を入力でき、すべてのコンテナを収集することを表します。
includeLabels: ## 指定されたlabelを含むPodを収集します。workloadと同時に指定することはできません。
key: value1 ## 同じkeyの下で複数のvalue値を持つpodをマッチングできます。例:environment = production,qaと入力すると、keyがenvironmentで、value値がproductionまたはqaの場合、いずれもマッチングされます。複数のvalue値を入力する場合はカンマで区切ってください。excludeLabelsも同時に指定した場合、excludeLabelsとの積集合に該当するpodをマッチングします。
excludeLabels: ## 指定されたlabelを含まないPodを収集します。workload、namespace、excludeNamespaceと同時に指定することはできません。
key2: value2 ## 同じkeyの下で複数のvalue値を持つpodをマッチングできます。例:environment = production,qaと入力すると、keyがenvironmentで、value値がproductionまたはqaの場合、いずれも除外されます。複数のvalue値を入力する場合はカンマで区切ってください。includeLabelsも同時に指定した場合、includeLabelsとの積集合に該当するpodをマッチングします。
metadataLabels: ## 具体的にどのpod labelをメタデータとして収集するかを指定します。指定しない場合は、すべてのpod labelをメタデータとして収集します。
- label1
metadataContainer: ## 具体的にどのコンテナ環境関連メタデータを収集するかを指定します。指定しない場合は、すべてのコンテナ環境関連メタデータ(namespace,pod_name,pod_ip,pod_uid,container_id,container_name,image_name)を収集します。
- namespace
customLabels: ## ユーザー定義のmetadata
label: l1
workloads: ## 指定された名前空間 -> 指定されたワークロードタイプ内 -> 指定されたワークロード -> 指定されたコンテナ内のログを収集します。
- container: xxx ## 収集するコンテナ名。指定しない場合は、workload Pod内のすべてのコンテナを表します。
containerOperator: in ## container選択方式。含める場合はin、除外する場合はnotinを入力します。
kind: deployment ## workloadタイプ。deployment、daemonset、statefulset、job、cronjobをサポートします。
name: sample-app ## workloadの名前
namespace: prod ## workloadの名前空間
containerFile: ## コンテナ内ファイル設定。type:container_fileの場合のみ有効です。
namespace: default ## 収集コンテナのkubernetes名前空間。1つの名前空間を指定する必要があります。
excludeNamespace: nm1,nm2 ## 収集コンテナのkubernetes名前空間を除外します。複数の名前空間をサポートします。複数の名前空間がある場合は「,」で区切ります。例:nm1,nm2。指定しない場合は、すべての名前空間を表します。注意:namespaceと同時に指定することはできません。
nsLabelSelector: environment in (production),tier in (frontend) ## 名前空間ラベルに基づいて、条件を満たすnamespaceをフィルタリングします。
containerOperator: in ## container選択方式。含める場合はin、除外する場合はnotinを入力します。
container: xxx ## ログを収集する、または収集しないコンテナ名を指定します。複数指定でき、カンマで区切ります。containerOperatorがinの場合、*を入力でき、すべてのコンテナを収集することを表します。workloadのタイプと名前を指定した場合、ここで指定したワークロード内のコンテナ名を定義できます。
logPath: /var/logs ## ログフォルダ。ワイルドカード*と?をサポートします。*は複数の任意の文字に一致し、?は1つの任意の文字に一致します。
filePattern: app_*.log ## ログファイル名。ワイルドカード*と?をサポートします。*は複数の任意の文字に一致し、?は1つの任意の文字に一致します。
## コンテナ内の複数のログパスとファイルを指定します。このパラメータはlogPath、filePatternと互換性がありません。filePathsまたは(logPath、filePattern)のみ指定できます。
## (logPathとfilePattern)からfilePathsへ変更すると、ログの再収集が発生します。逆にfilePathsからlogPathとfilePatternへ変更した場合も同様です。
filePaths:
- file: /var/logs ## ログフォルダ。ワイルドカード*と?をサポートします。*は複数の任意の文字に一致し、?は1つの任意の文字に一致します。
path: app_*.log ## ログファイル名。ワイルドカード*と?をサポートします。*は複数の任意の文字に一致し、?は1つの任意の文字に一致します。
- file: /var/logs1
path: app_*.log
includeLabels: ## 指定されたlabelを含むPodを収集します。workloadと同時に指定することはできません。
key: value1 ## 収集ルールで収集されたログにはmetadataが付与され、コンシューマー側に報告されます。同じkeyの下で複数のvalue値を持つpodをマッチングできます。例:environment = production,qaと入力すると、keyがenvironmentで、value値がproductionまたはqaの場合、いずれもマッチングされます。複数のvalue値を入力する場合はカンマで区切ってください。excludeLabelsも同時に指定した場合、excludeLabelsとの積集合に該当するpodをマッチングします。
excludeLabels: ## 指定されたlabelを含まないPodを収集します。workloadと同時に指定することはできません。
key2: value2 ## 同じkeyの下で複数のvalue値を持つpodをマッチングできます。例:environment = production,qaと入力すると、keyがenvironmentで、value値がproductionまたはqaの場合、いずれも除外されます。複数のvalue値を入力する場合はカンマで区切ってください。includeLabelsも同時に指定した場合、includeLabelsとの積集合に該当するpodをマッチングします。
metadataLabels: ## 具体的にどのpod labelをメタデータとして収集するかを指定します。指定しない場合は、すべてのpod labelをメタデータとして収集します。
- namespace
metadataContainer: ## 具体的にどのコンテナ環境関連メタデータを収集するかを指定します。指定しない場合は、すべてのコンテナ環境関連メタデータ(namespace,pod_name,pod_ip,pod_uid,container_id,container_name,image_name)を収集します。
customLabels: ## ユーザー定義のmetadata
key: value
workload: ## 指定された名前空間 -> 指定されたワークロードタイプ内 -> 指定されたワークロード内のすべてのコンテナを収集します。ワークロード内のコンテナを指定するには、外側のcontainerで指定する必要があります。
kind: deployment ## workloadタイプ。deployment、daemonset、statefulset、job、cronjobをサポートします。
name: sample-app ## workloadの名前
namespace: prod ## workloadの名前空間

hostFile: ## ノードファイルパスです。type:host_fileの場合のみ有効です。
filePattern: '*.log' ## ログファイル名。ワイルドカード*と?をサポートします。*は複数の任意の文字に一致し、?は1つの任意の文字に一致します。
logPath: /tmp/logs ## ログフォルダ。ワイルドカード*と?をサポートします。*は複数の任意の文字に一致し、?は1つの任意の文字に一致します。
## コンテナ内の複数のログパスとファイルを指定します。このパラメータはlogPath、filePatternと互換性がありません。filePathsまたは(logPath、filePattern)のみ指定できます。
## (logPathとfilePattern)からfilePathsへ変更すると、ログの再収集が発生します。逆にfilePathsからlogPathとfilePatternへ変更した場合も同様です。
filePaths:
- file: /var/logs ## ログフォルダ。ワイルドカード*と?をサポートします。*は複数の任意の文字に一致し、?は1つの任意の文字に一致します。
path: app_*.log ## ログファイル名。ワイルドカード*と?をサポートします。*は複数の任意の文字に一致し、?は1つの任意の文字に一致します。
- file: /var/logs1
path: app_*.log
customLabels: ## ユーザー定義のmetadata
label1: v1

ログソース設定例

コンテナ標準出力
コンテナファイル
ホストファイル
示例1:default名前空間内のすべてのコンテナの標準出力を収集します。
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
metadata:
name: test ## 収集設定名
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 Tagに「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
...
示例4:production名前空間内のingress-gatewayワークロードに属するpod内の、ingressという名前のコンテナの標準出力を収集します。
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
inputDetail:
type: container_stdout
containerStdout:
allContainers: false
containerOperator: in
container: ingress
workloads:
- namespace: production
name: ingress-gateway
kind: deployment
...
示例1:production名前空間内のingress-gateway deploymentに属するpod内のnginxコンテナ内の/data/nginx/log/パスにあるaccess.logという名前のファイルを収集します。
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
metadata:
name: test ## 収集設定名
spec:
inputDetail:
type: container_file
containerFile:
namespace: production
workload:
name: ingress-gateway
kind: deployment
container: nginx
filePaths:
- file: access.log
path: /data/nginx/log
...
示例2:production名前空間内のpod Tagに「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
filePaths:
- file: access.log
path: /data/nginx/log
...
示例:ホストの/data/パスにあるすべての.logファイルを収集します。
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
metadata:
name: test ## 収集設定名
spec:
inputDetail:
type: host_file
hostFile:
logPath: /data
filePattern: *.log
...

ステップ3:LogConfigオブジェクトの作成

ステップ2ではLogConfig.yaml宣言ファイルを定義しています。このLogConfig.yaml宣言ファイルに基づいて、kubectlコマンドを使用してLogConfigオブジェクトを作成できます。
kubectl create -f /usr/local/LogConfig.yaml

ステップ4:LogConfigの確認

kubectl get logconfig

後続操作

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

ヘルプとサポート

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

フィードバック