AMA コネクタを使用した CEF と Syslog のトラブルシューティング

この記事では、Microsoft Sentinel の Azure Monitor エージェント (AMA) を使用した Common Event Format (CEF) と Syslog データ収集のトラブルシューティングガイダンスについて説明します。このガイドを使用して、ログフォワーダーマシンに関するインジェストの問題を診断して解決します。コマンドと構成は、AMA と RSyslog/Syslog-ng がインストールされているログフォワーダーマシンで実行する必要があります。

トラブルシューティングを開始する前に、次の記事を理解しておいてください。

アーキテクチャの概要

次の図は、RSyslog と Azure Monitor エージェントを使用して、ログソースから Microsoft Sentinel/Log Analytics ワークスペースへのデータフローを示しています。

主なコンポーネント:

RSyslog/Syslog-ng: ポート 514 のログを受信し、それらを AMA に転送します
Azure Monitor エージェント: データ収集規則 (DCR) に従ってログを処理する
データ収集規則: 収集するログと、それらを送信する場所を定義します

最初の検証手順

ログが受信されていることを確認する

ログは、構成後に Microsoft Sentinel に表示されるまでに最大 20 分かかる場合があります。

tcpdump を実行して、フォワーダーにログが到着していることを確認します。
```
sudo tcpdump -i any port 514 -A -vv
```
正しいフォワーダー IP アドレスにメッセージを送信するようにログソースが構成されていることを確認します。
接続に影響する可能性があるインフラストラクチャコンポーネントを確認します。
- Firewalls
- ロードバランサー
- ネットワークセキュリティグループ

Azure Monitor エージェントの拡張機能の状態を確認する

Azure portal で、ログフォワーダー仮想マシンに移動します。
[拡張機能とアプリケーション] を選択します。
AzureMonitorLinuxAgent 拡張機能を選択します。
[状態] に [プロビジョニングが成功しました] と表示されていることを確認します。

エージェントのバージョンを確認する

AzureMonitorLinuxAgent 拡張機能ブレードで、[バージョン] フィールドを確認します。
バージョンが 2 から 3 の最新リリースの 1 つであることを確認します。最新バージョンについては、AMA バージョンの詳細を参照してください。

注

新しいバージョンは、最初のリリース後にロールアウトされるまでに最大 5 週間かかる場合があります。

エージェントレベルのトラブルシューティング

エージェントと RSyslog サービスが実行されていることを確認します。

sudo systemctl status azuremonitoragent
sudo systemctl status rsyslog
sudo systemctl status syslog-ng.service # If using Syslog-ng

RSyslog の構成を確認する

RSyslog 構成は、/etc/rsyslog.conf内の/etc/rsyslog.d/とファイルで構成されます。

ポートの構成を確認します。

grep -E 'imudp|imtcp' /etc/rsyslog.conf

予想される出力:

module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")

AMA 転送構成が存在することを確認します。

cat /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf

ファイルの先頭は次のとおりです。

# Azure Monitor Agent configuration: forward logs to azuremonitoragent

ポートの状態を確認する

必要なポートが待ち受け状態であることを確認してください。

sudo ss -lnp | grep -E "28330|514"

予想される出力:

udp   UNCONN 0      0      0.0.0.0:514         0.0.0.0:*    users:(("rsyslogd",pid=12289,fd=5))
tcp   LISTEN 0      10     127.0.0.1:28330     0.0.0.0:*    users:(("mdsd",pid=1424,fd=1363))
tcp   LISTEN 0      25     0.0.0.0:514         0.0.0.0:*    users:(("rsyslogd",pid=12289,fd=7))

これにより、次の内容が確認されます。

RSyslog はポート 514 (TCP および UDP) でリッスンしています
MDSD (AMA コンポーネント) がポート 28330 (TCP) でリッスンしています

データコレクションルールの構成を検証する

DCR がエージェントで正しく構成されているかどうかを確認します。

CEF ログの場合:

sudo grep -i -r "SECURITY_CEF_BLOB" /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks

Cisco ASA ログの場合:

sudo grep -i -r "SECURITY_CISCO_ASA_BLOB" /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks

