Delen via

Opname in de wachtrij bewaken met metrische gegevens

  • Artikel

In het gequeueerde opnameproces optimaliseert Azure Data Explorer de datalading voor hoge doorvoer door binnenkomende kleine gegevensbrokjes samen te voegen tot batches op basis van een configureerbaar beleid voor batchgewijze opname. Met het batchverwerkingsbeleid kunt u de triggervoorwaarden voor het verzegelen van een batch instellen (gegevensgrootte, aantal blobs of verstreken tijd). Deze batches worden vervolgens optimaal opgenomen voor snelle queryresultaten.

In dit artikel leert u hoe u metriek kunt gebruiken om wachtrijverwerking naar Azure Data Explorer te monitoren in de Azure Portal.

Batchfasen

De fasen die in deze paragraaf worden beschreven, zijn van toepassing op alle batchverwerkingen. Voor Azure Event Grid, Azure Event Hubs, Azure IoT Hub en Cosmos DB, haalt een gegevensverbinding de gegevens op uit externe bronnen en voert een initiële herindeling van de gegevens uit voordat deze in de wachtrij worden geplaatst voor opname.

Opname in wachtrij vindt plaats in stappen:

  1. De Batching Manager luistert naar de wachtrij voor verwerkingsberichten en verwerkt aanvragen.
  2. De Batching Manager optimaliseert de opnamedoorvoer door de kleine binnenkomende gegevenssegmenten te nemen en de URL's te batchen op basis van het batchbeleid voor opname.
  3. De Opnamemanager verzendt de opnameopdrachten naar de Azure Data Explorer Storage Engine.
  4. De Azure Data Explorer Storage Engine de opgenomen gegevens opslaat, zodat deze beschikbaar zijn voor query's.

Azure Data Explorer biedt een set metrische gegevens van Azure Monitor opnamegegevens, zodat u uw gegevensopname kunt bewaken in alle fasen en onderdelen van het opnameproces in de wachtrij.

De metrische gegevens over opname van Azure Data Explorer bieden gedetailleerde informatie over:

  • Het resultaat van de opname in de wachtrij.
  • De hoeveelheid opgenomen gegevens.
  • De latentie van de ingestie in de wachtrij en waar deze plaatsvindt.
  • Het batchverwerkingsproces zelf.
  • Voor Event Hubs-, Event Grid- en IoT Hub-opname: het aantal ontvangen gebeurtenissen.

In dit artikel leert u hoe u meetgegevens over gegevensinvoer kunt gebruiken in het Azure-portal om de gegevensinvoer in de wachtrij te monitoren in Azure Data Explorer.

Voorwaarden

Metrische grafieken maken met Azure Monitor Metrics Explorer

Hieronder vindt u een algemene uitleg over het gebruik van de metrische gegevens van Azure Monitor die vervolgens in de volgende secties worden geïmplementeerd. Gebruik de volgende stappen om metrische grafieken te maken met de Azure Monitor Metrics Explorer in Azure Portal:

  1. Meld u aan bij de Azure Portal en navigeer naar de overzichtspagina voor uw Azure Data Explorer-cluster.

  2. Selecteer metrische gegevens in de linkernavigatiebalk om het deelvenster met metrische gegevens te openen.

  3. Open de tijdkiezer deelvenster rechtsboven in het deelvenster met metrische gegevens en wijzig het tijdsbereik in de tijd die u wilt analyseren. In dit artikel analyseren we gegevensopname naar Azure Data Explorer in de afgelopen 48 uur.

  4. Selecteer een bereik en een metrische naamruimte:

    • Het Bereik is de naam van uw Azure Data Explorer-cluster. In het volgende voorbeeld gebruiken we een cluster met de naam demo11.
    • De metrische naamruimte moet worden ingesteld op metrische gegevens van Kusto-cluster. Dit is de naamruimte die de metrische gegevens van Azure Data Explorer bevat.

    Schermopname die laat zien hoe u instellingen voor een metrische waarde selecteert in Azure Portal.

  5. Selecteer de metrieknaam en de relevante aggregatiewaarde.

