Rozwiązywanie problemów z łącznością — Azure Event Hubs
Aplikacje klienckie mogą mieć problemy z nawiązaniem połączenia z centrum zdarzeń z wielu różnych powodów. Problemy z łącznością mogą być trwałe lub przejściowe.
Jeśli problem występuje przez cały czas (stały), sprawdź te ustawienia i inne opcje wymienione w sekcji Rozwiązywanie stałych problemów z łącznością w tym artykule.
- Connection string
- Ustawienia zapory organizacji
- Ustawienia zapory IP
- Ustawienia zabezpieczeń sieci (punkty końcowe usługi, prywatne punkty końcowe itp.) i inne
W przypadku problemów przejściowych wypróbuj następujące opcje, które mogą pomóc w rozwiązywaniu problemów. Aby uzyskać więcej informacji, zobacz Rozwiązywanie przejściowych problemów z łącznością.
- Uaktualnianie do najnowszej wersji zestawu SDK
- Uruchamianie poleceń w celu sprawdzenia porzuconych pakietów
- Uzyskaj informacje na temat śledzenia sieci.
Rozwiązywanie stałych problemów z łącznością
Jeśli aplikacja w ogóle nie może nawiązać połączenia z centrum zdarzeń, wykonaj kroki opisane w tej sekcji, aby rozwiązać ten problem.
Sprawdź, czy wystąpiła awaria usługi
Sprawdź awarię usługi Azure Event Hubs w lokacji stanu usługi platformy Azure.
Weryfikowanie parametry połączenia
Sprawdź, czy używany parametry połączenia jest poprawny. Zobacz Uzyskiwanie parametry połączenia, aby uzyskać parametry połączenia przy użyciu witryny Azure Portal, interfejsu wiersza polecenia lub programu PowerShell.
W przypadku klientów platformy Kafka sprawdź, czy pliki producer.config lub consumer.config są prawidłowo skonfigurowane. Aby uzyskać więcej informacji, zobacz Wysyłanie i odbieranie komunikatów za pomocą platformy Kafka w usłudze Event Hubs.
Jakich protokołów mogę używać do wysyłania i odbierania zdarzeń?
Producenci lub nadawcy mogą wysyłać zdarzenia do centrum zdarzeń przy użyciu protokołu Advanced Messaging Queuing Protocol (AMQP), Kafka lub HTTPS.
Odbiorcy lub odbiorcy używają protokołu AMQP lub platformy Kafka do odbierania zdarzeń z centrum zdarzeń. Usługa Event Hubs obsługuje tylko model ściągania, który umożliwia konsumentom odbieranie z niego zdarzeń. Nawet w przypadku używania programów obsługi zdarzeń do obsługi zdarzeń z centrum zdarzeń procesor zdarzeń wewnętrznie używa modelu ściągania do odbierania zdarzeń z centrum zdarzeń.
AMQP
Protokół AMQP 1.0 umożliwia wysyłanie zdarzeń do usługi Azure Event Hubs i odbieranie zdarzeń. Protokół AMQP zapewnia niezawodną, wydajną i bezpieczną komunikację zarówno do wysyłania, jak i odbierania zdarzeń. Można go używać do przesyłania strumieniowego o wysokiej wydajności i czasie rzeczywistym i jest obsługiwany przez większość zestawów SDK usługi Azure Event Hubs.
HTTPS/REST API
Zdarzenia można wysyłać tylko do usługi Event Hubs przy użyciu żądań HTTP POST. Usługa Event Hubs nie obsługuje odbierania zdarzeń za pośrednictwem protokołu HTTPS. Jest odpowiedni dla lekkich klientów, gdzie bezpośrednie połączenie TCP nie jest możliwe.
Apache Kafka
Usługa Azure Event Hubs ma wbudowany punkt końcowy platformy Kafka, który obsługuje producentów i konsumentów platformy Kafka. Aplikacje utworzone przy użyciu platformy Kafka mogą używać protokołu Kafka (w wersji 1.0 lub nowszej) do wysyłania i odbierania zdarzeń z usługi Event Hubs bez żadnych zmian w kodzie.
Zestawy SDK platformy Azure tworzą abstrakcję podstawowych protokołów komunikacyjnych i zapewniają uproszczony sposób wysyłania i odbierania zdarzeń z usługi Event Hubs przy użyciu języków takich jak C#, Java, Python, JavaScript itp.
Jakie porty należy otworzyć w zaporze?
Do wysyłania i odbierania zdarzeń można użyć następujących protokołów w usłudze Azure Event Hubs:
- Advanced Message Queuing Protocol 1.0 (AMQP)
- Protokół hypertext Transfer Protocol 1.1 z protokołem Transport Layer Security (HTTPS)
- Apache Kafka
Poniższa tabela zawiera porty wychodzące, które należy otworzyć, aby używać tych protokołów do komunikowania się z usługą Azure Event Hubs.
Protokół | Porty | Szczegóły |
---|---|---|
AMQP | 5671 i 5672 | Zobacz Przewodnik po protokole AMQP |
HTTPS | 443 | Ten port jest używany dla interfejsu API HTTP/REST i dla obiektów AMQP-over-WebSocket. |
Kafka | 9093 | Zobacz Używanie usługi Event Hubs z aplikacji platformy Kafka |
Port HTTPS jest wymagany do komunikacji wychodzącej również wtedy, gdy protokół AMQP jest używany przez port 5671, ponieważ kilka operacji zarządzania wykonywanych przez zestawy SDK klienta i uzyskiwanie tokenów z identyfikatora Entra firmy Microsoft (jeśli jest używane) działa za pośrednictwem protokołu HTTPS.
Oficjalne zestawy SDK platformy Azure zwykle używają protokołu AMQP do wysyłania i odbierania zdarzeń z usługi Event Hubs. Opcja protokołu AMQP-over-WebSockets działa za pośrednictwem portu TCP 443, podobnie jak interfejs API HTTP, ale w przeciwnym razie jest funkcjonalnie taka sama jak zwykły protokół AMQP. Ta opcja ma większe opóźnienie początkowego połączenia z powodu dodatkowego uzgadniania rund i nieco większego obciążenia w miarę kompromisu związanego z udostępnianiem portu HTTPS. Jeśli ten tryb jest wybrany, port TCP 443 jest wystarczający do komunikacji. Następujące opcje umożliwiają wybranie zwykłego trybu protokołu AMQP lub protokołu WEBSocket protokołu AMQP:
Język | Opcja |
---|---|
.NET | EventHubConnectionOptions.TransportType z właściwością EventHubsTransportType.AmqpTcp lub EventHubsTransportType.AmqpWebSockets |
Java | com.microsoft.azure.eventhubs.EventProcessorClientBuilder.transporttype with AmqpTransportType.AMQP or AmqpTransportType.AMQP_WEB_SOCKETS |
Węzeł | Właściwość EventHubConsumerClientOptions.webSocketOptions |
Python | EventHubConsumerClient.transport_type z protokołem TransportType.Amqp lub TransportType.AmqpOverWebSocket |
Jakie adresy IP muszę zezwolić?
Podczas pracy z platformą Azure czasami musisz zezwolić określonym zakresom adresów IP lub adresom URL w zaporze firmowej lub serwerze proxy na dostęp do wszystkich usług platformy Azure, których używasz lub których próbujesz użyć. Sprawdź, czy ruch jest dozwolony na adresach IP używanych przez usługę Event Hubs. Adresy IP używane przez usługę Azure Event Hubs: zobacz Zakresy adresów IP platformy Azure i tagi usług — chmura publiczna.
Sprawdź również, czy adres IP przestrzeni nazw jest dozwolony. Aby znaleźć odpowiednie adresy IP, aby zezwolić na połączenia, wykonaj następujące kroki:
Uruchom następujące polecenie w wierszu polecenia:
nslookup <YourNamespaceName>.servicebus.windows.net
Zanotuj adres IP zwrócony w pliku
Non-authoritative answer
.
Jeśli używasz przestrzeni nazw hostowanej w starszym klastrze (w oparciu o usługi Cloud Services — CNAME kończące się na *.cloudapp.net), a przestrzeń nazw jest strefowo nadmiarowa, należy wykonać kilka dodatkowych kroków. Jeśli przestrzeń nazw znajduje się w nowszym klastrze (opartym na zestawie skalowania maszyn wirtualnych — CNAME kończącym się na *.cloudapp.azure.com) i strefowo nadmiarowym, możesz pominąć poniższe kroki.
Najpierw uruchom polecenie nslookup w przestrzeni nazw.
nslookup <yournamespace>.servicebus.windows.net
Zanotuj nazwę w sekcji odpowiedzi nieautorytatywnej, która jest w jednym z następujących formatów:
<name>-s1.cloudapp.net <name>-s2.cloudapp.net <name>-s3.cloudapp.net
Uruchom polecenie nslookup dla każdego z sufiksami s1, s2 i s3, aby uzyskać adresy IP wszystkich trzech wystąpień uruchomionych w trzech strefach dostępności,
Uwaga
Adres IP zwracany przez
nslookup
polecenie nie jest statycznym adresem IP. Pozostaje jednak stała do momentu usunięcia lub przeniesienia bazowego wdrożenia do innego klastra.
Jakie adresy IP klienta wysyłają zdarzenia do mojej przestrzeni nazw lub odbierają zdarzenia?
Najpierw włącz filtrowanie adresów IP w przestrzeni nazw.
Następnie włącz dzienniki diagnostyczne dla zdarzeń połączenia sieci wirtualnej usługi Event Hubs, postępując zgodnie z instrukcjami w obszarze Włączanie dzienników diagnostycznych. Zostanie wyświetlony adres IP, dla którego połączenie zostało odrzucone.
{
"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"
}
Ważne
Dzienniki sieci wirtualnej są generowane tylko wtedy, gdy przestrzeń nazw zezwala na dostęp z określonych adresów IP (reguł filtrowania adresów IP). Jeśli nie chcesz ograniczać dostępu do przestrzeni nazw przy użyciu tych funkcji i nadal chcesz uzyskać dzienniki sieci wirtualnej w celu śledzenia adresów IP klientów łączących się z przestrzenią nazw usługi Event Hubs, możesz użyć następującego obejścia: Włącz filtrowanie adresów IP i dodaj łączny adresowalny zakres IPv4 (128.0.0.0/1
- 0.0.0.0/1
) i zakres IPv6 ().::/1
- 8000::/1
Uwaga
Obecnie nie można określić źródłowego adresu IP pojedynczego komunikatu lub zdarzenia.
Sprawdź, czy tag usługi Event Hubs jest dozwolony w sieciowych grupach zabezpieczeń
Jeśli aplikacja działa wewnątrz podsieci i istnieje skojarzona sieciowa grupa zabezpieczeń, upewnij się, że ruch wychodzący z Internetu jest dozwolony, czy tag usługi Event Hubs (EventHub
) jest dozwolony. Zobacz Tagi usługi dla sieci wirtualnej i wyszukaj ciąg EventHub
.
Sprawdź, czy aplikacja musi być uruchomiona w określonej podsieci sieci wirtualnej
Upewnij się, że aplikacja jest uruchomiona w podsieci sieci wirtualnej, która ma dostęp do przestrzeni nazw. Jeśli tak nie jest, uruchom aplikację w podsieci, która ma dostęp do przestrzeni nazw lub dodaj adres IP maszyny, na której aplikacja jest uruchomiona do zapory adresów IP.
Podczas tworzenia punktu końcowego usługi sieci wirtualnej dla przestrzeni nazw centrum zdarzeń przestrzeń nazw akceptuje ruch tylko z podsieci powiązanej z punktem końcowym usługi. Istnieje wyjątek od tego zachowania. Możesz dodać określone adresy IP w zaporze ip, aby umożliwić dostęp do publicznego punktu końcowego centrum zdarzeń. Aby uzyskać więcej informacji, zobacz Punkty końcowe usługi sieciowej.
Sprawdź ustawienia zapory adresów IP dla przestrzeni nazw
Sprawdź, czy publiczny adres IP maszyny, na której działa aplikacja, nie jest blokowany przez zaporę ip.
Domyślnie przestrzenie nazw usługi Event Hubs są dostępne z Internetu, o ile żądanie jest dostarczane z prawidłowym uwierzytelnianiem i autoryzacją. Zapora ip umożliwia dalsze ograniczenie go tylko do zestawu adresów IPv4 lub IPv6 lub zakresów adresów w notacji CIDR (routing międzydomenowy bez klas).
Reguły zapory adresów IP są stosowane na poziomie przestrzeni nazw usługi Event Hubs. W związku z tym reguły mają zastosowanie do wszystkich połączeń od klientów przy użyciu dowolnego obsługiwanego protokołu. Każda próba połączenia z adresu IP, który nie jest zgodny z dozwoloną regułą IP w przestrzeni nazw usługi Event Hubs, jest odrzucana jako nieautoryzowana. Odpowiedź nie wspomina o regule adresu IP. Reguły filtrowania adresów IP są stosowane w kolejności, a pierwsza reguła zgodna z adresem IP określa akcję akceptowania lub odrzucania.
Aby uzyskać więcej informacji, zobacz Konfigurowanie reguł zapory adresów IP dla przestrzeni nazw usługi Azure Event Hubs. Aby sprawdzić, czy masz problemy z filtrowaniem adresów IP, siecią wirtualną lub łańcuchem certyfikatów, zobacz Rozwiązywanie problemów związanych z siecią.
Sprawdź, czy dostęp do przestrzeni nazw można uzyskać przy użyciu tylko prywatnego punktu końcowego
Jeśli przestrzeń nazw usługi Event Hubs jest skonfigurowana jako dostępna tylko za pośrednictwem prywatnego punktu końcowego, upewnij się, że aplikacja kliencka uzyskuje dostęp do przestrzeni nazw za pośrednictwem prywatnego punktu końcowego.
Usługa Azure Private Link umożliwia dostęp do usługi Azure Event Hubs za pośrednictwem prywatnego punktu końcowego w sieci wirtualnej. Prywatny punkt końcowy to interfejs sieciowy, który nawiązuje prywatne i bezpieczne połączenie z usługą obsługiwaną przez usługę Azure Private Link. Prywatny punkt końcowy używa prywatnego adresu IP z sieci wirtualnej, efektywnie przenosząc usługę do sieci wirtualnej. Cały ruch do usługi może być kierowany przez prywatny punkt końcowy. Nie jest wówczas wymagane użycie bram, urządzeń NAT, połączeń ExpressRoute, połączeń VPN ani publicznych adresów IP. Ruch między siecią wirtualną a usługą odbywa się za pośrednictwem sieci szkieletowej firmy Microsoft, eliminując ekspozycję z publicznego Internetu. Możesz nawiązać połączenie z wystąpieniem zasobu platformy Azure, zapewniając najwyższy poziom szczegółowości kontroli dostępu.
Aby uzyskać więcej informacji, zobacz Konfigurowanie prywatnych punktów końcowych. Zobacz sekcję Sprawdzanie, czy połączenie prywatnego punktu końcowego działa , aby potwierdzić, że jest używany prywatny punkt końcowy.
Rozwiązywanie problemów związanych z siecią
Aby rozwiązać problemy związane z siecią w usłudze Event Hubs, wykonaj następujące kroki:
Przejdź do lub wget https://<yournamespacename>.servicebus.windows.net/
. Pomaga to sprawdzić, czy występują problemy z filtrowaniem adresów IP, siecią wirtualną lub łańcuchem certyfikatów (najczęściej podczas korzystania z zestawu Java SDK).
Przykład pomyślnego komunikatu:
<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>
Przykład komunikatu o błędzie niepowodzenia:
<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>
Rozwiązywanie przejściowych problemów z łącznością
Jeśli występują sporadyczne problemy z łącznością, zapoznaj się z poniższymi sekcjami, aby uzyskać porady dotyczące rozwiązywania problemów.
Korzystanie z najnowszej wersji zestawu SDK klienta
Niektóre przejściowe problemy z łącznością mogły zostać rozwiązane w nowszych wersjach zestawu SDK niż używane przez Ciebie. Upewnij się, że używasz najnowszej wersji zestawów SDK klienta w aplikacjach. Zestawy SDK są stale ulepszane przy użyciu nowych/zaktualizowanych funkcji i poprawek błędów, więc zawsze testują najnowszy pakiet. Zapoznaj się z informacjami o wersji, aby zapoznać się z problemami, które zostały naprawione, oraz dodane/zaktualizowane funkcje.
Aby uzyskać informacje na temat zestawów SDK klientów, zobacz artykuł Zestawy SDK klienta usługi Azure Event Hubs.
Uruchom polecenie , aby sprawdzić porzucone pakiety
Jeśli występują sporadyczne problemy z łącznością, uruchom następujące polecenie, aby sprawdzić, czy istnieją jakiekolwiek porzucone pakiety. To polecenie próbuje ustanowić 25 różnych połączeń TCP co 1 sekundę z usługą. Następnie możesz sprawdzić, ile z nich się, ile zakończyło niepowodzeniem, a także zobaczyć opóźnienie połączenia TCP. Narzędzie można pobrać psping
z tego miejsca.
.\psping.exe -n 25 -i 1 -q <yournamespacename>.servicebus.windows.net:5671 -nobanner
Możesz użyć równoważnych poleceń, jeśli używasz innych narzędzi, takich jak tnc
, ping
i tak dalej.
Uzyskaj ślad sieci, jeśli poprzednie kroki nie pomogą i przeanalizują je przy użyciu narzędzi, takich jak Wireshark. W razie potrzeby skontaktuj się z pomoc techniczna firmy Microsoft.
Uaktualnienia/ponowne uruchomienia usługi
Przejściowe problemy z łącznością mogą wystąpić z powodu uaktualnień usługi zaplecza i ponownych uruchomień. Gdy wystąpią, mogą wystąpić następujące objawy:
- Może wystąpić spadek przychodzących komunikatów/żądań.
- Plik dziennika może zawierać komunikaty o błędach.
- Aplikacje mogą zostać odłączone od usługi przez kilka sekund.
- Żądania mogą być chwilowo ograniczane.
Jeśli kod aplikacji korzysta z zestawu SDK, zasady ponawiania są już wbudowane i aktywne. Aplikacja ponownie łączy się bez znaczącego wpływu na aplikację/przepływ pracy. Przechwycenie tych błędów przejściowych, wycofywanie i ponawianie próby wywołania gwarantuje, że kod jest odporny na te przejściowe problemy.
Następne kroki
Odwiedź następujące artykuły: