クライアント アプリケーションがイベント ハブに接続できない場合は、この記事を使用して問題を診断して解決してください。 接続の問題は、永続的な問題 (接続が成功しない) と一時的な問題 (断続的な障害) の 2 つのカテゴリに分類されます。
永続的な問題については、「永続的な接続の問題のトラブルシューティング」セクションに記載されているこれらの設定とその他のオプションを確認してください。
- 接続文字列
- 組織のファイアウォール設定
- IP ファイアウォール設定
- ネットワーク セキュリティ設定 (サービス エンドポイント、プライベート エンドポイントなど)
一時的な問題については、問題のトラブルシューティングに役立つ可能性のある、以下のオプションを試してください。 詳細については、「 一時的な接続の問題のトラブルシューティング」を参照してください。
- 最新バージョンの SDK にアップグレードする
- コマンドを実行して、破棄されたパケットを確認する
- ネットワーク トレースを取得します。
永続的な接続の問題のトラブルシューティング
アプリケーションがイベント ハブにまったく接続できない場合は、このセクションの手順に従って問題のトラブルシューティングを行います。
サービス停止があるかどうかを確認する
Azure サービスの状態サイトで Azure Event Hubs のサービス停止を確認します。
接続文字列を確認する
使用している接続文字列が正しいことを確認します。 Get 接続文字列 を参照して、Azure ポータル、CLI、または PowerShell を使用して接続文字列を取得します。
Kafka クライアントの場合は、 producer.config または consumer.config ファイルが正しく構成されていることを確認します。 詳細については、「Event Hubs で Kafka を使用してメッセージを送受信する」を参照してください。
イベントの送受信に使用できるプロトコルは何ですか?
プロデューサーまたは送信者は、Advanced Messaging Queuing Protocol (AMQP)、Kafka、または HTTPS プロトコルを使用して、イベント ハブにイベントを送信できます。
コンシューマーまたは受信者は AMQP または Kafka を使用して、イベント ハブからイベントを受信します。 Event Hubs は、コンシューマーがイベントを受信できるプル モデルのみをサポートします。 イベント ハンドラーを使用してイベント ハブからのイベントを処理する場合でも、イベント プロセッサは内部的にプル モデルを使用してイベント ハブからイベントを受信します。
AMQP
AMQP 1.0 プロトコルを使用して、Azure Event Hubs との間でイベントを送受信できます。 AMQP により、イベントの送信と受信の両方に、信頼性が高く、パフォーマンスが高く、セキュリティで保護された通信を実現できます。 これは、ハイパフォーマンスのリアルタイム ストリーミングに使用できます。また、ほとんどの Azure Event Hubs SDK でサポートされています。
HTTP/REST API
Event Hubs にイベントを送信できるのは、HTTP POST 要求を使用した場合のみです。 Event Hubs は、HTTPS 経由でのイベントの受信をサポートしていません。 これは、直接 TCP 接続を利用できない軽量クライアントに適しています。
Apache Kafka
Azure Event Hubs には、Kafka プロデューサーとコンシューマーをサポートする Kafka エンドポイントが組み込まれています。 Kafka を使用して構築されたアプリケーションは、コードを変更することなく、Kafka プロトコル (バージョン 1.0 以降) を使用して Event Hubs との間でイベントを送受信できます。
Azure SDK では、基になる通信プロトコルを抽象化し、C#、Java、Python、JavaScript などの言語を使用して Event Hubs からイベントを送受信するための簡略化された方法が提供されます。
ファイアウォールで開く必要があるのはどのポートですか。
Azure Event Hubs でイベントを送受信するために、次のプロトコルを使用できます。
- 高度メッセージキューイングプロトコル1.0(AMQP)
- トランスポート層セキュリティ を使用したハイパーテキスト転送プロトコル 1.1 (HTTPS)
- Apache Kafka
これらのプロトコルを使用して Azure Event Hubs と通信するために開く必要がある送信ポートについては、次の表を参照してください。
| プロトコル | ポート | 詳細 |
|---|---|---|
| AMQP | 5671 と 5672 | AMQP プロトコル ガイドに関するページを参照してください |
| HTTPS | 443 | このポートは、HTTP/REST API と AMQP (WebSocket 経由) で使用されます。 |
| Kafka | 9093 | Kafka アプリケーションからの Event Hubs の使用に関するページをご覧ください |
クライアント SDK によって実行されるいくつかの管理操作と Microsoft Entra ID からのトークンの取得 (使用時) が HTTPS 経由で実行されるため、AMQP がポート 5671 経由で使用される場合も、送信通信には HTTPS ポートが必要です。
公式の Azure SDK では、通常、Event Hubs に対するイベントの送受信で AMQP プロトコルが使用されます。 WebSocket 経由の AMQP プロトコル オプションは、HTTP API と同様に、ポート TCP 443 で実行されますが、それ以外については通常の AMQP と機能的に同じです。 このオプションでは、HTTPS ポートを共有するためのトレードオフとして、追加のハンドシェイクのラウンドトリップが発生し、若干のオーバーヘッドが生じるため、初期接続の待機時間が長くなります。 このモードが選択されている場合は、通信のためには TCP ポート 443 で十分です。 次のオプションでは、通常の AMQP または AMQP WebSocket モードを選択できます。
| Language | オプション |
|---|---|
| .NET | EventHubConnectionOptions.TransportType プロパティが EventHubsTransportType.AmqpTcp または EventHubsTransportType.AmqpWebSockets |
| Java | com.microsoft.azure.eventhubs.EventProcessorClientBuilder.transporttype が AmqpTransportType.AMQP または AmqpTransportType.AMQP_WEB_SOCKETS |
| Node |
EventHubConsumerClientOptions に webSocketOptions プロパティがある。 |
| Python | EventHubConsumerClient.transport_type が TransportType.Amqp または TransportType.AmqpOverWebSocket |
どのような IP アドレスを許可する必要がありますか。
Azure を使用している場合、使用している、または使用しようとしているすべての Azure サービスにアクセスするために、企業のファイアウォールまたはプロキシで特定の IP アドレス範囲または URL を許可することが必要になる場合があります。 Event Hubs によって使用される IP アドレスでトラフィックが許可されていることを確認します。 Azure Event Hubs によって使用される IP アドレスについては、「Azure の IP 範囲とサービス タグ - パブリック クラウド」を参照してください。
また、名前空間の IP アドレスが許可されていることを確認します。 接続を許可する適切な IP アドレスを検索するには、次の手順を実行します。
コマンド プロンプトで、次のコマンドを実行します。
nslookup <YourNamespaceName>.servicebus.windows.netNon-authoritative answerで返された IP アドレスをメモします。
もしあなたの名前空間が ゾーン冗長であれば、 非権威的な回答 セクションの名前には -s1、 -s2、または -s3 の接尾辞が付けられ、可用性ゾーンインスタンスを識別します。 他の2つの接尾辞(例:nslookup)に対して再度<yournamespace>-s2.servicebus.windows.netを実行し、残りの可用性ゾーンインスタンスのIPアドレスを取得します。
注意
nslookup コマンドによって返された IP アドレスは、静的 IP アドレスではありません。 ただし、基になるデプロイが削除されるか別のクラスターに移動されるまでは変わりません。
どのクライアント IP によって名前空間からイベントの送信または受信が行われているか
まず、名前空間で IP フィルターを有効にします。
次に、「診断ログを有効にする」の手順に従って、Event Hubs 仮想ネットワーク接続イベントの診断ログを有効にします。 接続が拒否された IP アドレスが表示されます。
{
"SubscriptionId": "0000000-0000-0000-0000-000000000000",
"NamespaceName": "namespace-name",
"IPAddress": "1.2.3.4",
"Action": "Deny Connection",
"Reason": "IPAddress doesn't belong to a subnet with Service Endpoint enabled.",
"Count": "65",
"ResourceId": "/subscriptions/0000000-0000-0000-0000-000000000000/resourcegroups/testrg/providers/microsoft.eventhub/namespaces/namespace-name",
"Category": "EventHubVNetConnectionEvent"
}
重要
仮想ネットワーク ログが生成されるのは、名前空間で特定の IP アドレス (IP フィルター規則) からのアクセスが許可されている場合のみです。 これらの機能を使用する名前空間へのアクセス制限は行いたくないものの、Event Hubs 名前空間に接続しているクライアントの IP アドレスを追跡する仮想ネットワーク ログは取得したい場合は、IP フィルタリングを有効にし、アドレス指定可能な IPv4 範囲 (0.0.0.0/1 - 128.0.0.0/1) と IPv6 範囲 (::/1 - 8000::/1) をすべて追加するという回避策を使用できます。
注意
現時点では、個々のメッセージまたはイベントのソース IP を特定することはできません。
ネットワーク セキュリティ グループで Event Hubs サービス タグが許可されていることを確認する
アプリケーションがサブネット内で実行され、関連付けられているネットワーク セキュリティ グループがある場合は、インターネット送信トラフィックが許可されているか、Event Hubs サービス タグ (EventHub) が許可されているかを確認します。 「仮想ネットワーク サービス タグ」を参照し、EventHub を検索してください。
アプリケーションを仮想ネットワークの特定のサブネットで実行する必要があるかどうかを確認する
名前空間にアクセスできる仮想ネットワーク サブネットでアプリケーションが実行されていることを確認します。 そうでない場合は、名前空間にアクセスできるサブネットでアプリケーションを実行するか、アプリケーションが実行されているマシンの IP アドレスを IP ファイアウォールに追加します。
イベントハブ名前空間の仮想ネットワーク サービス エンドポイントを作成すると、名前空間では、サービス エンドポイントにバインドされているサブネットからのトラフィックのみを受け入れます。 この動作には例外があります。 イベント ハブのパブリック エンドポイントへのアクセスを有効にするために、IP ファイアウォールで特定の IP アドレスを追加できます。 詳細については、ネットワーク サービス エンドポイントに関するページを参照してください。
名前空間の IP ファイアウォール設定を確認する
アプリケーションが実行されているマシンのパブリック IP アドレスが IP ファイアウォールによってブロックされていないことを確認します。
既定では、要求に有効な認証と承認がある限り、Event Hubs 名前空間にはインターネットからアクセスできます。 IP ファイアウォールを使用すると、これをさらに CIDR (クラスレス ドメイン間ルーティング) 表記の IPv4 や IPv6 のアドレスのセット、またはアドレス範囲のみに制限できます。
IP ファイアウォール規則は、Event Hubs 名前空間レベルで適用されます。 したがって、規則は、サポートされているプロトコルを使用するクライアントからのすべての接続に適用されます。 Event Hubs 名前空間上の許可 IP 規則に合致しない IP アドレスからの接続試行はすべて、未承認として拒否されます。 その応答に、IP 規則に関する記述は含まれません。 IP フィルター規則は順に適用され、IP アドレスと一致する最初の規則に基づいて許可アクションまたは拒否アクションが決定されます。
詳細については、「Azure Event Hubs 名前空間に対する IP ファイアウォール規則を構成する」を参照してください。 IP フィルター処理、仮想ネットワーク、または証明書チェーンの問題があるかどうかを確認するには、「 ネットワーク関連の問題のトラブルシューティング」を参照してください。
プライベート エンドポイントのみを使用して名前空間にアクセスできるかどうかを確認する
Event Hubs がプライベート エンドポイント経由でのみアクセスできるように構成されている場合は、クライアント アプリケーションがプライベート エンドポイント経由で名前空間にアクセスしていることを確認します。
Azure Private Link サービスを使用すると、仮想ネットワーク内のプライベート エンドポイント経由で Azure Event Hubs にアクセスできます。 プライベート エンドポイントとは、Azure Private Link を使用するサービスにプライベートかつ安全に接続するネットワーク インターフェイスです。 プライベート エンドポイントは、ご自分の仮想ネットワークからのプライベート IP アドレスを使用して、サービスを実質的に仮想ネットワークに取り込みます。 サービスへのすべてのトラフィックをプライベート エンドポイント経由でルーティングできるため、ゲートウェイ、NAT デバイス、ExpressRoute または VPN 接続、パブリック IP アドレスは必要ありません。 仮想ネットワークとサービスの間のトラフィックは、Microsoft のバックボーン ネットワークを経由して、パブリック インターネットからの公開を排除します。 最高レベルの細分性でアクセスを制御しながら Azure リソースのインスタンスに接続できます。
詳細については、プライベート エンドポイントの構成に関するページを参照してください。 プライベート エンドポイントが使用されていることを確認するには、プライベート エンドポイント接続の動作検証に関するセクションを参照してください。
ネットワーク関連の問題のトラブルシューティング
Event Hubs に関するネットワーク関連の問題をトラブルシューティングするには、次の手順に従います。
wget を参照するか、 wget を使用して https://<yournamespacename>.servicebus.windows.net/にアクセスします。 この手順は、IP フィルター処理、仮想ネットワーク、または証明書チェーンの問題 (Java SDK の使用時に最も一般的) があるかどうかを確認するのに役立ちます。
成功したメッセージの例を次に示します。
<feed xmlns="http://www.w3.org/2005/Atom"><title type="text">Publicly Listed Services</title><subtitle type="text">This is the list of publicly-listed services currently available.</subtitle><id>uuid:27fcd1e2-3a99-44b1-8f1e-3e92b52f0171;id=30</id><updated>2019-12-27T13:11:47Z</updated><generator>Service Bus 1.1</generator></feed>
失敗したエラー メッセージの例を次に示します。
<Error>
<Code>400</Code>
<Detail>
Bad Request. To know more visit https://aka.ms/sbResourceMgrExceptions. . TrackingId:b786d4d1-cbaf-47a8-a3d1-be689cda2a98_G22, SystemTracker:NoSystemTracker, Timestamp:2019-12-27T13:12:40
</Detail>
</Error>
一時的な接続に関する問題のトラブルシューティング
断続的な接続の問題が発生している場合は、トラブルシューティングのヒントについて次のセクションを参照してください。
最新バージョンのクライアント SDK を使用する
新しいバージョンの SDK では、一時的な接続の問題が修正される可能性があります。 アプリケーションで最新バージョンのクライアント SDK を使用していることを確認します。 SDK は、新機能または更新された機能とバグ修正によって継続的に改善されるため、常に最新のパッケージでテストしてください。 修正された問題と追加または更新された機能については、リリース ノートを確認してください。
クライアント SDK の詳細については、「Azure Event Hubs - クライアント SDK」を参照してください。
コマンドを実行して、破棄されたパケットを確認する
断続的な接続の問題がある場合は、次のコマンドを実行して、破棄されたパケットがあるかどうかを確認します。 このコマンドは、1 秒ごとに 25 件の異なる TCP 接続をサービスと確立しようとします。 その後、成功または失敗した数を確認し、TCP 接続の待機時間も確認できます。
psping ツールは、ここからダウンロードできます。
.\psping.exe -n 25 -i 1 -q <yournamespacename>.servicebus.windows.net:5671 -nobanner
tnc やping などの他のツールを使用している場合は、同等のコマンドを使用できます。
前の手順で解決できない場合は、ネットワーク トレースを取得して Wireshark などのツールを使用して分析します。 必要に応じて Microsoft サポート にお問い合わせください。
サービスのアップグレードと再起動
バックエンド サービスのアップグレードと再起動により、一時的な接続の問題が発生する可能性があります。 これらの問題が発生すると、次の現象が発生する可能性があります。
- 受信メッセージまたは要求が削除されます。
- ログ ファイルにエラー メッセージが表示されます。
- アプリケーションは数秒間サービスから切断されます。
- 要求は一時的に制限されます。
アプリケーション コードで SDK を使用している場合は、アクティブな再試行ポリシーが既に存在します。 アプリケーションは、アプリケーションまたはワークフローに大きな影響を与えずに再接続します。 これらの一時的なエラーをキャッチし、バックオフし、呼び出しを再試行することで、コードでこれらの一時的な問題を処理できることを確認します。
次のステップ
次の記事をご覧ください。