異なるサーバーに分散しているビジネスログやシステムログは、一元的に検索、監視、分析することが困難です。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権限を付与する必要があります。詳細な権限付与については、「付録:カスタム権限ポリシー」をご参照ください。
収集設定のワークフロー
事前準備:プロジェクトと Logstore を作成します。プロジェクトは、異なるアプリケーションログを分離するためのリソース管理単位であり、Logstore はログを保存するために使用されます。
マシングループの設定 (LoongCollector のインストール):サーバーの種類に基づいて LoongCollector をインストールし、サーバーをマシングループに追加します。マシングループは、収集ノードの管理、構成の配布、およびサーバーの状態管理に使用されます。
グローバル設定と入力設定:収集設定の名前、ログ収集のソースと範囲を定義します。
ログの処理と構造化:ログのフォーマットに基づいて処理ルールを設定します。
複数行ログ:Java の例外スタックや Python のトレースバックなど、単一のログが複数行にまたがる場合に使用します。正規表現で各ログの開始を識別し、連続する行を単一の完全なログにマージします。
構造化解析:正規表現、区切り文字、NGINX パターンなどの解析プラグインを使用して、生文字列を構造化されたキーと値のペアに抽出します。これにより、各フィールドを個別にクエリおよび分析できます。
ログフィルタリング:収集ブラックリストとコンテンツフィルタリングルールを設定して、有効なログコンテンツをスクリーニングします。これにより、冗長なデータの転送とストレージを削減します。
ログの分類:トピックを使用して、異なるアプリケーション、サーバー、またはパスソースからのログを区別します。
クエリと分析の設定:全文インデックスはデフォルトで有効になっており、キーワード検索をサポートします。構造化されたフィールドの正確なクエリと分析のためにフィールドインデックスを有効にすると、検索効率が向上します。
検証とトラブルシューティング:設定完了後、ログが正常に収集されていることを確認します。データ収集がない、ハートビートの失敗、解析エラーなどの問題が発生した場合は、「よくある質問」を参照してトラブルシューティングを行ってください。
事前準備
ログを収集する前に、ログを管理および保存するためのプロジェクトと Logstore を作成する必要があります。これらのリソースが既にある場合は、このステップをスキップして「マシングループの設定 (LoongCollector のインストール)」に進んでください。
プロジェクトの作成
Logstore の作成
ステップ 1:マシングループの設定 (LoongCollector のインストール)
事前準備が完了したら、ご利用のサーバーに LoongCollector をインストールし、マシングループに追加します。
以下のインストール手順は、ログソースが SLS プロジェクトと同じ Alibaba Cloud アカウントおよびリージョンにある Alibaba Cloud ECS インスタンスである場合にのみ適用されます。
ご利用の ECS インスタンスとプロジェクトが異なるアカウントまたはリージョンにある場合、またはログソースがオンプレミスサーバーである場合は、「LoongCollector のインストールと設定」をご参照ください。
操作手順:
[Logstores] ページで、対象の Logstore 名の前にある
アイコンをクリックして展開します。[データ収集] の横にある
アイコンをクリックし、[クイックデータインポート] ダイアログボックスで、テキストログ収集テンプレート (「単一行 - テキストログ」など) を選択し、[今すぐ統合] をクリックします。すべてのテキストログ収集テンプレートは、解析プラグインのみが異なり、残りの設定プロセスは同じで、後で変更できます。
[マシングループ設定] ページで、次のパラメーターを設定します:
シナリオ:サーバー
インストール環境:ECS
マシングループの選択:対象サーバーの LoongCollector のインストール状況とマシングループの設定に基づいて、対応する操作を選択します:
LoongCollector がインストールされ、マシングループに追加されている場合は、[ソースマシングループ] リストからマシングループを選択し、[適用済みサーバーグループ] に追加します。新しく作成する必要はありません。
LoongCollector がインストールされていない場合は、[マシングループの作成] をクリックします:
以下の手順では、LoongCollector のワンクリック自動インストールとマシングループの作成について説明します。
システムは、プロジェクトと同じリージョンにある ECS インスタンスを自動的にリストアップします。ログを収集したいインスタンスを 1 つ以上選択します。
[インストールしてマシングループを作成] をクリックします。システムは、選択した ECS インスタンスに LoongCollector を自動的にインストールします。
マシングループの [名前] を設定し、[OK] をクリックします。
説明インストールが失敗するか、待機状態のままの場合は、ECS のリージョンがプロジェクトのリージョンと同じであるか確認してください。
LoongCollector が既にインストールされているサーバーを既存のマシングループに追加するには、よくある質問の「既存のマシングループにサーバーを追加するにはどうすればよいですか?」をご参照ください。
ハートビートステータスの確認:[次へ] をクリックします。[マシングループのハートビート] セクションが表示されます。[ハートビート] ステータスを確認します。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 オブジェクトなどのログは複数行にまたがることが多いため、デフォルトの収集モードでは不完全な複数のレコードに分割され、コンテキストが失われます。これを防ぐには、複数行モードを有効にし、先頭行を一致させる正規表現を設定して、同じログの連続する行を単一の完全なログにマージします。
例:
未処理の生ログ | デフォルトの収集モードでは、各行が個別のログとなり、スタックトレースが分断され、コンテキストが失われる | 複数行モードを有効にすると、先頭行を一致させる正規表現が完全なログを識別し、その完全な意味構造を保持する |
|
|
|
操作手順:[Logtail 構成] ページの [プロセッサー設定] セクションで、[複数行モード] を有効にします:
[タイプ] で、[カスタム] または [複数行 JSON] を選択します。
カスタム:可変形式の生ログの場合、[先頭行の正規表現] を設定して、各ログの開始行を識別します。
先頭行の正規表現:データの完全な行に一致する正規表現を自動生成または手動で入力します。例えば、上記の例の正規表現は
\[\d+-\d+-\w+:\d+:\d+,\d+]\s\[\w+]\s.*です。自動生成:[生成] をクリックします。次に、[ログサンプル] テキストボックスで、抽出したいログコンテンツを選択し、[自動生成] をクリックします。
手動入力:[正規表現を手動で入力] をクリックします。式を入力した後、[検証] をクリックします。
複数行 JSON:ログが標準の JSON 形式である場合、SLS は単一の生ログ内の改行を自動的に処理します。
分割失敗時の処理方法:
破棄:行頭ルールに一致しないテキストセグメントを破棄します。
単一行を保持:一致しないテキストを別々の行に保持します。
シナリオ 2:構造化ログ
NGINX のアクセスログやアプリケーションの出力ログなど、生のログが非構造化または半構造化テキストである場合、直接のクエリや分析は非効率的です。SLS は、さまざまな形式の生ログを自動的に構造化データに変換できる多様なデータ解析プラグインを提供します。これにより、後続の分析、モニタリング、アラートのための堅固なデータ基盤が提供されます。
例:
生ログ | 構造化ログ |
| |
操作手順:[Logtail 構成] ページの [プロセッサー設定] セクションで
解析プラグインの追加:[プロセッサーの追加] をクリックし、実際の形式に基づいて正規表現解析、区切り文字解析、または JSON 解析などのプラグインを設定します。この例では、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 レベルのログなど、価値の低いまたは無関係なログを大量に収集すると、ストレージリソースを浪費し、コストを増加させ、クエリ効率に影響を与え、データ漏洩のリスクをもたらします。これに対処するため、効率的で安全なログ収集のために詳細なフィルタリングポリシーを実装します。
コンテンツフィルタリングによるコスト削減
ログのコンテンツに基づいてフィールドをフィルタリングします。たとえば、レベルが WARNING または ERROR のログのみを収集します。
例:
未処理の生ログ |
|
| |
操作手順:[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:検証とトラブルシューティング
設定が完了したら、マシングループに適用して保存します。しばらく待ってから、以下のチェックリストを使用して検証します。
検証チェックリスト
ログファイルに新しいコンテンツがあることを確認する:LoongCollector は増分ログのみを収集します。
tail -f /path/to/your/log/fileを実行し、ビジネス操作をトリガーして、新しいログが書き込まれていることを確認します。LoongCollector のステータスを確認する:
sudo /etc/init.d/loongcollectord status。マシングループのハートビートを確認する: ページに移動します。対象のマシングループ名をクリックします。 セクションで、[ハートビート] ステータスを確認します。
ハートビートが OK の場合、マシングループは SLS プロジェクトに接続されています。
ハートビートが FAIL の場合は、「マシングループのハートビートが FAIL になる」を参照してトラブルシューティングを行ってください。
ログのクエリ:対象の Logstore のクエリと分析ページに移動します。[検索と分析] をクリックし (デフォルトの時間範囲は過去 15 分)、新しいログが流入しているか確認します。
一般的な問題のトラブルシューティング
マシングループのハートビートが FAIL になる
ユーザー ID の確認:ご利用のサーバーが ECS インスタンスでない場合、または ECS インスタンスとプロジェクトが異なる Alibaba Cloud アカウントに属している場合は、指定されたディレクトリに正しいユーザー ID が存在するか確認してください。存在しない場合は、次のコマンドを実行して手動で作成します。
Linux:
cd /etc/ilogtail/users/ && touch <uid>コマンドを実行してユーザー ID ファイルを作成します。Windows:
C:\LogtailData\users\ディレクトリに移動し、<uid>という名前の空のファイルを作成します。
マシングループ ID の確認:マシングループの作成時にカスタム ID を使用した場合は、指定されたディレクトリに
user_defined_idファイルが存在するか確認してください。存在する場合は、ファイルの内容がマシングループに設定されたカスタム ID と一致しているか確認します。Linux:
# カスタム ID を設定します。ディレクトリが存在しない場合は、手動で作成してください。 echo "user-defined-1" > /etc/ilogtail/user_defined_idWindows:
C:\LogtailDataディレクトリに、user_defined_idという名前の新しいファイルを作成し、カスタム ID を書き込みます。(ディレクトリが存在しない場合は、手動で作成してください。)
ユーザー ID とマシングループ ID の両方が正しく設定されている場合は、「LoongCollector (Logtail) のマシングループに関する問題のトラブルシューティング」を参照して、さらに調査してください。
データが収集されない
増分ログの確認:LoongCollector (Logtail) を収集用に設定した後、対象のログファイルに新しいログが追加されない場合、LoongCollector (Logtail) はそのファイルからデータを収集しません。
マシングループのハートビートステータスの確認: ページに移動します。対象のマシングループ名をクリックします。 セクションで、[ハートビート] ステータスを確認します。
ハートビートが OK の場合、マシングループは SLS プロジェクトに接続されています。
ハートビートが FAIL の場合は、「マシングループのハートビートが FAIL になる」を参照してトラブルシューティングを行ってください。
LoongCollector (Logtail) の収集設定がマシングループに適用されていることを確認する:LoongCollector (Logtail) の収集設定が作成されていても、マシングループに適用されていなければログは収集できません。
ページに移動し、対象のマシングループ名をクリックして、[マシングループ設定] ページに移動します。
ページで、[構成の管理] を表示します。左側には [すべての Logtail 構成] が表示され、右側には [適用済みの Logtail 構成] が表示されます。対象の LoongCollector (Logtail) 収集設定が右側の適用済みエリアに移動されている場合、設定は対象のマシングループに正常に適用されています。
対象の LoongCollector (Logtail) 収集設定が右側の適用済みエリアに移動されていない場合は、[変更] をクリックします。左側の [すべての Logtail 構成] リストで、対象の LoongCollector (Logtail) 構成名を選択し、
をクリックして右側の適用済みエリアに移動し、[保存] をクリックします。
ログ収集エラーまたはフォーマットエラー
トラブルシューティング:この状況は、ネットワーク接続と基本設定が正常であることを示します。問題は、ログの内容と解析ルールの不一致である可能性が高いです。問題の特定には、特定のエラーメッセージを確認する必要があります:
[Logtail 構成] ページで、収集エラーのある LoongCollector (Logtail) 構成の名前をクリックします。[ログ収集エラー] タブで、[時間範囲の選択] をクリックしてクエリ時間を設定します。
セクションで、エラーログのアラームメトリックを表示し、「データ収集における一般的なエラー」で対応するソリューションを見つけます。
制限事項
項目 | 制限事項 |
単一ログの長さ | デフォルトの制限は 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 のネットワークタイプ、起動パラメーター、および設定ファイル」をご参照ください。 収集パスを 重要 同じ Logtail インスタンスでこれら 2 つの形式を混在させないでください。そうしないと、同じファイルが複数の Logtail 収集設定に一致し、重複収集が発生する可能性があります。 20 を超えるファイルが未処理の場合、新しく生成されたログは失われます。このような場合は、まず Logstore のシャード書き込みクォータを超えていないか確認し、Logtail の同時実行レベルを調整してください。詳細については、「Logtail のネットワークタイプ、起動パラメーター、および設定ファイル」をご参照ください。 |
ログ解析がブロックされた場合の収集動作 | ログ解析がブロックされると、Logtail はそのログファイルのファイル記述子を開いたままにします。これにより、ブロック中にファイルが削除されてデータが失われるのを防ぎます。 解析がブロックされている間に複数のログファイルローテーションが発生した場合、Logtail はファイルをローテーションキューに配置します。 |
正規表現 | Perl 互換正規表現 (PCRE) をサポートします。 |
JSON | 標準 JSON (RFC7159, ECMA-404) を完全にサポートします。 |
ファイルオープン動作 | 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 はファイル収集履歴をメモリに保持し、ファイルが変更された後に増分部分のみが収集されるようにします。保持範囲外のログに書き込みが発生した場合、重複収集が発生します。
|
非標準テキストログ |
|
課金
LoongCollector または Logtail のインストールは無料です。
ログの取り込み、ストレージ、インデックス、クエリ、変換、転送には、Logstore の課金モードに基づいて料金が発生します。
インストールまたは設定中に Global Accelerator 機能を使用する場合、アクセラレーションネットワークを介して送信されるデータに対して追加のトラフィック料金が発生します。
よくある質問
ECS サーバーから別の Alibaba Cloud アカウントのプロジェクトにログを送信するにはどうすればよいですか?
LoongCollector をインストールしていない場合は、「インストールと設定」を参照し、適切なクロスアカウントシナリオを選択してインストールしてください。
LoongCollector を既にインストールしている場合は、次の手順に従ってユーザー ID を設定します。この ID は、サーバーが SLS プロジェクトを所有するアカウントによってアクセスされ、そのログが収集される権限を持つことを示します。
非アカウントの ECS インスタンス、オンプレミスサーバー、または他のクラウドプロバイダーのサーバーからログを収集する場合にのみ、ユーザー ID を設定する必要があります。
SLS を所有する Alibaba Cloud アカウントの ID をコピーします:右上隅のプロファイル画像にマウスを合わせます。表示されるタブからアカウント ID を表示してコピーします。
ログを収集したいサーバーにログインし、Alibaba Cloud アカウント ID ファイルを作成してユーザー ID を設定します:
touch /etc/ilogtail/users/{Alibaba_Cloud_account_ID} # /etc/ilogtail/users ディレクトリが存在しない場合は、手動で作成してください。ユーザー ID 設定ファイルはファイル名のみが必要で、ファイル拡張子は不要です。
ECS サーバーから同じアカウントの別のリージョンのプロジェクトにログを送信するにはどうすればよいですか?
LoongCollector をインストールしていない場合は、「インストールと設定」を参照し、適切なクロスリージョンシナリオを選択してインストールしてください。
LoongCollector を既にインストールしている場合は、LoongCollector の設定を変更する必要があります。
sudo /etc/init.d/ilogtaild stopコマンドを実行して LoongCollector を停止します。LoongCollector の起動設定ファイル
ilogtail_config.jsonを変更します。ネットワーク要件に応じて、次の 2 つの方法のいずれかを選択します:設定ファイルパス:
/usr/local/ilogtail/ilogtail_config.json方法 1:インターネットを使用して転送する
「リージョン ID」を参照し、設定ファイル内のリージョンを SLS が配置されているリージョンに置き換えます。変更するフィールドは次のとおりです:
primary_regionconfig_serversのリージョン部分data_servers内のregionとendpoint_listのリージョン部分
方法 2:転送アクセラレーションを使用する
data_server_list パラメーターのエンドポイント行を
log-global.aliyuncs.comに置き換えます。ファイルパスについては、「Logtail のネットワークタイプ、起動パラメーター、および設定ファイル」をご参照ください。
sudo /etc/init.d/ilogtaild startコマンドを実行して LoongCollector を起動します。
既存のマシングループにサーバーを追加するにはどうすればよいですか?
設定済みのマシングループがあり、新しくデプロイされた ECS インスタンスやオンプレミスサーバーなどの新しいサーバーを追加して、その収集設定を継承したい場合は、次の手順でバインドします。
前提条件:
設定済みのマシングループが既に存在する。
新しいサーバーに LoongCollector がインストールされている。
操作手順:
対象のマシングループ ID を表示します:
対象のプロジェクトページで、左側のナビゲーションウィンドウで
をクリックします。[マシングループ] ページで、対象のマシングループ名をクリックします。
マシングループ設定ページで、マシングループ ID を表示します。
ID の種類に基づいて対応する操作を実行します:
説明1 つのマシングループに Linux サーバーと Windows サーバーの両方を含めることはできません。Linux サーバーと Windows サーバーの両方に同じカスタム ID を設定しないでください。1 つのサーバーに複数のカスタム ID を設定でき、改行で区切ります。
タイプ 1:マシングループ ID が IP アドレスの場合
サーバーで、次のコマンドを実行して
app_info.jsonファイルを開き、ipの値を確認します。cat /usr/local/ilogtail/app_info.json対象のマシングループ設定ページで、[変更] をクリックし、サーバーの IP アドレスを入力します。複数の IP アドレスは改行で区切ります。
設定が完了したら、[保存] をクリックし、ハートビートステータスを確認します。ハートビートが OK になった後、サーバーは自動的にマシングループの収集設定を適用します。
ハートビートステータスが FAIL の場合は、よくある質問の「マシングループのハートビートが FAIL になる」を参照して、さらにトラブルシューティングを行ってください。
タイプ 2:マシングループ ID がカスタム ID の場合
オペレーティングシステムに応じて、対象のマシングループに一致するカスタム ID 文字列を指定されたファイルに書き込みます:
ディレクトリが存在しない場合は、手動で作成する必要があります。ファイルパスと名前は SLS によって固定されており、カスタマイズできません。
Linux:カスタム文字列を
/etc/ilogtail/user_defined_idファイルに書き込みます。Windows:カスタム文字列を
C:\LogtailData\user_defined_idに書き込みます。
別のプロジェクトから収集設定をインポートするにはどうすればよいですか?
事前準備とマシングループ設定が完了したら、既存のプロジェクトから現在の Logstore に収集設定を迅速にインポートできます。これにより、繰り返しの設定を避け、効率を向上させることができます。
操作手順:
マシングループ設定が完了したら、[次へ] をクリックして [Logtail 構成] ページに移動します。
ページ右上の [他の構成をインポート] をクリックします。
インポート元のプロジェクトとそのプロジェクト下の収集設定を選択します。
[OK] をクリックします。システムは選択した設定を自動的に読み込みます。
インポートされた設定情報が正しいことを確認した後、[次へ] をクリックして [クエリと分析の設定] ページに移動し、後続の設定を完了します。
マシングループ ID として使用するサーバーの IP アドレスを取得するにはどうすればよいですか?
LoongCollector (Logtail) がインストールされているサーバーで、/usr/local/ilogtail/app_info.json ファイルを開き、ip の値を確認します。
Logtail によって自動的に取得されたサーバーの IP アドレスは、以下に示すように app_info.json ファイルの ip フィールドに記録されます。
複数のサーバーがある場合は、対応する IP アドレスを手動で入力します。IP アドレスは改行で区切る必要があります。
1 つのマシングループに Linux サーバーと Windows サーバーの両方を含めることはできません。同じマシングループに Windows サーバーと Linux サーバーの両方の IP アドレスを追加しないでください。
同じログファイルを複数の収集設定で同時に収集するにはどうすればよいですか?
デフォルトでは、データの重複を避けるため、SLS はテキストログファイルが複数の Logtail 構成によって収集されることを制限しています。同じログファイルを複数の収集設定で同時に収集できるようにするには、ファイルが複数回収集されることを許可する機能をを手動で有効にする必要があります。
操作手順:
複数コピーを収集すると、ファイル読み取り IO、コンピューティングリソース、およびネットワーク IO が線形に増加します。
Simple Log Service コンソールにログインし、対象のプロジェクトに移動します。
左側のナビゲーションウィンドウで、
[Logstores] を選択し、対象の Logstore を見つけます。その名前の前にある
アイコンをクリックして Logstore を展開します。[Logtail 構成] をクリックします。構成リストで、対象の Logtail 構成を見つけ、[操作] 列の [Logtail 構成の管理] をクリックします。
Logtail 構成ページで、[編集] をクリックします:
で、[ファイルの複数回収集を許可] を有効にします。
設定が完了したら、[保存] をクリックします。
最後のログエントリが長い遅延の後に報告されるのはなぜですか?なぜ時々切り捨てられるのですか?
原因:ログの切り捨ては通常、ログファイルの末尾に改行がない場合や、例外スタックなどの複数行ログが完全に書き込まれていない場合に発生します。エージェントはログが終了したかどうかを判断できないため、コンテンツの最後の部分が時期尚早に分割されたり、遅れて報告されたりすることがあります。LoongCollector (Logtail) のバージョンによって処理メカニズムが異なります:
1.8 より前のバージョン:
ログの最後の行に改行 (キャリッジリターン) がない場合、または複数行のログ段落が終了していない場合、エージェントは次の書き込みを待って出力をトリガーします。これにより、最後のログエントリが新しいログが書き込まれるまで長時間送信されずに保持される可能性があります。バージョン 1.8 以降:
ログがスタックするのを防ぐために、タイムアウト更新メカニズムが導入されました。不完全なログ行が検出されると、システムはタイマーを開始します。タイムアウト後、現在のコンテンツを自動的に送信し、ログが最終的に収集されることを保証します。デフォルトのタイムアウト:60 秒 (ほとんどのシナリオで完全性を確保するため)
必要に応じてこの値を調整しますが、0 に設定しないでください。ログの切り捨てや部分的なコンテンツの損失を引き起こす可能性があります。
ソリューション:
待機時間を延長して、収集される前に完全なログが書き込まれるようにします:
Simple Log Service コンソールにログインし、対象のプロジェクトに移動します。
左側のナビゲーションウィンドウで、
[Logstores] を選択し、対象の Logstore を見つけます。その名前の前にある
アイコンをクリックして Logstore を展開します。[Logtail 構成] をクリックします。構成リストで、対象の Logtail 構成を見つけ、[操作] 列の [Logtail 構成の管理] をクリックします。
Logtail 構成ページで、[編集] をクリックします:
で、次の JSON 設定を追加してタイムアウトをカスタマイズします:
{ "FlushTimeoutSecs": 1 }デフォルト値:起動パラメーター
default_reader_flush_timeoutによって決定されます (通常は数秒)。単位:秒。
推奨値:≥1 秒。0 に設定しないでください。ログの切り捨てや部分的なコンテンツの損失を引き起こす可能性があります。
設定が完了したら、[保存] をクリックします。
LoongCollector (Logtail) が動作中に内部エンドポイントからインターネットに切り替わるのはなぜですか?自動的に元に戻せますか?
動作中、LoongCollector (Logtail) が内部の同一リージョンエンドポイントとの通信異常 (ネットワーク障害や接続タイムアウトなど) を検出した場合、システムは自動的にパブリックドメイン名に切り替えてデータを送信します。これにより、ログ収集の継続性と信頼性が確保され、ログのバックログや損失が防止されます。
LoongCollector:回復後、自動的に内部ネットワークに戻ります。
Logtail:自動的には戻りません。内部ネットワーク通信を再開するには、手動で再起動する必要があります。
付録:ネイティブプロセッサーの詳細
[Logtail 構成] ページの [プロセッサー設定] セクションで、プロセッサーを追加して生ログを構造化します。既存の収集設定に処理プラグインを追加するには、次の手順に従います:
左側のナビゲーションウィンドウで、
[Logstores] を選択し、対象の Logstore を見つけます。その名前の前にある
アイコンをクリックして Logstore を展開します。[Logtail 構成] をクリックします。構成リストで、対象の Logtail 構成を見つけ、[操作] 列の [Logtail 構成の管理] をクリックします。
Logtail 構成ページで、[編集] をクリックします。
このセクションでは、一般的なログ処理シナリオをカバーする、一般的に使用される処理プラグインのみを紹介します。その他の機能については、「拡張プロセッサー」をご参照ください。
プラグインの組み合わせルール (LoongCollector / Logtail 2.0 以降):
ネイティブプロセッサーと拡張プロセッサーは、独立して使用することも、必要に応じて組み合わせることもできます。
ネイティブプロセッサーは、パフォーマンスと安定性が高いため、優先的に使用してください。
ネイティブ機能がビジネスニーズを満たせない場合は、設定済みのネイティブプロセッサーの後に拡張プロセッサーを追加して、補足的な処理を行います。
順序の制約:
すべてのプラグインは、設定された順序で順次実行され、処理チェーンを形成します。注意:すべてのネイティブプロセッサーは、どの拡張プロセッサーよりも前に配置する必要があります。拡張プロセッサーを追加した後は、さらにネイティブプロセッサーを追加することはできません。
正規表現解析
正規表現を使用してログフィールドを抽出し、ログをキーと値のペアに解析します。各フィールドは独立してクエリおよび分析できます。
例:
未処理の生ログ | 正規表現解析プラグインの使用 |
| |
操作手順:[Logtail 構成] ページの [プロセッサー設定] セクションで、[プロセッサーの追加] をクリックし、 を選択します:
正規表現:ログに一致させるために使用する式。自動生成するか、手動で入力します:
自動生成:
[生成] をクリックします。
[ログサンプル] で、抽出するログコンテンツを選択します。
[正規表現の生成] をクリックします。

手動入力:ログ形式に基づいて [正規表現を手動で入力] します。
設定後、[検証] をクリックして、正規表現がログコンテンツを正しく解析できるかテストします。
抽出されたフィールド:抽出されたログコンテンツ (値) に対応するフィールド名 (キー)。
その他のパラメーターについては、「シナリオ 2:構造化ログ」の共通設定パラメーターの説明をご参照ください。
区切り文字解析
区切り文字を使用してログコンテンツを構造化し、複数のキーと値のペアに解析します。単一文字および複数文字の区切り文字の両方がサポートされています。
例:
未処理の生ログ | 指定された文字 |
| |
操作手順:[Logtail 構成] ページの [プロセッサー設定] セクションで、[プロセッサーの追加] をクリックし、 を選択します:
区切り文字:ログコンテンツを分割するために使用する文字を指定します。
例:CSV ファイルの場合、[カスタム] を選択し、カンマ (,) を入力します。
引用符:フィールド値に区切り文字が含まれている場合、誤った分割を防ぐためにフィールド値を引用符で囲む必要があります。
抽出されたフィールド:各列のフィールド名 (キー) を表示順に指定します。ルールは次のとおりです:
フィールド名には、文字、数字、アンダースコア (_) のみを含めることができます。
文字またはアンダースコア (_) で始まる必要があります。
最大長:128 バイト。
その他のパラメーターについては、「シナリオ 2:構造化ログ」の共通設定パラメーターの説明をご参照ください。
標準 JSON 解析
オブジェクトタイプの JSON ログをキーと値のペアに解析して構造化します。
例:
未処理の生ログ | 標準 JSON キーと値のペアの自動抽出 |
| |
操作手順:[Logtail 構成] ページの [プロセッサー設定] セクションで、[プロセッサーの追加] をクリックし、 を選択します:
元のフィールド:解析対象の生ログを含むフィールド。デフォルト値は content です。
その他のパラメーターについては、「シナリオ 2:構造化ログ」の共通設定パラメーターの説明をご参照ください。
ネストされた JSON 解析
展開深度を指定して、ネストされた JSON ログをキーと値のペアに解析します。
例:
未処理の生ログ | 展開深度:0、展開深度をプレフィックスとして使用 | 展開深度:1、展開深度をプレフィックスとして使用 |
| | |
操作手順:[Logtail 構成] ページの [プロセッサー設定] セクションで、[プロセッサーの追加] をクリックし、 を選択します:
元のフィールド:展開するソースフィールドの名前を指定します。例:
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 配列構造の抽出 |
| |
操作手順:[Logtail 構成] ページの [プロセッサー設定] セクションで、[処理モード] を [SPL] に切り替え、SPL ステートメントを設定し、json_extract 関数を使用して JSON 配列から JSON オブジェクトを抽出します。
例:ログフィールド content の JSON 配列から要素を抽出し、結果を新しいフィールド json1 と json2 に保存します。
* | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')Apache ログ解析
Apache ログ設定ファイルの定義に基づいて、ログコンテンツを複数のキーと値のペアに構造化します。
例:
未処理の生ログ | Apache Common Log Format |
| |
操作手順:[Logtail 構成] ページの [プロセッサー設定] セクションで、[プロセッサーの追加] をクリックし、 を選択します:
[ログフォーマット] は [combined] です。
[APACHE LogFormat 設定] は、[ログフォーマット] に基づいて自動的に入力されます。
重要自動入力された内容が、サーバーの Apache 設定ファイル (通常は /etc/apache2/apache2.conf にあります) で定義されている LogFormat と完全に同じであることを確認してください。
その他のパラメーターについては、「シナリオ 2:構造化ログ」の共通設定パラメーターの説明をご参照ください。
IIS ログ解析
IIS ログフォーマット定義に基づいて、ログコンテンツを複数のキーと値のペアに構造化します。
比較例:
生ログ | Microsoft IIS サーバー固有のフォーマットへの適応 |
| |
操作手順:[Logtail 構成] ページの [プロセッサー設定] セクションで、[プロセッサーの追加] をクリックし、 を選択します:
ログフォーマット: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:構造化ログ」の共通設定パラメーターの説明をご参照ください。
データマスキング
ログ内の機密データをマスキングします。
例:
未処理の生ログ | マスキング結果 |
| |
操作手順:[Logtail 構成] ページの [プロセッサー設定] セクションで、[プロセッサーの追加] をクリックし、 を選択します:
時刻解析
ログ内の時刻フィールドを解析し、解析結果をログの __time__ フィールドとして設定します。
例:
未処理の生ログ | 時刻解析 |
|
|
操作手順:[Logtail 構成] ページの [プロセッサー設定] セクションで、[プロセッサーの追加] をクリックし、 を選択します:
元のフィールド:解析前のログコンテンツを含むフィールド。
時刻フォーマット:ログ内のタイムスタンプに対応する時刻フォーマットを設定します。
タイムゾーン:ログの時刻フィールドのタイムゾーンを選択します。デフォルトでは、これは LoongCollector (Logtail) プロセスが実行されている環境のタイムゾーンです。
付録:権限ポリシーリファレンス
Alibaba Cloud アカウントでのログイン:デフォルトでは、Alibaba Cloud アカウントは完全な権限を持ち、すべての操作を実行できます。
RAM ユーザーでのログイン:Alibaba Cloud アカウントは、RAM ユーザーに必要なアクセスポリシーを付与する必要があります。
カスタム権限ポリシー (詳細な制御)
システムポリシーが最小権限の原則を満たさない場合は、詳細な権限付与のためにカスタムポリシーを作成します。以下は、これらの権限を含む権限ポリシーの例です:
プロジェクトの表示:プロジェクトリストと指定されたプロジェクトの詳細を表示します。
Logstore の管理:プロジェクト下の Logstore を作成、変更、または削除します。
収集設定の管理:収集設定を作成、削除、変更します。
ログの表示:指定されたプロジェクト下の指定された Logstore のデータをクエリおよび分析します。
${regionName}、${uid}、${projectName}、および${logstoreName}を実際のリージョン名、Alibaba Cloud アカウント ID、対象プロジェクト、および Logstore に置き換えてください。
権限 | アクション | リソース |
読み取り専用プロジェクト |
|
|
指定されたプロジェクトの取得 |
|
|
Logstore の管理 |
|
|
LoongCollector (Logtail) データインポートの管理 |
|
|
保存された検索のクエリ |
|
|
ダッシュボードのクエリ |
|
|
指定された Logstore のログのクエリ |
|
|
ECS を操作する権限 |
|
|
OOS を操作する権限 (任意) SLS および ECS インスタンスと同じアカウントおよびリージョンで OOS を介して LoongCollector (Logtail) が自動的にインストールされる場合にのみ必要です。 |
|
|
システム権限ポリシー
システム定義のポリシーを使用する場合は、次の権限を追加することを推奨します:
AliyunLogFullAccess:SLS を管理する権限。AliyunECSFullAccess:ECS を管理する権限。(任意)
AliyunOOSFullAccess:OOS を使用してワンクリックで LoongCollector (Logtail) をインストールする場合に必要です。






