Simple Log Service:コンテナログ収集のトラブルシューティング

既存のセキュリティグループを再利用した ACK クラスターにおけるハートビートの問題

ACK クラスターが既存のセキュリティグループを使用する場合、LoongCollector または Logtail がマシングループのハートビートの報告に失敗することがあります。これは、ECS セキュリティグループが Pod CIDR からのインバウンドトラフィックを許可していない場合に発生します。その結果、LoongCollector は CoreDNS にアクセスして SLS エンドポイントを解決できません。

次の手順で問題を解決します。

1. ECS コンソールにログインし、ACK クラスターで使用されているセキュリティグループを見つけます。

2. Pod CIDR からのすべてのプロトコルとポートを許可する [受信ルール] を追加します。 たとえば、クラスターの Pod CIDR が 10.229.0.0/16 の場合、この値を使用します。

3. Pod が CoreDNS にアクセスして SLS エンドポイントを解決できることを確認してください。

4. kube-system 名前空間の loongcollector-ds DaemonSet を再起動します:

   kubectl rollout restart daemonset/loongcollector-ds -n kube-system

5. 再度マシングループのハートビートを確認し、ログ収集が再開されることを確認します。

よくある質問：Docker/LoongCollector をデプロイした後にハートビートがないのはなぜですか?

Docker デプロイ後に LoongCollector または Logtail がハートビートを表示しない、またはマシングループへの登録に失敗する場合、根本原因は通常、ユーザー識別子 (AliUID) 設定の欠落です。

解決策：

1. ホストマシン上で、/etc/ilogtail/users/ ディレクトリを作成します。

   mkdir -p /etc/ilogtail/users/

2. /etc/ilogtail/users/ ディレクトリに、Alibaba Cloud アカウント ID という名前の空のファイルを作成します。

   touch /etc/ilogtail/users/<your-alibaba-cloud-account-id>

3. LoongCollector または Logtail コンテナを起動する際に、次のフラグを追加してディレクトリを読み取り専用としてマウントします。

   -v /etc/ilogtail/users:/etc/ilogtail/users:ro

4. LoongCollector または Logtail コンテナを再起動します。

確認: SLS コンソールにログオンし、リソース > マシングループ の順に選択し、目的のマシン グループを見つけます。[操作] 列の [ステータスを確認] をクリックします。[マシン グループのステータスを表示] ダイアログ ボックスで、マシン グループのハートビート ステータスが [OK] に変更されたことを確認します。

よくある質問：複数の Docker Swarm サーバーが同じ IP を報告している場合に、マシングループに 1 つのサーバーしか表示されないのはなぜですか?

原因: Docker Swarm クラスターでは、コンテナネットワークを介して複数のサーバーが同じ内部 IP アドレスを報告する場合があります。これらのサーバーが同じ ALIYUN_LOGTAIL_USER_DEFINED_ID 環境変数の値も共有している場合、システムはそれらを区別できず、マシングループ には 1 つのエントリしか表示されません。

解決策 1: 各サーバー上の Logtail コンテナに、一意の ALIYUN_LOGTAIL_USER_DEFINED_ID 環境変数を設定します。

各サーバーに異なる値を設定し、その値が対応するマシングループの設定と一致するようにします。 例：

-e ALIYUN_LOGTAIL_USER_DEFINED_ID=<unique-id-for-this-server>

解決策 2: 環境変数 ALIYUN_LOGTAIL_WORKING_IP を設定して、各サーバーに一意の IP アドレスを手動で指定します。

ホストのパブリック IP アドレスや、すべてのサーバー間で一意の内部ネットワーク IP アドレスなど、各ホストを一意に識別する値を使用します。

-e ALIYUN_LOGTAIL_WORKING_IP=<unique-ip-for-this-server>

Istio サイドカーログが欠落している場合のトラブルシューティング

Istio サイドカーログは、一致するコンテナログファイルが存在しなくなった場合や、ContainerFilters が Istio サイドカーコンテナと完全に一致しない場合に、収集されないことがあります。

次のチェックを順番に実行してください。

1. Pod の Deployment または StatefulSet を確認し、Logtail 設定の正しい環境変数が含まれていることを確認してください。例：

   aliyun_logs_reconfig-zltx-test-stdout: "stdout"

2. Logtail コンポーネントがインストールされ、実行されていることを確認します。その ConfigMap に期待される設定が含まれていることを確認してください。

3. 収集設定では、ContainerFilters を使用して Istio サイドカーコンテナの完全一致を設定し、フィルターがアプリケーションコンテナだけでなくサイドカーコンテナを識別することを確認します。

