Simple Log Service:コンテナログ収集に関する問題のトラブルシューティング

FAQ：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 に変わったことを確認します。

FAQ：複数の 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>

マシングループがすべてのコンテナノードをカバーしていない

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

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

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

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

   docker ps -a | grep <container-name>

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

FAQ：コンテナメタデータのプレビューで 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

FAQ：コンテナログを収集する際のファイル作成の失敗や権限エラーにはどう対処すればよいですか？

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

解決策：

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

2. ファイルの権限を -rw-r--r-- (644) に設定してください。

   chmod 644 <file-path>

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

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

FAQ：エラー「parse cri docker line error: invalid CRI log, timestamp not found」への対処方法

原因： ログのパースに失敗しました。このエラーは、通常、誤った複数行ログの設定が原因で発生します。

解決策：

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

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

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

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

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

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

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 名

• 対象のコンテナ名