Metrische gegevens voor Application Gateway
Application Gateway publiceert gegevenspunten naar Azure Monitor voor de prestaties van uw Application Gateway- en back-endinstanties. Deze gegevenspunten worden metrische gegevens genoemd en zijn numerieke waarden in een geordende set tijdreeksgegevens. Metrische gegevens beschrijven een bepaald aspect van uw toepassingsgateway op een bepaald moment. Als er aanvragen via de Application Gateway stromen, worden de metrische gegevens in intervallen van 60 seconden meten en verzonden. Als er geen aanvragen worden verzonden via application gateway of geen gegevens voor een metrische waarde, wordt de metrische waarde niet gerapporteerd. Zie metrische gegevens van Azure Monitor voor meer informatie.
Metrische gegevens die worden ondersteund door Application Gateway V2 SKU
Notitie
Ga naar de gegevensverwijzing voor informatie met betrekking tot TLS/TCP-proxy.
Metrische tijdsinstellingen
Application Gateway biedt verschillende ingebouwde metrische timinggegevens met betrekking tot de aanvraag en het antwoord, die allemaal worden gemeten in milliseconden.
Notitie
Als er meer dan één listener in de Application Gateway is, filtert u altijd op listenerdimensie terwijl u verschillende metrische latentiegegevens vergelijkt om zinvolle deductie te krijgen.
Notitie
Latentie kan worden waargenomen in de metrische gegevens, omdat alle metrische gegevens worden samengevoegd met intervallen van één minuut. Deze latentie kan variëren voor verschillende exemplaren van de toepassingsgateway op basis van de metrische begintijd.
U kunt metrische timinggegevens gebruiken om te bepalen of de waargenomen vertraging wordt veroorzaakt door het clientnetwerk, Application Gateway-prestaties, het back-endnetwerk en de TCP-stackverzadiging van de back-endserver, prestaties van back-endtoepassingen of een grote bestandsgrootte. Zie Metrische tijdsinstellingen voor meer informatie.
Als er bijvoorbeeld een piek is in de reactietijdtrend van de eerste back-end byte, maar de trend van de back-endverbindingstijd stabiel is, kunt u afleiden dat de toepassingsgateway naar de back-endlatentie en de tijd die nodig is om de verbinding tot stand te brengen stabiel is. De piek wordt veroorzaakt door een toename van de reactietijd van de back-endtoepassing. Als de piek in de reactietijd van de eerste byte van de back-end is gekoppeld aan een bijbehorende piek in de back-endverbindingstijd, kunt u afleiden dat het netwerk tussen Application Gateway en de back-endserver of de TCP-stack van de back-endserver is verzadigd.
Als u een piek ziet in de reactietijd van de laatste byte van de back-end, maar de reactietijd van de eerste byte van de back-end stabiel is, kunt u afleiden dat de piek wordt veroorzaakt door een groter bestand dat wordt aangevraagd.
Als de totale tijd van de Application Gateway een piek heeft, maar de reactietijd van de laatste byte van de back-end stabiel is, kan het een teken zijn van prestatieknelpunten bij de Application Gateway of een knelpunt in het netwerk tussen client en Application Gateway. Als de client RTT ook een overeenkomstige piek heeft, geeft dit aan dat de degradatie is vanwege het netwerk tussen client en Application Gateway.
Metrische gegevens van Application Gateway
Voor Application Gateway zijn er verschillende metrische gegevens beschikbaar. Zie metrische gegevens van Application Gateway voor een lijst.
Metrische gegevens van back-end
Voor Application Gateway zijn er verschillende metrische back-endgegevens beschikbaar. Zie Metrische gegevens van back-end voor een lijst.
Metrische gegevens van Web Application Firewall (WAF)
Zie WAF v2 Metrics en WAF v1 Metrics voor meer informatie over WAF-bewaking.
Visualisatie met metrische gegevens
Blader naar een toepassingsgateway en selecteer Metrische gegevens onder Bewaking. Om de beschikbare waarden te zien, selecteert u de vervolgkeuzelijst METRISCH.
In de volgende afbeelding ziet u een voorbeeld met drie metrische gegevens voor de afgelopen 30 minuten:
Zie Ondersteunde metrische gegevens met Azure Monitor voor een huidige lijst met metrische gegevens.
Waarschuwingsregels voor metrische gegevens
U kunt waarschuwingsregels starten op basis van metrische gegevens voor een resource. Een waarschuwing kan bijvoorbeeld een webhook aanroepen of een beheerder een e-mail sturen als de doorvoer van de toepassingsgateway hoger, onder of op een drempelwaarde voor een opgegeven periode ligt.
In het volgende voorbeeld wordt uitgelegd hoe u een waarschuwingsregel maakt waarmee een e-mail naar een beheerder wordt verzonden nadat de doorvoer een drempelwaarde heeft overschreden:
selecteer Waarschuwing voor metrische gegevens toevoegen om de pagina Regel toevoegen te openen. U kunt deze pagina ook bereiken vanaf de pagina met metrische gegevens.
Vul op de pagina Regel toevoegen de naam, voorwaarde en meldingssecties in en selecteer OK.
Selecteer in de voorwaardekiezer een van de vier waarden: Groter dan, Groter dan of gelijk aan, Kleiner dan of Kleiner dan of Gelijk aan.
Selecteer in de periodekiezer een periode van vijf minuten tot zes uur.
Als u e-maileigenaren, inzenders en lezers selecteert, kan het e-mailbericht dynamisch zijn op basis van de gebruikers die toegang hebben tot die resource. Anders kunt u een door komma's gescheiden lijst met gebruikers opgeven in het vak E-mailadressen van extra beheerders.
Als de drempelwaarde wordt overschreden, komt er een e-mailbericht dat lijkt op de e-mail in de volgende afbeelding:
Er wordt een lijst met waarschuwingen weergegeven nadat u een metrische waarschuwing hebt gemaakt. Het biedt een overzicht van alle waarschuwingsregels.
Zie Waarschuwingsmeldingen ontvangen voor meer informatie over waarschuwingsmeldingen.
Als u meer wilt weten over webhooks en hoe u deze kunt gebruiken met waarschuwingen, gaat u naar Een webhook configureren in een metrische Azure-waarschuwing.
Volgende stappen
- Visualiseer teller- en gebeurtenislogboeken met behulp van Azure Monitor-logboeken.
- Visualiseer uw Azure-activiteitenlogboek met een Power BI-blogbericht .
- Azure-activiteitenlogboeken weergeven en analyseren in Power BI en meer blogpost.