すべてのプロダクト
Search
ドキュメントセンター

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

最終更新日:Dec 02, 2025

異なるサーバーに分散しているビジネスログやシステムログは、一元的に検索、監視、分析することが困難です。LoongCollector (Logtail) を使用して、Elastic Compute Service (ECS) インスタンス、セルフマネージド IDC、または他のクラウドプロバイダーのホストからテキストログをリアルタイムで収集し、Simple Log Service (SLS) に送信して一元的な管理と分析を行います。完全なログを収集するには、過去のログファイルをインポートします。

注意事項

  • サポートされるオペレーティングシステムとアーキテクチャ:

    LoongCollector は Linux システムのみをサポートします。Windows ホストの場合は、Logtail を使用してください。新しい収集シナリオでは LoongCollector の使用を推奨します。

    LoongCollector は SLS の次世代ログ収集エージェントであり、Logtail のアップグレード版です。LoongCollector または Logtail のいずれか一方のみをインストールする必要があり、両方をインストールする必要はありません。
  • コンピューティングリソース要件:

    • CPU:最小 0.4 コア。

    • メモリ:最小 300 MB。

    • 推奨使用量:安定した動作を確保するため、LoongCollector (Logtail) の実際のリソース使用量を制限の 80% 未満に維持してください。実際の使用量は、収集速度、監視対象のディレクトリとファイルの数、送信ブロッキングの程度などの要因によって異なります。

  • 権限要件:

    Resource Access Management (RAM) ユーザーを使用する場合、AliyunLogFullAccess および AliyunECSFullAccess 権限を付与する必要があります。詳細な権限付与については、「付録:カスタム権限ポリシー」をご参照ください。

収集設定のワークフロー

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

  2. マシングループの設定 (LoongCollector のインストール)サーバーの種類に基づいて LoongCollector をインストールし、サーバーをマシングループに追加します。マシングループは、収集ノードの管理、構成の配布、およびサーバーの状態管理に使用されます。

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

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

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

      • 複数行ログ:Java の例外スタックや Python のトレースバックなど、単一のログが複数行にまたがる場合に使用します。正規表現で各ログの開始を識別し、連続する行を単一の完全なログにマージします。

      • 構造化解析:正規表現、区切り文字、NGINX パターンなどの解析プラグインを使用して、生文字列を構造化されたキーと値のペアに抽出します。これにより、各フィールドを個別にクエリおよび分析できます。

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

    4. ログの分類トピックを使用して、異なるアプリケーション、サーバー、またはパスソースからのログを区別します。

  4. クエリと分析の設定:全文インデックスはデフォルトで有効になっており、キーワード検索をサポートします。構造化されたフィールドの正確なクエリと分析のためにフィールドインデックスを有効にすると、検索効率が向上します。

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

事前準備

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

プロジェクトの作成

  1. Simple Log Service コンソールにログインします

  2. [プロジェクトの作成] をクリックし、次のパラメーターを設定します:

    • リージョン:ログソースが配置されているリージョン。作成後に変更することはできません。

    • プロジェクト名:Alibaba Cloud 内でグローバルに一意である必要があり、作成後に変更することはできません。

    • 他の設定はデフォルトのままにし、[作成] をクリックします。他のパラメーターの詳細については、「プロジェクトの作成」をご参照ください。

Logstore の作成

  1. プロジェクト名をクリックして、対象のプロジェクトに移動します。

  2. 左側のナビゲーションウィンドウで、image[ログストレージ] を選択し、[+] をクリックします。

  3. [Logstore の作成] ページで、次の主要な設定を完了します:

    • Logstore 名:プロジェクト内で一意の Logstore 名。作成後に変更することはできません。

    • Logstore タイプ:要件に応じて [標準] または [クエリ] を選択します。

    • 課金モード

      • 機能単位の課金:ストレージ、インデックス、読み取り/書き込み操作などのリソースが個別に課金される課金モード。このモードは、小規模なシナリオや機能の使用量が予測できない場合に適しています。

      • 書き込みデータ量に応じた課金:書き込まれた生データの量のみに基づいて課金されます。この課金方法には、30 日間の無料ストレージと、データ変換や配信などの無料機能が含まれます。ストレージ期間が約 30 日のビジネスシナリオや、複雑なデータ処理パイプラインに最適です。

    • データ保持期間:ログを保持する日数 (1〜3,650)。値が 3,650 の場合は永続的なストレージを示します。デフォルトは 30 日です。

    • 他の設定はデフォルトのままにし、[OK] をクリックします。他の設定の詳細については、「Logstore の管理」をご参照ください。

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

事前準備が完了したら、ご利用のサーバーに LoongCollector をインストールし、マシングループに追加します。

説明

以下のインストール手順は、ログソースが SLS プロジェクトと同じ Alibaba Cloud アカウントおよびリージョンにある Alibaba Cloud ECS インスタンスである場合にのみ適用されます。

ご利用の ECS インスタンスとプロジェクトが異なるアカウントまたはリージョンにある場合、またはログソースがオンプレミスサーバーである場合は、「LoongCollector のインストールと設定」をご参照ください。

操作手順:

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

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

    すべてのテキストログ収集テンプレートは、解析プラグインのみが異なり、残りの設定プロセスは同じで、後で変更できます。
  3. [マシングループ設定] ページで、次のパラメーターを設定します:

    • シナリオサーバー

    • インストール環境ECS

    • マシングループの選択:対象サーバーの LoongCollector のインストール状況とマシングループの設定に基づいて、対応する操作を選択します:

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

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

        以下の手順では、LoongCollector のワンクリック自動インストールとマシングループの作成について説明します。
        1. システムは、プロジェクトと同じリージョンにある ECS インスタンスを自動的にリストアップします。ログを収集したいインスタンスを 1 つ以上選択します。

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

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

        説明

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

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

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

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

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

LoongCollector のインストールとマシングループの設定が完了したら、[Logtail 構成] ページに移動し、ログの収集と処理のルールを定義します。

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

収集設定の名前、ログ収集のソースと範囲を定義します。

グローバル設定

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

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

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

入力設定

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

  • ファイルパス:ログ収集パス。

    • Linux:パスはスラッシュ (/) で始まる必要があります。例:/data/mylogs/**/*.log は、/data/mylogs ディレクトリとそのサブディレクトリにある .log 拡張子を持つすべてのファイルを示します。

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

  • 最大ディレクトリ監視深度[ファイルパス]** ワイルドカード文字に一致するディレクトリの最大深度。デフォルト値は 0 で、現在のディレクトリのみを監視することを示します。