出力には、DCR 構成を含む JSON 文字列が表示されます。

ファイアウォール規則を確認する

ファイアウォール規則で次の間の通信が許可されていることを確認します。

ログソースと RSyslog (ポート 514)
RSyslog と AMA (ポート 28330)
AMA と Azure エンドポイント

データ収集規則の構成

トラブルシューティングのためのすべての機能を有効にする

最初のトラブルシューティングの場合:

Azure portal で、データ収集規則に移動します。
すべての syslog 機能を有効にします。
すべてのログレベルを選択します。
使用可能な場合は、機能または重大度のないメッセージの収集を有効にします。

詳細については、「施設と重大度の選択」を参照してください。

共通イベント形式 (CEF) 検証

CEF 形式の要件

CEF では、次の構造を持つトランスポートメカニズムとして Syslog が使用されます。

<Priority>Timestamp Hostname CEF:Version|Device Vendor|Device Product|Device Version|Device Event Class ID|Name|Severity|[Extension]

例:

Jan 18 11:07:53 host CEF:0|Vendor|Product|1.0|100|EventName|5|src=10.0.0.1 dst=10.0.0.2

CEF の書式設定に関する一般的な問題

ヘッダーの形式が正しくありません

CEF バージョンが存在することを確認します。 CEF:0|
すべてのヘッダーフィールドが存在し、パイプ (|) 文字で区切る必要があります

不適切な文字エスケープ

ヘッダー値のパイプ文字 (|) はエスケープする必要があります。 \|
バックスラッシュ () はエスケープする必要があります。\\
拡張内の等号 (=) はエスケープする必要があります。 \=

欠損値または未マッピング値

値を標準フィールドにマップできない場合は、 AdditionalExtensions 列に格納されます。
フィールドマッピングについては、CEF および CommonSecurityLog フィールドマッピングを参照してください

完全な CEF 仕様については、"Implementing ArcSight Common Event Format (CEF)" のドキュメントを検索してください。

高度なトラブルシューティング

診断トレースを有効にする

Warnung

トラブルシューティングセッションに対してのみトレースフラグを有効にします。トレースフラグを使用すると、ディスク領域をすばやく埋めることができる広範なログが生成されます。

AMA 構成ファイルを編集します。
```
sudo vim /etc/default/azuremonitoragent
```

MDSD_OPTIONS行にトレースフラグを追加します。

export MDSD_OPTIONS="-A -c /etc/opt/microsoft/azuremonitoragent/mdsd.xml -d -r $MDSD_ROLE_PREFIX -S $MDSD_SPOOL_DIRECTORY/eh -L $MDSD_SPOOL_DIRECTORY/events -e $MDSD_LOG_DIR/mdsd.err -w $MDSD_LOG_DIR/mdsd.warn -o $MDSD_LOG_DIR/mdsd.info -T 0x2002"

エージェントを再起動します。

sudo systemctl restart azuremonitoragent

問題を再現し、数分待ちます。
/var/opt/microsoft/azuremonitoragent/log/mdsd.infoでデバッグ情報を確認します。
トラブルシューティングの後、トレースフラグを削除し、エージェントを再起動します。

ログ処理をリアルタイムで監視する

処理された受信ログを表示します。

tail -f /var/opt/microsoft/azuremonitoragent/log/mdsd.info

特定のログの種類をフィルター処理します。

sudo tail -f /var/opt/microsoft/azuremonitoragent/log/mdsd.* | grep -a "CEF"

特定のファシリティログを確認します。

grep local0.info /var/opt/microsoft/azuremonitoragent/log/mdsd.info

ログ処理が成功したことを確認する

トレースフラグが有効になっている場合は、デバッグ出力を調べることで、ログが正しく処理されていることを確認できます。

ASA ログ取り込みの例

Cisco ASA ログの場合、正常な処理はログに次のように表示されます。

2022-01-18T22:00:14.8650520Z: virtual bool Pipe::SyslogCiscoASAPipeStage::PreProcess(std::shared_ptr<CanonicalEntity>) (.../mdsd/PipeStages.cc +604) [PipeStage] Processing CiscoASA event '%ASA-1-105003: (Primary) Monitoring on 123'

