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	Elastic Compute Service (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 に接続されていることを示します。

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

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

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

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

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

   • Docker 標準出力：[Docker 標準出力と標準エラー - 新バージョン] を選択します。

     コンテナー標準出力を収集するためのテンプレートには、新バージョンと旧バージョンの 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)