コンテナログ収集に関するよくある質問
ダウンロード
フォーカスモード
フォントサイズ
インストールとアップグレード関連
TKEクラスタにログ収集コンポーネントをデプロイする方法を教えてください。
1. TKEコンソールにログインします。
2. 左側のナビゲーションバーで、運用保守機能管理をクリックし、機能管理ページに入ります。
3. 操作対象のクラスタを見つけ、設定をクリックします。
4. 表示されたウィンドウで、ログ収集欄の編集をクリックします。
5. ログ収集を有効にするにチェックを入れ、確定をクリックします。
6. 閉じるをクリックします。
TKEクラスタ内のログ収集コンポーネントをアップグレードする方法を教えてください。
1. TKEコンソールにログインします。
2. 左側のナビゲーションバーで、運用保守機能管理をクリックし、機能管理ページに入ります。
3. アップグレード可能なコンポーネントがあるクラスタを見つけ、設定をクリックします。
4. 表示されたウィンドウで、ログ収集欄の編集をクリックします。
5. コンポーネントのアップグレードをクリックします。
ネットワークと権限関連
TencentCloud APIのドメインに接続できない場合、どうすればよいですか？
TKE（Tencent Kubernetes Engine）のログ収集コンポーネントとCLS（Cloud Log Service）間で通信を行うコンポーネント cls-provisioner は、Tencent Cloud API ドメインを使用するため、ドメインへの接続性を確保する必要があります。コンポーネントのデプロイに失敗するなどの問題が発生し、ログに下図のようなエラーが表示されている場合、それはネットワークドメインが不通であることを示しています。
上図に示すように、cls-provisioner の起動に異常が発生しています。ログを確認すると、cls.internal.tencentcloudapi.com のドメインに接続できないことが分かりました。
Tencent Cloud上のマシンでは、デフォルトでTencent Cloudの内部および外部ネットワークのドメインはすべて接続可能です。通常、このような問題が発生する原因は、TKEノードのDNS設定が変更されたことです。以下の2つの方法で修復できます：
TKEノードマシンのDNS設定にTencent CloudのデフォルトDNSを追加します。
ホストマシン上のDNSサーバーがcore-dnsである場合、corednsにTencent CloudのDNS解決を追加するだけで対応できます。
説明：
TKEクラスタでドメイン名が解決できない問題が発生した場合は、まずTKEノードのDNS設定を確認することをお勧めします。
CLSログアップロード用ドメインに接続できない場合、どうすればよいですか？
ログアップロードのドメインはTencentCloud APIのドメインとは異なります。ログアップロードのドメインは
<region>.cls.tencentcs.com（外部ネットワーク）および<region>.cls.tencentyun.com（内部ネットワーク）です。詳細については、ドメインドキュメントを参照してください。修復方法：
クラスタノードマシンでドメインへのアクセスを確立します。
cls-provisionerとCLS間の通信で未承認と表示された場合、どうすればよいですか？
cls-provisionerとCLSの通信では、通常、次のようなエラーが発生します：
修復方法：
TKEクラスタを作成したアカウントで、ポリシーを事前に設定します。つまり、TKE_QCSRoleロールにQcloudAccessForTKERoleInOpsManagementポリシーを関連付けます。
収集関連
CLSに収集されたログが切り捨てられた場合、どうすればよいですか？
一部のケースでは、ユーザーログの出力タイプは標準出力ですが、CLSに収集されたログが切り捨てられていることが判明します。これは、Dockerのデフォルトのログストレージであるjson-toolに1行あたりのログサイズの制限があり、16Kを超えるログは切り捨てられるためです。
修復方法：
ログ出力を変更し、1行あたりのログ出力が16Kを超えないようにしてください。
ログが重複して収集される場合、どうすればよいですか？
ユーザーがCLSコンソールで検索したところ、一部のログに重複収集が発生していることを確認しました。この場合、まずログ出力のパスを確認し、ログがPV/PVCで作成された永続化ストレージに出力されているかどうかを確認してください。
ログが永続化ストレージに出力されている場合、業務Podが再構築されると、ログが再収集される原因となります。以下のコマンドを使用して、Podのyaml定義を確認できます：
kubectl get pods <pod_name> -n <namespace> -o yaml | less
以下のような情報が返された場合、ログが永続化ストレージに出力されていることを示します。
ビジネスでCFSを使用しており、かつCFSがコンテナにマウントされています。
CFS宣言を使用しました。
修復方法：
ログを永続化ストレージに保存する必要がない場合は、コンテナクラスタでログ収集を有効にすることで、ログをCLSに収集できます。
ログファイルを永続化ストレージに保存する必要がある場合は、CLSコンソールでLogListener収集ルールを設定する際に、収集ポリシーを増分収集に変更できます。ただし、増分収集ではすべてのログが収集されるとは限りません。
ログの収集漏れが発生した場合、どうすればよいですか？
Loglistenerは現在、NFS上に保存されたログをサポートしていません。Loglistenerはファイルの更新情報を取得するために、Linuxカーネルイベントをサブスクライブしており、能動的に対象ファイルをスキャンするわけではありません。
NFSファイルの更新情報はNFSサーバー側で処理されるため、クライアント側のローカルカーネルでイベントを生成できず、そのため感知されません。したがって、NFSファイルはリアルタイムに収集できず、収集漏れが発生する可能性があります。
収集設定とPodが一致しない場合、どうすればよいですか？
以下の操作を行うことで調査できます：
1. 以下のコマンドを使用して、Podのlabelが収集設定と一致しているかどうかを確認してください。
kubectl get pods <pod_name> -n <namespace> --show-labels
一致しています。次の手順を実行してください。
一致していません。正しい内容と照らし合わせて収集設定を修正してください。
2. Podのworkload（Deploymentまたはstatefulsetsなど）が収集設定と一致しているかどうかを確認してください。
kubectl get pods -n <namespace> |grep testa
一致しています。次の手順を実行してください。
一致していません。正しい内容と照らし合わせて収集設定を修正してください。
3. 以下のコマンドを使用して、Podのyaml定義を確認し、containerの名前と収集設定で指定されたコンテナ名が一致しているかどうかを確認してください。
kubectl get pods <pod_name> -n <namespace> -o yaml
一致しています。タスクは完了しました。
一致していません。正しい内容と照らし合わせて収集設定を修正してください。
収集パスが正しくない場合、どうすればよいですか？
コンテナファイルまたはホストファイルを収集するシナリオでは、収集対象のディレクトリパスが正しいこと、および収集ルールに一致するログが存在することを確認してください。
ログファイルにシンボリックリンクを使用できますか？
コンテナファイル収集のシナリオでは、収集対象のログファイルにシンボリックリンクが存在することはサポートされていません。
Kubernetes環境では、CLSはコンテナファイルのホスト上の位置を解析することで実現されています。コンテナ内のシンボリックリンク先はコンテナ内のパスを指しているため、収集対象ファイルにシンボリックリンクが存在する場合、正しく到達できません。
修復方法：
収集ルールのパスとマッチングファイルを、実際にログファイルが存在するパスとファイルに変更し、シンボリックリンクへのマッチングを回避してください。
収集仕様の制限をトリガーするものは何ですか？
Loglistenerによる収集はコンテナ環境ではリソースが制限されるため、監視対象のディレクトリとファイルの数に制限があります：
監視ディレクトリ数：5000
監視ファイル数：10000
コンテナファイルまたはホストファイルを収集するシナリオでは、このような問題が発生する可能性があります。通常、ユーザーが期限切れのログファイルをクリーンアップしていないため、Loglistenerのログを確認すると、以下のような情報が記録されています：
修復方法：
ログディレクトリで
treeコマンドを使用して、ディレクトリ全体の現在のディレクトリ数とファイル数がLoglistenerの制限に達しているかどうかを確認してください。制限に達していない場合は、ビジネスコンテナが存在するホストの/var/log/tke-log-agentで
tree -L 5を実行し、マシン全体の粒度が制限に達しているかどうかを確認してください。
Loglistenerの制限はマシン粒度であるため、特定のコンテナファイル数が閾値に達していなくても、マシン全体の粒度ではすべてのコンテナファイルが制限に達している可能性があります。制限に達した場合は、期限切れのログを速やかにアーカイブし、Loglistenerが監視するディレクトリとファイルによって消費されるリソースを削減してください。
Dockerfileでvolumeを定義した場合、どうすればよいですか？
Docker環境では、
docker history $imageコマンドを使用して、イメージのビルド情報を確認します。Containerd環境：
crictl inspecti $imageコマンドを使用して、イメージのビルド情報を確認します。以下の情報が返されます。これにより、Dockerfile内でユーザーがボリューム/logs/live-srvをカスタマイズしており、それがまさにログが存在するディレクトリであることがわかります。この操作は、ログ収集コンポーネントが正しいログファイルを見つけるのを妨げます。
修復方法：
Dockerfileを変更してvolumeを削除し、イメージを再ビルドしてサービスを再デプロイしてください。
サービスログの書き込みディレクトリを変更し、Dockerfileで定義されたvolumeパスに書き込まないでください。
その他のご質問
コンテナエンジンタイプの識別エラーが発生した場合、どうすればよいですか？
Docker環境では、一部のシナリオで古いバージョンのバグが発生し、ログ収集コンポーネントが正常に起動できず、panicログが出力されることがあります。
主な原因は、ユーザーがTKEクラスタノードのDocker設定をカスタマイズしたことにより、以下の図に示すエラーが発生することです：
修復方法：
/etc/docker/daemon.jsonの設定に、
"storage-driver": "overlay2"を追加します。以下の図に示す通りです：
TKEコンソールでログ収集コンポーネントのバージョンをアップグレードします。新しいバージョンの収集コンポーネントではこの問題が修正されているため、Docker設定を変更する必要はありません。
filePatternでサブディレクトリを設定した場合、どうすればよいですか？
以下の図に示すように、ユーザーがfilePatternフィールドパラメータにサブディレクトリを設定しています。この操作により、ログを正常に収集できなくなります。
修復方法：
logPathパラメータでログファイルのディレクトリを設定し、filePatternではファイルタイプパラメータのみを設定し、サブディレクトリは設定しないでください。
フィードバック