2. ログの処理と構造化

ログ処理ルールを設定して、生の非構造化ログを構造化された検索可能なデータに変換します。これにより、ログのクエリと分析の効率が向上します。まず、ログサンプルを追加することを推奨します:

[Logtail 構成] ページの [プロセッサー設定] セクションで、[サンプルログの追加] をクリックし、収集するログコンテンツを入力します。システムはサンプルに基づいてログ形式を識別し、正規表現と解析ルールの生成を支援するため、設定が簡素化されます。

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

Java の例外スタックや JSON オブジェクトなどのログは複数行にまたがることが多いため、デフォルトの収集モードでは不完全な複数のレコードに分割され、コンテキストが失われます。これを防ぐには、複数行モードを有効にし、先頭行を一致させる正規表現を設定して、同じログの連続する行を単一の完全なログにマージします。

例:

未処理の生ログ

デフォルトの収集モードでは、各行が個別のログとなり、スタックトレースが分断され、コンテキストが失われる

複数行モードを有効にすると、先頭行を一致させる正規表現が完全なログを識別し、その完全な意味構造を保持する

image

image

image

操作手順:[Logtail 構成] ページの [プロセッサー設定] セクションで、[複数行モード] を有効にします:

  • [タイプ] で、[カスタム] または [複数行 JSON] を選択します。

    • カスタム:可変形式の生ログの場合、[先頭行の正規表現] を設定して、各ログの開始行を識別します。

      • 先頭行の正規表現:データの完全な行に一致する正規表現を自動生成または手動で入力します。例えば、上記の例の正規表現は \[\d+-\d+-\w+:\d+:\d+,\d+]\s\[\w+]\s.* です。

        • 自動生成:[生成] をクリックします。次に、[ログサンプル] テキストボックスで、抽出したいログコンテンツを選択し、[自動生成] をクリックします。

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

    • 複数行 JSON:ログが標準の JSON 形式である場合、SLS は単一の生ログ内の改行を自動的に処理します。

  • 分割失敗時の処理方法

    • 破棄:行頭ルールに一致しないテキストセグメントを破棄します。

    • 単一行を保持:一致しないテキストを別々の行に保持します。

シナリオ 2:構造化ログ

NGINX のアクセスログやアプリケーションの出力ログなど、生のログが非構造化または半構造化テキストである場合、直接のクエリや分析は非効率的です。SLS は、さまざまな形式の生ログを自動的に構造化データに変換できる多様なデータ解析プラグインを提供します。これにより、後続の分析、モニタリング、アラートのための堅固なデータ基盤が提供されます。

例:

生ログ

構造化ログ

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 で、収集されたログエントリ全体です。

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

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


3. ログフィルタリング

DEBUG レベルや INFO レベルのログなど、価値の低いまたは無関係なログを大量に収集すると、ストレージリソースを浪費し、コストを増加させ、クエリ効率に影響を与え、データ漏洩のリスクをもたらします。これに対処するため、効率的で安全なログ収集のために詳細なフィルタリングポリシーを実装します。

コンテンツフィルタリングによるコスト削減

ログのコンテンツに基づいてフィールドをフィルタリングします。たとえば、レベルが WARNING または ERROR のログのみを収集します。

例:

未処理の生ログ

WARNING または ERROR ログのみを収集

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

操作手順:[Logtail 構成] ページの [プロセッサー設定] セクションで

[プロセッサーの追加] をクリックし、[ネイティブプロセッサー] > [データフィルタリング] を選択します:

  • フィールド名:フィルタリングに使用するログフィールド。

  • フィールド値:フィルタリングに使用する正規表現。部分的なキーワードマッチではなく、完全一致のみがサポートされます。

ブラックリストによる収集範囲の制御

ブラックリストを使用して指定されたディレクトリやファイルを除外し、無関係または機密性の高いログがアップロードされるのを防ぎます。

操作手順:[Logtail 構成] ページの [入力設定] > [その他の入力設定] セクションで、[収集ブラックリスト] を有効にし、[追加] をクリックします。

ディレクトリとファイル名の完全一致およびワイルドカードマッチングをサポートします。サポートされているワイルドカード文字はアスタリスク (*) とクエスチョンマーク (?) のみです。
  • ファイルパスブラックリスト:除外するファイルパスを指定します。例:

    • /home/admin/private*.log/home/admin/ ディレクトリ内の private で始まり .log で終わるすべてのファイルを無視します。

    • /home/admin/private*/*_inner.log/home/admin/ ディレクトリ下の private で始まるディレクトリ内の _inner.log で終わるファイルを無視します。

  • ファイルブラックリスト:収集中に無視するファイル名のリスト。例:

    • app_inner.log:収集中に app_inner.log という名前のすべてのファイルを無視します。

  • ディレクトリブラックリスト:ディレクトリパスはスラッシュ (/) で終わることはできません。例:

    • /home/admin/dir1/:ディレクトリブラックリストは有効になりません。

    • /home/admin/dir*:収集中に /home/admin/ ディレクトリ下の dir で始まるすべてのサブディレクトリ内のファイルを無視します。

    • /home/admin/*/dir/home/admin/ ディレクトリの第 2 レベルにある dir という名前のサブディレクトリ内のすべてのファイルを無視します。例えば、/home/admin/a/dir ディレクトリ内のファイルは無視されますが、/home/admin/a/b/dir ディレクトリ内のファイルは収集されます。

4. ログの分類

/apps/app-A/run.log/apps/app-B/run.log のように、複数のアプリケーションやインスタンスからのログが同じフォーマットでパスが異なる場合、収集時にそのソースを区別するのは困難です。トピックを設定することで、異なるアプリケーション、サービス、またはパスからのログを論理的に区別できます。これにより、単一の Logstore 内で効率的な分類と正確なクエリが可能になります。

操作手順:[グローバル設定] > [その他のグローバル設定] > [ログトピックタイプ]:トピックを生成する方法を選択します。以下の 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

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

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

  • 全文インデックスはデフォルトで有効になっており、生ログコンテンツのキーワード検索をサポートします。

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

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

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

設定が完了したら、マシングループに適用して保存します。しばらく待ってから、以下のチェックリストを使用して検証します。

