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 gaat vervolgens door de regio van de bron naar de host van een VIRTUELE machine in de back-endpool. 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. Statustests 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 metriek Gezondheidsteststatus met aggregatietype Gemiddeld.

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 metrische gegevens voor SNAT-verbindingen beschrijven het volume van geslaagde en mislukte verbindingen voor uitgaande stromen.

Een mislukt verbindingsvolume van meer dan nul geeft aan dat de SNAT-poortuitputting is uitgeput. U moet verder onderzoeken wat deze fouten kunnen 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.

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 metrische waarde geeft aan hoeveel unieke stromen er tot stand zijn gebracht tussen een internetbron en een back-end-VM of virtuele-machineschaalset die zich achter een load balancer bevindt en geen openbaar IP-adres heeft. Door het aantal SNAT-poorten dat u gebruikt te vergelijken met de metriek voor toegewezen SNAT-poorten, kunt u bepalen of uw service last heeft van SNAT-uitputting en daardoor misschien uitval van de uitgaande datastroom ondervindt.

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. Als u bijvoorbeeld het SNAT-gebruik voor TCP-stromen per machine wilt bewaken, aggregeren op gemiddelde, gesplitst op BACK-end-IP-adressen 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 het metrische type Bytes Count en/of Packet Count , waarbij Sum als aggregatie wordt gebruikt.

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 gebruiken 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 de status van het onderliggende gegevensvlak 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. Deze informatie wordt aangegeven door de blauwe trace voor beschikbaarheid van gegevenspaden, die later op 100 procent lag.

• 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 grafiek stelt klanten in staat om zelfstandig problemen met de implementatie op te lossen, zonder te hoeven gissen of ondersteuning te vragen of andere problemen zich voordoen. De service was niet beschikbaar omdat statustests mislukken vanwege een onjuiste configuratie of een mislukte toepassing.