Azure Operator Insights インジェスト エージェントの監視とトラブルシューティングを行う
インジェスト エージェントの概要については、「インジェスト エージェントの概要」を参照してください。
インジェスト エージェントからのデータ収集に関して問題があることがわかった場合は、このセクションの情報を使って一般的な問題を修正するか、診断パッケージを作成してください。 診断パッケージは、Azure portal で作成したサポート チケットにアップロードできます。
インジェスト エージェントはソフトウェア パッケージであるため、診断はアプリケーションの機能に限定されます。 OS やリソースの監視は提供されていません。 標準的なツール (snmpd、Prometheus ノード エクスポーター、その他のツールなど) を使って、OS レベルのデータ、ログ、メトリックをお使いの監視システムに送信することをお勧めします。 「Azure Monitor を使用して仮想マシンを監視する」では、Azure VM 上でインジェスト エージェントを実行している場合に使用できるツールが説明されています。
エージェントは、/var/log/az-aoi-ingestion/ 下のファイルにログとメトリックを書き込みます。 構成の誤りなど、何らかの理由でエージェントの起動に失敗する場合は、stdout.log ファイルに問題について説明した人間が判読できるログが記載されます。
メトリックは、わかりやすいシンプルな形式で報告されます。
前提条件
- 以下のトラブルシューティング手法のほとんどでは、エージェントを実行している VM への SSH 接続が必要です。
インジェスト エージェントの診断
診断パッケージを収集するには、仮想マシンに SSH 接続して、/usr/bin/microsoft/az-aoi-ingestion-gather-diags
コマンドを実行します。 このコマンドを実行すると、現在のディレクトリに日付付きの zip ファイルが生成され、それをシステムからコピーできます。
Azure Monitor エージェントを使用してログの収集を構成している場合は、Log Analytics ワークスペースのポータル ビューでインジェスト エージェントログを表示できます。問題をデバッグするために診断パッケージを収集する必要がない場合があります。
Note
問題を調査するときに、Microsoft サポートから診断パッケージを求められる場合があります。 診断パッケージには、お客様のデータや資格情報の値は含まれません。
すべてのソースに共通する問題
問題は、大きく 4 つのカテゴリに分類されます。
- エージェントの構成の誤り (エージェントの起動に失敗する)。
- ソースからのデータの受信に関する問題 (通常は構成の誤り、またはネットワーク接続)。
- データ製品の入力ストレージ アカウントへのファイルのアップロードに関する問題 (通常はネットワーク接続)。
- エージェントが実行されている VM に関する問題。
エージェントの起動に失敗する
症状: sudo systemctl status az-aoi-ingestion
を実行すると、サービスが失敗状態であることが表示される。
- サービスが実行されていることを確認します。
sudo systemctl start az-aoi-ingestion
- /var/log/az-aoi-ingestion/stdout.log ファイルを調べて、エラーが報告されていないか確認します。 構成ファイルに関する問題を修正し、エージェントを再度起動します。
Azure Operator Insights にデータが表示されない
症状: Azure Data Explorer にデータが表示されない。
- インジェスト エージェント VM とデータ製品の入力ストレージ アカウントの間のネットワーク接続とファイアウォール構成を確認します。
- インジェスト エージェントからのログで、Azure へのアップロードに関するエラーを調べます。 ログが認証の問題を示している場合は、エージェントの構成でシンク設定と認証がデータ製品用に正しく設定されていることを確認します。 その後、エージェントを再起動します。
- インジェスト エージェントがソースからデータを受信していることを確認します。 ネットワークとインジェスト エージェントの間のネットワーク接続とファイアウォール構成を確認します。
MCC EDR ソースに関する問題
このセクションでは、MCC EDR ソースに固有の問題について説明します。
インジェストに関する問題を特定してデバッグするために、MCC が提供する診断、または Azure Monitor で Azure Operator Insights 自体が提供する診断を使うこともできます。
MCC が接続できない
症状: MCC が MSF の利用不可に関するアラームを報告する。
- エージェントが実行されていることを確認します。
- MCC が正しい IP とポートで構成されていることを確認します。
- エージェントからのログを調べ、接続が報告されているかどうかを確認します。 そうでない場合は、エージェント VM へのネットワーク接続を確認し、ファイアウォールがポート 36001 へのトラフィックをブロックしていないことを確認します。
- パケット キャプチャを収集して、接続に失敗している場所を確認します。
Azure Operator Insights に EDR が表示されない
症状: Azure Data Explorer にデータが表示されない。
- MCC が正常であり、インジェスト エージェントが実行されていることを確認します。
- 診断パッケージのインジェスト エージェント ログで Azure にアップロードするエラーを確認します。 ログが無効な接続文字列または接続の問題を示している場合は、構成、接続文字列、または SAS トークンを修正して、エージェントを再起動します。
- ストレージ アカウントのネットワーク接続とファイアウォール構成を確認します。
データが見つからないか不完全である
症状: Azure Monitor で予想よりも低い ADX の受信 EDR レートが表示される。
- エージェントがすべての VM で実行されており、診断 パッケージ ログにエラーが報告されていないことを確認します。
- エージェント VM がレートの負荷を超えて送信されていないことを確認します。
- 診断パッケージのエージェント メトリックで、ドロップされたバイト数/ドロップされた EDR を確認します。 メトリックに破棄されたデータが表示されない場合、MCC はエージェントにデータを送信していません。 "受信バイト" メトリックを調べて、MCC から受信しているデータの量を確認します。
- エージェント VM が過負荷になっていないことを確認します (CPU とメモリの使用状況を監視します)。 特に、他のプロセスが VM のリソースを奪っていないことを確認します。
SFTP プル ソースに関する問題
このセクションでは、SFTP プル ソースに固有の問題について説明します。
インジェストに関する問題を特定してデバッグするために、Azure Monitor で Azure Operator Insights 自体が提供する診断を使うこともできます。
エージェントが SFTP サーバーに接続できない
症状: Azure Operator Insights にファイルがアップロードされない。 エージェントのログ ファイル (/var/log/az-aoi-ingestion/stdout.log) に、SFTP サーバーの接続に関するエラーが含まれている。
- エージェントが使用する SFTP ユーザーと資格情報が、SFTP サーバーに対して有効であることを確認します。
- エージェントと SFTP サーバーの間のネットワーク接続とファイアウォール構成を確認します。 既定では、SFTP 接続を受け入れるために、SFTP サーバーのポート 22 が開かれている必要があります。
- エージェント VM 上の
known_hosts
ファイルに、SFTP サーバーの有効な SSH 公開キーが含まれていることを確認します。- エージェント VM で、
ssh-keygen -l -F *<sftp-server-IP-or-hostname>*
を実行します。 - 出力がない場合は、
known_hosts
に一致するエントリが含まれていません。 Azure Operator Insights インジェスト エージェントのセットアップに関する記事の手順に従って、SFTP サーバーのknown_hosts
エントリを追加します。
- エージェント VM で、
Azure Operator Insights にファイルがアップロードされない
症状: Azure Data Explorer にデータが表示されない。 カテゴリ Ingestion
のログが Azure Operator Insights 監視データに表示されないか、エラーが含まれています。 関連するデータ型の、[取り込まれた列の数] データ品質メトリックの値がゼロです。
- エージェントがすべての VM で実行されており、ログにエラーが報告されていないことを確認します。
- SFTP サーバー上の正しい場所にファイルが存在し、ファイル ソースの構成が原因で除外されていないことを確認します (「ファイルが見つからない」を参照)。
- 構成された SFTP ユーザーが、
base_path
の下にあるすべてのディレクトリを読み取ることができることを確認します。このファイル ソース構成では除外されません。 - インジェスト エージェント VM とデータ製品の入力ストレージ アカウントの間のネットワーク接続とファイアウォール構成を確認します。
ファイルが見つからない
症状: Azure Data Explorer にデータが見つからない。 Azure Operator Insights 監視データで、カテゴリ Ingestion
のログの量が期待されるよりも表示量が少ないか、ログにデータが含まれています。 関連するデータ型の、[取り込まれた列の数] データ品質メトリックの値が期待されるよりも少なくなっています。
- エージェントがすべての VM で実行されており、ログにエラーが報告されていないことを確認します。 診断パッケージ ログで、不足しているファイルの名前を検索して、そのファイルに関連するエラーを見つけます。
- SFTP サーバー上にファイルが存在し、ファイル ソースの構成が原因で除外されていないことを確認します。ファイル ソースの構成を調べて、以下を確認します。
- ファイルは、SFTP サーバー上の
base_path
で定義されているパスの下に存在しています。 アップロードするファイルのファイル パスにシンボリック リンクがないことを確認します。インジェスト エージェントでは、シンボリック リンクが無視されます。 - ファイルの "最終変更" 時刻は、このファイル ソースの最新のアップロード実行時刻より
settling_time
秒以上前です。 - ファイルの "最終変更" 時刻は、
exclude_before_time
より後です (指定されている場合)。 base_path
を基準としたファイル パスは、include_pattern
によって指定される正規表現と一致します (指定されている場合)。base_path
を基準としたファイル パスは、exclude_pattern
によって指定される正規表現と一致 "しません" (指定されている場合)。
- ファイルは、SFTP サーバー上の
- 最近のファイルが見つからない場合は、エージェントのログを調べて、インジェスト エージェントが期待された時刻にソースのアップロードを実行したことを確認します。 ソース構成の
cron
パラメーターによって、予想されるスケジュールが指定されます。 - エージェント VM が過負荷になっていないことを確認します (CPU とメモリの使用状況を監視します)。 特に、他のプロセスが VM のリソースを奪っていないことを確認します。
ファイルが複数回アップロードされる
症状: Azure Operator Insights に重複データが表示される。
- 前回のアップロード時点での診断パッケージ ログで、インジェスト エージェントで再試行可能なエラーが発生し、その後該当するアップロードを最後に正常なアップロードが行われた 24 時間後よりも後に再試行されたかどうかを確認します。 その場合、エージェントは再試行中に重複データをアップロードしている可能性があります。 データの重複は、再試行にのみ影響するはずです。
- 構成ファイルで定義されている各ファイル ソースが重複しないファイル セットを参照していることを確認します。 複数のファイル ソースが SFTP サーバー上の同じ場所からファイルをプルするように構成されている場合は、
include_pattern
とexclude_pattern
の構成フィールドを使って、各ファイル ソースが対象にすべき個別のファイル セットを指定します。 - SFTP インジェスト エージェントのインスタンスを複数実行している場合は、各エージェント用に構成されたファイル ソースが他のエージェントのファイル ソースと重複していないことを確認します。 特に、他のエージェントの構成から誤ってコピーされたファイル ソース構成に注意してください。
- 構成されたファイル ソースのパイプライン
id
を最近変更した場合は、exclude_before_time
フィールドを使って、新しいパイプラインid
でファイルが再アップロードされないようにします。 その手順については、Azure Operator Insights インジェスト エージェントの構成の変更に関する記事を参照してください。
関連するコンテンツ
具体的には、次の方法を学習します。
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示