検証チェックリスト

  1. ログファイルに新しいコンテンツがあることを確認する:LoongCollector は増分ログのみを収集します。tail -f /path/to/your/log/file を実行し、ビジネス操作をトリガーして、新しいログが書き込まれていることを確認します。

  2. LoongCollector のステータスを確認するsudo /etc/init.d/loongcollectord status

  3. マシングループのハートビートを確認するimage[リソース] > [マシングループ] ページに移動します。対象のマシングループ名をクリックします。[マシングループ設定] > [マシングループステータス] セクションで、[ハートビート] ステータスを確認します。

  4. ログのクエリ:対象の Logstore のクエリと分析ページに移動します。[検索と分析] をクリックし (デフォルトの時間範囲は過去 15 分)、新しいログが流入しているか確認します。

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

マシングループのハートビートが FAIL になる

  1. ユーザー ID の確認:ご利用のサーバーが ECS インスタンスでない場合、または ECS インスタンスとプロジェクトが異なる Alibaba Cloud アカウントに属している場合は、指定されたディレクトリに正しいユーザー ID が存在するか確認してください。存在しない場合は、次のコマンドを実行して手動で作成します。

    • Linux:cd /etc/ilogtail/users/ && touch <uid> コマンドを実行してユーザー ID ファイルを作成します。

    • Windows:C:\LogtailData\users\ ディレクトリに移動し、<uid> という名前の空のファイルを作成します。

  2. マシングループ ID の確認:マシングループの作成時にカスタム ID を使用した場合は、指定されたディレクトリに user_defined_id ファイルが存在するか確認してください。存在する場合は、ファイルの内容がマシングループに設定されたカスタム ID と一致しているか確認します。

    • Linux:

      # カスタム ID を設定します。ディレクトリが存在しない場合は、手動で作成してください。
      echo "user-defined-1" > /etc/ilogtail/user_defined_id
    • Windows:C:\LogtailData ディレクトリに、user_defined_id という名前の新しいファイルを作成し、カスタム ID を書き込みます。(ディレクトリが存在しない場合は、手動で作成してください。)

  3. ユーザー ID とマシングループ ID の両方が正しく設定されている場合は、「LoongCollector (Logtail) のマシングループに関する問題のトラブルシューティング」を参照して、さらに調査してください。


データが収集されない

  1. 増分ログの確認:LoongCollector (Logtail) を収集用に設定した後、対象のログファイルに新しいログが追加されない場合、LoongCollector (Logtail) はそのファイルからデータを収集しません。

  2. マシングループのハートビートステータスの確認image[リソース] > [マシングループ] ページに移動します。対象のマシングループ名をクリックします。[マシングループ設定] > [マシングループステータス] セクションで、[ハートビート] ステータスを確認します。

  3. LoongCollector (Logtail) の収集設定がマシングループに適用されていることを確認する:LoongCollector (Logtail) の収集設定が作成されていても、マシングループに適用されていなければログは収集できません。

    1. image[リソース] > [マシングループ] ページに移動し、対象のマシングループ名をクリックして、[マシングループ設定] ページに移動します。

    2. ページで、[構成の管理] を表示します。左側には [すべての Logtail 構成] が表示され、右側には [適用済みの Logtail 構成] が表示されます。対象の LoongCollector (Logtail) 収集設定が右側の適用済みエリアに移動されている場合、設定は対象のマシングループに正常に適用されています。

    3. 対象の LoongCollector (Logtail) 収集設定が右側の適用済みエリアに移動されていない場合は、[変更] をクリックします。左側の [すべての Logtail 構成] リストで、対象の LoongCollector (Logtail) 構成名を選択し、image をクリックして右側の適用済みエリアに移動し、[保存] をクリックします。


ログ収集エラーまたはフォーマットエラー

トラブルシューティング:この状況は、ネットワーク接続と基本設定が正常であることを示します。問題は、ログの内容と解析ルールの不一致である可能性が高いです。問題の特定には、特定のエラーメッセージを確認する必要があります:

  1. [Logtail 構成] ページで、収集エラーのある LoongCollector (Logtail) 構成の名前をクリックします。[ログ収集エラー] タブで、[時間範囲の選択] をクリックしてクエリ時間を設定します。

  2. [収集例外モニタリング] > [完全なエラー情報] セクションで、エラーログのアラームメトリックを表示し、「データ収集における一般的なエラー」で対応するソリューションを見つけます。

制限事項

項目

制限事項

単一ログの長さ

デフォルトの制限は 512 KB です。max_read_buffer_size 起動パラメーターを使用して、最大 8 MB まで調整できます。詳細については、「Logtail のネットワークタイプ、起動パラメーター、および設定ファイル」をご参照ください。

複数行ログが先頭行の正規表現によって分割された後も、各ログのサイズ制限は 512 KB です。ログが 512 KB を超える場合、強制的に複数のエントリに分割されて収集されます。例えば、単一のログが 1,025 KB の場合、最初の 512 KB が処理され、次に次の 512 KB、最後に残りの 1 KB が処理されます。最終結果は複数の不完全なログエントリになります。

ファイルエンコーディング

UTF-8 または GBK エンコーディングのログファイルをサポートします。処理性能を向上させるには UTF-8 を使用してください。

警告

ログファイルが他のエンコード形式を使用している場合、文字化けやデータ損失などの問題が発生する可能性があります。

ログファイルのローテーション

ログローテーションキューのデフォルトサイズは 20 です。logreader_max_rotate_queue_size 起動パラメーターを使用して調整します。詳細については、「Logtail のネットワークタイプ、起動パラメーター、および設定ファイル」をご参照ください。

収集パスを xxx.log または xxx.log* 形式に設定します。

重要

同じ Logtail インスタンスでこれら 2 つの形式を混在させないでください。そうしないと、同じファイルが複数の Logtail 収集設定に一致し、重複収集が発生する可能性があります。

20 を超えるファイルが未処理の場合、新しく生成されたログは失われます。このような場合は、まず Logstore のシャード書き込みクォータを超えていないか確認し、Logtail の同時実行レベルを調整してください。詳細については、「Logtail のネットワークタイプ、起動パラメーター、および設定ファイル」をご参照ください。

ログ解析がブロックされた場合の収集動作

ログ解析がブロックされると、Logtail はそのログファイルのファイル記述子を開いたままにします。これにより、ブロック中にファイルが削除されてデータが失われるのを防ぎます。

解析がブロックされている間に複数のログファイルローテーションが発生した場合、Logtail はファイルをローテーションキューに配置します。

