Simple Log Service:Docker コンテナログの収集 (標準出力/ファイル)

注意事項

• 権限要件：デプロイに使用する Alibaba Cloud アカウントまたは RAM ユーザーは、AliyunLogFullAccess 権限を持っている必要があります。

• Docker バージョンと LoongCollector の要件：

  • ご利用の Docker Engine のバージョンが 29.0 以降、またはサポートされる最小 Docker API バージョンが 1.42 以降の場合、LoongCollector 3.2.4 以降を使用する必要があります。そうでない場合、LoongCollector はコンテナの標準出力やファイルログを収集できません。

  • LoongCollector のバージョン 3.2.4 以降は、Docker API バージョン 1.24 から 1.48 までをサポートします。

  • LoongCollector のバージョン 3.2.3 以前は、Docker API バージョン 1.18 から 1.41 までをサポートします。

• 標準出力の収集に関する制限事項：

  • Docker の設定ファイル daemon.json に "log-driver": "json-file" を追加する必要があります。

  • CentOS 7.4 以降のバージョン (CentOS 8.0 を除く) では、fs.may_detach_mounts=1 を設定する必要があります。

• テキストログ収集の制限事項： overlay および overlay2 ストレージドライバーのみがサポートされています。他のドライバータイプの場合、ログディレクトリを手動でマウントする必要があります。

収集設定の作成プロセス

1. 事前準備：プロジェクトと Logstore を作成します。プロジェクトは異なるアプリケーションのログを分離するためのリソース管理単位であり、Logstore はログを保存するために使用されます。

2. マシングループの設定 (LoongCollector のインストール)：ログを収集したいサーバーに LoongCollector をインストールし、サーバーをマシングループに追加します。マシングループを使用して、収集ノードを一元管理し、設定を配布し、サーバーの状態を管理します。

3. ログ収集ルールの作成と設定

   1. グローバル設定と入力設定：収集設定の名前、ログ収集のソースと範囲を定義します。

   2. ログの処理と構造化：ログのフォーマットに基づいて処理ルールを設定します。

      • 複数行ログ：Java の例外スタックや Python のトレースバックなど、単一のログが複数行にまたがる場合に適用されます。各ログの開始を識別するために正規表現を使用する必要があります。

      • 構造化解析：正規表現、区切り文字、または NGINX モードのプラグインなどの解析プラグインを設定して、生の文字列を構造化されたキーと値のペアに抽出します。これにより、後続のクエリと分析が容易になります。

   3. ログフィルタリング：収集ブラックリストとコンテンツフィルタリングルールを設定して、有効なログコンテンツをスクリーニングします。この方法は、冗長なデータの転送とストレージを削減します。

   4. ログの分類：トピックとログタグを設定して、異なるアプリケーション、コンテナ、またはパスソースからのログを柔軟に区別します。

4. クエリと分析の設定：システムはデフォルトでフルテキストインデックスを有効にし、キーワード検索をサポートします。構造化されたフィールドの正確なクエリと分析のために、フィールドインデックスを有効にして検索効率を向上させることを推奨します。

5. 検証とトラブルシューティング：設定完了後、ログが正常に収集されることを確認します。データが収集されない、ハートビートの失敗、解析エラーなどの問題が発生した場合は、「よくある質問」セクションをご参照ください。

事前準備

ログを収集する前に、ログを管理および保存するためのプロジェクトと Logstore を計画し、作成する必要があります。必要なリソースがすでにある場合は、このステップをスキップして、「ステップ 1：マシングループの設定 (LoongCollector のインストール)」に進んでください。

ステップ 1：マシングループの設定 (LoongCollector のインストール)

Docker ホストに LoongCollector をコンテナとしてデプロイし、ホストをマシングループに追加します。マシングループを使用して、複数の収集ノードを一元管理し、設定を配布し、ステータスを監視します。

1. イメージの取得

   Docker がインストールされているホストで、次のコマンドを実行して LoongCollector イメージをプルします。ダウンロード速度と安定性を向上させるために、${region_id} をホストのリージョン IDまたは近くのリージョン (例：cn-hangzhou) に置き換えます。

   # LoongCollector イメージアドレス
   docker pull aliyun-observability-release-registry.${region_id}.cr.aliyuncs.com/loongcollector/loongcollector:v3.0.12.0-25723a1-aliyun
   
   # Logtail イメージアドレス
   docker pull registry.${region_id}.aliyuncs.com/log-service/logtail:v2.1.11.0-aliyun