Voor enkele voorbeelden in dit artikel selecteren we Filter toevoegen en Toepassen Splitsen voor statistieken die dimensies bevatten. We gebruiken ook Metrische toevoegen om andere metrische gegevens in dezelfde grafiek te tekenen en + Nieuwe grafiek om meerdere grafieken in één weergave weer te geven.

Telkens wanneer u een nieuwe metrische waarde toevoegt, herhaalt u stap vier en vijf.

Notitie

Zie voor meer informatie over het gebruik van metrische gegevens voor het bewaken van Azure Data Explorer in het algemeen en het werken met het deelvenster met metrische gegevens, Azure Data Explorer-prestaties, -status en -gebruik bewaken met metrische gegevens.

In dit artikel leert u welke metrische gegevens kunnen worden gebruikt om opname in de wachtrij bij te houden en hoe u deze metrische gegevens gebruikt.

Het opnameresultaat weergeven

Het opnameresultaat metriek biedt informatie over het totale aantal bronnen dat succesvol is opgenomen en de bronnen die niet konden worden opgenomen.

In dit voorbeeld gebruiken we deze metrische waarde om het resultaat van onze opnamepogingen weer te geven en de statusgegevens te gebruiken om eventuele mislukte pogingen op te lossen.

  1. Selecteer in het deelvenster Metrische gegevens in Azure Monitor het item Metriek toevoegen.
  2. Selecteer opnameresultaat als de waarde metrische en Som als de Aggregatie--waarde. In deze selectie ziet u de resultaten van gegevensopname door de tijd heen in één grafieklijn.
  3. Selecteer de knop Toepassen van splitsen boven de grafiek en kies Status om de grafiek te segmenteren op status van de opnameresultaten. Nadat u de gesplitste waarden hebt geselecteerd, klikt u op afstand van de splitskiezer om deze te sluiten.

De metrische gegevens worden nu gesplitst op status en we kunnen informatie zien over de status van de opnameresultaten, opgesplitst in drie regels:

  1. Blauw voor geslaagde opnameprocessen.
  2. Oranje voor opnamebewerkingen die zijn mislukt vanwege entiteit niet gevonden.
  3. Paars voor innamebewerkingen die zijn mislukt vanwege onjuiste aanvraag.

Schermopname van het deelvenster Metrische gegevens in Azure Portal met een grafiek met opnameresultaten die zijn geaggregeerd op som en gesplitst op status.

Houd rekening met het volgende bij het bekijken van het diagram met opnameresultaten.

  • Wanneer u event hub- of IoT hub-gegevensinvoer gebruikt, is er een vooraggregatie van gebeurtenissen in de gegevensverbindingscomponent. Tijdens deze opnamefase worden gebeurtenissen behandeld als één bron die moet worden opgenomen. Daarom worden enkele gebeurtenissen weergegeven als één opnameresultaat na de aggregatie vooraf.
  • Tijdelijke fouten worden intern opnieuw geprobeerd in een beperkt aantal pogingen. Elke tijdelijke fout wordt gerapporteerd als een tijdelijk verwerkingsresultaat. Daarom kan één inname leiden tot meer dan één innameresultaat.
  • Opnamefouten in de grafiek worden vermeld per foutcodecategorie. Zie opnamefoutcodes in Azure Data Explorerom de volledige lijst met opnamefoutcodes per categorie te bekijken en een beter inzicht te krijgen in de mogelijke foutoorzaken.
  • Voor meer informatie over een opnamefout kunt u diagnostische logboeken voor mislukte opname instellen. Het is echter belangrijk om te overwegen dat het genereren van logs resulteert in het creëren van extra middelen, en daarom een toename van de kosten van verkochte goederen (COGS).

De hoeveelheid opgenomen gegevens weergeven

