Vanliga frågor och svar om Event Hubs

Ett namnområde är en omfångscontainer för händelsehubbar eller Kafka-ämnen. Det ger dig ett unikt FQDN. Ett namnområde fungerar som en programcontainer som kan innehålla flera händelsehubbar eller Kafka-ämnen.

Nej. När den har distribuerats går det inte att ändra (till exempel) från standardnivå till premiumnivå utan att distribuera en ny resurs.

Kapacitetsallokeringsenheter (TUs) eller bearbetningsenheter (PUs)) faktureras på namnområdesnivå. Ett namnområde är också associerat med en region.

Du kanske vill skapa ett nytt namnområde i stället för att använda ett befintligt i något av följande scenarier:

• Du behöver en händelsehubb som är associerad med en ny region.
• Du behöver en händelsehubb som är associerad med en annan prenumeration.
• Du behöver en händelsehubb med en distinkt kapacitetsallokering (d.v.s. kapacitetsbehovet för namnområdet med den tillagda händelsehubben skulle överskrida tröskelvärdet på 40 TU och du vill inte gå till det dedikerade klustret).''

Standardnivån för Azure Event Hubs innehåller funktioner utöver vad som är tillgängligt på Basic-nivån. Följande funktioner ingår i Standard:

• Längre kvarhållning av händelser
• Ytterligare asynkrona anslutningar, med en överförbrukningsavgift för mer än det antal som ingår
• Mer än en enskild konsumentgrupp
• Fånga
• Kafka-integrering

Mer information om prisnivåer, inklusive Event Hubs Dedicated, finns i prisinformationen för Event Hubs.

Azure Event Hubs är tillgängligt i alla Azure-regioner som stöds. En lista finns på sidan Azure-regioner .

Ja, så länge alla händelsehubbar finns i samma namnrymd.

Standardnivån för Event Hubs stöder för närvarande en maximal kvarhållningsperiod på sju dagar, medan den här gränsen är 90 dagar för premium- och dedikerad nivå. Händelsehubbar är inte avsedda som ett permanent datalager. Kvarhållningsperioder som är längre än 24 timmar är avsedda för scenarier där det är praktiskt att spela upp en ström av händelser till samma system. Till exempel för att träna eller verifiera en ny maskininlärningsmodell på befintliga data. Om du behöver kvarhållning av meddelanden längre än sju dagar hämtar aktivering av Event Hubs Capture på din händelsehubb data från din händelsehubb till det Lagringskonto eller Azure Data Lake Service-konto som du väljer. Aktivering av avbildning medför en avgift baserat på dina köpta dataflödesenheter.

Du kan konfigurera kvarhållningsperioden för insamlade data på ditt lagringskonto. Livscykelhanteringsfunktionen i Azure Storage erbjuder en omfattande, regelbaserad princip för allmänna v2- och bloblagringskonton. Använd principen för att överföra dina data till lämpliga åtkomstnivåer eller förfalla i slutet av datans livscykel. Mer information finns i Hantera livscykeln för Azure Blob Storage.

Event Hubs genererar uttömmande mått som ger tillstånd för dina resurser till Azure Monitor. Du kan också utvärdera den övergripande hälsan för Event Hubs-tjänsten, inte bara på namnområdesnivå utan även på entitetsnivå. Lär dig mer om vilken övervakning som erbjuds för Azure Event Hubs.

Azure Event Hubs standard-, premium- och dedikerade nivåer lagrar och bearbetar data som publiceras i den region som du väljer när du skapar ett Event Hubs-namnutrymme. Som standard finns kunddata kvar i den regionen. När geo-haveriberedskap har konfigurerats för ett Azure Event Hubs-namnområde kopieras metadata till den sekundära region som du väljer. Därför uppfyller den här tjänsten automatiskt kraven på regiondatahemvist, inklusive de som anges i Säkerhetscenter.

Vilka protokoll kan jag använda för att skicka och ta emot händelser?

Producenter eller avsändare kan använda PROTOKOLL för Advanced Messaging Queuing (AMQP), Kafka eller HTTPS för att skicka händelser till en händelsehubb.

Konsumenter eller mottagare använder AMQP eller Kafka för att ta emot händelser från en händelsehubb. Event Hubs stöder endast pull-modellen för konsumenter att ta emot händelser från den. Även när du använder händelsehanterare för att hantera händelser från en händelsehubb använder händelseprocessorn internt pull-modellen för att ta emot händelser från händelsehubben.