2. LoongCollector コンテナの起動

   次のコマンドを実行してコンテナを起動します。ディレクトリを正しくマウントし、必要な環境変数を設定してください：

   docker run -d \
       -v /:/logtail_host:ro \
       -v /var/run/docker.sock:/var/run/docker.sock \
       --env ALIYUN_LOGTAIL_CONFIG=/etc/ilogtail/conf/${sls_upload_channel}/ilogtail_config.json \
       --env ALIYUN_LOGTAIL_USER_ID=${aliyun_account_id} \
       --env ALIYUN_LOGTAIL_USER_DEFINED_ID=${user_defined_id} \
       aliyun-observability-release-registry.${region_id}.cr.aliyuncs.com/loongcollector/loongcollector:v3.0.12.0-25723a1-aliyun

   パラメーターの説明：

   • ${sls_upload_channel}：ログアップロードチャネル。フォーマットはプロジェクトリージョン-ネットワーク転送タイプです。例：

     転送タイプ	設定値のフォーマット	例	シナリオ
     内部ネットワーク転送	regionId	cn-hangzhou	ECS インスタンスとプロジェクトが同じリージョンにある。
     インターネット転送	regionId-internet	cn-hangzhou-internet	ECS インスタンスとプロジェクトが異なるリージョンにある。 サーバーが他のクラウドプロバイダーまたは自社データセンターにある。
     転送アクセラレーション	regionId-acceleration	cn-hangzhou-acceleration	中国国内外のリージョン間通信。

   • ${aliyun_account_id}：Alibaba Cloud アカウント ID。

   • ${user_defined_id}：マシングループのカスタム ID。この ID はマシングループをバインドするために使用されます。例えば、user-defined-docker-1 を使用します。ID はリージョン内で一意である必要があります。

     重要

     以下の起動条件を満たす必要があります：

     • 3 つの主要な環境変数が正しく設定されていること：

       ALIYUN_LOGTAIL_CONFIG、ALIYUN_LOGTAIL_USER_ID、および ALIYUN_LOGTAIL_USER_DEFINED_ID。

     • /var/run/docker.sock ディレクトリがマウントされていること。このディレクトリはコンテナのライフサイクルイベントをリッスンするために使用されます。

     • ルートディレクトリ / が /logtail_host にマウントされていること。これはホストのファイルシステムにアクセスするために使用されます。

3. コンテナの実行ステータスの確認

   docker ps | grep loongcollector

   期待される出力例：

   6ad510001753   aliyun-observability-release-registry.cn-beijing.cr.aliyuncs.com/loongcollector/loongcollector:v3.0.12.0-25723a1-aliyun   "/usr/local/ilogtail…"   About a minute ago   Up About a minute             recursing_shirley

4. マシングループの設定

   左側のナビゲーションウィンドウで、リソース > マシングループ を選択し、 > マシングループの作成 をクリックし、次のパラメーターを設定して [ OK ] をクリックします：

   • 名前：マシングループのカスタム名を入力します。例：docker-host-group。

   • マシングループ識別子：[カスタム識別子] を選択します。

   • カスタム識別子：コンテナ起動時に設定した ${user_defined_id} を入力します。ID は完全に一致する必要があります。そうでない場合、関連付けは失敗します。

5. マシングループのハートビートステータスの確認

   新しいマシングループの名前をクリックして詳細ページに移動し、マシングループステータス を確認します：

   • OK：LoongCollector が SLS に接続されていることを示します。

   • FAIL：問題のトラブルシューティング方法については、「ハートビートエラーのトラブルシューティング」をご参照ください。

ステップ 2：ログ収集ルールの作成と設定

LoongCollector がどのログを収集し、その構造をどのように解析し、コンテンツをフィルタリングし、設定を登録済みのマシングループにバインドするかを定義します。

1. [Logstores] ページで、対象の Logstore 名の横にある アイコンをクリックします。