De metrische gegevens Verwerkte blobs, Ontvangen blobs, en Verwijderde blobs bieden informatie over het aantal blobs dat wordt verwerkt, ontvangen en verwijderd door de invoeringscomponenten tijdens de fases van gequeueud ingeven.

In dit voorbeeld gebruiken we deze metrische gegevens om te zien hoeveel gegevens zijn doorgegeven via de opnamepijplijn, hoeveel gegevens zijn ontvangen door de opnameonderdelen en hoeveel gegevens zijn verwijderd.

Verwerkte blobs

  1. Selecteer in het deelvenster Metrische gegevens in Azure Monitor Metrischetoevoegen.
  2. Selecteer Blobs Verwerkt als de Metrische waarde en Som als de Aggregatie-waarde.
  3. Selecteer de knop Splitsen toepassen en kies componenttype om de grafiek te segmenteren op de verschillende opnameonderdelen.
  4. Als u zich wilt richten op een specifieke database in uw cluster, selecteert u de knop Filter toevoegen boven de grafiek en kiest u vervolgens welke databasewaarden u wilt opnemen bij het tekenen van de grafiek. In dit voorbeeld filteren we op de blobs die naar de GitHub-database worden verzonden door Database te selecteren als de Eigenschap, = als de Operatoren GitHub in de vervolgkeuzelijst Waarden. Nadat u de filterwaarden hebt geselecteerd, klikt u weg van de filterkiezer om deze te sluiten.

In de grafiek ziet u nu hoeveel blobs er naar de GitHub--database zijn verzonden en hoe deze in de loop van de tijd bij elk van de opnamecomponenten zijn verwerkt.

Schermopname van het deelvenster Metrische gegevens in Azure Portal met een grafiek met blobs die zijn verwerkt vanuit de GitHub-database, samengevoegd op som en gesplitst op onderdeeltype.

  • U ziet dat er op 13 februari een afname is van het aantal blobs dat in de loop van de tijd is opgenomen in de GitHub-database. U ziet ook dat het aantal blobs dat op elk van de onderdelen is verwerkt, vergelijkbaar is, wat betekent dat ongeveer alle gegevens die in het gegevensverbinding onderdeel zijn verwerkt, ook zijn verwerkt door de Batching Manager-, Opnamebeheeren Azure Data Explorer Storage Engine onderdelen. Deze gegevens zijn gereed voor query's.

Ontvangen blobs

Om meer inzicht te krijgen in de relatie tussen het aantal blobs dat is ontvangen voor elk onderdeel en het aantal blobs dat in elk onderdeel is verwerkt, voegen we een nieuwe grafiek toe:

  1. Selecteer + Nieuwe grafiek.
  2. Kies dezelfde waarden als hierboven voor Bereik, Metrische naamruimte, en Aggregatie, en selecteer de Blobs Ontvangen metrische waarde.
  3. Selecteer de knop Splitting toepassen en kies componenttype om de Blobs ontvangen metrische waarde op onderdeeltype te splitsen.
  4. Selecteer de knop Filter toevoegen en stel dezelfde waarden in als voordat u alleen de blobs wilt filteren die naar de GitHub-database worden verzonden.

Schermopname van het deelvenster Metrische gegevens in Azure Portal met grafieken van verwerkte blobs en blobs die zijn ontvangen van de github-database, geaggregeerd op som en gesplitst op onderdeeltype.

  • Als u de grafieken vergelijkt, ziet u dat het aantal blobs dat door elk onderdeel wordt ontvangen, nauw overeenkomt met het aantal blobs dat door elk onderdeel is verwerkt. Deze vergelijking geeft aan dat er geen blobs zijn verwijderd tijdens opname.

Blobs laten vallen

Als u wilt bepalen of er blobs zijn die zijn gedropt tijdens het opnameproces, moet u de prestatie-indicator Blobs Dropped analyseren. Deze metrische waarde laat zien hoeveel blobs zijn verwijderd tijdens opname en helpt u te detecteren of er een probleem is in de verwerking van een specifiek opnameonderdeel. Voor elke verwijderde blob krijgt u ook een opnameresultaat metrische gegevens met meer informatie over de reden voor fout.

