針對連線問題進行疑難排解 - Azure 事件中樞
用戶端應用程式無法連線到事件中樞的原因有很多種。 連線問題可能是永久性或暫時性的。
如果此問題持續發生 (永久),請檢查本文針對永久性連線問題進行疑難排解一節中提及的設定和其他選項。
- Connection string
- 貴組織的防火牆設定
- IP 防火牆設定
- 網路安全性設定 (服務端點、私人端點等) 和其他設定
若為暫時性問題,請嘗試下列選項,以協助對問題進行疑難排解。 如需詳細資訊,請參閱針對暫時性連線問題進行疑難排解。
- 升級至最新版本的 SDK
- 執行命令以檢查捨棄的封包
- 取得網路追蹤。
針對永久性連線問題進行疑難排解
如果應用程式完全無法連線到事件中樞,請遵循本節中的步驟來針對問題進行疑難排解。
檢查是否有服務中斷的情形
在 Azure 服務狀態網站上檢查 Azure 事件中樞的服務中斷。
確認連線字串
確認所使用的連接字串正確無誤。 請參閱取得連接字串,以使用 Azure 入口網站、CLI 或 PowerShell 來取得連接字串。
如果是 Kafka 用戶端,則請確認 producer.config 或 consumer.config 檔案的設定是否正確。 如需詳細資訊,請參閱使用事件中樞內的 Kafka 傳送及接收訊息。
我可以使用哪些通訊協議來傳送和接收事件?
產生者或寄件者可以使用進階傳訊佇列通訊協定(AMQP)、Kafka 或 HTTPS 通訊協定,將事件傳送至事件中樞。
取用者或接收者會使用AMQP或 Kafka 從事件中樞接收事件。 事件中樞僅支持取用者從中接收事件的提取模型。 即使您使用事件處理程式來處理事件中樞的事件,事件處理器內部也會使用提取模型從事件中樞接收事件。
AMQP
您可以使用AMQP 1.0通訊協定,將事件傳送至 Azure 事件中樞 並從 Azure 事件中樞 接收事件。 AMQP 為傳送和接收事件提供可靠、高效能且安全的通訊。 您可以將其用於高效能和即時串流,而且大部分 Azure 事件中樞 SDK 都支援。
HTTPS/REST API
您只能使用 HTTP POST 要求將事件傳送至事件中樞。 事件中樞不支援透過 HTTPS 接收事件。 它適用於無法進行直接 TCP 連線的輕量型用戶端。
Apache Kafka
Azure 事件中樞 具有內建的 Kafka 端點,可支援 Kafka 生產者和取用者。 使用 Kafka 建置的應用程式可以使用 Kafka 通訊協定(1.0 版或更新版本)從事件中樞傳送和接收事件,而不需要變更任何程式代碼。
Azure SDK 會抽象基礎通訊協定,並提供簡化的方式,使用 C#、Java、Python、JavaScript 等語言從事件中樞傳送和接收事件。
我需要在防火牆上開啟哪些連接埠?
您可以使用下列通訊協定搭配 Azure 事件中樞來傳送和接收事件:
- 進階訊息佇列通訊協定 1.0 (AMQP)
- 具有傳輸層安全性的超文字傳輸通訊協定 1.1 (HTTPS)
- Apache Kafka
請參閱下表,了解您需要開啟哪些輸出連接埠,以使用這些通訊協定與 Azure 事件中樞進行通訊。
通訊協定 | 連接埠 | 詳細資料 |
---|---|---|
AMQP | 5671 與 5672 | 請參閱 AMQP 通訊協定指南 |
HTTPS | 443 | 此連接埠用於 HTTP/REST API 和透過 WebSocket 的 AMQP。 |
Kafka | 9093 | 請參閱從 Kafka 應用程式使用事件中樞 |
透過連接埠 5671 使用 AMQP 時,必須使用 HTTPS 連接埠才能進行輸出通訊,因為用戶端 SDK 執行的數個管理作業及從 Microsoft Entra ID (若有使用) 取得權杖的作業都要透過 HTTPS 執行。
官方 Azure SDK 通常會使用 AMQP 通訊協定,從事件中樞傳送和接收事件。 透過 WebSocket 的 AMQP 通訊協定選項會透過連接埠 TCP 443 (和 HTTP API 一樣) 來執行,但在功能上與一般 AMQP 並無不同。 此選項的初始連線延遲較高 (因為會進行額外的交握來回行程),額外負荷也會多一點 (以便能共用 HTTPS 連接埠)。 如果選取此模式,則 TCP 連接埠 443 就足供進行通訊。 下列選項可供選取一般 AMQP 或 AMQP WebSocket 模式:
需要允許哪些 IP 位址?
在使用 Azure 時,有時候必須在公司防火牆或 Proxy 中允許特定 IP 位址範圍或 URL 存取您所使用或嘗試使用的所有 Azure 服務。 請確認事件中樞所使用的 IP 位址上已允許該流量。 若要了解 Azure 事件中樞所使用的 IP 位址:請參閱 Azure IP 範圍和服務標籤 - 公用雲端。
此外,也請確認是否已允許命名空間的 IP 位址。 若要尋找要允許連線使用的正確 IP 位址,請遵循下列步驟:
從命令提示字元執行下列命令:
nslookup <YourNamespaceName>.servicebus.windows.net
記下
Non-authoritative answer
中傳回的 IP 位址。
如果您使用裝載在較舊叢集中的命名空間(根據 雲端服務 - CNAME 結尾為 *.cloudapp.net),且命名空間是區域備援,您必須遵循幾個額外的步驟。 如果您的命名空間位於較新的叢集上(根據以 *.cloudapp.azure.com 結尾的虛擬機擴展集 - CNAME 和區域備援,您可以略過下列步驟。
首先,在命名空間上執行 nslookup。
nslookup <yournamespace>.servicebus.windows.net
記下 [非授權回答] 區段中的名稱,其採用下列其中一種格式:
<name>-s1.cloudapp.net <name>-s2.cloudapp.net <name>-s3.cloudapp.net
針對尾碼為 s1、s2 和 s3 的每個名稱執行 nslookup,以取得三個執行個體全都在三個可用性區域執行的 IP 位址。
注意
nslookup
命令傳回的 IP 位址不是靜態 IP 位址。 不過,該位址會保持不變,直到基礎部署被刪除或移至不同的叢集為止。
哪些用戶端 IP 會在我的命名空間中傳送事件或接收事件?
首先,在命名空間上啟用 IP 篩選。
然後,遵循啟用診斷記錄中的指示,為事件中樞虛擬網路連線事件啟用診斷記錄。 您會看到連線遭到拒絕的 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 篩選器規則) 進行存取時,才會產生虛擬網路記錄。 如果您不想要使用這些功能來限制對命名空間的存取權,但仍想要取得虛擬網路記錄來追蹤連線至事件中樞命名空間的用戶端 IP 位址,您可以使用下列因應措施:啟用 IP 篩選,並新增整個可定址的 IPv4 範圍 (0.0.0.0/1
- 128.0.0.0/1
) 和 IPv6 範圍 (::/1
- 8000::/1
)。
注意
目前無法判斷個別訊息或事件的來源 IP。
確認網路安全性群組中允許事件中樞服務標記
如果應用程式在子網路內執行,而且有相關聯的網路安全性群組,請確認是否已允許網際網路輸出流量,或是否已允許事件中樞服務標籤 (EventHub
)。 請參閱虛擬網路服務標籤,並搜尋 EventHub
。
檢查應用程式是否需要在虛擬網路的特定子網路中執行
確認應用程式是在可存取命名空間的虛擬網路子網路中執行。 如果不是,請在可存取命名空間的子網路中執行應用程式,或將應用程式執行所在機器的 IP 位址新增至 IP 防火牆。
為事件中樞命名空間建立虛擬網路服務端點時,命名空間只會接受與服務端點繫結的子網路所傳來的流量。 此行為有例外狀況。 您可在 IP 防火牆中新增特定 IP 位址,以啟用事件中樞公用端點的存取權。 如需詳細資訊,請參閱網路服務端點。
檢查命名空間的 IP 防火牆設定
檢查確認 IP 防火牆並未封鎖應用程式執行所在機器的公用 IP 位址。
根據預設,只要要求具備有效的驗證和授權,便可以從網際網路存取事件中樞命名空間。 透過 IP 防火牆,您可以將其進一步限制為僅允許一組 IPv4 或 IPv6 位址,或是使用 CIDR (無類別網域間路由) 標記法來設定位址範圍。
IP 防火牆規則會在事件中樞命名空間層級套用。 因此,規則會套用至來自用戶端的所有連接 (使用任何受支援的通訊協定)。 任何來自某個 IP 位址的連線嘗試,只要不符合事件中樞命名空間上的允許 IP 規則,系統就會將其視為未經授權而予以拒絕。 回應不會提及 IP 規則。 IP 篩選器規則會依序套用,而且第一個符合 IP 位址的規則會決定接受或拒絕動作。
如需詳細資訊,請參閱設定 Azure 事件中樞命名空間的 IP 防火牆規則。 若要檢查您是否有 IP 篩選、虛擬網路或憑證鏈結的問題,請參閱針對網路相關問題進行疑難排解。
檢查是否只能使用私人端點來存取命名空間
如果事件中樞命名空間設定為只能透過私人端點來存取,請確認用戶端應用程式會透過私人端點來存取命名空間。
Azure Private Link 服務可讓您透過虛擬網路中的私人端點來存取 Azure 事件中樞。 私人端點是一種網路介面,其可以私人且安全的方式連線至 Azure Private Link 所支援服務。 私人端點會使用您虛擬網路中的私人 IP 位址,有效地將服務帶入您的虛擬網路中。 服務的所有流量都可以透過私人端點路由傳送,因此不需要閘道、NAT 裝置、ExpressRoute 或 VPN 連線或公用 IP 位址。 虛擬網路和服務間的流量會在通過 Microsoft 骨幹網路時隨之減少,降低資料在網際網路中公開的風險。 您可以連線至 Azure 資源的執行個體,以提供您存取控制中最高層級的細微性。
如需詳細資訊,請參閱設定私人端點。 請參閱驗證私人端點連線可運作一節,以確認您已使用私人端點。
針對網路相關問題進行疑難排解
若要針對事件中樞的網路相關問題進行疑難排解,請遵循下列步驟:
瀏覽至或 wgethttps://<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 事件中樞 - 用戶端 SDK 一文。
執行命令以檢查捨棄的封包
如果有間歇性的連線問題,請執行下列命令來檢查是否有任何封包遭到捨棄。 此命令會嘗試每隔 1 秒便與服務建立 25 個不同的 TCP 連線。 然後,您可以檢查其中有多少連線成功/失敗,另外也可以查看 TCP 連線延遲。 您可以從這裡下載 psping
工具。
.\psping.exe -n 25 -i 1 -q <yournamespacename>.servicebus.windows.net:5671 -nobanner
如果您使用的是 tnc
、ping
等其他工具,則可以使用對等的命令。
如果先前的步驟無法提供協助,請取得網路追蹤,然後使用 Wireshark 等工具進行分析。 如有需要,請連絡 Microsoft 支援服務。
服務升級/重新啟動
暫時性連線問題可能是因為後端服務升級和重新啟動所造成的。 在發生這些問題時,您可能會看到下列徵兆:
- 傳入的訊息/要求中可能有捨棄情形。
- 記錄檔可能包含錯誤訊息。
- 應用程式與服務的連線可能會中斷幾秒鐘。
- 要求可能會短暫節流。
如果應用程式的程式碼使用 SDK,便已內建並啟用重試原則。 該應用程式會重新連線,不會對應用程式/工作流程產生重大影響。 攔截這些暫時性錯誤、退出,然後再試著呼叫一次,便會確保程式碼能從這些暫時性問題復原。
下一步
請參閱以下文章: