Simple Log Service:ホストからのテキストログの継続的な収集

操作手順：

1. [Logstores] ページで、対象の Logstore 名の左側にある をクリックして展開します。

2. データのインポート の横にある アイコンをクリックします。 データのインポート ダイアログボックスで、テキストログ取り込みテンプレート (単一行テキストログなど) を選択し、今すぐ統合 をクリックします。

   すべてのテキストログ取り込みテンプレートは、解析プラグインのみが異なります。残りの設定プロセスは同じで、後で変更できます。

3. サーバグループ設定 ページで、次のパラメーターを設定します:

   • 使用シナリオ: ホストシナリオ

   • インストール環境：ECS

   • マシングループの設定：対象サーバーの LoongCollector のインストール状況とマシングループの設定に基づいて、適切なオプションを選択します：

     • LoongCollector がインストールされ、マシングループに追加されている場合は、ソースサーバーグループ リストから選択して 適用されたサーバーグループ リストに追加します。再度作成する必要はありません。

     • LoongCollector がインストールされていない場合は、サーバグループの作成 をクリックします:

       以下の手順では、LoongCollector の自動インストールとマシングループの作成について説明します。

       1. システムは、プロジェクトと同じリージョンにある ECS インスタンスを自動的にリストアップします。ログを収集するインスタンスを 1 つ以上選択します。

       2. [インストールしてマシングループとして作成] をクリックします。システムは、選択した ECS インスタンスに LoongCollector を自動的にインストールします。

       3. マシングループの名前を設定し、OK をクリックします。

       説明

       インストールが失敗した場合、または待機状態のままの場合は、ECS のリージョンがプロジェクトのリージョンと同じであるかを確認してください。

     • LoongCollector がすでにインストールされているサーバーを既存のマシングループに追加するには、「サーバーを既存のマシングループに追加するにはどうすればよいですか？」をご参照ください。

4. ハートビートステータスの確認：次へ をクリックします。マシングループのハートビートステータス セクションが表示されます。ハートビート のステータスを確認します。ステータスが OK の場合、マシングループの接続は正常です。次へ をクリックして Logtail 構成ページに移動します。

   ステータスが FAIL の場合、最初のハートビートを確立するのに時間がかかることがあります。約 2 分待ってから、ハートビートのステータスを更新してください。更新後も FAIL のままである場合は、「マシングループのハートビートが FAIL」をご参照のうえ、トラブルシューティングを行ってください。

グローバル設定：

• 設定名：収集設定のカスタム名です。プロジェクト内で一意である必要があります。作成後に名前を変更することはできません。命名規則：

  • 小文字、数字、ハイフン (-)、アンダースコア (_) のみを含めることができます。

  • 小文字または数字で開始および終了する必要があります。

入力設定：

• タイプ: テキストログ収集。