De opnamelatentie weergeven

De metriek faselatentie en detectielatentie bewaken de latentie in het ingestieproces en vertellen u of er lange latenties optreden in Azure Data Explorer of voordat gegevens worden binnengehaald bij Azure Data Explorer voor ingestie.

  • Fase Latentie geeft de periode aan vanaf het moment dat een bericht wordt ontdekt door Azure Data Explorer totdat de inhoud wordt ontvangen door een invoereenheid voor verwerking.
  • Discovery Latency wordt gebruikt voor gegevensverwerkingpijplijnen met data-verbindingen (zoals Event Hub, IoT Hub en Event Grid). Deze metriek geeft informatie over de tijdsduur vanaf het moment dat gegevens in de wachtrij worden geplaatst totdat ze worden ontdekt door Azure Data Explorer-gegevensverbindingen. Deze periode ligt voorafgaand aan Azure Data Explorer en is daarom niet opgenomen in de fase-latentie metriek die alleen de latentie in Azure Data Explorer meet.

Notitie

Volgens het standaard batchbeleidis standaard batchtijd vijf minuten. Als de batch daarom niet wordt verzegeld door andere triggers, wordt de batch na vijf minuten verzegeld.

Wanneer u een lange latentie ziet totdat gegevens gereed zijn voor query's, kan het analyseren van Stage-latency en Discovery-latency u helpen begrijpen of de lange latentie te wijten is aan lange latentie in Azure Data Explorer, of dat er sprake is van een upstream probleem naar Azure Data Explorer. Wanneer de latentie zich in Azure Data Explorer bevindt, kunt u ook het specifieke onderdeel detecteren dat verantwoordelijk is voor de lange latentie.

Faselatentie (preview)

Laten we eerst eens kijken naar de wachttijd van het opnameproces in de wachtrij. Zie Batching-fasenvoor een uitleg van elke fase.

  1. Selecteer in het deelvenster Metrische gegevens in Azure Monitor Metrischetoevoegen.
  2. Selecteer Faselatentie als de metriekwaarde en Gemiddelde als de aggregatiewaarde.
  3. Selecteer de knop Toepassen Splitsen en kies Componenttype om de grafiek te segmenteren op de verschillende invoeringscomponenten.
  4. Selecteer de knop Filter toevoegen en filter op de gegevens die naar de GitHub-database worden verzonden. Nadat u de filterwaarden hebt geselecteerd, klikt u weg van de filterkiezer om deze te sluiten. In de grafiek ziet u nu de latentie van invoerbewerkingen die naar de GitHub-database worden verzonden bij elk van de componenten via invoerprocessen in de loop van de tijd.

Schermopname van het deelvenster Metrische gegevens in Azure Portal met een grafiek van de latentie van fasen voor de opname uit de GitHub-database, geaggregeerd volgens het gemiddelde en gesplitst op componenttype.

We kunnen de volgende informatie uit deze grafiek zien:

  • De latentie bij het Event Hubs-gegevensverbinding onderdeel is ongeveer 0 seconden. Dit is logisch, omdat faselatentie alleen latentie meet wanneer een bericht wordt gedetecteerd door Azure Data Explorer.
  • De langste tijd in het opnameproces (ongeveer 5 minuten) verstrijkt vanaf het moment dat het Batching Manager-onderdeel gegevens ontvangt tot het moment dat het Innamebeheer-onderdeel gegevens ontvangt. In dit voorbeeld gebruiken we het standaardbatchbeleid voor de GitHub-database. Zoals vermeld, is de latentietijdslimiet voor het standaard batchverwerkingsbeleid vijf minuten. Dit geeft dus waarschijnlijk aan dat bijna alle gegevens op tijd zijn gebatcheerd en dat de meeste latentietijd voor de opname in de wachtrij is veroorzaakt door de batchverwerking zelf.
  • De latentie van de opslagengine in de grafiek vertegenwoordigt de latentie totdat gegevens zijn opgeslagen in de Azure Data Explorer Storage Engine en klaar zijn voor query's. U kunt zien dat de gemiddelde totale latentie van de tijd van gegevensdetectie door Azure Data Explorer totdat deze gereed is voor query 5,2 minuten is.

