1. イメージのプル

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

# 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

パラメーター：

• ${aliyun_account_id}：ご利用の Alibaba Cloud アカウントの ID。

• ${user_defined_id}：コンテナをマシングループにバインドするマシングループのカスタム識別子 (例：user-defined-docker-1)。識別子はリージョン内で一意である必要があります。

• ${sls_upload_channel}: ログアップロードチャンネル。値は、次の表で説明するように、プロジェクトをホストする リージョン と ネットワーク伝送タイプ で構成されます。

各転送タイプの背後にあるネットワーク特性については、本トピックの「付録：ネットワーク転送タイプ」セクションをご参照ください。

必須の起動条件：

• 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)。

• 識別子： ユーザー定義 ID を選択します。

• ユーザー定義 ID: コンテナの起動時に設定した ${user_defined_id} を入力します。値は同一にする必要があります。一致しない場合、関連付けに失敗します。

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

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

• OK：LoongCollector は Simple Log Service に接続されています。

• FAIL：「ハートビート問題の概要」を参照して問題をトラブルシューティングしてください。

1. グローバル設定と入力設定

始める前に、データインポートテンプレートを選択し、マシングループをバインドしたことを確認してください。このステップでは、収集設定の名前、ログソース、および収集範囲を定義します。

2. ログの処理と構造化

ログ処理ルールを設定して、生の非構造化ログを構造化データに変換し、ログのクエリと分析の効率を向上させます。まずログサンプルを追加することを推奨します。

Logtail構成 ページの 設定の処理 セクションで、ログサンプルの追加 をクリックして、収集したいログコンテンツを入力します。Simple Log Service はサンプルからログフォーマットを識別し、正規表現と解析ルールの生成を支援することで、構成を簡素化します。

シナリオ 1：Java スタックログなどの複数行ログの処理

Java の例外スタックや JSON などのログは、通常複数行にわたります。デフォルトの収集モードでは、これらはいくつかの不完全なエントリに分割され、コンテキストが失われます。これを防ぐために、複数行モードをオンにし、先頭行の正規表現を設定して、同じログの連続する行を 1 つの完全なエントリにマージします。

例：

手順: Logtail構成 ページで、設定の処理 セクションで、マルチラインモード をオンにします:

• タイプ: カスタム または マルチライン JSON を選択します。

  • カスタム：生ログのフォーマットは固定されていません。行先頭の正規表現 を設定して、各ログの開始行を識別します。

    • 行先頭の正規表現: 式を自動的に生成するか、手動で入力できます。正規表現は、完全な行に一致する必要があります。上記の例では、式は \[\d+-\d+-\w+:\d+:\d+,\d+]\s\[\w+]\s.* です。

      • 自動生成: [正規表現を自動生成] をクリックし、ログサンプル テキストボックスで抽出するログ内容を選択した後、[正規表現を生成] をクリックします。

      • 手動入力：[正規表現を手動で入力] をクリックします。式を入力した後、[検証] をクリックします。

  • マルチライン JSON：すべての生ログが標準 JSON フォーマットの場合、Simple Log Service は単一の JSON ログ内の改行を自動的に処理します。

• 分割失敗の処理方法：

  • Discard: 先頭行ルールに一致しないセグメントは破棄されます。

  • 単一行を保持: 一致しないテキストは分割され、元の単一行モードで保持されます。

シナリオ 2：ログの構造化

NGINX のアクセスログやアプリケーションの出力ログなど、生ログが非構造化または半構造化テキストである場合、直接クエリや分析を行うのは非効率です。Simple Log Service は、さまざまなフォーマットの生ログを自動的に構造化データに変換する複数のデータ解析プラグインを提供し、その後の分析、モニタリング、アラート機能のための強固なデータ基盤を提供します。

例：

手順： Logtail構成 ページの 設定の処理 セクションで：

