Microsoft Azure イベント・ハブ・プロトコルの FAQ

以下のよくある質問と回答を使用して、 Microsoft Azure Event Hubs プロトコルを理解してください。

イベント・ハブに接続するためにストレージ・アカウントが必要なのはなぜですか?

イベント・ハブのリースとパーティションを管理するには、 Microsoft Azure Event Hubs プロトコル用のストレージ・アカウントが必要です。 詳しくは、 イベント処理プログラム・ホストの資料 (https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-event-processor-host) を参照してください。

Microsoft Azure Event Hubs プロトコルがストレージ・アカウントを使用するのはなぜですか?

Microsoft Azure Event Hubs プロトコルは、ストレージ・アカウントを使用してパーティションの所有権を追跡します。 このプロトコルによって、<Event Hub Name> → <Consumer group Name> ディレクトリー内の Azure ストレージ・アカウントに Blob ファイルが作成されます。 各 Blob ファイルは、イベント・ハブによって管理される番号付きパーティションに関連しています。 詳細については、イベント処理プログラムのホストドキュメント (https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-event-processor-host) を参照してください。

ストレージ・アカウントが保管する必要があるデータの量はどの程度ですか?

ストレージ・アカウントに保管する必要があるデータの量は、パーティションの数に最大 150 バイトを掛けた値です。

ストレージ・アカウントにイベントを含める必要がありますか?

いいえ。 ログをストレージに保管することは、Microsoft が提供するオプションです。 ただし、このオプションはプロトコルでは使用されません。

Microsoft Azure Event Hubs プロトコルによって作成される BLOB ファイルはどのようなものですか?

次の例は、プロトコルによって作成された Blob ファイルに保管される内容を示したものです。
{"offset":"@latest","sequenceNumber":0,"partitionId":"3","epoch":8,"owner":"","token":""}”

他のイベント・ハブと同じストレージ・アカウントを使用できますか?

ストレージ・アカウントにデータを保管できるイベント・ハブの数に制限はありません。 同じ QRadar® 環境内のすべてのログ・ソースに対して同じストレージ・アカウントを使用できます。 これにより、すべてのイベント・ハブ・パーティション管理フォルダーおよびファイル用の単一の場所が作成されます。

プロトコルがイベントを収集していない場合はどうすればよいですか?

プロトコルが機能しているように見えて、プロトコル・テスト・ツールがすべてのテストに合格し、イベントが表示されない場合は、以下のステップに従ってイベントがポストされたかどうかを確認します。
  1. イベント・ハブが収集するイベントがあることを確認します。 Azure 側の構成が正しくない場合、イベント・ハブはイベントを収集しない可能性があります。
  2. 「ゲートウェイ・ログ・ソースとして使用 (Use as a Gateway Log Source)」が有効な場合、Event Hub ログ・ソースが収集したイベントがないかペイロード検索を実行します。 イベントがどのように表示されるかがわからない場合は、ステップ 4 に進みます。
  3. 「ゲートウェイ・ログ・ソースとして使用 (Use as a Gateway Log Source)」オプションが有効になっていて、プロトコルがイベントを収集していない場合、ゲートウェイを無効にして同じログ・ソースをテストします。 「ゲートウェイ・ログ・ソースとして使用 (Use as a Gateway Log Source)」を無効に設定すると、収集されるすべてのイベントは、プロトコルに接続されているログ・ソースを使用するように強制されます。 「ゲートウェイ・ログ・ソースとして使用 (Use as a Gateway Log Source)」が無効になっているときにイベントを受信しているが、「ゲートウェイ・ログ・ソースとして使用 (Use as a Gateway Log Source)」が有効になっているときにイベントを受信しない場合、ログ・ソース ID オプションに問題があるか、トラフィック分析はイベントを DSM に自動的に突き合わせることができません。
  4. ステップ 2 またはステップ 3 で、予期されるログ・ソースからイベントを受信しないことが確認された場合、イベント・ハブのログ・ソース logsourceidentifierpattern に問題がある可能性があります。 イベント・ハブのログ・ソース ID パターンに関連する問題については、サポートへの問い合わせが必要な場合があります。

ポートが異なる 2 つの異なる IP のポートを開く必要があるのはなぜですか?

Microsoft Azure Event Hub プロトコルはイベント・ハブ・ホストとストレージ・アカウント・ホストの間で通信するため、異なるポートを開くには 2 つの異なる IP が必要です。

イベント・ハブ接続は、ポート 5671 および 5672 の Advanced Message Queuing Protocol (AMQP) を使用します。 ストレージ・アカウントは、ポート 443 の HTTPS を使用します。 ストレージ・アカウントとイベント・ハブの IP は異なるため、2 つの異なるポートを開く必要があります。

Microsoft Event Hubs プロトコルを使用して < Service/Product> イベントを収集できますか?

Microsoft Event Hubs プロトコルは、イベント・ハブに送信されるすべてのイベントを収集しますが、サポートされる DSM によってすべてのイベントが解析されるわけではありません。 サポートされる DSM のリストについては、 QRadar でサポートされる DSMを参照してください。

「 Azure Linux Events To Syslog のフォーマット」 オプションは何を行いますか?

このオプションは、 Azure Linux® イベントを受け取ります。このイベントは、メタデータを含む JSON 形式でラップされ、標準の syslog 形式に変換されます。 ペイロードのメタデータが必要な特定の理由がない限り、このオプションを有効にしてください。 このオプションを無効にすると、ペイロードは Linux DSM で解析されません。

( 上に戻る )