• ファイルパス：収集するログファイルのパスです。

  • Linux：スラッシュ (/) で始まる必要があります。例：/data/mylogs/**/*.log は、/data/mylogs ディレクトリ内の .log 拡張子を持つすべてのファイルを示します。Node.js アプリケーションの場合、一般的なログパスは /var/log/nodejs/*.log で、/var/log/nodejs 配下のすべての .log ファイルを収集します。

  • Windows：ドライブ文字で始まる必要があります。例：C:\Program Files\Intel\**\*.Log。

• ディレクトリ監視の最大深度: ファイルパス のワイルドカード ** がマッチする最大のディレクトリ深度です。 デフォルトは 0 で、現在のディレクトリのみが監視されることを意味します。

シナリオ 2：構造化ロギング

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 : Mozi11a/5.0 (Nindows NT 10.0; Win64; x64) AppleMebKit/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

手順: Logtail構成 ページの 設定の処理 エリアで

1. 解析プラグインの追加: 処理プラグインの追加 をクリックし、実際のフォーマットに基づいて、正規表現解析、区切り文字解析、JSON 解析などのプラグインを設定します。この例では、NGINX ログ収集を使用します。ネイティブ処理プラグイン > NGINX モード解析 を選択します。

2. 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"';

   重要

   ここでのフォーマット定義は、サーバー上でログを生成するフォーマットと完全に一致している必要があります。一致しない場合、ログの解析は失敗します。

3. 例：winston で生成された JSON 形式のログを収集する

   winston はデフォルトで JSON 形式のログを出力します。これらは標準の JSON ログであるため、正規表現を書かずに直接 JSON 解析を使用できます。

   サンプルログ：

   {"level":"info","message":"User logged in","timestamp":"2026-01-01T00:00:00.000Z"}

   プロシージャ: Logtail構成 ページで、入力設定 エリアで、ファイルパス を /var/log/nodejs に、ファイル名パターンを app.log に設定します。次に、設定の処理 エリアで、処理プラグインの追加 をクリックし、ネイティブ処理プラグイン > JSON 解析 を選択します。

   • [システム時間を使用] をオフにし、[時間キー] を timestamp に、[時間変換フォーマット] を %Y-%m-%dT%H:%M:%S.%fZ に設定します。

   • JSON 解析プラグインは、timestamp、level、message を個別のフィールドとして自動的に抽出します。userId などのカスタムフィールドも、追加の設定なしで解析されます。完全なパラメーターの詳細については、「付録：ネイティブ解析プラグインの説明」の標準 JSON 解析と時間解析をご参照ください。

4. 例：pino で生成されたカスタムフォーマットのログを収集する

   pino や同様のライブラリがカスタムのプレーンテキスト出力を生成するように設定されている場合、ログは標準の JSON ではないため、正規表現解析を使用し、キャプチャグループでフィールドを抽出します。

   サンプルログ：

   2026-01-01T00:00:00.000Z [INFO] User logged in

   プロシージャ: Logtail構成 ページの 入力設定 エリアで、ファイルパス を /var/log/nodejs に、ファイル名パターンを pino.log に設定します。 次に、設定の処理 エリアで 処理プラグインの追加 をクリックし、ネイティブ処理プラグイン > 正規表現解析 を選択します。

   • 正規表現：^(\S+) \[(\w+)\] (.*)$

   • フィールド名 (キャプチャグループの順)：time、level、message。[時間キー] を time に設定します。完全なパラメーターの詳細については、「付録：ネイティブ解析プラグインの説明」の正規表現解析をご参照ください。

5. 一般的な設定パラメーター： 以下のパラメーターは複数のデータ解析プラグインに表示され、その機能と使用法は一貫しています。

   • ソースフィールド：解析対象のソースフィールド名を指定します。デフォルトは content で、収集されたログエントリ全体です。

   • 解析失敗時にソースフィールドを保持：このオプションを有効にすることを推奨します。フォーマットの不一致などでログがプラグインによって正常に解析できない場合、このオプションにより元のログコンテンツが失われず、指定されたソースフィールドに完全に保持されます。

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

手順: グローバル設定 > その他のグローバル設定 > ログテーマのタイプ で、トピックの生成方法を選択します。 次の 3 つのタイプがサポートされています。

• マシングループトピック：収集設定が複数のマシングループに適用される場合、LoongCollector はサーバーのマシングループ名を __topic__ フィールドとして自動的に使用してアップロードします。これは、ホストごとにログを分類するシナリオに適しています。

• カスタム: フォーマットは customized://<custom_topic_name> です。例: customized://app-login。これは、固定サービス識別子を持つ静的トピックシナリオに適しています。

• ファイルパス抽出：ログファイルの完全なパスからキー情報を抽出し、ログソースを動的にマークします。これは、複数のユーザーやアプリケーションが同じログファイル名を共有しているが、パスが異なる場合に適しています。複数のユーザーやサービスが異なるトップレベルディレクトリにログを書き込むが、サブパスとファイル名が同じ場合、ファイル名だけではソースを区別できません。例：

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

  この場合、ファイルパス抽出を設定し、正規表現を使用して完全なパスからキー情報を抽出できます。一致した結果は、トピックとして Logstore にアップロードされます。

  ファイルパス抽出ルール：正規表現のキャプチャグループに基づく

  正規表現を設定すると、システムはキャプチャグループの数と命名に基づいて出力フィールドのフォーマットを自動的に決定します。ルールは次のとおりです：

  ファイルパスの正規表現では、スラッシュ (/) をエスケープする必要があります。

  キャプチャグループの種類	シナリオ	生成されるフィールド	正規表現の例	一致するパスの例	生成されるフィールドの例
  単一のキャプチャグループ (1 つの (.*?) のみ)	ソースを区別するために 1 つのディメンションのみが必要 (ユーザー名、環境など)	__topic__ フィールドを生成	\/logs\/(.*?)\/app\.log	/logs/userA/app.log	__topic__: userA
  複数の名前なしキャプチャグループ (複数の (.*?))	ソースを区別するために複数のディメンションが必要だが、意味的なタグは不要	タグフィールド __tag__:__topic_{i}__ を生成。{i} はキャプチャグループの序数	\/logs\/(.*?)\/(.*?)\/app\.log	/logs/userA/svcA/app.log	__tag__:__topic_1__userA __tag__:__topic_2__svcA
  複数の名前付きキャプチャグループ ((?P<name>.*?) を使用)	ソースを区別するために複数のディメンションが必要で、クエリと分析を容易にするためにフィールドの意味を明確にしたい場合	タグフィールド __tag__:{name} を生成	\/logs\/(?P<user>.*?)\/(?P<service>.*?)\/app\.log	/logs/userA/svcA/app.log	__tag__:user:userA; __tag__:service:svcA

デフォルトでは、すべてのログが現在の Logstore に送信され、圧縮方法は lz4 です。同じソースからのログを異なる Logstore に配信するには、以下の設定を構成できます：

デフォルトでは、データの重複を避けるため、Simple Log Service はテキストログファイルが 1 つの Logtail 構成によってのみ収集されるように制限しています。同じログファイルを複数の構成で同時に収集できるようにするには、ファイルが複数回収集されることを許可する機能を手動で有効にする必要があります。

操作手順：

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

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

3. その名前の左側にある をクリックして Logstore を展開します。

4. Logtail構成 をクリックします。構成リストで、目的の Logtail 構成を見つけ、「操作」列の Logtail 設定の管理 をクリックします。

5. Logtail 構成ページで、編集をクリックします：

   • 入力設定 > その他の入力設定で、ファイルを複数回収集できるようにする を有効にします。

6. 構成が完了したら、OK をクリックします。

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

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

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

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

  • 自動生成：

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

    • ログサンプル で、抽出するログの内容を選択します。

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

  • 手動入力：ログ形式に基づいて [正規表現の手動入力] を行います。

  設定が完了したら、[検証] をクリックして、正規表現がログコンテンツを正しく解析できるかテストします。

• ログ抽出フィールド: 抽出されたログ内容 (Value) に対応するフィールド名 (Key) を設定します。

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

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

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

• 区切りモード: ログの内容を分割するために使用する文字を指定します。

  例：CSV ファイルの場合、カスタム を選択し、コンマ (,) を入力します。

• 引用符: フィールド値に区切り文字が含まれている場合、誤って分割されないように、引用符でフィールドを囲む必要があります。

• ログ抽出フィールド: 分割順に、各列に対応するフィールド名 (キー) を設定します。ルールは次のとおりです。

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

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

  • 最大長：128 バイト。

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

{"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

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

• 元のフィールド: デフォルト値は content です。このフィールドは、解析対象の生ログの内容を格納するために使用されます。

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

{"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"}}}}

手順: 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 に変更するには、後で フィールドの名前変更 プラグインを追加してマッピングを完了できます。

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

例：

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

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

手順: Logtail構成 ページの 設定の処理 エリアで、処理モード を SPL に切り替え、[SPL ステートメント] を設定し、json_extract 関数を使用して JSON 配列から JSON オブジェクトを抽出します。

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

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

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

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]

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

• ログ形式: combined.

• APACHE 設定フィールド：システムは、ログ形式 に基づいて構成を自動的に入力します。

  重要

  自動入力されたコンテンツが、サーバーの Apache 設定ファイル (通常は /etc/apache2/apache2.conf にあります) で定義されている LogFormat と完全に同じであることを必ず確認してください。

IIS ログフォーマット定義に基づいてログコンテンツを構造化し、複数のキーと値のペアに解析します。

比較例：

#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken

c-ip: cs-username
cs-bytes: sc-substatus
cs-method: cs-method
cs-uri-query: cs-uri-query
cs-uri-stem: cs-uri-stem
cs-username: s-port
date: #Fields:
s-computername: s-sitename
s-ip: s-ip
s-sitename: time
sc-bytes: sc-status
sc-status: c-ip
sc-win32-status: cs (User-Agent)
time: date
time-taken: sc-win32-status

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

• ログ形式: IIS サーバーログで使用されるログフォーマットを選択します。

  • IIS：IIS ログファイル形式。

  • NCSA：NCSA 共通ログ形式。

  • W3C：W3C 拡張ログファイル形式。

• IIS 設定フィールド: IIS または NCSA を選択すると、Simple Log Service によって IIS 設定フィールドがデフォルトで設定されます。 W3C を選択した場合は、IIS 設定ファイル内の logExtFileFlags パラメーターの内容に設定してください。 例:

  logExtFileFlags="Date, Time, ClientIP, UserName, SiteName, ComputerName, ServerIP, Method, UriStem, UriQuery, HttpStatus, Win32Status, BytesSent, BytesRecv, TimeTaken, ServerPort, UserAgent, Cookie, Referer, ProtocolVersion, Host, HttpSubStatus"

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

例：

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

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

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

• 元のフィールド：解析前のログの内容が含まれているソースフィールドです。

• マスキング方法：

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

  • md5：機密コンテンツを対応する MD5 ハッシュに置き換えます。

• 文字列の置き換え: マスキング方法 に const を選択した場合、機密コンテンツを置き換える文字列を入力する必要があります。

• 置き換えられたコンテンツより前のコンテンツの式: 機密コンテンツの検索に使用されます。RE2 構文を使用して設定します。

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

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

例：

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

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

• 元のフィールド：解析前のログの内容を含むソースフィールドです。

• 時間形式: ログの時間内容に合わせて設定します。

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