4. 修正されたワークロードまたは収集設定を適用し、新しいサイドカーログエントリを生成して、SLS がそれを受信するかどうかを確認してください。

マシングループが一部のコンテナノードをカバーしない問題

症状：マシングループのハートビートは正常ですが、一部のコンテナからのログ収集が停止しています。

この問題は、コンテナが マシングループ に含まれていないサーバーで実行されている場合に発生することがあります。

トラブルシューティング手順：

1. すべての関連サーバーで、次のコマンドを実行して、コンテナが実際に実行されているノードを特定してください。

   docker ps -a | grep <container-name>

2. マシングループに追加されていないサーバー上でコンテナが実行されている場合、SLS コンソールの マシングループ にそのサーバーの IP アドレスを追加します。

よくある質問：コンテナメタデータのプレビューで Pod が見つからない、または emptyDir からログを収集できないのはなぜですか?

原因: DaemonSet モードで実行されている Logtail は、コンテナ内の emptyDir 一時ストレージに直接アクセスできません。これにより、Logtail はログファイルを読み取ったり、コンテナメタデータを抽出したりできなくなり、コンテナメタデータの プレビュー で Pod が見つかりません。

解決策 1 (推奨)：アプリケーションログ出力を標準出力 (stdout/stderr) にリダイレクトします。

1. ファイルの代わりに stdout または stderr にログを書き込むようにアプリケーションを変更してください。

2. SLS コンソールで、標準の Kubernetes ログパスを使用するように収集パスを設定してください。

   /logtail_host/var/log/pods/<namespace>_<pod-name>-<uid>/<container-name>/*.log

解決策 2：アプリケーションがファイルにログを書き込む必要がある場合は、ログボリュームマウントを emptyDir から hostPath または PVC に変更します。

1. Pod 仕様で、ログがホストからアクセス可能なパスに永続化されるように、emptyDir ボリュームを hostPath または PVC 定義に置き換えます。

2. SLS 収集パスを、ホスト上の実際のマウントパスを指すように調整してください。例：

   /logtail_host/var/log/your-app/*.log

よくある質問：コンテナログを収集する際のファイル作成の失敗または権限エラーを処理する方法は?

症状：エラーメッセージは、Logtail がコンテナ内に特定の空のファイルを作成する必要があることを示していますが、ファイルの作成に失敗するか、権限エラーが報告されます。

解決策：

1. エラーメッセージで指定された空のファイルをコンテナ内に手動で作成してください。

2. ファイルパーミッションを -rw-r--r-- (644) に設定します:

   chmod 644 <file-path>

3. コンテナを再起動してください。

代替手段：上記の手順の後も問題が解決しない場合は、コンテナログディレクトリをホストマシンにマウントし、対応するホストパスからログを収集するように SLS を設定してください。このアプローチは、コンテナ内ファイル収集よりも安定しています。

よくある質問："parse cri docker line error: invalid CRI log, timestamp not found" というエラーを処理する方法は?

原因：ログ解析に失敗しています。このエラーは、複数行ログ設定が正しくないことが原因で発生することが一般的です。

解決策：

1. 行頭の正規表現を確認して調整するか、複数行モードを無効にしてください。

   • YAML 設定： multiline 設定セクションをコメントアウトします。

   • SLS コンソールの場合：Logtail 設定を開き、複数行モードを無効にしてください。

2. [K8s 名前空間の正規表現] およびその他のフォーマットフィールドが正しいことを確認してください。複数の名前空間を指定する場合は、正しい区切り文字で区切られていることを確認してください。

3. YAML 設定を変更した後、再適用して変更を有効にしてください。

   kubectl apply -f <your-config-file>.yaml

よくある質問：JSON 解析プラグインの横に赤い感嘆符が表示され、Logtail 設定を保存できない場合はどうすればよいですか?

症状：Logtail 設定に JSON 解析プラグインを追加した後、プラグインアイコンの横に赤い感嘆符が表示され、ダイアログボックスで設定を保存できません。

原因：赤い感嘆符は通常、プラグインが設定されていないこと、または設定が変更されたが適用されていないことを示しています。

解決策：

1. Logtail 設定編集ページで、デフォルトで追加された JSON 解析プラグインを削除してください。

2. JSON 解析プラグインを手動で再度追加し、ログサンプルや解析ルールなど、すべての必須フィールドに入力してください。

3. 設定が完了すると、赤い感嘆符が消え、Logtail 設定を保存できるようになります。

よくある質問：複数の Logtail 設定が同じファイルに一致するため、データが収集されない場合 (MULTI CONFIG MATCH ALARM) はどうすればよいですか?

症状: Logtail の運用ログに MULTI CONFIG MATCH ALARM アラートが表示され、対象ファイルからデータが収集されません。

原因：デフォルトでは、ログファイルは 1 つの Logtail 設定にのみ一致できます。複数の Logtail 設定が同じファイルに一致する場合、そのうちの 1 つのみが有効になります。他の設定はデータを収集できず、MULTI CONFIG MATCH ALARM アラートをトリガーします。

解決策：

1. 冗長な Logtail 設定の削除: Simple Log Service コンソールで、マシングループ に関連付けられているすべての Logtail 設定を確認します。各ファイルが 1 つの設定のみに一致するように、重複した設定または未使用の設定を削除します。

2. Pod 名で一致を分割する：同じファイルに対して複数の設定が必要な場合 (たとえば、Pod 名で収集を分割する場合)、公式ドキュメントに記載されているように設定を変更してください。各 Logtail 設定が、より正確なパスまたはラベルフィルターを通じて独自の対象ファイルにのみ一致するようにし、パスの重複を避けてください。

3. 変更後、Logtail 運用ログを確認し、MULTI CONFIG MATCH ALARM アラートが消え、データが期待どおりに収集されることを確認してください。

FAQ: コンテナログの収集時に Logtail で no such file or directory エラーが発生した場合の対処方法

現象: Logtail 運用ログに no such file or directory エラーが含まれ、対象コンテナのログを収集できません。収集後にログをクエリおよび分析できるように、LogStore にインデックスが作成されていることを確認してください。

原因：対象の収集パスがノード上に存在しません。この問題は通常、Kubernetes Pod のライフサイクルまたはログローテーションメカニズムに関連しています。

解決策：

1. Pod がまだ存在するかどうかを確認する：Pod が削除されている場合、対応するログパスは存在しなくなり、エラーを無視できます。Pod がまだ実行されている場合は、サーバー (ノード) にログインして、実際のログパスが存在するかどうかを確認してください。

2. 可能な場合はコンテナ標準出力収集を使用する：ACK コンソールでログ収集設定を作成する際に、[コンテナ標準出力]タイプを選択し、コンテナ内部のファイルパスに依存するのではなく、コンテナラベルまたはコンテナ名で対象コンテナに一致させてください。

3. ファイル収集が必要な場合の設定に関する推奨事項: ワイルドカードパス (例: /logtail_host/var/log/pods/*/*.log) を使用し、Logtail 設定で新しいファイルの自動検出を有効にして、ログローテーションや Pod の再作成後に Logtail が新しいパスを追跡できるようにします。

