接続に関する問題のトラブルシューティング - Azure Event Hubs

クライアント アプリケーションがイベント ハブに接続できない理由はさまざまです。 接続の問題は、永続的である場合もあれば、一時的である場合もあります。

問題が毎回 (永続的に) 発生する場合は、この記事の「永続的な接続の問題のトラブルシューティング」セクションに記載されている、以下の設定とその他のオプションを確認してください。

• 接続文字列
• 組織のファイアウォール設定
• IP ファイアウォール設定
• ネットワーク セキュリティ設定 (サービス エンドポイント、プライベート エンドポイントなど)、その他の設定

一時的な問題については、問題のトラブルシューティングに役立つ可能性のある、以下のオプションを試してください。 詳細については、「一時的な接続の問題のトラブルシューティング」を参照してください。

• 最新バージョンの SDK にアップグレードする
• コマンドを実行して、破棄されたパケットを確認する
• ネットワーク トレースを取得します。

永続的な接続の問題のトラブルシューティング

アプリケーションがイベント ハブにまったく接続できない場合は、このセクションの手順に従って問題のトラブルシューティングを行います。

サービス停止があるかどうかを確認する

Azure サービスの状態サイトで Azure Event Hubs のサービス停止を確認します。

接続文字列を確認する

使用している接続文字列が正しいことを確認します。 Azure portal、CLI、または PowerShell を使用して接続文字列を取得するには、接続文字列の取得に関するページを参照してください。

Kafka クライアントの場合、producer.config または consumer.config の各ファイルが正しく構成されていることを確認します。 詳細については、「Event Hubs で Kafka を使用してメッセージを送受信する」を参照してください。

ファイアウォールで開く必要があるのはどのポートですか。

Azure Event Hubs でイベントを送受信するために、次のプロトコルを使用できます。

• Advanced Message Queuing Protocol 1.0 (AMQP)
• トランスポート層セキュリティ を使用したハイパーテキスト転送プロトコル 1.1 (HTTPS)
• Apache Kafka

これらのプロトコルを使用して Azure 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 モードを選択できます。

どのような IP アドレスを許可する必要がありますか。

Azure を使用している場合、使用している、または使用しようとしているすべての Azure サービスにアクセスするために、企業のファイアウォールまたはプロキシで特定の IP アドレス範囲または URL を許可することが必要になる場合があります。 Event Hubs によって使用される IP アドレスでトラフィックが許可されていることを確認します。 Azure Event Hubs によって使用される IP アドレスについては、「Azure の IP 範囲とサービス タグ - パブリック クラウド」を参照してください。

また、名前空間の IP アドレスが許可されていることを確認します。 接続を許可する適切な IP アドレスを検索するには、次の手順を実行します。

1. コマンド プロンプトで、次のコマンドを実行します。

   nslookup <YourNamespaceName>.servicebus.windows.net
   

2. Non-authoritative answer で返された IP アドレスをメモします。

古いクラスター (Cloud Services がベース、つまり CNAME が *.cloudapp.net で終わる) でホストされている名前空間を使用していて、名前空間がゾーン冗長の場合は、以下のいくつかの追加手順に従う必要があります。 名前空間が新しいクラスター (仮想マシン スケール セット (VMSS) がベース、つまり CNAME が *.cloudapp.azure.com で終わる) でゾーン冗長上にある場合は、以下の手順をスキップできます。

1. まず、名前空間に対して nslookup を実行します。

   nslookup <yournamespace>.servicebus.windows.net
   

2. non-authoritative answer セクションの名前をメモします。これは、次のいずれかの形式になります。

   <name>-s1.cloudapp.net
   <name>-s2.cloudapp.net
   <name>-s3.cloudapp.net
   

3. 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"
}

ネットワーク セキュリティ グループで 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 を利用している場合、再試行ポリシーは既に組み込まれており、アクティブになっています。 アプリケーションやワークフローに大きな影響を与えずに、アプリケーションは再接続されます。 これらの一時的なエラーを捕捉して、一旦元に戻った後、呼び出しを再試行することで、コードにこれらの一時的な問題に対する回復性を持たせることができます。

次のステップ

次の記事をご覧ください。

• 認証と承認の問題のトラブルシューティング