AMQP

Du kan använda PROTOKOLLET AMQP 1.0 för att skicka händelser till och ta emot händelser från Azure Event Hubs. AMQP tillhandahåller tillförlitlig, högpresterande och säker kommunikation för både sändning och mottagning av händelser. Du kan använda den för strömning med höga prestanda och realtid och stöds av de flesta SDK:er för Azure Event Hubs.

HTTPS/REST API

Du kan bara skicka händelser till Event Hubs med HTTP POST-begäranden. Event Hubs har inte stöd för att ta emot händelser via HTTPS. Den är lämplig för lätta klienter där en direkt TCP-anslutning inte är möjlig.

Apache Kafka

Azure Event Hubs har en inbyggd Kafka-slutpunkt som stöder Kafka-producenter och konsumenter. Program som skapas med Kafka kan använda Kafka-protokollet (version 1.0 eller senare) för att skicka och ta emot händelser från Event Hubs utan några kodändringar.

Azure SDK:er abstraherar de underliggande kommunikationsprotokollen och ger ett förenklat sätt att skicka och ta emot händelser från Event Hubs med hjälp av språk som C#, Java, Python, JavaScript osv.

Vilka portar behöver jag öppna i brandväggen?

Du kan använda följande protokoll med Azure Event Hubs för att skicka och ta emot händelser:

• Advanced Message Queuing Protocol 1.0 (AMQP)
• Hypertext Transfer Protocol 1.1 med Transport Layer Security (HTTPS)
• Apache Kafka

Se följande tabell för de utgående portar som du behöver öppna för att använda dessa protokoll för att kommunicera med Azure Event Hubs.

HTTPS-porten krävs för utgående kommunikation även när AMQP används via port 5671, eftersom flera hanteringsåtgärder som utförs av klient-SDK:er och förvärv av token från Microsoft Entra-ID (när det används) körs över HTTPS.

De officiella Azure SDK:erna använder vanligtvis AMQP-protokollet för att skicka och ta emot händelser från Event Hubs. Protokollalternativet AMQP-over-WebSockets körs via port TCP 443 precis som HTTP-API:et, men är i övrigt funktionellt identiskt med vanlig AMQP. Det här alternativet har högre inledande anslutningsfördröjning på grund av extra handskakningsturer och något mer omkostnader som kompromiss för att dela HTTPS-porten. Om det här läget är valt räcker det med TCP-port 443 för kommunikation. Med följande alternativ kan du välja vanligt AMQP- eller AMQP WebSockets-läge:

Vilka IP-adresser behöver jag tillåta?

När du arbetar med Azure måste du ibland tillåta att specifika IP-adressintervall eller URL:er i företagets brandvägg eller proxy får åtkomst till alla Azure-tjänster som du använder eller försöker använda. Kontrollera att trafiken tillåts på IP-adresser som används av Event Hubs. För IP-adresser som används av Azure Event Hubs: se Azure IP-intervall och tjänsttaggar – offentligt moln.

Kontrollera också att IP-adressen för ditt namnområde är tillåten. Följ dessa steg för att hitta rätt IP-adresser för att tillåta dina anslutningar:

1. Kör följande kommando från en kommandotolk:

   nslookup <YourNamespaceName>.servicebus.windows.net
   

2. Anteckna IP-adressen som returnerades i Non-authoritative answer.

Om du använder ett namnområde som finns i ett äldre kluster (baserat på Cloud Services – CNAME som slutar på *.cloudapp.net) och namnområdet är zonredundant måste du följa några extra steg. Om ditt namnområde finns i ett nyare kluster (baserat på VM-skalningsuppsättning – CNAME som slutar på *.cloudapp.azure.com) och zonredundant kan du hoppa över stegen nedan.

1. Först kör du nslookup på namnområdet.

   nslookup <yournamespace>.servicebus.windows.net
   

2. Anteckna namnet i avsnittet icke-auktoritativt svar , som är i något av följande format:

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

3. Kör nslookup för var och en med suffixen s1, s2 och s3 för att hämta IP-adresserna för alla tre instanser som körs i tre tillgänglighetszoner.

   Kommentar

   IP-adressen som returneras av nslookup kommandot är inte en statisk IP-adress. Den förblir dock konstant tills den underliggande distributionen tas bort eller flyttas till ett annat kluster.

Vilka klient-IP-adresser skickar händelser till eller tar emot händelser från mitt namnområde?

