tencent cloud

Tencent Kubernetes Engine

お知らせ・リリースノート
製品アップデート情報
製品リリース記録
製品の説明
製品の優位性
製品アーキテクチャ
ユースケース
製品機能
リージョンとアベイラビリティーゾーン
クイックスタート
初心者ガイド
標準クラスターのクイック作成
ビギナー向け事例
コンテナアプリケーションのクラウドへのデプロイ Check List
TKE標準クラスターガイド
テンセントクバネティスエンジン
クラスター管理
ネットワーク管理
ストレージ管理
Worker ノードの概要
Kubernetes Object Management
ワークロード
クラウドネイティブサービスガイド
Prometheus監視サービス
TKE Serverlessクラスターガイド
TKE登録クラスターガイド
実践チュートリアル
Serverlessクラスター
ネットワーク
ログ
監視
運用・保守
DevOps
オートスケーリング
よくあるご質問
クラスター類
TKE Serverlessクラスター
運用保守系
サービス類
イメージリポジトリ類
リモート端末類
ドキュメントTencent Kubernetes Engine

コンテナログをCLSに収集する

フォーカスモード
フォントサイズ
最終更新日: 2023-04-28 15:30:11
ここではTKEコンソールでログ収集ルールを設定し、Tencent Cloud Log Service(CLS)に送信する方法をご紹介します。

操作手順

ログ収集ルールの作成

1. TKEコンソールにログインし、左側ナビゲーションバーのログ管理 > ログルールを選択します。
2. 下図のように、「ログルール」ページ上方でリージョンおよびログ収集ルールを設定する必要があるクラスターを選択し、新規作成をクリックします。

3. 下図のように、「ログ収集ルールの新規作成」ページでログサービス消費側を設定し、消費側 > タイプCLSを選択します。

収集ルール名:ログ収集ルール名をカスタマイズできます。
ログ所在リージョン:CLSはクロスリージョンログ配信をサポートしています。「変更」をクリックすることによってログを配信する目標リージョンを選択することができます。
ログセット:ログ所在リージョンに基づいて作成済みのログセットを表示します。既存のログセットが適切でない場合は、CLSコンソールでログセットを新規作成することができます。操作の詳細については、ログセットの作成をご参照ください。
ログトピック:ログセット下で対応するログトピックを選択します。ログトピックを「自動作成」および「既存のものを選択」の2種類のモードをサポートしています。
高度な設定:
デフォルトメタデータ:CLSはデフォルトでメタデータpod_namenamespacecontainer_nameをインデックスに設定してログ検索に使用します。
カスタムメタデータ:カスタムメタデータおよびログインデックスをサポートしています。
説明
CLSは国内および海外リージョン間のクロスリージョンログ配信をサポートしていません。CLSに対してログサービスがアクティブ化されていないリージョンは近接配信のみをサポートしています。例えば深圳クラスターが収集したコンテナログは広州への配信のみをサポートし、天津クラスターが収集したコンテナログは北京への配信のみをサポートしています。詳細はコンソールによって確認することができます。
1つのログトピックは現在1つのログの設定のみサポートしています。すなわちログ、審査、イベントは同一のtopicを採用できず、上書きが発生するため、選択するログトピックがその他の収集設定に占有されていないことを確認してください。ログセット下に500個のログトピックが存在する場合、ログトピックを新規作成することはできません。
カスタムメタデータおよびメタデータベースのオープンインデックスは作成後に変更できません。CLSコンソールで変更できます。
4. 収集タイプを選択し、ログソースを設定します。現在収集タイプはコンテナ標準出力コンテナファイルパスおよびノードファイルパスをサポートしています。
コンテナ標準出力ログ
コンテナ内のファイルログログ
ノードファイルログ
下図のように、ログソースはすべてのコンテナ指定ワークロード指定 Pod Lablesの3つのタイプをサポートしています。



