接続に関する問題のトラブルシューティング - Azure Event Hubs
クライアント アプリケーションがイベント ハブに接続できない理由はさまざまです。 接続の問題は、永続的である場合もあれば、一時的である場合もあります。
問題が毎回 (永続的に) 発生する場合は、この記事の「永続的な接続の問題のトラブルシューティング」セクションに記載されている、以下の設定とその他のオプションを確認してください。
- 接続文字列
- 組織のファイアウォール設定
- IP ファイアウォール設定
- ネットワーク セキュリティ設定 (サービス エンドポイント、プライベート エンドポイントなど)、その他の設定
一時的な問題については、問題のトラブルシューティングに役立つ可能性のある、以下のオプションを試してください。 詳細については、「一時的な接続の問題のトラブルシューティング」を参照してください。
- 最新バージョンの SDK にアップグレードする
- コマンドを実行して、破棄されたパケットを確認する
- ネットワーク トレースを取得します。
永続的な接続の問題のトラブルシューティング
アプリケーションがイベント ハブにまったく接続できない場合は、このセクションの手順に従って問題のトラブルシューティングを行います。
サービス停止があるかどうかを確認する
Azure サービスの状態サイトで Azure Event Hubs のサービス停止を確認します。
接続文字列を確認する
使用している接続文字列が正しいことを確認します。 Azure portal、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 でサポートされています。
HTTPS/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 でイベントを送受信するために、次のプロトコルを使用できます。
- Advanced Message Queuing Protocol 1.0 (AMQP)
- トランスポート層セキュリティ を使用したハイパーテキスト転送プロトコル 1.1 (HTTPS)
- Apache Kafka
これらのプロトコルを使用して Azure Event Hubs と通信するために開く必要がある送信ポートについては、次の表を参照してください。
Protocol | Port | 詳細 |
---|---|---|
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 モードを選択できます。
言語 | オプション |
---|---|
.NET | EventHubConnectionOptions.TransportType プロパティが EventHubsTransportType.AmqpTcp または EventHubsTransportType.AmqpWebSockets |
Java | com.microsoft.azure.eventhubs.EventProcessorClientBuilder.transporttype が AmqpTransportType.AMQP または AmqpTransportType.AMQP_WEB_SOCKETS |
ノード | 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.net
Non-authoritative answer
で返された IP アドレスをメモします。
以前のクラスター (Cloud Services に基づく - CNAME が *.cloudapp.net で終わる) でホストされている名前空間を使用しており、その名前空間がゾーン冗長である場合は、いくつかの追加手順に従う必要があります。 名前空間が新しいクラスター (仮想マシン スケール セットに基づく - CNAME が *.cloudapp.azure.com で終わる) 上にあり、ゾーン冗長である場合は、以下の手順をスキップできます。
まず、名前空間に対して nslookup を実行します。
nslookup <yournamespace>.servicebus.windows.net
non-authoritative answer セクションの名前をメモします。これは、次のいずれかの形式になります。
<name>-s1.cloudapp.net <name>-s2.cloudapp.net <name>-s3.cloudapp.net
s1、s2、s3 のサフィックスが付いているそれぞれについて nslookup を実行し、3 つの可用性ゾーンで実行されている 3 つのインスタンスすべての 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
) をすべて追加するという回避策を使用できます。
Note
現時点では、個々のメッセージまたはイベントのソース 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 のネットワーク関連の問題をトラブルシューティングするには、次の手順を実行します。
https://<yournamespacename>.servicebus.windows.net/
の参照または wget を行います。 これは、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
からダウンロードできます。
.\psping.exe -n 25 -i 1 -q <yournamespacename>.servicebus.windows.net:5671 -nobanner
tnc
やping
などの他のツールを使用している場合は、同等のコマンドを使用できます。
前の手順で解決できない場合は、ネットワーク トレースを取得して Wireshark などのツールを使用して分析します。 必要に応じて Microsoft サポート にお問い合わせください。
サービスのアップグレードまたは再起動
バックエンド サービスのアップグレードと再起動が原因で、一時的な接続の問題が発生する場合があります。 これが発生している場合は、以下の現象が確認される可能性があります。
- 受信したメッセージや要求が破棄される可能性があります。
- ログ ファイルにエラー メッセージが含まれる可能性があります。
- アプリケーションが数秒間サービスから切断される可能性があります。
- 要求が一時的に抑えられる場合があります。
アプリケーションのコードで SDK を利用している場合、再試行ポリシーは既に組み込まれており、アクティブになっています。 アプリケーションやワークフローに大きな影響を与えずに、アプリケーションは再接続されます。 これらの一時的なエラーを捕捉して、一旦元に戻った後、呼び出しを再試行することで、コードにこれらの一時的な問題に対する回復性を持たせることができます。
次のステップ
次の記事をご覧ください。