Detectielatentie

Als u invoer met gegevensverbindingen gebruikt, kunt u op lange termijn de latentie naar Azure Data Explorer schatten, omdat latentie ook kan optreden voordat Azure Data Explorer de gegevens voor invoer ontvangt. Hiervoor kunt u de ontdekkingslatentie metrieken gebruiken.

  1. Selecteer + Nieuwe grafiek.
  2. Selecteer detectielatentie als de waarde metrische en Avg als de Aggregatie waarde.
  3. Selecteer de knop Splitsen toepassen en kies componenttype om de grafiek te segmenteren op de verschillende typen gegevensverbindingsonderdelen. Nadat u de splitswaarden hebt geselecteerd, klikt u buiten de splitskiezer om deze te sluiten.

Schermopname van het deelvenster Metingen in de Azure-portal met een grafiek van de detectielatentie voor opname uit de GitHub-database, geaggregeerd op gemiddeld en opgesplitst naar onderdeeltype.

  • U kunt zien dat de detectielatentie gedurende de meeste tijd bijna 0 seconden is, wat aangeeft dat Azure Data Explorer gegevens heeft ontvangen vlak na het ophalen van gegevens. De hoogste piek van ongeveer 300 milliseconden is rond 13 februari om 14:00 uur, wat aangeeft dat het Azure Data Explorer-cluster op dit moment de gegevens ongeveer 300 milliseconden heeft ontvangen na het ophalen van gegevens.

Inzicht in het batchverwerkingsproces

In de tweede fase van de opnamestroom in de wachtrij optimaliseert het Batching Manager-onderdeel de opnamedoorvoer door de gegevens die worden ontvangen, te batcheren op basis van de opname batchverwerkingsbeleid.

De volgende set metrische gegevens helpt u te begrijpen hoe uw gegevens tijdens de opname worden gebatcheerd:

  • pakketten verwerkt: het aantal pakketten dat is voltooid voor verwerking.
  • Batchgrootte: de geschatte grootte van ongecomprimeerde gegevens in een batch die is geaggregeerd voor verwerking.
  • Batchduur: De duur van elke afzonderlijke batch vanaf het moment dat de batch wordt opengemaakt totdat de batch wordt verzegeld.
  • Batch Blob Count: het aantal blobs in een voltooide batch voor opname.

Verwerkte batches

Laten we beginnen met een algemeen overzicht van het batchverwerkingsproces door te kijken naar de Batches verwerkt metrische gegevens.

  1. Selecteer in het deelvenster Metrieken van Azure Monitor Voeg metriektoe.
  2. Selecteer batches verwerkt als de waarde metrische en Som als de Aggregatie waarde.
  3. Selecteer de knop Toepassen splitsing en kies Batching Type om de grafiek te segmenteren op basis van de reden waarom de batch is verzegeld. Zie Batching-typenvoor een volledige lijst met batchtypen.
  4. Selecteer de knop Filter toevoegen en filter op de batches die naar de GitHub-database worden verzonden. Nadat u de filterwaarden hebt geselecteerd, klikt u weg van de filterkiezer om deze te sluiten.

In de grafiek ziet u het aantal verzegelde batches met gegevens die in de loop van de tijd naar de GitHub-database zijn verzonden, gesplitst door de Batching Type.

Schermopname van het deelvenster Metrische gegevens in Azure Portal met een grafiek met batches die zijn verwerkt voor opname uit de GitHub-database, samengevoegd op som en gesplitst op batchtype.

  • U ziet dat er in de loop van de tijd 2-4 batches per tijdseenheid zijn en dat alle batches worden verzegeld door tijd zoals geschat in de sectie Fase Latentie, waaruit blijkt dat het ongeveer vijf minuten duurt om gegevens te batcheren op basis van het standaard batchbeleid.