ログソースは指定ワークロード指定Pod Lablesの2種類のタイプをサポートしています。
ファイルパスの収集はファイルパスおよびワイルドカードルールをサポートしています。例えばコンテナファイルパスが/opt/logs/*.logの場合、収集パスを/opt/logs、ファイル名を*.logとして指定できます。下図に示すとおりです。


注意
「コンテナファイルパス」 はソフトリンクにすることはできません。そうしない場合、ソフトリンクの実際のパスがコレクターのコンテナ内に存在しなくなり、ログの収集が失敗します。

収集パスはファイルパスおよびワイルドカードルール方式の入力をサポートしています。例えばすべてのファイルパスを /opt/logs/service1/*.log/opt/logs/service2/*.logの形式で収集する必要がある場合、収集パスのフォルダを/opt/logs/service*、ファイル名を*.logとして指定できます。
実際のニーズに応じてKey-Value形式のmetadataをカスタマイズして追加することができ、metadataはログレコード内に追加されます。

注意:
「ノードファイルパス」はソフトリンクにすることができません。そうしない場合、ソフトリンクの実際のパスがコレクターに存在しなくなり、ログの収集が失敗します。
1つのノードのログファイルは1つのログトピックのみによって収集されます。

説明
「コンテナの標準出力」および「コンテナ内ファイル「(「ノードファイルパス」、すなわちhostPathマウントは含みません)は、オリジナルのログ内容を除き、 コンテナまたはkubernetesに関連するメタデータを追加して(ログを生成するコンテナ ID)一緒にCLSに報告し、ユーザーがログを確認する時にソースの追跡またはコンテナ識別子に基づき、特徴(コンテナ名、labels)検索を行うことができるようにします。 コンテナまたはkubernetesに関連するメタデータについては下部の表をご参照ください。
フィールド名
意味
container_id
ログが属するコンテナIDです。
container_name
ログが属するコンテナ名です。
image_name
ログが属するコンテナのイメージ名IPです。
namespace
ログが属するpodのnamespaceです。
pod_uid
ログが属するpodのユーザーIDです。
pod_name
ログが属するpod名です。
pod_lable_{label name}
ログが属するpodのlabelです(例えば1つのpodに、app=nginx、env=prodという2つのlabelがある場合、アップロードされたログにはpod_label_app:nginx、pod_label_env:prodという2つのmetedataが添付されます)。

5. 収集ポリシーを設定します。全量または増分を設定できます。
全量:全量収集はログファイルの始めから収集することを指します。
増分:増分収集はファイル末尾から1Mまでの部分から収集を開始することを指します(ログファイルが1M未満の場合、全量収集と同等の効果を有します)。
6. 下図のように、次へをクリックし、ログ解析方式を選択します。

エンコードモード:UTF-8およびGBKをサポートしています。
抽出モード:さまざまなタイプの抽出モードをサポートしています。詳細は次のとおりです。
解析モード
説明
関連ドキュメント
フルテキストを1行で記入
1つのログは1行の内容のみを含み、改行コード\\nを1つのログの終了マーカーとし、各ログはキー値がCONTENTの完全な文字列として解析され、インデックスを有効化すると全文検索によってログ内容を検索できます。ログ時間は収集時間を基準とします。
フルテキストを複数行で記入
1つの完全なログが複数行に跨がることを意味し、1行目の正規表現を採用する方式でマッチングを行い、ある行のログが予め設定した正規表現にマッチングした場合、1つのログの始まりであると認識します。次の行の先頭はこのログの終了識別子として表示されます。デフォルトのキー値CONTENTも設定され、ログ時間は収集時間を基準とします。正規表現の自動生成をサポートしています。
シングルライン-完全な正規表現
1つの完全なログから正規表現形式で複数のkey-valueのログを抽出する解析モードを指します。まずログサンプルを入力し、次にカスタマイズされた正規表現を入力する必要があります。システムは正規表現内のキャプチャグループに基づいて対応するkey-valueを抽出します。正規表現の自動生成をサポートしています。
マルチライン-完全な正規表現
ログテキスト内の複数行にまたがる完全なログデータ(例:Javaプログラムログ)に適用され、正規表現に基づいて複数のkey-valueキー値のログ解析モードを抽出します。まずログサンプルを入力し、次にカスタマイズされた正規表現を入力する必要があります。システムは正規表現内のキャプチャグループに基づいて対応するkey-valueを抽出します。正規表現の自動生成をサポートしています。
JSON
JSON形式のログは、第1階層のkeyを対応するフィールド名として自動的に抽出します。第1階層のvalueは対応するフィールドの値とします。このような方法によりログ全体の構造化処理を行い、それぞれの完全なログは改行文字\\nを終了識別子とします。
区切り文字
1つのログデータは指定した区切り文字に基づいてログ全体に構造化処理を行い、それぞれの完全なログは改行コード \\nを終了識別子とします。ログサービスが区切り文字形式のログ処理を行う時に、各個別のフィールドに一意のkeyを定義する必要があり、無効フィールド、すなわち収集する必要がないフィールドは空欄を埋めることができ、すべてのフィールドが空であることはサポートしていません。
フィルタ:LogListenerはフィルタルールに一致するログのみを収集します。Keyは完全一致をサポートし、フィルタリングルールはErrorCode = 404のログのような正規表現のマッチングをサポートします。必要に応じてフィルタを有効化してルールを設定することができます。
説明
1つのログトピックは現在1つの収集設定のみをサポートしています。そのログトピックを選択したすべてのコンテナのログが選択するログ解析方式を受け入れることができることを確認してください。同一ログトピックで異なる収集設定を新規作成した場合、古い収集設定は上書きされます。
7. 完了をクリックすると、CLSに配信されるコンテナログ収集ルールの作成が完了します。

ログルールの更新

1. TKEコンソールにログインし、左側ナビゲーションバーのログ管理 > ログルールを選択します。
2. 下図のように、「ログルール」ページの上方でリージョンおよびログ収集ルールを更新する必要があるクラスターを選択し、右側の収集ルールの編集をクリックします。

3. 必要に応じて対応する設定を更新し、完了をクリックします。
注意
ログセットおよびログトピックは更新できません。

関連ドキュメント

コンソールを使用してログ収集を設定できるだけでなく、リソースのカスタマイズ(CustomResourceDefinitions、CRD)の方式でログ収集を設定することができます。詳細については、YAMLによってCRDを使用してログ収集を設定するをご参照ください。

ヘルプとサポート

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

フィードバック