4. Logtail 設定がマシン グループに適用されていることを確認します: Logtail 設定が、ターゲット ポッドを含む マシングループ に関連付けられていることを確認してください。

5. Logtail 運用ログを確認する：多数のエラーがすでに破棄された Pod に集中している場合は、それらを無視できます。エラーが継続し、Pod がまだ実行されている場合は、収集パスを修正するか、ノードマウントを確認してください。

FAQ: logfiletoobig が原因で Logtail がファイルをスキップし、収集が中断した場合の対処方法

現象: Logtail の運用ログに logfiletoobig アラートが表示され、対象ファイルがスキップされ、ログ収集が中断されます。

原因：対象ログファイルのサイズが Logtail のデフォルト制限を超えています。Logtail は安定性を保護するためにファイルをスキップします。

解決策：

1. Logtail 収集パラメーターの調整: Logtail 設定または マシングループ のグローバルパラメーターで、次の変更を行います。

   • 大容量ファイルがスキップされるのを防ぐため、MaxLogFileSize を、たとえば 1GB に増やします。

   • ローテーションされたファイルの追跡を改善するには、MaxLogFileInodeCacheSize を、たとえば 2000 に増やします。

   • EnableContainerDiscovery を true に設定すると、Logtail はコンテナのログパスを自動的に検出し、新しいポッドの追跡エントリを自動的に作成できます。

2. 再スキャンをトリガーする：ACK クラスターで次のコマンドを実行して、loongcollector-ds (または Logtail-ds) Pod を削除してください。DaemonSet は自動的に Pod を再作成し、すべてのコンテナログパスを再スキャンします。

   kubectl delete pod -n kube-system -l k8s-app=loongcollector-ds

