Diagnose van standaard load balancer met metrische gegevens, meldingen en resourcestatus

De metrische gegevens over beschikbaarheid van gegevenspaden beschrijven de status binnen de regio van het gegevenspad naar de rekenhost waar uw VM's zich bevinden. De metrische waarde is een weerspiegeling van de status van uw load balancer, op basis van uw configuratie en de Azure-infrastructuur. U kunt de metrische waarde gebruiken om het volgende te doen:

• Controleer de externe beschikbaarheid van uw service.

• Onderzoek het platform waar uw service is geïmplementeerd en bepaal of deze in orde is. Bepaal of uw gast-besturingssysteem of toepassing gezond is.

• Isoleren of een gebeurtenis is gerelateerd aan uw service of het onderliggende gegevensvlak. Verwar deze metriek niet met de Health Probe Status-metriek.

Haal de beschikbaarheid van het gegevenspad voor uw load balancer-resources op:

1. Zorg ervoor dat de juiste load balancer-resource is geselecteerd.

2. Selecteer in de vervolgkeuzelijst Metrische gegevens de optie Beschikbaarheid van gegevenspaden.

3. Selecteer Avg in de vervolgkeuzelijst Aggregatie.

4. Voeg bovendien een filter toe op het front-end-IP-adres of de front-endpoort als parameter, met het vereiste front-end-IP-adres of de front-endpoort. Groepeer ze vervolgens volgens de geselecteerde dimensie.

De metrische waarde wordt gegenereerd door een testservice binnen de regio die verkeer simuleert. De testservice genereert periodiek een pakket dat overeenkomt met de front-end- en taakverdelingsregel van uw implementatie. Het pakket doorloopt vervolgens de regio van de bron naar de host van een VM in de backendpool. De load balancer-infrastructuur voert dezelfde taakverdelings- en vertaalbewerkingen uit als voor al het andere verkeer. Nadat de test op de host is binnengekomen, waar een VM in de back-endpool zich bevindt, genereert de host een reactie op de testservice. Dit verkeer wordt niet weergegeven op uw VM.

Houd er rekening mee dat de metrische gegevens over beschikbaarheid van gegevenspaden alleen worden gegenereerd in front-end-IP-configuraties met taakverdelingsregels.

De metrische gegevens over beschikbaarheid van gegevenspaden kunnen om de volgende redenen worden gedegradeerd:

• Uw implementatie heeft geen gezonde virtuele machines meer in de achtergrondpool.

• Er is een storing in de infrastructuur opgetreden.

Voor diagnostische doeleinden kunt u de metriek voor beschikbaarheid van gegevenspaden samen met de status van de gezondheidstest gebruiken.

Gebruik Gemiddelde als de aggregatie voor de meeste scenario's.

De gezondheidscontrole statusmaatstaf beschrijft de gezondheid van uw toepassingsimplementatie zoals geconfigureerd door u wanneer u de gezondheidscontrole van uw load balancer configureert. De load balancer gebruikt de status van de gezondheidstest om te bepalen waar nieuwe datastromen heen moeten. Controleproeven zijn afkomstig van een Azure infrastructuuradres en zijn zichtbaar in het gastbesturingssysteem van de virtuele machine.

Status van de gezondheidstest voor uw load balancer-resources bekijken:

1. Selecteer de Health Probe Status-metriek met het Avg-aggregatietype .

2. Pas een filter toe op het vereiste IP-adres of de poort van de front-end (of beide).

Gezondheidsonderzoeken mislukken om de volgende redenen:

• U configureert een statustest voor een poort die niet luistert of niet reageert of het verkeerde protocol gebruikt. Als uw service gebruikmaakt van directe server-terugkeer of zwevende IP-regels, controleer dan of de service luistert op het IP-adres van de IP-configuratie van de NIC en de loopback die is geconfigureerd met het frontend-IP-adres.

• Uw netwerkbeveiligingsgroep, de firewall van het gastbesturingssysteem van de virtuele machine of de filters van de toepassingslaag staan het gezondheidscontroleverkeer niet toe.

Gebruik Gemiddelde als de aggregatie voor de meeste scenario's.

De SNAT Connection Count-metriek beschrijft het volume van succesvolle en mislukte verbindingen voor uitgaande stromen.

Een defect verbindingsvolume groter dan nul duidt op uitputting van SNAT-poorten. Je moet verder onderzoeken om te achterhalen wat deze storingen kan veroorzaken. SNAT-poortuitputting manifesteert zich als een fout bij het tot stand brengen van een uitgaande verbinding. Lees het artikel over uitgaande verbindingen om inzicht te krijgen in de scenario's en mechanismen op het werk en om te leren hoe u SNAT-poortuitputting kunt beperken en ontwerpen.

Als uitgaande verbindingen af en toe uitvallen, kan mogelijke SNAT-poortuitputting de oorzaak zijn. Controleer de SNAT-poortgebruik- en allocatiemetrics en bekijk de SNAT-poortuitputtingsrichtlijnen. Voor een grotere SNAT-capaciteit gebruik je Azure NAT Gateway.

Ga als volgt te werk om SNAT-verbindingsstatistieken op te halen:

1. Selecteer het metrische gegevenstype SNAT Connections en Sum als aggregatie.

