tencent cloud

フィードバック

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

最終更新日:2023-04-26 18:43:22
    ここでは、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が添付されます)。
    
    お問い合わせ

    カスタマーサービスをご提供できるため、ぜひお気軽にお問い合わせくださいませ。

    テクニカルサポート

    さらにサポートが必要な場合は、サポートチケットを送信して弊社サポートチームにお問い合わせください。24時間365日のサポートをご提供します。

    電話サポート(24 時間365日対応)