2. [データ収集] の横にある をクリックします。[クイックデータインポート] ダイアログボックスで、ログソースに基づいてテンプレートを選択し、[今すぐ統合] をクリックします。

   • Docker 標準出力：[Docker Stdout および Stderr - 新バージョン] を選択します。

     コンテナ標準出力を収集するためのテンプレートには、新バージョンと旧バージョンの 2 つがあります。新バージョンの使用を推奨します。新旧バージョンの違いについては、「付録：コンテナ標準出力の新旧バージョンの比較」をご参照ください。旧バージョンで収集するには、「Docker コンテナからの標準出力の収集 (旧バージョン)」をご参照ください。

   • Docker ファイルログ：[Docker ファイル - コンテナ] を選択します。

3. [マシングループ] を設定し、[次へ] をクリックします。

   • シナリオ：[Docker コンテナ] を選択します。

   • ステップ 1 で作成したマシングループを、ソースマシングループリストから適用済みマシングループリストに移動します。

4. [Logtail 設定] ページで、次のパラメーターを設定し、[次へ] をクリックします。

192.168.*.* - - [15/Apr/2025:16:40:00 +0800] "GET /nginx-logo.png HTTP/1.1" 0.000 514 200 368 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.*.* Safari/537.36"

body_bytes_sent: 368
http_referer: -
http_user_agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.x.x Safari/537.36
remote_addr:192.168.*.*
remote_user: -
request_length: 514
request_method: GET
request_time: 0.000
request_uri: /nginx-logo.png
status: 200
time_local: 15/Apr/2025:16:40:00

{"level":"WARNING","timestamp":"2025-09-23T19:11:40+0800","cluster":"yilu-cluster-0728","message":"Disk space is running low","freeSpace":"15%"}
{"level":"ERROR","timestamp":"2025-09-23T19:11:42+0800","cluster":"yilu-cluster-0728","message":"Failed to connect to database","errorCode":5003}
{"level":"INFO","timestamp":"2025-09-23T19:11:47+0800","cluster":"yilu-cluster-0728","message":"User logged in successfully","userId":"user-123"}

{"level":"WARNING","timestamp":"2025-09-23T19:11:40+0800","cluster":"yilu-cluster-0728","message":"Disk space is running low","freeSpace":"15%"}
{"level":"ERROR","timestamp":"2025-09-23T19:11:42+0800","cluster":"yilu-cluster-0728","message":"Failed to connect to database","errorCode":5003}

ステップ 3：クエリと分析の設定

ログ処理とプラグイン設定が完了したら、[次へ] をクリックして [クエリと分析の設定] ページに進みます：

• システムはデフォルトでフルテキストインデックスを有効にし、元のログコンテンツに対するキーワード検索をサポートします。

• フィールドによる正確なクエリを実行するには、ページのプレビューデータが読み込まれた後、[インデックスの自動生成] をクリックします。SLS は、プレビューデータの最初のエントリに基づいてフィールドインデックスを生成します。

設定が完了したら、[次へ] をクリックして、収集プロセス全体の設定を完了します。

ステップ 4：検証とトラブルシューティング

収集設定が完了し、マシングループに適用されると、システムは自動的に設定を配布し、増分ログの収集を開始します。

次のステップ

1. ログのクエリと分析：

2. データ可視化：可視化ダッシュボードを使用して、主要なメトリックのトレンドを監視します。

3. データ異常の自動アラート：アラートポリシーを設定して、システムの異常をリアルタイムで把握します。

一般的なコマンド

LoongCollector (Logtail) の実行ステータスの表示

docker exec ${logtail_container_id} /etc/init.d/ilogtaild status

LoongCollector (Logtail) のバージョン番号、IP アドレス、起動時間などの情報の表示

docker exec ${logtail_container_id} cat /usr/local/ilogtail/app_info.json

LoongCollector (Logtail) の実行ログの表示

# LoongCollector の実行ログを表示
docker exec a287de895e40 tail -n 5 /usr/local/ilogtail/loongcollector.LOG

# Logtail の実行ログを表示
docker exec a287de895e40 tail -n 5 /usr/local/ilogtail/ilogtail.LOG

