Dela via

Felsöka Azure Event Hubs

  • Artikel

Den här artikeln beskriver metoder för felundersökning, vanliga fel för autentiseringstyperna i Event Hubs-biblioteket och åtgärdssteg för att lösa dessa fel. Förutom de allmänna felsökningstekniker och vägledningar som gäller oavsett händelsehubbars användningsfall, omfattar följande artiklar specifika funktioner i Event Hubs-biblioteket:

Resten av den här artikeln beskriver allmänna felsökningstekniker och vägledning som gäller för alla användare av Event Hubs-biblioteket.

Hantera Event Hubs-undantag

Alla Event Hubs-undantag omsluts i en AmqpException. Dessa undantag har ofta en underliggande AMQP-felkod som anger om ett fel ska försökas igen. För återförsöksbara fel (d.v.s. amqp:connection:forced eller amqp:link:detach-forced) försöker klientbiblioteken återställa från dessa fel baserat på de återförsöksalternativ som anges när klienten instansieras. Om du vill konfigurera alternativ för återförsök, följ exemplet och publicera händelser till en specifik partition. När felet inte kan göras om finns det ett konfigurationsproblem som måste lösas.

Det rekommenderade sättet att lösa det specifika undantag som AMQP-undantaget representerar är att följa vägledningen för Event Hubs-meddelandefel.

Hitta relevant information i undantagsmeddelanden

En AmqpException- innehåller följande tre fält som beskriver felet:

  • getErrorCondition: Det underliggande AMQP-felet. En beskrivning av felen finns i dokumentationen AmqpErrorCondition Enum eller OASIS AMQP 1.0-specifikationen.
  • isTransient: Ett värde som anger om det är möjligt att försöka utföra samma åtgärd. SDK-klienter tillämpar återförsöksprincipen när felet är tillfälligt.
  • getErrorContext: Innehåller följande information om var AMQP-felet uppstod:

Vanliga undantag

amqp:connection:forced och amqp:link:detach-forced

När anslutningen till Event Hubs är inaktiv kopplar tjänsten bort klienten efter en stund. Det här problemet är inget problem eftersom klienterna återupprättar en anslutning när en tjänståtgärd begärs. Mer information finns i AMQP-fel i Azure Service Bus.

Behörighetsproblem

En AmqpException med en AmqpErrorCondition- på amqp:unauthorized-access innebär att de angivna inloggningsuppgifterna inte tillåter att utföra åtgärden (mottagning eller sändning) med Event Hubs. Lös problemet genom att prova följande uppgifter:

Andra möjliga lösningar finns i Felsöka autentiserings- och auktoriseringsproblem med Event Hubs.

Anslutningsproblem

Tidsgräns vid anslutning till tjänsten

Prova följande uppgifter för att lösa problem med tidsgränsen:

TLS/SSL-handskakningsfel

Det här felet kan inträffa när en avlyssningsproxy används. För att verifiera rekommenderar vi att du testar i värdmiljön med proxyn inaktiverad.

Socket-överbelastningsfel

Program bör föredra att hantera Event Hubs-klienterna som en singleton, skapa och använda en enda instans under programmets livslängd. Den här rekommendationen är viktig eftersom varje klienttyp hanterar sin anslutning. När du skapar en ny Event Hubs-klient resulterar det i en ny AMQP-anslutning som använder en socket. Dessutom är det viktigt att klienter ärver från java.io.Closeable, så att ditt program måste anropa close() när det är klart med en klient.

Om du vill använda samma AMQP-anslutning när du skapar flera klienter kan du använda flaggan EventHubClientBuilder.shareConnection(), hålla en referens till den EventHubClientBuilderoch skapa nya klienter från samma builder-instans.

Ansluta med en IoT-anslutningssträng

Eftersom översättning av en anslutningssträng kräver att du frågar IoT Hub-tjänsten kan Event Hubs-klientbiblioteket inte använda den direkt. I det IoTConnectionString.java exemplet beskrivs hur du frågar IoT Hub för att översätta en IoT-anslutningssträng till en som kan användas med Event Hubs.

Mer information finns i följande artiklar:

Det går inte att lägga till komponenter i anslutningssträngen