正規表現

Perl 互換正規表現 (PCRE) をサポートします。

JSON

標準 JSON (RFC7159, ECMA-404) を完全にサポートします。{"name": "\xE5\xAD\xA6"} のような非標準 JSON はサポートされていません。

ファイルオープン動作

Logtail は、データ整合性を確保するために、収集されたファイルとローテーションキュー内のファイルを開いたままにします。ファイルは次の状況で閉じられます:

  • ファイルが 5 分以上変更されていない。

  • ローテーションが発生し、収集が完了した。

  • Logtail 収集設定が変更された。

ファイルが完全に収集されたか、まだ書き込み中であるかに関わらず、ファイルが削除された後、制御可能な時間内にファイルハンドルを解放したい場合は、force_release_deleted_file_fd_timeout 起動パラメーターを使用してタイムアウトを設定します。詳細については、「Logtail のネットワークタイプ、起動パラメーター、および設定ファイル」をご参照ください。

初回ログ収集の動作

Logtail は増分ログファイルのみを収集します。ファイルが最初に変更されたと検出されたとき、そのサイズが 1 MB (コンテナ標準出力の場合は 512 KB) を超える場合、収集は最後の 1 MB から開始されます。それ以外の場合は、ファイルの先頭から開始されます。

Logtail 収集設定の tail_size_kb パラメーターを使用して、新しいファイルの初回収集サイズを調整します。詳細については、「Logtail 構成 (レガシー)」をご参照ください。

Logtail 収集設定が適用された後、ログファイルが変更されない場合、Logtail はそのファイルを収集しません。過去のファイルを収集するには、「過去のログファイルをインポートする」をご参照ください。

ファイルが上書きされたときの動作

Logtail は、inode とファイルの最初の 1,024 バイトのハッシュを使用してファイルを識別します。ファイルが上書きされ、inode または最初の 1,024 バイトのハッシュのいずれかが変更された場合、ファイルは新しいファイルとして扱われ、収集は最初から開始されます。それ以外の場合は、収集されません。

ファイルが移動されたときの動作

ファイルが移動された後、これまでこのファイルに一致したことのない Logtail 収集設定に一致する場合、移動されたドキュメントは新しいファイルとして扱われ、収集は最初から開始されます。それ以外の場合は、収集されません。

ファイル収集履歴

Logtail はファイル収集履歴をメモリに保持し、ファイルが変更された後に増分部分のみが収集されるようにします。保持範囲外のログに書き込みが発生した場合、重複収集が発生します。

  • デフォルトでは、過去 1 か月間の履歴ファイルが保持されます。

  • 同じディレクトリに 5,000 を超える履歴ファイルがある場合、過去 1 週間分のレコードのみが保持されます。

  • 同じディレクトリに 10,000 を超える履歴ファイルがある場合、過去 1 日分のレコードのみが保持されます。

非標準テキストログ

\0 を含むログの行については、バージョン 2.1.10 および 3.0.12 以降では、ログの中央にある \0 のみが保持されます。プレフィックスとサフィックスの \0 部分は破棄されます。他のバージョンでは、最初の \0 で切り捨てられるか、完全に保持される場合があります。アップグレードを推奨します。他のエスケープ文字 (ASCII カラーなど) や不可視文字については、Logtail はそのまま報告します。

課金

  • LoongCollector または Logtail のインストールは無料です。

  • ログの取り込み、ストレージ、インデックス、クエリ、変換、転送には、Logstore の課金モードに基づいて料金が発生します。

  • インストールまたは設定中に Global Accelerator 機能を使用する場合、アクセラレーションネットワークを介して送信されるデータに対して追加のトラフィック料金が発生します。

よくある質問

ECS サーバーから別の Alibaba Cloud アカウントのプロジェクトにログを送信するにはどうすればよいですか?

LoongCollector をインストールしていない場合は、「インストールと設定」を参照し、適切なクロスアカウントシナリオを選択してインストールしてください。

LoongCollector を既にインストールしている場合は、次の手順に従ってユーザー ID を設定します。この ID は、サーバーが SLS プロジェクトを所有するアカウントによってアクセスされ、そのログが収集される権限を持つことを示します。

非アカウントの ECS インスタンス、オンプレミスサーバー、または他のクラウドプロバイダーのサーバーからログを収集する場合にのみ、ユーザー ID を設定する必要があります。
  1. SLS を所有する Alibaba Cloud アカウントの ID をコピーします:右上隅のプロファイル画像にマウスを合わせます。表示されるタブからアカウント ID を表示してコピーします。

  2. ログを収集したいサーバーにログインし、Alibaba Cloud アカウント ID ファイルを作成してユーザー ID を設定します:

    touch /etc/ilogtail/users/{Alibaba_Cloud_account_ID} # /etc/ilogtail/users ディレクトリが存在しない場合は、手動で作成してください。ユーザー ID 設定ファイルはファイル名のみが必要で、ファイル拡張子は不要です。

ECS サーバーから同じアカウントの別のリージョンのプロジェクトにログを送信するにはどうすればよいですか?

LoongCollector をインストールしていない場合は、「インストールと設定」を参照し、適切なクロスリージョンシナリオを選択してインストールしてください。

LoongCollector を既にインストールしている場合は、LoongCollector の設定を変更する必要があります。

  1. sudo /etc/init.d/ilogtaild stop コマンドを実行して LoongCollector を停止します。

  2. LoongCollector の起動設定ファイル ilogtail_config.json を変更します。ネットワーク要件に応じて、次の 2 つの方法のいずれかを選択します:

    設定ファイルパス:/usr/local/ilogtail/ilogtail_config.json

    • 方法 1:インターネットを使用して転送する

      リージョン ID」を参照し、設定ファイル内のリージョンを SLS が配置されているリージョンに置き換えます。変更するフィールドは次のとおりです:

      • primary_region

      • config_servers のリージョン部分

      • data_servers 内の regionendpoint_list のリージョン部分

    • 方法 2:転送アクセラレーションを使用する

      data_server_list パラメーターのエンドポイント行を log-global.aliyuncs.com に置き換えます。ファイルパスについては、「Logtail のネットワークタイプ、起動パラメーター、および設定ファイル」をご参照ください。

    設定ファイルの例

    $cat 
    {
        "primary_region" : "cn-shanghai",
        "config_servers" :
        [
            "http://logtail.cn-shanghai.log.aliyuncs.com"
        ],
        "data_servers" :
        [
            {
                "region" : "cn-shanghai",
                "endpoint_list": [
                    "cn-shanghai.log.aliyuncs.com"
                ]
            }
        ],
        "cpu_usage_limit" : 0.4,
        "mem_usage_limit" : 384,
        "max_bytes_per_sec" : 20971520,
        "bytes_per_sec" : 1048576,
        "buffer_file_num" : 25,
        "buffer_file_size" : 20971520,
        "buffer_map_num" : 5
    }
  1. sudo /etc/init.d/ilogtaild start コマンドを実行して LoongCollector を起動します。

既存のマシングループにサーバーを追加するにはどうすればよいですか?

設定済みのマシングループがあり、新しくデプロイされた ECS インスタンスやオンプレミスサーバーなどの新しいサーバーを追加して、その収集設定を継承したい場合は、次の手順でバインドします。

前提条件:

操作手順:

  1. 対象のマシングループ ID を表示します:

    1. 対象のプロジェクトページで、左側のナビゲーションウィンドウで image[リソース] > [マシングループ] をクリックします。

    2. [マシングループ] ページで、対象のマシングループ名をクリックします。

    3. マシングループ設定ページで、マシングループ ID を表示します。

  2. ID の種類に基づいて対応する操作を実行します:

    説明

    1 つのマシングループに Linux サーバーと Windows サーバーの両方を含めることはできません。Linux サーバーと Windows サーバーの両方に同じカスタム ID を設定しないでください。1 つのサーバーに複数のカスタム ID を設定でき、改行で区切ります。

    • タイプ 1:マシングループ ID が IP アドレスの場合

      1. サーバーで、次のコマンドを実行して app_info.json ファイルを開き、ip の値を確認します。

        cat /usr/local/ilogtail/app_info.json
      2. 対象のマシングループ設定ページで、[変更] をクリックし、サーバーの IP アドレスを入力します。複数の IP アドレスは改行で区切ります。

      3. 設定が完了したら、[保存] をクリックし、ハートビートステータスを確認します。ハートビートが OK になった後、サーバーは自動的にマシングループの収集設定を適用します。

        ハートビートステータスが FAIL の場合は、よくある質問の「マシングループのハートビートが FAIL になる」を参照して、さらにトラブルシューティングを行ってください。
    • タイプ 2:マシングループ ID がカスタム ID の場合

      オペレーティングシステムに応じて、対象のマシングループに一致するカスタム ID 文字列を指定されたファイルに書き込みます:

      ディレクトリが存在しない場合は、手動で作成する必要があります。ファイルパスと名前は SLS によって固定されており、カスタマイズできません。
      • Linux:カスタム文字列を /etc/ilogtail/user_defined_id ファイルに書き込みます。

      • Windows:カスタム文字列を C:\LogtailData\user_defined_id に書き込みます。

別のプロジェクトから収集設定をインポートするにはどうすればよいですか?

事前準備マシングループ設定が完了したら、既存のプロジェクトから現在の Logstore に収集設定を迅速にインポートできます。これにより、繰り返しの設定を避け、効率を向上させることができます。

操作手順:

  1. マシングループ設定が完了したら、[次へ] をクリックして [Logtail 構成] ページに移動します。

  2. ページ右上の [他の構成をインポート] をクリックします。

  3. インポート元のプロジェクトとそのプロジェクト下の収集設定を選択します。

  4. [OK] をクリックします。システムは選択した設定を自動的に読み込みます。

  5. インポートされた設定情報が正しいことを確認した後、[次へ] をクリックして [クエリと分析の設定] ページに移動し、後続の設定を完了します。

マシングループ ID として使用するサーバーの IP アドレスを取得するにはどうすればよいですか?

LoongCollector (Logtail) がインストールされているサーバーで、/usr/local/ilogtail/app_info.json ファイルを開き、ip の値を確認します。

Logtail によって自動的に取得されたサーバーの IP アドレスは、以下に示すように app_info.json ファイルの ip フィールドに記録されます。IP地址

重要
  • 複数のサーバーがある場合は、対応する IP アドレスを手動で入力します。IP アドレスは改行で区切る必要があります。

  • 1 つのマシングループに Linux サーバーと Windows サーバーの両方を含めることはできません。同じマシングループに Windows サーバーと Linux サーバーの両方の IP アドレスを追加しないでください。

同じログファイルを複数の収集設定で同時に収集するにはどうすればよいですか?

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

操作手順:

重要

複数コピーを収集すると、ファイル読み取り IO、コンピューティングリソース、およびネットワーク IO が線形に増加します。

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

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

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

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

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

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

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

最後のログエントリが長い遅延の後に報告されるのはなぜですか?なぜ時々切り捨てられるのですか?

原因:ログの切り捨ては通常、ログファイルの末尾に改行がない場合や、例外スタックなどの複数行ログが完全に書き込まれていない場合に発生します。エージェントはログが終了したかどうかを判断できないため、コンテンツの最後の部分が時期尚早に分割されたり、遅れて報告されたりすることがあります。LoongCollector (Logtail) のバージョンによって処理メカニズムが異なります:

  • 1.8 より前のバージョン:
    ログの最後の行に改行 (キャリッジリターン) がない場合、または複数行のログ段落が終了していない場合、エージェントは次の書き込みを待って出力をトリガーします。これにより、最後のログエントリが新しいログが書き込まれるまで長時間送信されずに保持される可能性があります。

  • バージョン 1.8 以降:
    ログがスタックするのを防ぐために、タイムアウト更新メカニズムが導入されました。不完全なログ行が検出されると、システムはタイマーを開始します。タイムアウト後、現在のコンテンツを自動的に送信し、ログが最終的に収集されることを保証します。

    • デフォルトのタイムアウト:60 秒 (ほとんどのシナリオで完全性を確保するため)

    • 必要に応じてこの値を調整しますが、0 に設定しないでください。ログの切り捨てや部分的なコンテンツの損失を引き起こす可能性があります。

ソリューション:

待機時間を延長して、収集される前に完全なログが書き込まれるようにします:

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

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

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

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

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

    • [入力設定] > [その他の入力設定] > [高度なパラメーター] で、次の JSON 設定を追加してタイムアウトをカスタマイズします:

      {
        "FlushTimeoutSecs": 1
      }
      • デフォルト値:起動パラメーター default_reader_flush_timeout によって決定されます (通常は数秒)。

      • 単位:秒。

      • 推奨値:≥1 秒。0 に設定しないでください。ログの切り捨てや部分的なコンテンツの損失を引き起こす可能性があります。

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