Batchduur, grootte en aantal blobs

Laten we nu de verwerkte batches verder karakteriseren.

  1. Selecteer de knop + Grafiek toevoegen voor elke grafiek om meer grafieken te maken voor de metrische waarden Batchduur, Batchgrootteen Batch Blob Count.
  2. Gebruik Avg als de Aggregation-waarde.
  3. Net als in het vorige voorbeeld selecteert u de knop Filter toevoegen en filtert u op de gegevens die naar de GitHub-database worden verzonden.

Schermopname van het deelvenster Metrische gegevens in Azure Portal met grafieken van het aantal Batch-blobs, de batchduur en de metrische gegevens voor batchgrootte, voor opname uit de GitHub-database die is geaggregeerd op gemiddelde en gesplitst op batchtype.

Vanuit de Batchduur, Batchgrootteen Batch Blob Count grafieken kunnen we enkele inzichten concluderen:

  • De gemiddelde batchduur is vijf minuten (volgens het standaardbeleid voor batchverwerking). Houd hierbij rekening met de totale opnamelatentie.

  • In de grafiek Batchgrootte kunt u zien dat de gemiddelde grootte van batches in de loop van de tijd ongeveer 200-500 MB bedraagt. De optimale grootte van gegevens die moeten worden opgenomen, is 1 GB aan niet-gecomprimeerde gegevens en deze grootte wordt ook gedefinieerd als een zegelvoorwaarde volgens het standaard batchverwerkingsbeleid. Omdat er na verloop van tijd geen 1 GB aan gegevens in batches moet worden gebatcheerd, zien we geen batches die op grootte zijn verzegeld.

  • Het gemiddelde aantal blobs in de batches is ongeveer 160 blobs in de loop van de tijd, wat vervolgens afneemt tot 60-120 blobs. Op basis van het standaardbeleid voor batchverwerking kan een batch worden verzegeld wanneer het aantal blobs 1000 blobs is. Omdat we dit nummer niet bereiken, zien we geen batches die zijn verzegeld op aantal.

Gebeurtenissen vergelijken die zijn ontvangen met gebeurtenissen die zijn verzonden voor opname

Wanneer u Event Hub, IoT Hub of Event Grid-opname toepast, kan het handig zijn om het aantal gebeurtenissen dat door Azure Data Explorer wordt ontvangen, te vergelijken met het aantal gebeurtenissen dat vanuit de gebeurtenisbron naar Azure Data Explorer wordt verzonden. Met de metriek ontvangen gebeurtenissen, verwerkte gebeurtenissenen verwijderde gebeurtenissen kunt u deze vergelijking maken.

Ontvangen gebeurtenissen

  1. Selecteer in het deelvenster Metrische gegevens in Azure Monitor Metrischetoevoegen.
  2. Selecteer gebeurtenissen ontvangen als de metrische waarde en Som als de Aggregatie waarde.
  3. Selecteer de knop Filter toevoegen boven de grafiek en kies de eigenschap waarde componentnaam om de gebeurtenissen te filteren die zijn ontvangen door een specifieke gegevensverbinding die is gedefinieerd in uw cluster. In dit voorbeeld filteren we op de GitHubStreamingEvents gegevensverbinding. Nadat u de filterwaarden hebt geselecteerd, klikt u weg van de filterkiezer om deze te sluiten.

In de grafiek ziet u nu het aantal gebeurtenissen dat is ontvangen door de geselecteerde gegevensverbinding in de loop van de tijd:

Schermopname van het deelvenster Metingen in Azure Portal met een grafiek van de gebeurtenissen die tijdens de opname van de GitHub-database zijn ontvangen en die in de loop van de tijd zijn geaggregeerd.

  • In deze grafiek ontvangt de GitHubStreamingEvents gegevensverbinding ongeveer 200-500 gebeurtenissen per tijdseenheid.