2022-01-18T22:00:14.8651330Z: virtual void ODSUploader::execute(const MdsTime&) (.../mdsd/ODSUploader.cc +325) Uploading 1 SECURITY_CISCO_ASA_BLOB rows to ODS.

2022-01-18T22:00:14.8653090Z: int ODSUploader::UploadFixedTypeLogs(const string&, const string&, const std::function<void(bool, long unsigned int, int, long unsigned int)>&, int, uint64_t) (.../mdsd/ODSUploader.cc +691) Uploading to ODS with request 3333-44dd-555555eeeeee Host https://00001111-aaaa-2222-bbbb-3333cccc4444.ods.opinsights.azure.com for datatype SECURITY_CISCO_ASA_BLOB. Payload: {"DataType":"SECURITY_CISCO_ASA_BLOB","IPName":"SecurityInsights","ManagementGroupId":"00000000-0000-0000-0000-000000000002","sourceHealthServiceId":"2c2c2c2c-3333-dddd-4444-5e5e5e5e5e5e","type":"JsonData","DataItems":[{"Facility":"local0","SeverityNumber":"6","Timestamp":"2022-01-14T23:28:49.775619Z","HostIP":"127.0.0.1","Message":" (Primary) Monitoring on 123","ProcessId":"","Severity":"info","Host":"localhost","ident":"%ASA-1-105003"}]}. Uncompressed size: 443. Request size: 322

正常な処理の主要なインジケーター:

イベントは CiscoASA イベントとして認識されます
ログが ODS にアップロードされます (Operations Data Service)
追跡のために要求 ID が生成される
ペイロードに適切に書式設定された JSON データが含まれている

CEF ログインジェストの例

CEF ログの場合、正常な処理は次のように表示されます。

2022-01-14T23:09:13.9087860Z: int ODSUploader::UploadFixedTypeLogs(const string&, const string&, const std::function<void(bool, long unsigned int, int, long unsigned int)>&, int, uint64_t) (.../mdsd/ODSUploader.cc +691) Uploading to ODS with request 3333-44dd-555555eeeeee Host https://00001111-aaaa-2222-bbbb-3333cccc4444.ods.opinsights.azure.com for datatype SECURITY_CEF_BLOB. Payload: {"DataType":"SECURITY_CEF_BLOB","IPName":"SecurityInsights","ManagementGroupId":"00000000-0000-0000-0000-000000000002","sourceHealthServiceId":"2c2c2c2c-3333-dddd-4444-5e5e5e5e5e5e","type":"JsonData","DataItems":[{"Facility":"local0","SeverityNumber":"6","Timestamp":"2022-01-14T23:08:49.731862Z","HostIP":"127.0.0.1","Message":"0|device1|PAN-OS|8.0.0|general|SYSTEM|3|rt=Nov 04 2018 07:15:46 GMTcs3Label=Virtual","ProcessId":"","Severity":"info","Host":"localhost","ident":"CEF"}]}. Uncompressed size: 482. Request size: 350

CEF 処理が成功したことを示す主要なインジケーター:

データタイプはSECURITY_CEF_BLOB
アップロード要求に有効なエンドポイントが含まれている
CEF メッセージ構造はペイロードに保持されます
圧縮メトリックは、データが転送用に最適化されていることを示します

Important

ディスクの過剰な使用を防ぐために、調査を完了した後にトレースフラグを無効にすることを忘れないでください。

診断情報の収集

サポートケースを開く前に、次の情報を収集します。

AMA トラブルシューティングツールを実行する

スクリプトは、ログの種類ごとに特定のフラグを指定して実行できます。

--cef: 一般的なイベント形式のログの場合
--asa: Cisco ASA ログの場合
--ftd: Cisco Firepower Threat Defense のログの場合

出力は /tmp/troubleshooter_output_file.logに保存されます。

sudo wget -O Sentinel_AMA_troubleshoot.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/Syslog/Sentinel_AMA_troubleshoot.py && sudo python3 Sentinel_AMA_troubleshoot.py [--cef | --asa | --ftd]

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-01-12