[2025-08-25 09:17:44.610496]    [info]  [22]    /build/loongcollector/file_server/polling/PollingModify.cpp:75          polling modify resume:succeeded
[2025-08-25 09:17:44.610497]    [info]  [22]    /build/loongcollector/file_server/polling/PollingDirFile.cpp:100                polling discovery resume:starts
[2025-08-25 09:17:44.610498]    [info]  [22]    /build/loongcollector/file_server/polling/PollingDirFile.cpp:103                polling discovery resume:succeeded
[2025-08-25 09:17:44.610499]    [info]  [22]    /build/loongcollector/file_server/FileServer.cpp:117            file server resume:succeeded
[2025-08-25 09:17:44.610500]    [info]  [22]    /build/loongcollector/file_server/EventDispatcher.cpp:1019              checkpoint dump:succeeded

LoongCollector (Logtail) の再起動

# loongcollector を停止
docker exec a287de895e40 /etc/init.d/ilogtaild stop

# loongcollector を開始
docker exec a287de895e40 /etc/init.d/ilogtaild start

よくある質問

一般的なエラーメッセージ

エラーログ：The parameter is invalid : uuid=none

問題の説明：LoongCollector (Logtail) のログ (/usr/local/ilogtail/ilogtail.LOG) にエラーログ The parameter is invalid : uuid=none が含まれています。

ソリューション：ホストに product_uuid ファイルを作成し、有効な UUID (例：169E98C9-ABC0-4A92-B1D2-AA6239C0D261) を入力し、このファイルを LoongCollector (Logtail) コンテナの /sys/class/dmi/id/product_uuid ディレクトリにマウントします。

付録：ネイティブ解析プラグインの詳細説明

127.0.0.1 - - [16/Aug/2024:14:37:52 +0800] "GET /wp-admin/admin-ajax.php?action=rest-nonce HTTP/1.1" 200 41 "http://www.example.com/wp-admin/post-new.php?post_type=page" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Edg/127.0.0.0"