• 解析プラグインの追加: 処理プラグインの追加 をクリックし、実際のフォーマットに基づいて 正規表現解析、デリミタ解析、JSON 解析などのプラグイン を設定します。各プラグインのパラメーターについては、このトピックの「付録: ネイティブ解析プラグイン」セクションをご参照ください。次の例では NGINX ログを収集するため、ネイティブ処理プラグイン > NGINX モード解析 を選択します。

  • NGINX ログの設定：NGINX サーバー設定ファイル (nginx.conf) から完全なlog_format 定義をコピーして、このテキストボックスに貼り付けます。 例：

    log_format main  '$remote_addr - $remote_user [$time_local] "$request" ''$request_time $request_length ''$status $body_bytes_sent "$http_referer" ''"$http_user_agent"';

    サーバー上でログを生成するフォーマットと完全に同じである必要があります。そうでない場合、ログ解析は失敗します。

• 一般的な設定パラメーター：以下のパラメーターは複数のデータ解析プラグインに表示され、同じ機能と使用法を持ちます。

  • ソースフィールド：解析するソースフィールドの名前。デフォルト値：content、これは収集されたログコンテンツ全体です。

  • 解析失敗時にソースフィールドを保持：このオプションをオンにすることを推奨します。プラグインがログを解析できない場合 (例：フォーマットの不一致)、このオプションは完全な生ログコンテンツを指定されたソースフィールドに保持し、破棄しません。

  • 解析成功時にソースフィールドを保持：このオプションを選択すると、ログが正常に解析された場合でも生ログコンテンツが保持されます。

3. ログフィルタリング

DEBUG や INFO ログなど、価値の低いまたは無関係なログを大量に収集すると、ストレージリソースを浪費し、コストを増加させ、クエリ効率を低下させ、データ漏えいのリスクを生み出します。効率的で安全なログ収集のために、詳細なフィルタリングポリシーを使用してください。

フィルタリングはコンソールの 2 か所で設定されます。コンテンツフィルタリングは [プロセッサ設定] セクションの処理プラグインであり、収集ブラックリストとコンテナフィルタリングは [入力設定] セクションのスイッチです。

4. ログ分類

複数のアプリケーションやインスタンスが同じログフォーマットを共有する場合、ログソースを区別するのが難しくなり、クエリにコンテキストがなくなり、分析効率が低下します。これに対処するため、トピックとログタグ付けを設定して、自動的なコンテキスト関連付けと論理的な分類を行います。

/data/logs
├── userA
│   └── serviceA
│       └── service.log
├── userB
│   └── serviceA
│       └── service.log
└── userC
    └── serviceA
        └── service.log

5. 出力設定

デフォルトでは、すべてのログは lz4 圧縮で現在の Logstore に送信されます。同じソースからのログを異なる Logstore に配信するには、以下の手順を実行します。

複数のターゲットへの動的配信

• 複数のターゲットへの送信には LoongCollector 3.0.0 以降が必要です。Logtail はこの機能をサポートしていません。

• 最大 5 つの出力ターゲットを設定できます。

• 複数の出力先を設定すると、現在の LogStore の収集設定リストに収集設定が表示されなくなります。 複数ターゲットのディストリビューション設定を表示、変更、または削除するには、複数ターゲットのディストリビューション設定を管理する方法をご参照ください。

  手順: Logtail構成 ページで、出力設定 セクションで:

1. をクリックして出力設定を展開します。