Verwerkte gebeurtenissen en verwijderde gebeurtenissen

Als u wilt zien of er gebeurtenissen zijn verwijderd door Azure Data Explorer, gebruikt u de gebeurtenissen die zijn verwerkt en gebeurtenissen die zijn verwijderd metrische gegevens.

  1. Selecteer op de grafiek die u al hebt gemaakt Metriektoevoegen.
  2. Selecteer verwerkte gebeurtenissen als de metriek waarde en som als de aggregatie waarde.
  3. Selecteer Metrische toevoegen opnieuw en selecteer gebeurtenissen die zijn verwijderd als de waarde voor metrische en Som als de Aggregatie waarde.

In de grafiek ziet u nu het aantal gebeurtenissen dat is ontvangen, verwerkt en verwijderd door de GitHubStreamingEvents gegevensverbinding gedurende een bepaalde periode.

Schermopname van het deelvenster Metrische gegevens in Azure Portal met een grafiek van de gebeurtenissen die zijn ontvangen, verwerkt en verloren gegaan tijdens het verzamelen van gegevens uit de GitHub-database, geaggregeerd over tijd.

  • Bijna alle ontvangen gebeurtenissen zijn succesvol verwerkt door de gegevensverbinding. Er is één overgeslagen gebeurtenis, die overeenkomt met het mislukte opnameresultaat door een foutieve aanvraag die we zagen toen we de opname resultaat metriekbekeken.

Gebeurtenissen die zijn ontvangen in Azure Data Explorer vergelijken met uitgaande berichten van Event Hub

U kunt ook het aantal gebeurtenissen vergelijken dat is ontvangen met het aantal gebeurtenissen dat is verzonden van event hub naar Azure Data Explorer door de gebeurtenissen die ontvangen en uitgaande berichten metrische gegevens te vergelijken.

  1. Selecteer in de grafiek die u al hebt gemaakt voor de ontvangen gebeurtenissende optie Metriek toevoegen.

  2. Selecteer bereik en selecteer in het dialoogvenster Selecteer een bereik, blader naar en selecteer de naamruimte van de Event Hub die gegevens naar uw gegevensverbinding verzendt.

    Schermopname van het dialoogvenster Bereik selecteren in de Azure portal, met een zoekopdracht naar de github4demo in de lijst van naamruimten voor Event Hubs.

  3. Selecteer toepassen

  4. Selecteer uitgaande berichten als de metriekwaarde en som als de aggregatiewaarde.

Klik op afstand van de instellingen om het volledige diagram weer te geven waarmee het aantal gebeurtenissen dat door de Azure Data Explorer-gegevensverbinding wordt verwerkt, wordt vergeleken met het aantal gebeurtenissen dat vanuit de Event Hub wordt verzonden.

Schermopname van het deelvenster Metrische gegevens in Azure Portal met een grafiek met grafieken voor alle gebeurtenissen die zijn ontvangen, verwerkt, verwijderd en tijdens opname van de GitHub-database, geaggregeerd in de loop van de tijd.

  • U ziet dat alle gebeurtenissen die vanuit de Event Hub zijn verzonden, zijn verwerkt door de Azure Data Explorer-gegevensverbinding.
  • Als u meer dan één Event Hub in de Event Hub-naamruimte hebt, moet u de metrische gegevens van de uitgaande berichten filteren op de dimensie Entiteitsnaam om alleen gegevens op te halen uit de gewenste Event Hub in uw Event Hub-naamruimte.

Notitie

Er is geen optie om uitgaande berichten per consumentengroep te bewaken. De uitgaande berichten metriek telt het totale aantal berichten dat door alle consumentengroepen is geconsumeerd. Dus als je een paar consumentengroepen in je Event Hub hebt, zou je wellicht meer uitgaande berichten kunnen hebben dan ontvangen gebeurtenissen.

Verwante inhoud