Simple Log Service:ホストからテキストログを収集する

手順:

1. [Logstores] ページで、ターゲット Logstore 名の前にある アイコンをクリックして展開します。

2. [データ取り込み] の横にある アイコンをクリックし、[クイックデータ取り込み] ダイアログボックスで、テキストログ取り込みテンプレート (Single-line Text Log など) を選択して [今すぐ取り込み] をクリックします。

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

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 拡張子を持つすべてのファイルを示します。

  • 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: 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

手順: [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. 共通構成パラメーターの説明: 以下のパラメーターは、複数のデータ解析プラグインに表示され、統一された機能と使用法を持っています。

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

   • 解析失敗時にソースフィールドを保持: このオプションを有効にすることをお勧めします。プラグインによってログが正常に解析できない場合 (形式の不一致など)、このオプションにより、元のログコンテンツが失われることなく、指定されたソースフィールドに完全に保持されます。

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

手順: [グローバル構成] > [その他のグローバル構成] > [Topic タイプ]: Topic を生成する方法を選択します。以下の 3 種類がサポートされています:

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

• カスタム: customized://<custom_topic_name> の形式を使用します (例: customized://app-login)。この形式は、固定のビジネス識別子を持つ静的な Topic シナリオに適しています。

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

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

  この場合、ファイルパス抽出を構成し、正規表現を使用して完全なパスからキー情報を抽出できます。一致した結果は、Topic として 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

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

手順:

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

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

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

4. [Logtail 構成] をクリックします。構成リストで、ターゲットの Logtail 構成を見つけ、[アクション] 列の [Logtail 構成の管理] をクリックします。

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

   • [入力構成] > [その他の入力構成] で、[単一ファイルの複数収集を許可] を有効にします。

6. 構成が完了したら、[保存] をクリックします。

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

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 構成] ページの [処理構成] セクションで、[処理プラグインの追加] をクリックし、[ネイティブ処理プラグイン] > [正規表現解析] を選択します:

• 正規表現: ログに一致させるために使用する式。自動的に生成するか、手動で入力できます:

  • 自動生成:

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

    • [ログサンプル] で、抽出するログコンテンツを選択します。

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

      

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

  構成後、[検証] をクリックして、正規表現がログコンテンツを正しく解析できるかどうかをテストします。

• 抽出されたログフィールド: 抽出されたログコンテンツ (値) に対応するフィールド名 (キー)。

• その他のパラメーターについては、「シナリオ 2: 構造化ログ」の共通構成パラメーターの説明をご参照ください。

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

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 バイト。

• その他のパラメーターについては、「シナリオ 2: 構造化ログ」の共通構成パラメーターの説明をご参照ください。

オブジェクトタイプの 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 です。

• その他のパラメーターについては、「シナリオ 2: 構造化ログ」の共通構成パラメーターの説明をご参照ください。

展開深度を指定して、ネストされた 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 に変更する) には、後で [フィールド名の変更] プラグインを追加してマッピングを完了できます。

• その他のパラメーターについては、「シナリオ 2: 構造化ログ」の共通構成パラメーターの説明をご参照ください。

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 と完全に同じであることを確認してください。

• その他のパラメーターについては、「シナリオ 2: 構造化ログ」の共通構成パラメーターの説明をご参照ください。

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: Microsoft インターネットインフォメーションサービスのログファイル形式。

  • NCSA: Common Log Format。

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

• その他のパラメーターについては、「シナリオ 2: 構造化ログ」の共通構成パラメーターの説明をご参照ください。

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

例:

[{'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) プロセスが実行されている環境のタイムゾーンです。