3. 結果を検証するか、代替手段を使用する：SLS コンソールでログ受信ステータスを確認し、Logtail Pod に残留エラーがないかを確認してください。上記の方法が機能しない場合は、[K8s-Stdout-New]設定を試し、コンテナメタデータのプレビューを有効にして、ファイルパスではなく stdout パスを通じてログを収集してください。

ACK の補足トラブルシューティング

ACK クラスターで、上記のチェックの後もログ収集でデータが返されない場合は、次の 2 つの項目を確認してください。

1. ACK CRD 収集設定を確認する：次のコマンドを実行して、ACK クラスターの CRD 収集設定を表示してください。

   kubectl get ClusterAliyunPipelineConfig -A

   出力内の Logstore と収集ルールが期待と一致していることを確認してください。

2. コンテナイメージのボリューム宣言の確認: コンテナイメージで docker inspect コマンドを実行し、Config.Volumes フィールドを確認します。

   docker inspect <image-name> | grep -A5 Volumes

   Config.Volumes が空でない場合、イメージで VOLUME が宣言されており、ログファイルのパスが上書きされる可能性があります。VOLUME 宣言を削除するか、ボリュームを emptyDir にマウントしてください。

Logtail コンテナへのログイン

• 標準 Docker

  1. ホストで次のコマンドを実行し、Logtail コンテナを特定します：

     docker ps | grep logtail

     出力は次のようになります：

     223****6e        registry.cn-hangzhou.aliyuncs.com/log-service/logtail                             "/usr/local/ilogta..."   8 days ago          Up 8 days                               logtail-iba

  2. 次のコマンドを実行して、Logtail コンテナ内で bash シェルを起動します：

     docker exec -it 223****6e  bash

     223****6e は実際のコンテナ ID に置き換えてください。

• Kubernetes

  1. 次のコマンドを実行して、Logtail Pod を特定します：

     kubectl get po -n kube-system | grep logtail

     出力は次のようになります：

     logtail-ds-****d                                             1/1       Running    0          8d
     logtail-ds-****8                                             1/1       Running    0          8d

  2. 次のコマンドを実行して Pod にログインします：

     kubectl exec -it -n kube-system logtail-ds-****d -- bash

     logtail-ds-****d は実際の Pod ID に置き換えてください。

Logtail ランタイムログの確認

Logtail は、Logtail コンテナの /usr/local/ilogtail/ ディレクトリにログを保存します。ログファイルは ilogtail.LOG と logtail_plugin.LOG です。

1. Logtail コンテナにログインします。詳細については、「Logtail コンテナへのログイン」をご参照ください。

2. /usr/local/ilogtail/ ディレクトリに移動します。

   cd /usr/local/ilogtail

3. ilogtail.LOG ファイルと logtail_plugin.LOG ファイルを確認します。

   cat ilogtail.LOG
   cat logtail_plugin.LOG

Logtail のバージョン、IP アドレス、起動時間

1. ホストで次のコマンドを実行し、Logtail のバージョン、IP アドレス、起動時間を確認します：

   情報は、Logtail コンテナの /usr/local/ilogtail/app_info.json ファイルに保存されています：

   kubectl exec logtail-ds-****k -n kube-system cat /usr/local/ilogtail/app_info.json

   出力は次のようになります：

   {
      "UUID" : "",
      "hostname" : "logtail-****k",
      "instance_id" : "0EB****_172.20.4.2_1517810940",
      "ip" : "172.20.4.2",
      "logtail_version" : "0.16.2",
      "os" : "Linux; 3.10.0-693.2.2.el7.x86_64; #1 SMP Tue Sep 12 22:26:13 UTC 2017; x86_64",
      "update_time" : "2018-02-05 06:09:01"
   }

ACK クラスターでの Pod ログに関するトラブルシューティング情報の取得

ACK クラスター内の Pod のログ収集が正常でない場合は、次の手順に従って、セルフトラブルシューティング、またはテクニカルサポートへの提供に必要な基本情報を取得できます。

手順1：Logtail または LoongCollector の Pod 名を特定します。

kubectl get pods -n kube-system | grep -E 'logtail|loongcollector'

手順2：app_info.json ファイルから Logtail または LoongCollector インスタンスの IP アドレスを取得します。

kubectl exec <pod-name> -n kube-system cat /usr/local/ilogtail/app_info.json

返される JSON 出力の ip フィールドが、Logtail インスタンスの IP アドレスです。

サポートを依頼する場合は、トラブルシューティングのため、次の情報を提供してください：

• SLS プロジェクト名

• Logtail 収集設定名

• 対象 Pod 名

• 対象コンテナ名