Aktivera först IP-filtrering på namnområdet.

Aktivera sedan diagnostikloggar för händelsehubbars virtuella nätverksanslutningshändelser genom att följa anvisningarna i Aktivera diagnostikloggar. Du ser DEN IP-adress som anslutningen nekas för.

{
    "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 tillhandahåller en Kafka-slutpunkt som kan användas av dina befintliga Apache Kafka-baserade program. En konfigurationsändring är allt som krävs för att ha PaaS Kafka-upplevelsen. Det är ett alternativ till att köra ett eget Kafka-kluster. Event Hubs stöder Apache Kafka 1.0 och nyare klientversioner och fungerar med dina befintliga Kafka-program, verktyg och ramverk. Mer information finns i Event Hubs för Kafka-lagringsplats.

För att ansluta till en händelsehubb måste du uppdatera Kafka-klientkonfigurationerna. Det görs genom att skapa ett Event Hubs-namnområde och hämta anslutningssträng. Ändra bootstrap.servers till att peka event hubs FQDN och porten till 9093. Uppdatera sasl.jaas.config för att dirigera Kafka-klienten till din Event Hubs-slutpunkt (vilket är den anslutningssträng du har fått), med rätt autentisering enligt nedan:

bootstrap.servers={YOUR.EVENTHUBS.FQDN}:9093
request.timeout.ms=60000
security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="$ConnectionString" password="{YOUR.EVENTHUBS.CONNECTION.STRING}";

Exempel:

bootstrap.servers=dummynamespace.servicebus.windows.net:9093
request.timeout.ms=60000
security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="$ConnectionString" password="Endpoint=sb://dummynamespace.servicebus.windows.net/;SharedAccessKeyName=DummyAccessKeyName;SharedAccessKey=XXXXXXXXXXXXXXXXXXXXX";

Den maximala meddelandestorleken som tillåts för Event Hubs är 1 MB.

Dataflödet i Event Hubs definierar mängden data i megabyte eller antalet (i tusentals) händelser på 1 KB som inkommande och utgående via Event Hubs. Det här dataflödet mäts i dataflödesenheter (TUs). Köp TU:er innan du kan börja använda Event Hubs-tjänsten. Du kan uttryckligen välja TU:er för Event Hubs antingen med hjälp av portal- eller Event Hubs Resource Manager-mallar.

Ja, dataflödesenheter (TUs) gäller för alla händelsehubbar i ett Event Hubs-namnområde. Det innebär att du köper TU:er på namnområdesnivå och delas mellan händelsehubbarna under det namnområdet. Varje TU berättigar namnområdet till följande funktioner:

• Upp till 1 MB per sekund av ingresshändelser (händelser som skickas till en händelsehubb), men högst 1 000 ingresshändelser, hanteringsåtgärder eller kontroll-API-anrop per sekund.
• Upp till 2 MB per sekund av utgående händelser (händelser som förbrukas från en händelsehubb), men högst 4 096 utgående händelser.
• Upp till 84 GB händelselagring (tillräckligt för standardperioden på 1 timme).

Dataflödesenheter faktureras per timme. Faktureringen baseras på det maximala antalet enheter som valdes under den angivna timmen.

Du kan börja så lågt som en dataflödesenhet (TU) och aktivera autoinflate. Med funktionen autoinflate kan du utöka dina TU:er när trafiken/nyttolasten ökar. Du kan också ange en övre gräns för antalet RU:er.

Med funktionen autoinflate kan du skala upp dina dataflödesenheter (TUs). Det innebär att du kan börja med att köpa låga TU:er och automatiskt skala upp dina RU:er när ingressen ökar. Det ger dig ett kostnadseffektivt alternativ och fullständig kontroll över antalet TU:er som ska hanteras. Den här funktionen är endast en uppskalningsfunktion och du kan helt styra nedskalningen av antalet RU:er genom att uppdatera den.

Du kanske vill börja med enheter med lågt dataflöde (TUs), till exempel 2 TU:er. Om du förutsäger att trafiken kan växa till 15 TUs aktiverar du funktionen för automatisk blåsning på namnområdet och anger maxgränsen till 15 TUs. Nu kan du utöka dina TU:er automatiskt när trafiken växer.

Det kostar ingenting att associera med den här funktionen.

För närvarande är detta inte möjligt eftersom gamla Event Hubs-namnområden finns i olika kluster, och det finns inget sätt att migrera dem till de nya kluster som automatiskt aktiverar zonredundans när nya event hub-namnområden skapas.

Om det totala ingressdataflödet eller den totala ingresshändelsefrekvensen för alla händelsehubbar i ett namnområde överskrider de aggregerade genomflödesenhetsbidragen begränsas avsändare och får fel som anger att ingresskvoten har överskridits.

Om det totala utgående dataflödet eller den totala utgående hastigheten för händelser i alla händelsehubbar i ett namnområde överskrider de aggregerade genomflödesenhetsbidragen begränsas mottagarna men inga begränsningsfel genereras.

Ingress- och utgående kvoter tillämpas separat, så att ingen avsändare kan orsaka att händelseförbrukningen blir långsammare och inte heller kan en mottagare förhindra att händelser skickas till en händelsehubb.

När du skapar ett grundläggande eller ett standardnivånamnområde i Azure Portal kan du välja upp till 40 TU:er för namnområdet. Utöver 40 TU:er erbjuder Event Hubs resurs-/kapacitetsbaserade modeller som Event Hubs Premium och Event Hubs Dedikerade kluster. Mer information finns i Event Hubs Premium – översikt och Event Hubs Dedicated – översikt.

Event Hubs Dedikerade kluster erbjuder distributioner med en enda klientorganisation för kunder med de mest krävande kraven. Det här erbjudandet skapar ett kapacitetsbaserat kluster som inte är bundet av dataflödesenheter. Det innebär att du kan använda klustret för att mata in och strömma dina data enligt cpu- och minnesanvändningen i klustret. Mer information finns i Event Hubs Dedikerade kluster.

Stegvisa instruktioner och mer information om hur du konfigurerar ett dedikerat Event Hubs-kluster finns i Snabbstart: Skapa ett dedikerat Event Hubs-kluster med hjälp av Azure Portal.

Vad kan jag uppnå med ett kluster?

För ett Event Hubs-kluster beror hur mycket du kan mata in och strömma på faktorer som dina producenter, konsumenter och den hastighet med vilken du matar in och bearbetar.

I följande tabell visas de prestandamått som vi uppnådde under testningen med ett äldre dedikerat kluster.

I testningen användes följande kriterier:

• Ett Event Hubs-kluster på dedikerad nivå med fyra processorer användes.
• Händelsehubben som användes för inmatning hade 200 partitioner.
• De data som matades in togs emot av två mottagarprogram som tog emot från alla partitioner.

Kan jag skala upp eller skala ned mitt kluster?

Om du skapar klustret med alternativet Stöd för skalning kan du använda självbetjäningsupplevelsen för att skala ut och skala in efter behov. Du kan skala upp till 10 CUs med skalbara kluster med självbetjäning. Skalbara dedikerade kluster med självbetjäning baseras på ny infrastruktur, så de presterar bättre än dedikerade kluster som inte stöder självbetjäningsskalning. Prestanda för dedikerade kluster beror på faktorer som resursallokering, antal partitioner och lagring. Vi rekommenderar att du fastställer det antal processorer som krävs när du har testat med en verklig arbetsbelastning.

Skicka en supportbegäran om att skala ut eller skala ut i ditt dedikerade kluster i följande scenarier:

• Du behöver fler än 10 processorer för ett skalbart dedikerat kluster med självbetjäning (ett kluster som skapades med alternativuppsättningen Stöd för skalning ).
• Du måste skala ut eller skala ut i ett kluster som skapades utan att välja alternativet Stöd för skalning .
• Du måste skala ut eller skala ut i ett dedikerat kluster som skapades innan självbetjäningsupplevelsen släpptes.

Kan jag migrera från ett äldre kluster till ett skalbart kluster med självbetjäning?

På grund av skillnaden i den underliggande maskinvaru- och programvaruinfrastrukturen stöder vi för närvarande inte migrering av kluster som inte stöder självbetjäningsskalning för skalbara dedikerade kluster med självbetjäning. Om du vill använda självbetjäningsskalning måste du återskapa klustret. Information om hur du skapar ett skalbart kluster finns i Skapa ett event hubs-dedikerat kluster.

När ska jag skala mitt dedikerade kluster?

CPU-förbrukning är den viktigaste indikatorn för resursförbrukningen i ditt dedikerade kluster. När den totala CPU-förbrukningen börjar nå 70 % (utan att observera några onormala villkor, till exempel ett stort antal serverfel eller ett lågt antal lyckade begäranden), innebär det att klustret går mot sin maximala kapacitet. Du kan använda den här informationen som en indikator för att överväga om du behöver skala upp ditt dedikerade kluster eller inte.

Följ dessa steg för att övervaka cpu-användningen för det dedikerade klustret:

1. På sidan Mått i ditt dedikerade Event Hubs-kluster väljer du Lägg till mått.

2. Välj CPU som mått och använd Max som aggregering.

   

3. Välj Lägg till filter och lägg till ett filter för egenskapstypen Roll. Använd samma operator och välj alla värden (serverdel och gateway) i listrutan.

   

   Sedan kan du övervaka det här måttet för att avgöra när du ska skala ditt dedikerade kluster. Du kan också konfigurera aviseringar mot det här måttet för att få aviseringar när CPU-användningen når de tröskelvärden som du anger.

Hur fungerar geo-haveriberedskap med mitt kluster?

Du kan geo-parkoppla ett namnområde under ett kluster på dedikerad nivå med ett annat namnområde under ett kluster på dedikerad nivå. Vi rekommenderar inte att du parkopplar ett namnområde på dedikerad nivå med ett namnområde i standarderbjudandet eftersom dataflödesgränsen är inkompatibel och resulterar i fel.

Kan jag migrera mina Standard- eller Premium-namnområden till ett kluster på dedikerad nivå?

Vi stöder för närvarande inte någon automatiserad migreringsprocess för att migrera dina Event Hubs-data från ett Standard- eller Premium-namnområde till ett dedikerat.

Varför har ett äldre zonredundant dedikerat kluster minst åtta processorer?

För att tillhandahålla zonredundans för det dedikerade erbjudandet måste alla beräkningsresurser ha tre repliker i tre datacenter i samma region. Det här minimikravet stöder zonredundans (så att tjänsten fortfarande kan fungera när två zoner eller datacenter är nere) och resulterar i en beräkningskapacitet som motsvarar åtta PROCESSORer.

Vi kan inte ändra den här kvoten. Det är en begränsning av den aktuella arkitekturen med en dedikerad nivå.

Eftersom partition är en mekanism för dataorganisation som gör att du kan publicera och använda data parallellt. Vi rekommenderar att du balanserar skalningsenheter (dataflödesenheter för standardnivån, bearbetningsenheter för premiumnivån eller kapacitetsenheter för den dedikerade nivån) och partitioner för att uppnå optimal skalning. I allmänhet rekommenderar vi ett maximalt dataflöde på 1 MB/s per partition. Därför skulle en tumregel för att beräkna antalet partitioner vara att dividera det maximala förväntade dataflödet med 1 MB/s. Om ditt användningsfall till exempel kräver 20 MB/s rekommenderar vi att du väljer minst 20 partitioner för att uppnå optimalt dataflöde.

Men om du har en modell där ditt program har en tillhörighet till en viss partition är det inte fördelaktigt att öka antalet partitioner. Mer information finns i tillgänglighet och konsekvens.

Nej, det är inte möjligt eftersom partitioner inte kan ändras på standardnivån. Dynamiskt tillägg av partitioner är endast tillgängligt på premium- och dedikerade nivåer i Event Hubs.

Fullständig information om priser för Event Hubs finns i prisinformationen för Event Hubs.

Event Hubs Standard-nivån tillåter kvarhållningsperioder för meddelanden som är längre än 24 timmar, i högst sju dagar. Om storleken på det totala antalet lagrade händelser överskrider lagringsbidraget för antalet valda dataflödesenheter (84 GB per dataflödesenhet) debiteras den storlek som överskrider ersättningen enligt den publicerade Azure Blob Storage-hastigheten. Lagringsbidraget i varje dataflödesenhet täcker alla lagringskostnader för kvarhållningsperioder på 24 timmar, även om dataflödesenheten används upp till den maximala ingressen.

Den totala storleken på alla lagrade händelser, inklusive eventuella interna omkostnader för händelsehuvuden eller på disklagringsstrukturer i alla händelsehubbar, mäts under dagen. Vid slutet av dagen beräknas den högsta lagringsstorleken. Den dagliga lagringskvoten beräknas baserat på det minsta antal dataflödesenheten som valdes under dagen (varje dataflödesenhet ger en kvot på 84 GB). Om den totala storleken överskrider den beräknade dagliga lagringsmängden debiteras överskottslagringen med hjälp av Azure Blob Storage-priser (enligt den lokalt redundanta lagringstakten ).

Varje händelse som skickas till en händelsehubb räknas som ett fakturerbart meddelande. En ingresshändelse definieras som en dataenhet som är mindre än eller lika med 64 KB. Alla händelser som är mindre än eller lika med 64 KB i storlek anses vara en fakturerbar händelse. Om händelsen är större än 64 kB beräknas antalet fakturerbara händelser enligt händelsestorleken i multiplar på 64 kB. Till exempel faktureras en 8 KB-händelse som skickas till händelsehubben som en händelse, men ett 96 KB-meddelande som skickas till händelsehubben faktureras som två händelser.

Händelser som förbrukas från en händelsehubb och hanteringsåtgärder och kontrollanrop, till exempel kontrollpunkter, räknas inte som fakturerbara ingresshändelser, utan ackumuleras upp till genomflödesenhetsersättningen.

Anslutningsavgifter gäller endast när AMQP-protokollet används. Du debiteras inga anslutningsavgifter för att skicka händelser via HTTP, oavsett antalet sändande system eller enheter. Om du planerar att använda AMQP (till exempel för att uppnå effektivare händelseströmning eller för att aktivera dubbelriktad kommunikation i IoT-kommando- och kontrollscenarier) kan du läsa prisinformationssidan för Event Hubs för information om hur många anslutningar som ingår på varje tjänstnivå.

Avbildning aktiveras när en händelsehubb i namnområdet har alternativet Avbildning aktiverat. Event Hubs Capture debiteras varje månad per köpt dataflödesenhet. När antalet dataflödesenheter ökar eller minskar återspeglar Event Hubs Capture-faktureringen dessa ändringar i steg om hela timmen. Mer information om fakturering för Event Hubs Capture finns i Prisinformation för Event Hubs.

Capture använder ett lagringskonto som du anger när det är aktiverat på en händelsehubb. Eftersom det är ditt lagringskonto debiteras alla ändringar för den här konfigurationen till din Azure-prenumeration.

En lista över alla Event Hubs-kvoter finns i kvoter.

När du tar bort ett namnområde från en prenumeration väntar du i 4 timmar innan du återskapar det med samma namn i en annan prenumeration. Annars kan du få följande felmeddelande: Namespace already exists.

En lista över möjliga Event Hubs-undantag finns i Undantagsöversikt.

Event Hubs stöder två typer av diagnostikloggar – Avbilda felloggar och driftloggar – som båda representeras i json och kan aktiveras via Azure Portal.

Teknisk support för Event Hubs är tillgänglig via microsofts Q&A-frågesida för Azure Service Bus. Support för fakturering och prenumerationshantering ges utan kostnad.

Mer information om vårt serviceavtal finns på sidan Serviceavtal .

Om du kör den här koden på Azure Stack Hub får du körningsfel om du inte riktar in dig på en specifik version av Lagrings-API:et. Det beror på att Event Hubs SDK använder det senaste tillgängliga Azure Storage-API:et i Azure som kanske inte är tillgängligt på din Azure Stack Hub-plattform. Azure Stack Hub kan ha stöd för en annan version av Storage Blob SDK än vad som vanligtvis är tillgängligt i Azure. Om du använder Azure Blog Storage som kontrollpunktslager kontrollerar du vilken Version av Azure Storage API som stöds för din Azure Stack Hub-version och målversion i koden.

Om du till exempel kör på Azure Stack Hub version 2005 är den högsta tillgängliga versionen för lagringstjänsten version 2019-02-02. Som standard använder Event Hubs SDK-klientbiblioteket den högsta tillgängliga versionen på Azure (2019-07-07 vid tidpunkten för lanseringen av SDK). I det här fallet, förutom följande steg i det här avsnittet, måste du också lägga till kod för att rikta in dig på API-versionen för lagringstjänsten 2019-02-02. Ett exempel på hur du riktar in dig på en specifik Storage API-version finns i följande exempel för C#, Java, Python och JavaScript/TypeScript.

Ett exempel på hur du riktar in en specifik Storage API-version från din kod finns i följande exempel på GitHub:

• .NET
• Java
• Python – synkron, asynkron
• JavaScript och TypeScript

Nästa steg

Du kan lära dig mer om Event Hubs genom att gå till följande länkar:

• Översikt av händelsehubbar
• Skapa en händelsehubb
• Händelsehubbar blåses upp automatiskt