De äldre Event Hubs-klienterna tillät kunder att lägga till komponenter i anslutningssträngen som hämtades från Azure-portalen. De äldre klienterna finns i paket com.microsoft.azure:azure-eventhubs och com.microsoft.azure:azure-eventhubs-eph. Den aktuella generationen stöder endast anslutningssträngar i det formulär som publiceras av Azure-portalen.

Lägg till "TransportType=AmqpWebSockets"

Information om hur du använder webbsocketer finns i exemplet PublishEventsWithSocketsAndProxy.java.

Lägg till "Authentication=Managed Identity"

Information om hur du autentiserar med hanterad identitet finns i exemplet PublishEventsWithAzureIdentity.java.

Mer information om biblioteket Azure.Identity finns i blogginlägget Authentication och Azure SDK.

Aktivera och konfigurera loggning

Azure SDK för Java erbjuder en konsekvent loggningshistoria som hjälper dig att felsöka programfel och för att påskynda lösningen. De loggar som produceras registrerar flödet av en applikation innan det når sitt slutliga tillstånd för att hjälpa till att lokalisera grundproblemet. Vägledning om loggning finns i Konfigurera loggning i Azure SDK för Java och Felsökningsöversikt.

Förutom att aktivera loggning ger inställningen loggnivån till VERBOSE eller DEBUG insikter om bibliotekets tillstånd. I följande avsnitt visas exempelkonfigurationerna log4j2 och logback för att minska överdrivna meddelanden när utförlig loggning är aktiverad.

Konfigurera Log4J 2

Använd följande steg för att konfigurera Log4J 2:

  1. Lägg till beroendena i din pom.xml genom att använda de från loggningsexemplet pom.xml, i avsnittet "Beroenden som krävs för Log4j2".
  2. Lägg till log4j2.xml i mappen src/main/resources.

Konfigurera tillbakaloggning

Använd följande steg för att konfigurera tillbakaloggning:

  1. Lägg till beroendena i din pom.xml genom att använda de som finns i loggningsexemplet pom.xmli avsnittet "Beroenden som krävs för logback".
  2. Lägg till logback.xml i mappen src/main/resources.

Aktivera AMQP-transportloggning

Om det inte räcker med att aktivera klientloggning för att diagnostisera dina problem kan du aktivera loggning till en fil i det underliggande AMQP-biblioteket Qpid Proton-J-. Qpid Proton-J använder java.util.logging. Du kan aktivera loggning genom att skapa en konfigurationsfil med innehållet som visas i nästa avsnitt. Du kan också ange proton.trace.level=ALL och vilka konfigurationsalternativ du vill för java.util.logging.Handler implementeringen. Implementeringsklasserna och deras alternativ finns i Package java.util.logging i Java 8 SDK-dokumentationen.

Om du vill spåra AMQP-transportramarna anger du miljövariabeln PN_TRACE_FRM=1.

Exempelfil för "logging.properties"

Följande konfigurationsfil loggar TRACE-nivåutdata från Proton-J till proton-trace.log-filen:

handlers=java.util.logging.FileHandler
.level=OFF
proton.trace.level=ALL
java.util.logging.FileHandler.level=ALL
java.util.logging.FileHandler.pattern=proton-trace.log
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter
java.util.logging.SimpleFormatter.format=[%1$tF %1$tr] %3$s %4$s: %5$s %n

Minska loggning

Ett sätt att minska loggningen är att ändra verbositeten. Ett annat sätt är att lägga till filter som exkluderar loggar från loggningsnamnspaket som com.azure.messaging.eventhubs eller com.azure.core.amqp. Exempel finns i XML-filerna i avsnitten Konfigurera Log4J 2 och Konfigurera loggback.

När du skickar en bugg är loggmeddelandena från klasser i följande paket intressanta:

  • com.azure.core.amqp.implementation
  • com.azure.core.amqp.implementation.handler
    • Undantaget är att du kan ignorera meddelandet onDelivery i ReceiveLinkHandler.
  • com.azure.messaging.eventhubs.implementation

Nästa steg

Om felsökningsguiden i den här artikeln inte hjälper dig att lösa problem när du använder Azure SDK för Java-klientbibliotek rekommenderar vi att du ange ett problem i Azure SDK för Java GitHub-lagringsplatsen.