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

Simple Log Service:サーバーからテキストログを収集するために Logtail を自動的にインストールする

最終更新日:Jun 10, 2025

このトピックでは、オペレーションオーケストレーションサービス (OOS) に基づいて、Elastic Compute Service (ECS) インスタンスからテキストログを収集するために Logtail を自動的にインストールする方法について説明します。 ECS インスタンスと Simple Log Service プロジェクトは、同じ Alibaba Cloud アカウントに属し、同じリージョンに存在する必要があります。

制限事項

  • 以下のシナリオでは、サーバーからテキストログを収集するために Logtail を手動でインストールできます。ECS インスタンスと Simple Log Service プロジェクトは同じ Alibaba Cloud アカウントに属していますが、異なるリージョンに存在します。また、ECS インスタンスと Simple Log Service プロジェクトは異なる Alibaba Cloud アカウントに属しています。他のクラウドやセルフマネージドサーバーを含むシナリオも含まれます。詳細については、「サーバーからテキストログを収集するために Logtail を手動でインストールする」をご参照ください。

  • このトピックでは、1 つの Logtail 構成を使用してログファイルからログを収集する方法について説明します。複数の Logtail 構成を使用してログファイルからログを収集する場合は、このトピックの操作を実行してから、「ファイル内のログの複数のコピーを収集するにはどうすればよいですか?」に記載されている手順に従ってください。

  • デフォルトでは、Logtail は増分ログを収集します。履歴ログを収集することもできます。詳細については、「ログファイルから履歴ログをインポートする」をご参照ください。

前提条件

ステップ 1: Logtail をインストールし、マシングループを作成する

  1. Simple Log Service プロジェクトの作成に使用した Alibaba Cloud アカウントを使用して、Simple Log Service コンソール にログオンします。 [プロジェクト] セクションで、作成したプロジェクトをクリックします。image

  2. 表示されるページの左側のナビゲーションウィンドウで、[ログストレージ] をクリックします。管理するログストアをクリックし、[データ収集] の左側にあるドロップダウン矢印をクリックして、[Logtail 構成] をクリックします。 [Logtail 構成] ページで、[Logtail 構成を追加] をクリックします。 [クイックデータインポート] ダイアログボックスで、[正規表現 - テキストログ] を見つけて、[今すぐ統合] をクリックします。

    この例では、Logtail は完全な正規表現モードでテキストログを収集します。 Logtail を使用して、他のモードでテキストログを収集することもできます。詳細については、「」をご参照ください。image

  3. データインポートウィザードの [マシングループの構成] ステップで、[シナリオ] パラメーターを [サーバー] に、[インストール環境] パラメーターを [ECS] に設定します。次に、[マシングループを作成] をクリックします。 [マシングループを作成] パネルで、Simple Log Service プロジェクトと同じリージョンにある ECS インスタンスを選択し、[インストールしてマシングループを作成] をクリックします。image

  4. Logtail がインストールされた後、[マシングループの構成] セクションの [名前] パラメーターを構成し、[OK] をクリックします。image

  5. [次へ] をクリックします。 [ハートビート] 列の値が FAIL の場合は、[自動再試行] をクリックし、値が OK になるまで約 2 分待ちます。次に、[次へ] をクリックします。デフォルトでは、システムが Logtail を自動的にインストールすると、IP アドレスベースのマシングループが作成されます。 IP アドレスベースのマシングループをカスタム識別子ベースに変更する場合は、「マシングループを管理する」をご参照ください。image