body_bytes_sent: 41
http_referer: http://www.example.com/wp-admin/post-new.php?post_type=page
http_user_agent: Mozilla/5.0 (Windows NT 10.0; Win64; ×64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Edg/127.0.0.0
remote_addr: 127.0.0.1
remote_user: -
request_method: GET
request_protocol: HTTP/1.1
request_uri: /wp-admin/admin-ajax.php?action=rest-nonce
status: 200
time_local: 16/Aug/2024:14:37:52 +0800

05/May/2025:13:30:28,10.10.*.*,"POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=****************&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=******************************** HTTP/1.1",200,18204,aliyun-sdk-java

ip:10.10.*.*
request:POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=****************&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=******************************** HTTP/1.1
size:18204
status:200
time:05/May/2025:13:30:28
user_agent:aliyun-sdk-java

{"url": "POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=U0Ujpek********&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=pD12XYLmGxKQ%2Bmkd6x7hAgQ7b1c%3D HTTP/1.1", "ip": "10.200.98.220", "user-agent": "aliyun-sdk-java", "request": {"status": "200", "latency": "18204"}, "time": "05/Jan/2025:13:30:28"}

ip: 10.200.98.220
request: {"status": "200", "latency" : "18204" }
time: 05/Jan/2025:13:30:28
url: POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=U0Ujpek******&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=pD12XYLmGxKQ%2Bmkd6x7hAgQ7b1c%3D HTTP/1.1
user-agent:aliyun-sdk-java

{"s_key":{"k1":{"k2":{"k3":{"k4":{"k51":"51","k52":"52"},"k41":"41"}}}}}

0_s_key_k1_k2_k3_k41:41
0_s_key_k1_k2_k3_k4_k51:51
0_s_key_k1_k2_k3_k4_k52:52

1_s_key:{"k1":{"k2":{"k3":{"k4":{"k51":"51","k52":"52"},"k41":"41"}}}}

[{"key1":"value1"},{"key2":"value2"}]

json1:{"key1":"value1"}
json2:{"key2":"value2"}

* | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

1 192.168.1.10 - - [08/May/2024:15:30:28 +0800] "GET /index.html HTTP/1.1" 200 1234 "https://www.example.com/referrer" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.X.X Safari/537.36"

http_referer:https://www.example.com/referrer
http_user_agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.X.X Safari/537.36
remote_addr:192.168.1.10
remote_ident:-
remote_user:-
request_method:GET
request_protocol:HTTP/1.1
request_uri:/index.html
response_size_bytes:1234
status:200
time_local:[08/May/2024:15:30:28 +0800]

[{'account':'1812213231432969','password':'04a23f38'}, {'account':'1812213685634','password':'123a'}]

[{'account':'1812213231432969','password':'********'}, {'account':'1812213685634','password':'********'}]

{"level":"INFO","timestamp":"2025-09-23T19:11:47+0800","cluster":"yilu-cluster-0728","message":"User logged in successfully","userId":"user-123"}

付録：正規表現の制限 (コンテナフィルタリング)

コンテナフィルタリングに使用される正規表現は、Go の RE2 エンジンに基づいており、PCRE などの他のエンジンと比較していくつかの構文上の制限があります。正規表現を記述する際には、次の点に注意してください：

付録：コンテナ標準出力の新旧バージョンの比較

ログストレージの効率と収集の一貫性を向上させるため、コンテナ標準出力のログメタデータ形式がアップグレードされました。新しい形式では、メタデータが __tag__ フィールドに統合され、ストレージの最適化と形式の標準化が実現されています。

1. 新しい標準出力バージョンの主な利点

   • 大幅なパフォーマンス向上

     • C++ でリファクタリングされ、古い Go 実装と比較してパフォーマンスが 180% から 300% 向上しました。

     • データ処理のためのネイティブプラグインとマルチスレッド並列処理をサポートし、システムリソースを最大限に活用します。

     • ネイティブプラグインと Go プラグインを柔軟に組み合わせて、複雑なシナリオ要件に対応します。

   • 高い信頼性

     • 標準出力ログのローテーションキューをサポートします。ログ収集メカニズムはファイル収集メカニズムと統一されており、標準出力ログが急速にローテーションするシナリオで高い信頼性を提供します。

   • 低いリソース消費

     • CPU 使用率が 20% から 25% 削減されます。

     • メモリ使用量が 20% から 25% 削減されます。

   • O&M の一貫性の向上

     • 統一されたパラメーター設定：新しい標準出力収集プラグインの設定パラメーターは、ファイル収集プラグインと一貫しています。

     • 統一されたメタデータ管理：コンテナメタデータフィールドの命名とタグログの保存場所は、ファイル収集シナリオと統一されています。コンシューマー側は 1 つの処理ロジックを維持するだけで済みます。

2. 新旧バージョンの機能比較

   機能ディメンション	旧バージョンの機能	新バージョンの機能
   ストレージ方法	メタデータはログコンテンツに通常のフィールドとして直接埋め込まれます。	メタデータは __tag__ タグに一元的に保存されます。
   ストレージ効率	各ログは完全なメタデータを繰り返し保持するため、より多くのストレージスペースを消費します。	同じコンテキストの複数のログはメタデータを再利用できるため、ストレージコストを節約できます。
   フォーマットの一貫性	コンテナファイル収集フォーマットと一致しません。	フィールドの命名とストレージ構造は、コンテナファイル収集と完全に整合しており、統一されたエクスペリエンスを提供します。
   クエリアクセス方法	フィールド名で直接クエリできます。例：_container_name_。	__tag__ を介して対応するキー値にアクセスする必要があります。例：__tag__: _container_name_。

3. コンテナメタデータフィールドマッピングテーブル

   旧バージョンのフィールド名	新バージョンのフィールド名
   _container_ip_	__tag__:_container_ip_
   _container_name_	__tag__:_container_name_
   _image_name_	__tag__:_image_name_
   _namespace_	__tag__:_namespace_
   _pod_name_	__tag__:_pod_name_
   _pod_uid_	__tag__:_pod_uid_

   新バージョンでは、すべてのメタデータフィールドは、ログコンテンツに埋め込まれるのではなく、__tag__:<key> の形式でログのタグ領域に保存されます。

4. 新バージョン変更のユーザーへの影響

   • コンシューマー側の適応：保存場所が「コンテンツ」から「タグ」に変更されたため、ユーザーのログ消費ロジックを適宜調整する必要があります。例えば、クエリ中に __tag__ を介してフィールドにアクセスする必要があります。

   • SQL 互換性：クエリ SQL は互換性のために自動的に適応されているため、ユーザーは新旧両バージョンのログを同時に処理するためにクエリ文を変更する必要はありません。

詳細情報

[2023-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)