2. 出力先の追加 をクリックし、以下の設定を行います：

   • Logstores: 送信先 Logstore を選択します。

   • 圧縮方法：lz4 と zstd がサポートされています。

   • ルート設定: タグフィールドに基づいてログをルーティングおよび配信します。 ルーティング構成に一致するログは、送信先 LogStore にアップロードされます。 ルーティング構成が空の場合、収集されたすべてのログが送信先 LogStore にアップロードされます。

     • タグ名: ルーティングに使用するタグフィールドの名前です。 __tag__: プレフィックスを付けずに、 __path__ などのフィールド名を直接入力します。タグフィールドは、次の 2 つのカテゴリに分類されます:

       • エージェント関連：収集エージェント自体に関連し、プラグインとは独立しています (例：__hostname__、__user_defined_id__)。

       • 入力プラグイン関連：入力プラグインによって提供され、関連情報でログをエンリッチします (例：ファイル収集用の __path__、Kubernetes 収集用の _pod_name_ および _container_name_)。

         タグの詳細については、「収集タグの管理」をご参照ください。

     • タグ値: タグフィールドの値がこの値に一致するログが、送信先の LogStore に送信されます。

     • このタグフィールドを破棄するかどうか: このスイッチをオンにすると、アップロードされたログにこのタグフィールドは含まれなくなります。

アップロードされたログの表示

• ログファイルに新しいコンテンツがあることを確認する：LoongCollector は増分ログのみを収集します。tail -f /path/to/your/log/file を実行し、アプリケーション操作をトリガーして、新しいログが書き込まれていることを確認してください。

• ログのクエリ: 送信先 LogStore のクエリと分析ページに移動し、検索と分析 をクリックします。デフォルトの時間範囲は直近 15 分です。新しいログが届いているかどうかを確認します。デフォルトでは、収集された各 Docker コンテナのテキストログには、次のフィールドが含まれています。

コンテナ標準出力が使用するメタデータフィールド名については、本トピックの「付録：新旧コンテナ標準出力バージョンの比較」セクションをご参照ください。

一般的な問題のトラブルシューティング

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 (Logtail) の運用ログは、コンテナ内の /usr/local/ilogtail/ ディレクトリに保存されます。ファイル名は ilogtail.LOG で、ローテーションされたファイルは圧縮されて ilogtail.LOG.x.gz として保存されます。例：

# 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 ディレクトリにマウントします。

同じログファイルまたはコンテナ標準出力を複数の収集設定で収集するにはどうすればよいですか？

デフォルトでは、データの重複を防ぐため、Simple Log Service は各ログソースが 1 つの収集設定によってのみ収集されることを許可します。

• テキストログファイルは、1 つの Logtail 収集設定によってのみ照合できます。

• コンテナ標準出力 (stdout)：

• 新しい標準出力テンプレートを使用する場合、標準出力はデフォルトで 1 つの標準出力収集設定によってのみ収集できます。

• 古い標準出力テンプレートを使用する場合、複数の設定による収集がデフォルトでサポートされており、追加の設定は不要です。

  同じログソースを複数の収集設定で収集できるようにするには、以下の手順を実行します。

1. Simple Log Service コンソールにログインし、対象のプロジェクトに移動します。

2. 左側のナビゲーションウィンドウで、[Logstores] を選択し、対象の Logstore を見つけます。

3. その名前の横にある アイコンをクリックして Logstore を展開します。

4. Logtail構成 をクリックし、構成リストで送信先の Logtail 構成を見つけ、[操作] 列の Logtail 設定の管理 をクリックします。

5. Logtail 構成ページで、編集 をクリックし、入力設定 セクションまで下にスクロールします: - テキストファイルログを収集するには: ファイルを複数回収集できるようにする をオンにします。 - コンテナの標準出力を収集するには: 標準出力の複数回の収集を許可する をオンにします。

複数ターゲット配信設定を管理するにはどうすればよいですか？

複数ターゲット配信設定は複数の Logstore に関連付けられているため、このタイプの設定はプロジェクトレベルの管理ページで維持する必要があります。

1. Simple Log Service コンソールにログインし、対象のプロジェクトの名前をクリックします。

2. 送信先プロジェクトページで、左側のナビゲーションウィンドウで、リソースグループ > 設定の管理 をクリックします。

   このページでは、誤って Logstore が削除された後に残された設定を含む、プロジェクト内のすべての収集設定を一元管理します。

正規表現解析