LoongCollector (Logtail) が動作中に内部エンドポイントからインターネットに切り替わるのはなぜですか?自動的に元に戻せますか?

動作中、LoongCollector (Logtail) が内部の同一リージョンエンドポイントとの通信異常 (ネットワーク障害や接続タイムアウトなど) を検出した場合、システムは自動的にパブリックドメイン名に切り替えてデータを送信します。これにより、ログ収集の継続性と信頼性が確保され、ログのバックログや損失が防止されます。

  • LoongCollector:回復後、自動的に内部ネットワークに戻ります。

  • Logtail:自動的には戻りません。内部ネットワーク通信を再開するには、手動で再起動する必要があります。

付録:ネイティブプロセッサーの詳細

[Logtail 構成] ページの [プロセッサー設定] セクションで、プロセッサーを追加して生ログを構造化します。既存の収集設定に処理プラグインを追加するには、次の手順に従います:

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

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

  3. [Logtail 構成] をクリックします。構成リストで、対象の Logtail 構成を見つけ、[操作] 列の [Logtail 構成の管理] をクリックします。

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

このセクションでは、一般的なログ処理シナリオをカバーする、一般的に使用される処理プラグインのみを紹介します。その他の機能については、「拡張プロセッサー」をご参照ください。
重要

プラグインの組み合わせルール (LoongCollector / Logtail 2.0 以降):

  • ネイティブプロセッサーと拡張プロセッサーは、独立して使用することも、必要に応じて組み合わせることもできます。

  • ネイティブプロセッサーは、パフォーマンスと安定性が高いため、優先的に使用してください。

  • ネイティブ機能がビジネスニーズを満たせない場合は、設定済みのネイティブプロセッサーの後に拡張プロセッサーを追加して、補足的な処理を行います。

順序の制約:

すべてのプラグインは、設定された順序で順次実行され、処理チェーンを形成します。注意:すべてのネイティブプロセッサーは、どの拡張プロセッサーよりも前に配置する必要があります。拡張プロセッサーを追加した後は、さらにネイティブプロセッサーを追加することはできません。

正規表現解析

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

例:

未処理の生ログ

正規表現解析プラグインの使用

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 構成] ページの [プロセッサー設定] セクションで、[プロセッサーの追加] をクリックし、[ネイティブプロセッサー] > [データ解析 (正規表現モード)] を選択します:

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

    • 自動生成:

      • [生成] をクリックします。

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

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

        image

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

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

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

  • その他のパラメーターについては、「シナリオ 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 解析

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

例:

未処理の生ログ

標準 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 解析

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

例:

未処理の生ログ

展開深度:0、展開深度をプレフィックスとして使用

展開深度:1、展開深度をプレフィックスとして使用

{"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 展開後のフィールド名のプレフィックス。

  • 配列の展開:配列をインデックス付きのキーと値のペアに展開します。

    例:{"k":["a","b"]}{"k[0]":"a","k[1]":"b"} に展開されます。

    展開されたフィールドの名前を変更する (例:prefix_s_key_k1 を new_field_name に変更する) には、後で フィールド名変更プラグイン を追加してマッピングを完了します。
  • その他のパラメーターについては、「シナリオ 2:構造化ログ」の共通設定パラメーターの説明をご参照ください。


JSON 配列解析

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

例:

未処理の生ログ

JSON 配列構造の抽出

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

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

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

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

Apache ログ解析

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

例:

未処理の生ログ

Apache Common Log Format combined 解析

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 LogFormat 設定] は、[ログフォーマット] に基づいて自動的に入力されます。

    重要

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

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


IIS ログ解析

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

比較例:

生ログ

Microsoft 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 を選択すると、SLS はデフォルトの 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"}

image

操作手順:[Logtail 構成] ページの [プロセッサー設定] セクションで、[プロセッサーの追加] をクリックし、[ネイティブプロセッサー] > [時刻解析] を選択します:

  • 元のフィールド:解析前のログコンテンツを含むフィールド。

  • 時刻フォーマット:ログ内のタイムスタンプに対応する時刻フォーマットを設定します。

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

付録:権限ポリシーリファレンス

Alibaba Cloud アカウントでのログイン:デフォルトでは、Alibaba Cloud アカウントは完全な権限を持ち、すべての操作を実行できます。

RAM ユーザーでのログイン:Alibaba Cloud アカウントは、RAM ユーザーに必要なアクセスポリシーを付与する必要があります。

カスタム権限ポリシー (詳細な制御)

システムポリシーが最小権限の原則を満たさない場合は、詳細な権限付与のためにカスタムポリシーを作成します。以下は、これらの権限を含む権限ポリシーの例です:

  • プロジェクトの表示:プロジェクトリストと指定されたプロジェクトの詳細を表示します。

  • Logstore の管理:プロジェクト下の Logstore を作成、変更、または削除します。

  • 収集設定の管理:収集設定を作成、削除、変更します。

  • ログの表示:指定されたプロジェクト下の指定された Logstore のデータをクエリおよび分析します。

${regionName}${uid}${projectName}、および ${logstoreName} を実際のリージョン名、Alibaba Cloud アカウント ID、対象プロジェクト、および Logstore に置き換えてください。