ステップ 2: Logtail 構成を作成する

  1. [グローバル構成] セクションで、[構成名] パラメーターを構成します。

    image

  2. [入力構成] セクションで、[ファイルパス] パラメーターを構成します。 [ファイルパス] パラメーターは、収集するログを格納するために使用されるディレクトリを指定します。ファイルパスはスラッシュ (/) で始まる必要があります。この例では、[ファイルパス] パラメーターは /data/wwwlogs/main/**/*.Log に設定されています。これは、/data/wwwlogs/main ディレクトリにある .Log で終わるファイルからログが収集されることを示しています。 [最大ディレクトリ監視深度] パラメーターを構成して、監視するサブディレクトリの最大レベル数を指定できます。サブディレクトリは、指定したログファイルディレクトリにあります。このパラメーターは、[ファイルパス] パラメーターの値で ** ワイルドカード文字が一致できるサブディレクトリのレベルを指定します。値 0 は、指定されたログファイルディレクトリのみが監視されることを指定します。

    image

  3. [プロセッサ構成] セクションで、ログサンプル複数行モード、および 処理方法 パラメーターを構成します。image

    1. ログサンプル: [ログサンプル] フィールドに、実際のシナリオから収集されたサンプルログを入力します。サンプルログを使用すると、ログ処理関連のパラメーターを簡単に構成できます。

    2. 複数行モード: ビジネス要件に基づいて、複数行モードをオンにします。複数行ログは、複数の連続した行にまたがっています。複数行モードをオフにすると、Simple Log Service は単一行モードでログを収集します。各ログは 1 行に配置されます。複数行モードをオンにする場合は、次のパラメーターを構成する必要があります。

      • タイプ:

        • カスタム: 生データの形式が固定されていない場合は、[最初の行と一致する正規表現] パラメーターを構成して、ログの最初の行の先頭と一致します。 [最初の行と一致する正規表現] パラメーターを \[\d+-\d+-\w+:\d+:\d+,\d+]\s\[\w+]\s.* に設定すると、次のサンプルコードの生データは 2 つのログに分割されます。 [最初の行と一致する正規表現] パラメーターの値は、データの行全体と一致する必要があることに注意してください。

          [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)
          [2023-10-01T10:31:01,000] [INFO] java.lang.Exception: exception happened
        • 複数行 JSON: 生データが標準 JSON 形式の場合は、[タイプ] パラメーターを [複数行 JSON] に設定します。 Logtail は、JSON 形式のログ内で発生する改行を自動的に処理します。

      • 分割に失敗した場合の処理方法

        • 破棄: テキストを破棄します。

        • 単一行を保持: テキストの各行をログとして保存します。

    3. プロセッサ: [処理方法] パラメーターを [プロセッサ] に設定します。ログを分割するように処理プラグインが構成されています。この例では、Logtail は完全な正規表現モードでテキストログを収集し、データ解析 (正規表現モード) 処理プラグインが自動的に生成されます。ビジネス要件に基づいて他の処理プラグインを使用できます。

      次のセクションでは、一般的な処理プラグインの設定について説明します。時間解析、データフィルタリング、データマスキングなどの処理プラグインの機能の詳細については、「データ処理用の Logtail プラグインの概要」をご参照ください。 Simple Log Service は、Simple Log Service 処理言語 (SPL) ベースのデータ処理も提供します。 SPL ベースのデータ処理は、従来の処理プラグインの処理機能を備えていますが、より効率的です。詳細については、「Logtail SPL を使用してログを解析する」をご参照ください。

      データ解析 (正規表現モード) プラグイン

      プラグインの詳細については、「ネイティブプラグイン: データ解析 (正規表現モード)」をご参照ください。

      1. [プロセッサタイプ] ドロップダウンリストから [データ解析 (正規表現モード)] を選択して、プラグインの詳細構成ページに移動します。image

      2. ページで、[正規表現] パラメーターを構成し、抽出された値に基づいてキーを指定します。 [正規表現] フィールドの下にある [生成] をクリックし、次の図に基づいてサンプルログで特定のコンテンツを選択して、表示されるポップオーバーで [正規表現の生成] をクリックします。次に、Simple Log Service は、選択されたコンテンツの正規表現を自動的に生成します。

        image

      3. 正規表現が生成された後、[抽出されたフィールド] パラメーターで、抽出された値に基づいてキーを指定します。キーと値のペアを使用して、インデックスを作成できます。設定が完了したら、[OK] をクリックします。次に、[次へ] をクリックします。

        image

      データ解析 (JSON モード) プラグイン

      重要

      収集された JSON ログを処理する場合は、データ解析 (JSON モード) プラグインを追加できます。

      JSON ログは、オブジェクトまたは配列構造で記述できます。オブジェクト構造のログにはキーと値のペアが含まれ、配列構造のログには値の順序付きリストが含まれます。データ解析 (JSON モード) プラグインを使用して、オブジェクトタイプの JSON ログを解析し、各オブジェクトの最初のレイヤーからキーと値のペアを抽出できます。抽出されたキーはフィールド名として使用され、抽出された値はフィールド値として使用されます。データ解析 (JSON モード) プラグインを使用して、配列タイプの JSON ログを解析することはできません。きめ細かくデータを解析するには、「拡張プラグイン: JSON フィールドを展開する」をご参照ください。

      プラグインの詳細については、「ネイティブプラグイン: データ解析 (JSON モード)」をご参照ください。

      ビジネス要件に基づいて、複数行モードをオンにします。複数行モードをオンにする場合は、次のパラメーターを構成する必要があります。

      • [タイプ]: パラメーターを [複数行 JSON] に設定します。

      • [分割に失敗した場合の処理方法]: パラメーターを [単一行を保持] に設定します。

      image

      [処理方法] リストからデータ解析 (正規表現モード) プラグインを削除します。データ解析 (JSON モード) プラグインを追加します。image.png次のパラメーターを構成し、[OK] をクリックします。次に、[次へ] をクリックします。

      パラメーター

      説明

      [元のフィールド]

      解析前のログコンテンツを格納します。デフォルト値: content。

      [解析に失敗した場合に元のフィールドを保持]

      生ログの解析に失敗した後に取得された新しいログに元のフィールドを保持するかどうかを指定します。

      [解析に成功した場合に元のフィールドを保持]

      解析後に取得された新しいログに元のフィールドを保持するかどうかを指定します。

      [元のフィールドの新しい名前]

      保持する元のフィールドの新しい名前。 [解析に失敗した場合に元のフィールドを保持] または [解析に成功した場合に元のフィールドを保持] を選択した場合は、元のログコンテンツを格納する元のフィールドの名前を変更できます。

      データ解析 (デリミタモード) プラグイン

      説明

      データ解析 (デリミタモード) プラグインを使用して、デリミタを使用してログを構造化データに解析できます。この場合、ログは複数のキーと値のペアに解析されます。

      プラグインの詳細については、「ネイティブプラグイン: データ解析 (デリミタモード)」をご参照ください。

      [処理方法] リストからデータ解析 (正規表現モード) プラグインを削除し、データ解析 (デリミタモード) プラグインを追加します。image

      次の表に、データ解析 (デリミタモード) プラグインを追加するために構成する必要があるパラメーターを示します。設定が完了したら、[OK] をクリックします。次に、[次へ] をクリックします。

      パラメーター

      説明

      元のフィールド

      解析前のログコンテンツを格納する元のフィールド。デフォルト値:content。

      区切り文字

      デリミタ。実際のログの内容に基づいてデリミタを選択します。たとえば、[垂直バー] (|) を選択できます。

      説明

      [デリミタ] パラメータを [印刷不可能な文字] に設定した場合、0x<16進数の ASCII コード> の形式で文字を入力する必要があります。たとえば、16進数の ASCII コードが 01 の印刷不可能な文字を使用する場合、[0x01] と入力する必要があります。

      [見積もり]

      引用符。ログフィールドに区切り文字が含まれている場合、フィールドを囲む引用符を指定する必要があります。Simple Log Service は、一対の引用符で囲まれた内容を完全なフィールドとして解析します。収集したいログの形式に基づいて引用符を選択してください。

      説明

      非印字文字0x<印字不能文字の 16 進 ASCII コード>0x01 パラメーターを指定した場合、 の形式で文字を入力する必要があります。たとえば、16 進 ASCII コードが 01 の印刷不可文字を使用する場合、 と入力する必要があります。

      抽出フィールド

      • サンプルログを指定した場合、Simple Log Service は、指定されたサンプルログとデリミタに基づいてログコンテンツを自動的に抽出できます。各 Value パラメーターの Key パラメーターを設定します。Key パラメーターはフィールド名を指定します。Value パラメーターは抽出されたコンテンツを指定します。

      • サンプルログを指定しない場合、Value 列は使用できません。実際のログとデリミタに基づいてキーを指定する必要があります。

      キーには、英字、数字、およびアンダースコア(_)のみを含めることができ、英字またはアンダースコア(_)で始める必要があります。キーの長さは最大 128 バイトです。

      欠落フィールドを許可

      抽出された値の数が指定されたキーの数よりも少ない場合に、Simple Log Service にログをアップロードするかどうかを指定します。[欠落フィールドを許可] パラメーターを選択すると、ログは Simple Log Service にアップロードされます。

      この例では、ログは 11|22|33|44 で、デリミターパラメーターは縦棒(|)に設定され、キーは ABCD、および E に設定されています。

      • E フィールドの値は空です。[欠落フィールドを許可] パラメーターを選択すると、ログは Simple Log Service にアップロードされます。

      • [欠落フィールドを許可] パラメーターを選択しない場合、ログは破棄されます。

        説明

        Linux Logtail V1.0.28 以降、または Windows Logtail V1.0.28.0 以降を使用している場合は、デリミターモードでログを収集するときに [欠落フィールドを許可] パラメーターを設定できます。

      超過部分が割り当てられるフィールドの処理方法

      抽出された値の数が指定されたキーの数を超えた場合に、抽出された超過値を処理するために使用されるメソッド。有効な値:

      • 展開:超過値を保持し、__column$i__ 形式のフィールドに値を追加します。$i は、超過フィールドのシーケンス番号を指定します。シーケンス番号は 0 から始まります。例:__column0__ および __column1__

      • 保持:超過値を保持し、__column0__ フィールドに値を追加します。

      • 破棄:超過値を破棄します。

      [元のフィールドを保持 (解析失敗時)]

      生のログの解析に失敗した場合に、新しいログで元のフィールドを保持するかどうかを指定します。

      [元のフィールドを解析成功時に保持]

      解析後に取得される新しいログに元のフィールドを保持するかどうかを指定します。

      元のフィールドの新しい名前

      保持する元のフィールドの新しい名前です。[パースに失敗した場合、元のフィールドを保持する] または [パースに成功した場合、元のフィールドを保持する] を選択した場合、元のログコンテンツを格納する元のフィールドの名前を変更できます。

      データ解析 (Apache モード) プラグイン

      説明

      データ解析 (Apache モード) プラグインを使用して、Apache 構成ファイルで指定したログ フォーマットに基づいて、Apache ログを構造化データに解析できます。この場合、ログは複数のキーと値のペアに解析されます。

      プラグインの詳細については、「ネイティブ プラグイン: データ解析 (Apache モード)」をご参照ください。

      手順

      image 処理方法リストからデータ解析 (正規表現モード) プラグインを削除し、データ解析 (Apache モード) プラグインを追加します。

      次の表に、データ解析 (Apache モード) プラグインを追加するために構成する必要があるパラメーターを示します。設定が完了したら、[OK] をクリックします。次に、[次へ] をクリックします。

      パラメーター

      説明

      [ログ フォーマット]

      Apache 構成ファイルで指定するログ フォーマット。有効な値: common、combined、および Custom。

      [APACHE LogFormat 構成]

      Apache 構成ファイルで指定するログ構成セクション。ほとんどの場合、ログ構成セクションは LogFormat で始まります。

      • [ログ フォーマット] パラメーターを [common] または [combined] に設定すると、システムはこのフィールドに自動的に値を割り当てます。値が Apache 構成ファイルで指定した値と同じであることを確認してください。

      • [ログ フォーマット] パラメーターを [Custom] に設定した場合は、ビジネス要件に基づいて値を指定します。たとえば、LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D %f %k %p %q %R %T %I %O" customized と入力できます。

      [元のフィールド]

      解析前のログ コンテンツを格納する元のフィールド。デフォルト値: content。

      [正規表現]

      Apache ログの抽出に使用される正規表現。Simple Log Service は、[APACHE LogFormat 構成] フィールドの値に基づいて正規表現を自動的に生成します。

      [抽出されたフィールド]

      [APACHE LogFormat 構成] フィールドの値に基づいて自動的に抽出されるキー。

      [解析に失敗した場合、元のフィールドを保持する]

      生のログの解析に失敗した場合に、新しいログに元のフィールドを保持するかどうかを指定します。

      [解析に成功した場合、元のフィールドを保持する]

      解析後に取得された新しいログに元のフィールドを保持するかどうかを指定します。

      [元のフィールドの新しい名前]

      保持する元のフィールドの新しい名前。[解析に失敗した場合、元のフィールドを保持する] または [解析に成功した場合、元のフィールドを保持する] を選択した場合は、元のログ コンテンツを格納する元のフィールドの名前を変更できます。

      データ解析(NGINX モード)プラグイン

      説明

      データ解析(NGINX モード)プラグインを使用して、log_format に基づいて NGINX ログを構造化データに解析できます。この場合、ログは複数のキーと値のペアに解析されます。

      プラグインの詳細については、「ネイティブプラグイン: データ解析(NGINX モード)」をご参照ください。

      処理方法リストからデータ解析(正規表現モード)プラグインを削除し、データ解析(NGINX モード)プラグインを追加します。image次の表に、データ解析(NGINX モード)プラグインを追加するために構成する必要があるパラメーターを示します。設定が完了したら、[OK] をクリックします。次に、[次へ] をクリックします。

      パラメーター

      説明

      NGINX ログ設定

      NGINX 設定ファイルで指定するログ設定セクション。ログ設定セクションは 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"';

      詳細については、「NGINX ログの概要」をご参照ください。

      元のフィールド

      解析前のログコンテンツを格納する元のフィールド。デフォルト値:content。

      正規表現

      NGINX ログの抽出に使用する正規表現。Simple Log Service は、NGINX ログ設定 フィールドの値に基づいて正規表現を自動的に生成します。

      抽出されたフィールド

      NGINX ログ設定 フィールドの値に基づいて自動的に抽出されるキー。

      解析に失敗した場合、元のフィールドを保持する

      生のログの解析に失敗した場合に、新しいログに元のフィールドを保持するかどうかを指定します。

      解析に成功した場合、元のフィールドを保持する

      解析後に取得された新しいログに元のフィールドを保持するかどうかを指定します。

      元のフィールドの新しい名前

      保持する元のフィールドの新しい名前。解析に失敗した場合、元のフィールドを保持する または 解析に成功した場合、元のフィールドを保持する を選択した場合、元のログコンテンツを格納する元のフィールドの名前を変更できます。

      データ解析 (IIS モード) プラグイン

      説明

      データ解析 (IIS モード) プラグインを使用して、指定したログ形式に基づいてインターネットインフォメーションサービス (IIS) ログを構造化データに解析できます。この場合、ログは複数のキーと値のペアに解析されます。

      プラグインの詳細については、「ネイティブプラグイン: データ解析 (IIS モード)」をご参照ください。

      処理方法リストからデータ解析 (正規表現モード) プラグインを削除し、データ解析 (IIS モード) プラグインを追加します。image

      次の表は、データ解析 (IIS モード) プラグインを追加するために構成する必要があるパラメーターについて説明しています。設定が完了したら、[OK] をクリックします。次に、[次へ] をクリックします。

      パラメーター

      説明

      [ログ形式]

      IIS サーバーで生成されるログの形式。有効な値:

      • IIS: Microsoft IIS ログファイル形式

      • NCSA: NCSA 共通ログファイル形式

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

      [IIS 構成フィールド]

      IIS 構成フィールド。

      • [ログ形式] パラメーターを IIS または NCSA に設定すると、システムは自動的に 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"
        • IIS5 構成ファイルのデフォルトパス: C:\WINNT\system32\inetsrv\MetaBase.bin

        • IIS6 構成ファイルのデフォルトパス: C:\WINDOWS\system32\inetsrv\MetaBase.xml

        • IIS7 構成ファイルのデフォルトパス: C:\Windows\System32\inetsrv\config\applicationHost.config

      [元のフィールド]

      解析前のログコンテンツを格納する元のフィールド。デフォルト値: content。

      [正規表現]

      IIS ログの抽出に使用する正規表現。Simple Log Service は、[IIS 構成フィールド] フィールドの値に基づいて、正規表現を自動的に生成します。

      [抽出されたフィールド]

      [IIS 構成フィールド] フィールドの値に基づいて自動的に抽出されるキー。

      [解析に失敗した場合、元のフィールドを保持する]

      生のログの解析に失敗した場合に、取得した新しいログに元のフィールドを保持するかどうかを指定します。

      [解析に成功した場合、元のフィールドを保持する]

      解析後に取得した新しいログに元のフィールドを保持するかどうかを指定します。

      [元のフィールドの新しい名前]

      保持する元のフィールドの新しい名前。[解析に失敗した場合、元のフィールドを保持する] または [解析に成功した場合、元のフィールドを保持する] を選択した場合、元のログコンテンツを格納する元のフィールドの名前を変更できます。

      SPL ベースのデータ処理

      Simple Log Service は、カスタム SPL ベースのデータ処理も提供します。従来の処理プラグインと比較して、SPL ベースのデータ処理は、処理速度が速く、処理効率が高く、よりインテリジェントで使いやすくなっています。その結果、SPL ベースのデータ処理は、Simple Log Service の全体的な機能を大幅に向上させます。特定の SPL 文と Simple Log Service の計算機能に基づいてデータを処理できます。

  4. データクエリと分析を構成する

    Logtail 構成の作成には約 1 分かかります。Logstore の Logtail 構成を初めて作成し、特定の条件が満たされた場合、Logtail 構成が作成されます。条件には次のものがあります。[自動リフレッシュ] が完了している。指定されたログファイルディレクトリに増分ログが存在する。データのプレビューが可能である。Logtail 構成が作成された後、[次へ] をクリックします。Logtail 構成関連の設定は完了です。

    デフォルトでは、Simple Log Service でフルテキストインデックスが有効になっています。この場合、フルテキストインデックスが作成されます。インデックスに基づいてログ内のすべてのフィールドをクエリできます。収集されたログに基づいて、フィールドのインデックスを手動で作成することもできます。または、[自動インデックス生成] をクリックすることもできます。その後、Simple Log Service はフィールドのインデックスを生成します。フィールドインデックスに基づいて、正確な方法でデータをクエリできます。これにより、インデックス作成のコストが削減され、クエリの効率が向上します。詳細については、「インデックスを作成する」をご参照ください。image

    データ解析(正規表現モード)プラグインを使用して収集されたログを処理する場合、抽出されたキーと値のペアが [フィールド検索] セクションに自動的に表示されます。

    image

  • データ解析(正規表現モード)

    • 未加工ログ

      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"
    • 戻り結果

      image

    • 正規表現

      (\S+)\s-\s(\S+)\s\[([^]]+)]\s"(\w+)\s(\S+)\s([^"]+)"\s(\d+)\s(\d+)\s"([^"]+)"\s"([^"]+).*
  • データ解析(JSON モード)

    • 未加工ログ

      {"@timestamp":"2024-08-16T16:23:22+08:00","server_addr":"127.0.0.1","remote_addr":"127.0.0.1","scheme":"http","request_method":"POST","request_uri": "/wp-admin/admin-ajax.php","request_length": "1161","uri": "/wp-admin/admin-ajax.php", "request_time":1.099,"body_bytes_sent":78,"bytes_sent":675,"status":"200","upstream_time":"1.097","upstream_host":"unix:/dev/shm/php-cgi.sock","upstream_status":"200","host":"www.example.com","http_referer":"http://www.example.com/wp-admin/index.php","http_user_agent":"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"}
    • 戻り結果image

  • データ解析(Apache モード)

    • 未加工ログ

      combined 形式のログ:

      127.0.*.* - frank [10/Oct/2023:13:55:36 +0800] "GET /index.html HTTP/1.1" 200 1024 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36"
    • 戻り結果

      image

  • データ解析(NGINX モード)

    • NGINX のデフォルトログ形式( combined 形式)には、次のフィールドがあります。

      フィールド

      説明

      remote_addr

      クライアントの IP アドレス。

      remote_user

      クライアントがリクエストを送信するために使用するユーザー名。

      time_local

      サーバーのシステム時間。値は角括弧 [] で囲む必要があります。

      request

      リクエストの URI と HTTP プロトコル。

      status

      リクエストのステータス。

      body_bytes_sent

      クライアントに送信されるレスポンスのバイト数。レスポンスヘッダーはカウントされません。

      http_referer

      ソース Web ページの URL。

      http_user_agent

      クライアントのブラウザ情報。

      http_x_forwarded_for

      プロキシサーバーによって転送された実際のクライアント IP アドレス。

      デフォルトフィールドに加えて、一般的に使用される拡張フィールドを次に示します。

      フィールド

      説明

      request_time

      リクエスト全体の合計時間(秒単位、ミリ秒精度)。

      upstream_response_time

      バックエンドサーバーの応答時間。

      http_cookie

      クライアントから送信された Cookie データ。

      http_x_real_ip

      クライアントの実際の IP アドレス。

      uri

      リクエストされた URI パス。例: /index.html

      args

      リクエスト行のパラメーター。例: ?param1=value1&param2=value2

      content_length

      リクエストヘッダーの Content-Length フィールド。

      content_type

      リクエストヘッダーの Content-Type フィールド。

      host

      リクエストヘッダーの Host フィールド、またはリクエストを処理するサーバー名。

      server_addr

      サーバーアドレス。

      server_name

      サーバー名。

      server_port

      サーバーポート。

      server_protocol

      サーバーがクライアントに応答するときに使用するプロトコルバージョン。例: HTTP/1.1

      scheme

      リクエストプロトコル。例: http または https

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

      log_format で指定されたログ形式に基づいて NGINX によって生成されるログ:

      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"
    • 戻り結果

      image

  • データ解析(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
    • 戻り結果image

  • データ解析(デリミタモード)

    • 未加工ログ

      05/May/2022: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
    • 戻り結果

      image

  • 単一行モードでのログ収集

    • 未加工ログ

      Aug 19 11:20:51 hostname-1 crond[2995]: (CRON) INFO (@reboot jobs will be run at computer's startup.)
    • 戻り結果

      image

  • 複数行モードでのログ収集

    • 未加工ログ

      2024-08-19 13:47:37,070 ERROR Failed to join the cluster, retry...
      
      java.lang.IllegalStateException: Fail to get leader of group naming_service_metadata, Unknown leader
      	at com.alipay.sofa.jraft.core.CliServiceImpl.getPeers(CliServiceImpl.java:605)
      	at com.alipay.sofa.jraft.core.CliServiceImpl.getPeers(CliServiceImpl.java:498)
      	at com.alibaba.nacos.core.distributed.raft.JRaftServer.registerSelfToCluster(JRaftServer.java:353)
      	at com.alibaba.nacos.core.distributed.raft.JRaftServer.lambda$createMultiRaftGroup$0(JRaftServer.java:264)
      	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
      	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
      	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
      	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
      	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
      	at java.lang.Thread.run(Thread.java:748)
    • 戻り結果

      image

  • SPL

    詳細については、「SPL 文を使用してテキストログを収集する」をご参照ください。

拡張シナリオ

次のステップ

  • ログを収集した後、Simple Log Service のクエリおよび分析機能を使用して、収集されたログに関する情報を取得できます。詳細については、「ログクエリおよび分析のガイド」をご参照ください。

  • ログを収集した後、Simple Log Service の可視化機能を使用して、統計を収集し、ログを表示できます。詳細については、「ダッシュボードを作成する」をご参照ください。

  • ログを収集した後、Simple Log Service のアラート機能を使用して、ログの例外に対してアラートを自動的に生成できます。詳細については、「Simple Log Service でアラートルールを設定する」をご参照ください。