正規表現でログフィールドを抽出し、ログをキーと値のペアに解析して、各フィールドを独立してクエリおよび分析できるようにします。

例：

手順：Logtail構成 ページの 設定の処理 セクションで、処理プラグインの追加 をクリックして ネイティブ処理プラグイン > 正規表現解析 を選択します：

• 正規表現：ログのマッチングに使用する式です。自動で生成するか、手動で入力できます：

• 自動生成：

  1. [正規表現を自動生成] をクリックします。

  2. ログサンプル セクションで、抽出したいログの内容をハイライトします。

  3. [正規表現を生成] をクリックします。

     [ログサンプル] セクションに正しいフォーマットのログコンテンツ (Apache Combined アクセスログなど) が貼り付けられていることを確認し、そのセクションの [正規表現を生成] をクリックして解析式を自動生成します。 - 手動入力：ログフォーマットに基づいて正規表現を手動で入力します。

  構成が完了したら、[検証] をクリックして、正規表現がログコンテンツを正しく解析できるかどうかをテストします。 - ログ抽出フィールド: 抽出された各ログコンテンツ (値) に対して、フィールド名 (キー) を設定します。 - その他のパラメーターについては、シナリオ 2: ログの構造化に記載の一般的な構成パラメーターをご参照ください。

区切り文字解析

区切り文字でログコンテンツを構造化し、複数のキーと値のペアに解析します。単一文字および複数文字の区切り文字がサポートされています。

例：

手順: Logtail構成 ページの 設定の処理 セクションで、処理プラグインの追加 をクリックし、ネイティブ処理プラグイン > 区切り文字解析 を選択します:

• 区切りモード: ログの内容を区切る文字を指定します。例: CSV ファイルの場合、カスタム を選択し、カンマ (,) を入力します。

• 引用符：フィールド値にデリミタが含まれる場合、引用符を指定してフィールドを囲み、誤った分割を防ぎます。

• ログ抽出フィールド：列が分割される順序で、各列にフィールド名 (キー) を設定します。次のルールが適用されます。

• フィールド名には、文字、数字、アンダースコア (_) のみを含めることができます。

• フィールド名は、文字またはアンダースコア (_) で始まる必要があります。

• 最大長：128 バイト。

• その他のパラメーターについては、シナリオ 2: ログの構造化で説明されている一般的な構成パラメーターをご参照ください。

標準 JSON 解析

オブジェクトタイプの JSON ログを構造化し、キーと値のペアに解析します。

例：

手順：Logtail構成 ページの 設定の処理 セクションで、処理プラグインの追加 をクリックし、ネイティブ処理プラグイン > JSON 解析 を選択します：

• 元のフィールド：デフォルト値： content。このフィールドは、解析対象の生ログの内容を格納します。

• その他のパラメーターについては、シナリオ 2: ログの構造化に記載の一般的な構成パラメーターをご参照ください。

ネストされた JSON 解析

展開深度を指定して、ネストされた JSON ログをキーと値のペアに解析します。

例：

手順: Logtail構成 ページの 設定の処理 セクションで、処理プラグインの追加 をクリックし、拡張処理プラグイン > JSON フィールドの拡張 を選択します:

• 元のフィールド: 展開する元のフィールドの名前です。たとえば、content があります。

• JSON 拡張度: JSON オブジェクトの展開レベルです。値が 0 の場合は完全な展開 (デフォルト値) を示し、値が 1 の場合は現在のレベルを示します。以降も同様です。

• JSON 拡張連結文字：JSON 展開時にフィールド名を連結するために使用する文字。デフォルト値：アンダースコア (_)。

• JSON のフィールドプレフィックス拡張： JSON を展開した後のフィールド名に付加されるプレフィックスです。