ポリシーの例

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "log:ListProject",
        "log:GetAcceleration",
        "log:ListDomains",
        "log:GetLogging",
        "log:ListTagResources"
      ],
      "Resource": "acs:log:${regionName}:${uid}:project/*"
    },
    {
      "Effect": "Allow",
      "Action": "log:GetProject",
      "Resource": "acs:log:${regionName}:${uid}:project/${projectName}"
    },
    {
      "Effect": "Allow",
      "Action": [
        "log:ListLogStores",
        "log:*LogStore",
        "log:*Index",
        "log:ListShards",
        "log:GetCursorOrData",
        "log:GetLogStoreHistogram",
        "log:GetLogStoreContextLogs",
        "log:PostLogStoreLogs"
      ],
      "Resource": "acs:log:${regionName}:${uid}:project/${projectName}/*"
    },
    {
      "Effect": "Allow",
      "Action": "log:*",
      "Resource": [
        "acs:log:${regionName}:${uid}:project/${projectName}/logtailconfig/*",
        "acs:log:${regionName}:${uid}:project/${projectName}/machinegroup/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "log:ListSavedSearch",
      "Resource": "acs:log:${regionName}:${uid}:project/${projectName}/savedsearch/*"
    },
    {
      "Effect": "Allow",
      "Action": "log:ListDashboard",
      "Resource": "acs:log:${regionName}:${uid}:project/${projectName}/dashboard/*"
    },
    {
      "Effect": "Allow",
      "Action": "log:GetLogStoreLogs",
      "Resource": "acs:log:${regionName}:${uid}:project/${projectName}/logstore/${logstoreName}"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ecs:DescribeTagKeys",
        "ecs:DescribeTags",
        "ecs:DescribeInstances",
        "ecs:DescribeInvocationResults",
        "ecs:RunCommand",
        "ecs:DescribeInvocations",
        "ecs:InvokeCommand"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "oos:ListTemplates",
        "oos:StartExecution",
        "oos:ListExecutions",
        "oos:GetExecutionTemplate",
        "oos:ListExecutionLogs",
        "oos:ListTaskExecutions"
      ],
      "Resource": "*"
    }
  ]
}

権限

アクション

リソース

読み取り専用プロジェクト

  • GetAcceleration

  • GetLogging

  • ListProject

  • ListDomains

  • ListTagResources

acs:log:${regionName}:${uid}:project/*

指定されたプロジェクトの取得

GetProject

acs:log:${regionName}:${uid}:project/${projectName}

Logstore の管理

  • ListLogStores

  • *LogStore

  • *Index

  • ListShards

  • GetCursorOrData

  • GetLogStoreHistogram

  • GetLogStoreContextLogs

  • PostLogStoreLogs

acs:log:${regionName}:${uid}:project/${projectName}/*

LoongCollector (Logtail) データインポートの管理

*

  • acs:log:${regionName}:${uid}:project/${projectName}/logtailconfig/*

  • acs:log:${regionName}:${uid}:project/${projectName}/machinegroup/*

保存された検索のクエリ

ListSavedSearch

acs:log:${regionName}:${uid}:project/${projectName}/savedsearch/*

ダッシュボードのクエリ

ListDashboard

acs:log:${regionName}:${uid}:project/${projectName}/dashboard/*

指定された Logstore のログのクエリ

GetLogStoreLogs

acs:log:${regionName}:${uid}:project/${projectName}/logstore/${logstoreName}

ECS を操作する権限

  • DescribeTagKeys

  • DescribeTags

  • DescribeInstances

  • DescribeInvocationResults

  • RunCommand

  • DescribeInvocations

  • InvokeCommand

*

OOS を操作する権限 (任意)

SLS および ECS インスタンスと同じアカウントおよびリージョンで OOS を介して LoongCollector (Logtail) が自動的にインストールされる場合にのみ必要です。

  • ListTemplates

  • StartExecution

  • ListExecutions

  • GetExecutionTemplate

  • ListExecutionLogs

  • ListTaskExecutions

*

システム権限ポリシー

システム定義のポリシーを使用する場合は、次の権限を追加することを推奨します:

  • AliyunLogFullAccess:SLS を管理する権限。

  • AliyunECSFullAccess:ECS を管理する権限。

  • (任意) AliyunOOSFullAccess:OOS を使用してワンクリックで LoongCollector (Logtail) をインストールする場合に必要です。

関連情報

グローバル設定

パラメーター

説明

構成名

LoongCollector (Logtail) 構成の名前。プロジェクト内で一意である必要があります。作成後に名前を変更することはできません。

ログトピックタイプ

トピックの生成方法を選択します。オプションは、マシングループトピック、ファイルパス抽出、およびカスタムです。

高度なパラメーター

グローバル設定に関連するその他のオプションの高度な機能パラメーター。詳細については、「CreateLogtailPipelineConfig」をご参照ください。

入力設定

パラメーター

説明

ファイルパス

ホスト (ECS インスタンスなど) 上のログの場所に基づいて、ログディレクトリとファイル名を設定します:

ディレクトリとファイル名の両方が、完全モードとワイルドカードモードをサポートしています。ファイル名のルールについては、「ワイルドカードマッチング」をご参照ください。ログパスでサポートされているワイルドカード文字は、アスタリスク (*) とクエスチョンマーク (?) のみです。

ログファイルの検索モードは多層ディレクトリマッチングであり、指定されたディレクトリ (すべてのレベルのサブディレクトリを含む) 内の基準を満たすすべてのファイルが見つかります。例:

  • /apsara/nuwa/**/*.log は、/apsara/nuwa ディレクトリとそのサブディレクトリにある .log 拡張子を持つファイルを示します。

  • /var/logs/app_*/**/*.log は、/var/logs ディレクトリとそのサブディレクトリの下にある app_* 形式に一致するすべてのディレクトリ内の .log 拡張子を持つファイルを示します。

  • /var/log/nginx/**/access* は、/var/log/nginx ディレクトリとそのサブディレクトリにある access で始まるファイルを示します。

最大ディレクトリ監視深度

ログディレクトリが監視される最大深度を設定します。これは、[ファイルパス] のワイルドカード文字 ** が一致できる最大のディレクトリ深度です。値が 0 の場合は、現在のディレクトリのみが監視されます。

ファイルエンコーディング

ログファイルのエンコード形式を選択します。

初回収集サイズ

設定が最初に有効になったとき、これは一致したファイルの末尾からの収集開始位置を設定します。初回収集サイズは 1,024 KB に設定されています。

  • 初回収集時、ファイルが 1,024 KB 未満の場合、収集はファイルコンテンツの先頭から開始されます。

  • 初回収集時、ファイルが 1,024 KB を超える場合、収集はファイルの末尾から 1,024 KB 手前から開始されます。

値の範囲は 0 から 10,485,760 KB です。

収集ブラックリスト

[収集ブラックリスト] スイッチを有効にした後、ブラックリストを設定して、収集中に指定されたディレクトリまたはファイルを無視します。ディレクトリとファイル名の完全一致およびワイルドカードマッチングがサポートされています。サポートされているワイルドカード文字は、アスタリスク (*) とクエスチョンマーク (?) のみです。