2. Groeperen op verbindingsstatus zodat geslaagde en mislukte SNAT-verbindingsaantallen door verschillende lijnen worden weergegeven.

Met de metrische gegevens van de gebruikte SNAT-poorten wordt bijgehouden hoeveel SNAT-poorten worden gebruikt om uitgaande stromen te onderhouden. Deze metric geeft aan hoeveel unieke flows er zijn opgebouwd tussen een internetbron en een backend VM of virtual machine scale-set die achter een load balancer zit en geen publiek IP-adres heeft. Door het aantal SNAT-poorten dat je gebruikt te vergelijken met de Allocated SNAT Ports metriek, kun je bepalen of je dienst SNAT-uitputting ervaart of risico loopt op SNAT-uitputting en daardoor uitgaande stroomuitval.

Als uw metrische gegevens het risico van een storing in de uitgaande stroom aangeven, raadpleegt u het artikel en voert u stappen uit om dit te verhelpen om de servicestatus te waarborgen.

Gebruik en toewijzing van SNAT-poorten weergeven:

1. Stel de tijdaggregatie van de grafiek in op 1 minuut om ervoor te zorgen dat de gewenste gegevens worden weergegeven.

2. Selecteer Gebruikte SNAT-poorten en/of toegewezen SNAT-poorten als het metrische type en gemiddelde als de aggregatie.

   • Deze metrische gegevens zijn standaard het gemiddelde aantal SNAT-poorten dat is toegewezen aan of gebruikt door elke back-end-VM of virtuele-machineschaalset. Ze komen overeen met alle openbare IP-adressen van de front-end die zijn toegewezen aan de load balancer, geaggregeerd via TCP en UDP.

   • Als u het totale aantal SNAT-poorten wilt weergeven dat wordt gebruikt door of toegewezen voor de load balancer, gebruikt u sum voor metrische aggregatie.

3. Filter op een specifiek protocoltype, een set back-end-IP-adressen en/of front-end-IP's.

4. Als u de gezondheid per back-end- of front-endinstanties wilt bewaken, past u splitsing toe.

   • Bij het splitsen van notities kan slechts één metrische waarde tegelijk worden weergegeven.

5. Bijvoorbeeld, om het SNAT-gebruik voor TCP-stromen per machine te monitoren, aggregeren op gemiddelde, splitsen op Backend-IP's en filteren op protocoltype.

Zie SNAT (Source Network Address Translation) voor uitgaande verbindingen voor meer informatie over uitgaande verbindingen

Gebruik Sum als de aggregatie voor de meeste scenario's.

De metriek voor bytes en pakkettellers beschrijft het volume van bytes en pakketten dat per front-end door uw service wordt verzonden of ontvangen.

Gebruik Sum als de aggregatie voor de meeste scenario's.

Statistieken over byte- of pakketaantallen ophalen:

1. Selecteer de typen Bytes Count en Packet Count metriek, met Sum als aggregatie.

2. Voer een van de volgende bewerkingen uit:

   • Pas een filter toe op een specifieke frontend-IP, frontendpoort, backend-IP of backendpoort.

   • Haal algemene statistieken op voor uw load balancer-resource zonder te filteren.

Met behulp van een combinatie van de gegevenspadbeschikbaarheid en de gezondheidsonderzoekstatistieken in één grafiek, kunt u vaststellen waar het probleem zich bevindt en het oplossen. U kunt er zeker van zijn dat Azure correct werkt en deze kennis gebruikt om te bepalen of de configuratie of toepassing de hoofdoorzaak is.

U kunt metrische statustestgegevens gebruiken om te begrijpen hoe Azure de status van uw implementatie bekijkt volgens de configuratie die u hebt opgegeven. Het bekijken van gezondheidstests is altijd een goede eerste stap bij het monitoren of het vaststellen van een oorzaak.

U kunt dit nog een stap verder doen en metrische gegevens over beschikbaarheid van gegevenspaden gebruiken om inzicht te krijgen in hoe Azure de status van het onderliggende gegevensvlak weergeeft dat verantwoordelijk is voor uw specifieke implementatie. Wanneer u beide metrische gegevens combineert, kunt u isoleren waar de fout zich kan bevinden, zoals wordt geïllustreerd in dit voorbeeld:

Afbeelding: Beschikbaarheid van datapaden en status van gezondheidssondes combineren

In de grafiek ziet u de volgende informatie:

• De infrastructuur die als host fungeert voor uw VM's was aan het begin van de grafiek niet beschikbaar en op 0 procent. Later was de infrastructuur in orde en waren de VM's bereikbaar en werd meer dan één VIRTUELE machine in de back-end geplaatst. De blauwe trace voor datapadbeschikbaarheid, die later op 100 procent stond, geeft deze informatie aan.

• De status van de gezondheidscontrole, aangegeven door de paarse lijn, staat aan het begin van de grafiek op 0 procent. Het omcirkelde gebied met groen markeert waar de status van de gezondheidstest gezond werd en het moment waarop de implementatie van de klant nieuw verkeer kon accepteren.

De tabel helpt je bij het oplossen van de implementatie zonder te hoeven gokken of support te vragen of er andere problemen zijn. De service was niet beschikbaar omdat statustests mislukken vanwege een onjuiste configuratie of een mislukte toepassing.