• 配列を展開する: このオプションを有効にすると、配列がインデックス付きのキーと値のペアに展開されます。例： {"k":["a","b"]} は {"k[0]":"a","k[1]":"b"} に展開されます。

  たとえば、展開されたフィールド prefix_s_key_k1 を new_field_name に変更するには、後でフィールドの名前変更 プラグインを追加してマッピングを完了します。

• その他のパラメーターについては、シナリオ 2: ログの構造化で説明されている一般的な構成パラメーターをご参照ください。

JSON 配列解析

json_extract関数を使用して、JSON 配列から JSON オブジェクトを抽出します。

例：

手順： Logtail構成 ページの 設定の処理 セクションで、処理モード を SPL に切り替え、SPL 文 を設定し、json_extract 関数を使用して JSON 配列から JSON オブジェクトを抽出します。

例：content ログフィールドから JSON 配列の要素を抽出し、結果を新しい json1 および json2 フィールドに保存します。

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

Apache ログ解析

Apache ログ設定ファイルの定義に基づいてログコンテンツを構造化し、複数のキーと値のペアに解析します。

例：

手順: Logtail構成 ページの 設定の処理 セクションで、処理プラグインの追加 をクリックし、ネイティブ処理プラグイン > Apache モード解析 を選択します：

• ログ形式: combined

• APACHE 設定フィールド: Simple Log Service は、ログ形式 に基づいてこの設定を自動的に入力します。自動入力された内容が、サーバー上の Apache 設定ファイル (通常は /etc/apache2/apache2.conf) で定義されている LogFormat と同一であることを確認してください。

• その他のパラメーターについては、シナリオ 2: ログの構造化に記載の一般的な構成パラメーターをご参照ください。

データマスキング

ログ内の機密データをマスキングします。

例：

手順：Logtail構成 ページの 設定の処理 セクションで、処理プラグインの追加 をクリックし、ネイティブ処理プラグイン > データマスキング処理 を選択します：

• 元のフィールド：解析前のログの内容を格納するフィールドです。

• マスキング方法：

  • const：機密コンテンツを指定された文字列に置き換えます。

  • md5：機密コンテンツをその MD5 値に置き換えます。

• 文字列の置き換え：マスキング方法 に const を設定した場合、機密コンテンツを置き換える文字列を入力します。

• 置き換えられたコンテンツより前のコンテンツの式: 機密性の高いコンテンツを特定します。RE2 構文で設定します。

• 置き換えられたコンテンツの式: 機密コンテンツの式です。RE2 構文で設定します。

時間解析

ログ内の時間フィールドを解析し、解析結果をログの __time__ フィールドとして設定します。

例：

手順: Logtail構成 ページの 設定の処理 セクションで、処理プラグインの追加 をクリックし、ネイティブ処理プラグイン > 時間解析 を選択します：

• 元のフィールド: 解析前のログの内容を格納するフィールドです。

• 時間形式: ログ内の時間の内容に一致する時間フォーマットを設定します。

• タイムゾーン: ログの時間フィールドのタイムゾーンを選択します。デフォルトでは、マシンのタイムゾーンが使用されます。これは、LoongCollector (Logtail) プロセスをホストする環境のタイムゾーンです。

新しい標準出力の主な利点

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

• C++ でリファクタリングされた新バージョンは、以前の Go 実装に比べて 180% から 300% のパフォーマンス向上を実現します。

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

• ネイティブプラグインと Go プラグインの柔軟な組み合わせをサポートし、複雑なシナリオのニーズに対応します。

• より高い信頼性

• 標準出力ログのローテーションキューをサポートし、ログ収集メカニズムをファイル収集メカニズムと統一することで、標準出力ログが急速にローテーションする場合でも高い信頼性を提供します。

• リソース消費の削減

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

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

• O&M の一貫性の向上

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

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

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

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

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

新バージョンがユーザーに与える影響

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

• SQL 互換性：クエリ SQL は既に両方のバージョンと自動的に互換性があるため、どちらのバージョンのログを処理する場合でもクエリ文を変更する必要はありません。