重要
  • [ファイルパス] を設定する際にワイルドカード文字を使用し、それらのパスの一部をフィルタリングする必要がある場合は、ブラックリスト設定が有効になるように、[収集ブラックリスト] に対応する完全なパスを入力する必要があります。

    例えば、[ファイルパス]/home/admin/app*/log/*.log に設定したが、/home/admin/app1* ディレクトリ下のすべてのサブディレクトリをフィルタリングしたい場合は、[ディレクトリブラックリスト] を選択し、ディレクトリを /home/admin/app1*/** として設定する必要があります。/home/admin/app1* として設定した場合、ブラックリストは有効になりません。

  • ブラックリストとの照合には計算オーバーヘッドがあります。ブラックリストのエントリ数は 10 未満にしてください。

  • ディレクトリパスはスラッシュ (/) で終わることはできません。例えば、パスを /home/admin/dir1/ に設定した場合、ディレクトリブラックリストは有効になりません。

必要に応じて、ファイルパスブラックリスト、ファイルブラックリスト、またはディレクトリブラックリストを設定します。詳細は次のとおりです:

ファイルパスブラックリスト

  • [ファイルパスブラックリスト] を選択し、パスを /home/admin/private*.log として設定します。これにより、/home/admin/ ディレクトリ内の private で始まり .log で終わるすべてのファイルが無視されます。

  • [ファイルパスブラックリスト] を選択し、パスを /home/admin/private*/*_inner.log として設定します。これにより、/home/admin/ ディレクトリ下の private で始まるディレクトリ内の _inner.log で終わるファイルが無視されます。例えば、/home/admin/private/app_inner.log ファイルは無視され、/home/admin/private/app.log ファイルは収集されます。

ファイルブラックリスト

[ファイルブラックリスト] を選択し、ファイル名を app_inner.log として設定します。これにより、収集中に app_inner.log という名前のすべてのファイルが無視されます。

ディレクトリブラックリスト

  • [ディレクトリブラックリスト] を選択し、ディレクトリを /home/admin/dir1 として設定します。これにより、収集中に /home/admin/dir1 ディレクトリ内のすべてのファイルが無視されます。

  • [ディレクトリブラックリスト] を選択し、ディレクトリを /home/admin/dir* として設定します。これにより、/home/admin/ ディレクトリ下の dir で始まるすべてのサブディレクトリ内のファイルが無視されます。

  • [ディレクトリブラックリスト] を選択し、ディレクトリを /home/admin/*/dir として設定します。これにより、/home/admin/ ディレクトリの第 2 レベルにある dir という名前のサブディレクトリ内のすべてのファイルが無視されます。例えば、/home/admin/a/dir ディレクトリ内のファイルは無視されますが、/home/admin/a/b/dir ディレクトリ内のファイルは収集されます。

ファイルの複数回収集を許可

デフォルトでは、ログファイルは 1 つの LoongCollector (Logtail) 設定にしか一致できません。ファイル内のログを複数回収集する必要がある場合は、[ファイルの複数回収集を許可] スイッチを有効にする必要があります。

高度なパラメーター

ファイル入力プラグインに関連するその他のオプションの高度な機能パラメーター。詳細については、「CreateLogtailPipelineConfig」をご参照ください。

プロセッサー設定

パラメーター

説明

ログサンプル

収集するログのサンプル。実際のシナリオのログを必ず使用してください。ログサンプルは、ログ処理パラメーターの設定に役立ち、設定を簡素化します。複数のサンプルを追加でき、合計長は 1,500 文字を超えないようにしてください。

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

複数行モード

  • 複数行ログのタイプ:複数行ログとは、各エントリが連続した行に分散しているログのことです。各ログをコンテンツから区別する必要があります。

    • カスタム[先頭行の正規表現] を使用して各ログを区別します。

    • 複数行 JSON:各 JSON オブジェクトが複数行に展開されます。例:

      {
        "name": "John Doe",
        "age": 30,
        "address": {
          "city": "New York",
          "country": "USA"
        }
      }
  • 分割失敗時の処理方法:

    Exception in thread "main" java.lang.NullPointerException
        at com.example.MyClass.methodA(MyClass.java:12)
        at com.example.MyClass.methodB(MyClass.java:34)
        at com.example.MyClass.main(MyClass.java:½0)

    上記のログコンテンツについて、SLS が分割に失敗した場合:

    • 破棄:このログセグメントを直接破棄します。

    • 単一行を保持:ログテキストの各行を個別のログとして保持し、合計 4 つのログになります。

処理方法

[プロセッサー] には、[ネイティブプロセッサー][拡張プロセッサー] が含まれます。処理プラグインの詳細については、「ネイティブプロセッサーと拡張プロセッサーの使用上の注意」をご参照ください。

重要

処理プラグインの使用に関する制限は、コンソールページのプロンプトに従います。

  • Logtail 2.0:

    • ネイティブプロセッサーは任意の方法で組み合わせることができます。

    • ネイティブプロセッサーと拡張プロセッサーは同時に使用できますが、拡張プロセッサーはすべてのネイティブプロセッサーの後にのみ表示されます。

  • Logtail 2.0 より前のバージョン:

    • ネイティブプロセッサーと拡張プロセッサーを同時に追加することはサポートされていません。

    • ネイティブプロセッサーはテキストログの収集にのみ使用できます。ネイティブプロセッサーを使用する場合、次の要件を満たす必要があります:

      • 最初の処理プラグインは、正規表現解析プラグイン、区切り文字モード解析プラグイン、JSON 解析プラグイン、データ解析 (NGINX モード) プラグイン、Apache パターン解析プラグイン、または IIS パターン解析プラグインである必要があります。

      • 2 番目から最後の処理プラグインまで、最大で 1 つの時刻解析プラグイン、1 つのデータフィルタリングプラグイン、および複数のマスキングプラグインを含めることができます。

    • [解析失敗時に元のフィールドを保持] および [解析成功時に元のフィールドを保持] パラメーターについては、次の組み合わせのみが有効です。他の組み合わせは無効です。

      • 正常に解析されたログのみをアップロード:

        image

      • 成功時には解析されたログをアップロードし、失敗時には生ログをアップロード:

        image

      • 解析に成功した場合、解析されたログをアップロードし、生ログフィールドも追加します。失敗した場合は、生ログをアップロードします。

        例えば、生ログ "content": "{"request_method":"GET", "request_time":"200"}" が正常に解析された場合、生フィールドを追加すると、解析されたログに別のフィールドが追加されます。フィールド名は [元のフィールドの新しい名前] (入力されていない場合は、ソースフィールド名がデフォルトになります) で、フィールド値は生ログ {"request_method":"GET", "request_time":"200"} です。

        image