よくある質問：docker pull を実行して LoongCollector または Logtail イメージをプルすると、ホスト上の他のサービスに影響がありますか？

結論: docker pull コマンドのみを実行して LoongCollector または Logtail イメージをプルしても、ホストで実行されている他のサービスに影響はありません。これは、Alibaba Cloud ECS インスタンスとオンプレミスサーバーの両方に適用されます。docker pull コマンドは、イメージレイヤーをローカルのイメージリポジトリにダウンロードするだけです。コンテナを起動したり、追加の CPU やメモリリソースを消費したりすることはありません。

注意事項：

• 後で docker run を実行してコンテナを起動する際は、新しいコンテナが既存のワークロードと競合しないように、ホストに十分な CPU およびメモリリソースがあることを確認してください。

• コンテナのポートマッピングが、ホスト上の既存のサービスですでに使用されているポートと競合していないかを確認してください。

• Kubernetes でログ収集コンポーネントを長期間実行する場合は、Container Service for Kubernetes (ACK) コンソールの [コンポーネント管理] から DaemonSet モードで LoongCollector をインストールすることを推奨します。これにより、クラスターがリソースを統一的にスケジューリングできます。

よくある質問：Simple Log Service コンソールの ACK クラスターログアクセスページに K8s-Stdout-New オプションが見つからない場合はどうすればよいですか？

症状：Simple Log Service コンソールの ACK クラスターログアクセスページに [K8s-Stdout-New] エントリがありません。

原因：バックエンド機能が修復のためオフラインになっているため、エントリが一時的に利用できなくなっている可能性があります。

解決策 / 代替手段：

1. 従来のアクセス方法を一時的に使用する：コンソールで、従来の [K8s-Stdout] エントリを選択してアクセス設定を完了してください。このレガシーバージョンはメンテナンスが終了しており、一時的な回避策としてのみ使用してください。

2. コンソールエントリの代わりに CRD を使用 (推奨): コンソールエントリに依存することなく、クラスターで kubectl を使用して AliyunPipelineConfig CRD を作成し、新バージョンの stdout 収集を設定します。 このドキュメントの Container Stdout - New Version セクションにある YAML の例を参照し、パラメーターを実際のプロジェクト、LogStore、およびクラスターの情報に置き換えてから、次のコマンドを実行します。

   kubectl apply -f aliyun-pipeline-config.yaml

   この方法は、コンソールから作成した設定と同等であり、GitOps 方式で管理しやすくなります。

よくある質問：Running 状態でない Pod は、ファイルログ収集に影響しますか？

結論：はい、影響します。LoongCollector と Logtail は、コンテナ内部からファイルを収集します。サービスの起動に失敗し、Pod が Running 状態でない場合、コンテナはログファイルまたはそのディレクトリを作成しない可能性があります。コレクターは、存在しないパスからファイルを読み取ったり収集したりすることはできません。

ファイルログ収集を検証するには、サービス起動コマンドを一時的に設定して、コンテナが実行し続けるようにしてください。例：

sleep 3600

Pod が Running 状態になった後、設定されたファイルパスにテストログエントリを手動で書き込んでください。次に、LoongCollector または Logtail が新しいエントリを収集するかどうかを確認してください。テスト後、元の起動コマンドを復元してください。

よくある質問：メソッド名やその他のビジネスフィールドでコンテナ標準出力ログをクエリできないのはなぜですか？

Simple Log Service では、収集したログにフィールドが存在し、そのフィールドのインデックスが作成されている場合にのみ、フィールドをクエリできます。コンテナの標準出力またはアプリケーションログにメソッド名、呼び出し元情報、またはその他のビジネスフィールドが含まれていない場合、Simple Log Service でそのフィールドを直接クエリすることはできません。

アプリケーションまたはゲートウェイ (NGINX や Spring Cloud Gateway など) のロギング設定を確認してください。必要なすべてのビジネスフィールドが標準出力または収集対象のログファイルに書き込まれていることを確認してください。

Kubernetes コンテキストを追加するには、収集設定で [入力設定] を開き、[ログタグの付加] を有効にしてください。この機能により、環境変数や Kubernetes Pod ラベルをタグとして付加でき、Pod 名、名前空間、ラベルなどのメタデータを含めることができます。

ログコンテンツフィールドは、アプリケーションまたはゲートウェイが出力するテキストの一部です。メタデータタグは、収集中に付加され、ログのコンテキストを拡充します。タグを付加しても、元のログコンテンツに欠落しているメソッド名や呼び出し元フィールドが作成されるわけではありません。