Felsök problem med resurs hälsa och inkommande tillgänglighetTroubleshoot resource health, and inbound availability issues

Den här artikeln är en guide för att undersöka problem som påverkar tillgänglighet för klient delens IP-och Server dels resurser.This article is a guide to investigate issues impacting the availability of your load balancer frontend IP and backend resources.

Resource Health kontrollen (RHC) för Load Balancer används för att fastställa belastnings utjämningens hälso tillstånd.The Resource Health Check (RHC) for the Load Balancer is used to determine the health of your load balancer. Den analyserar tillgänglighets måttet för data Sök vägen under ett intervall på 2 minuter för att avgöra om belastnings Utjämnings slut punkter, kombinationerna av klient delens IP-adress och klient dels port med belastnings Utjämnings regler är tillgängliga.It analyzes the Data Path Availability metric over a 2-minute interval to determine whether the load balancing endpoints, the frontend IP and frontend ports combinations with load balancing rules, are available.

I tabellen nedan beskrivs RHC-logiken som används för att fastställa hälso tillståndet för belastningsutjämnaren.The below table describes the RHC logic used to determine the health state of your load balancer.

Resurs hälso statusResource health status BeskrivningDescription
TillgängligAvailable Standard belastnings Utjämnings resursen är felfri och tillgänglig.Your standard load balancer resource is healthy and available.
DegraderadDegraded Din standard belastningsutjämnare har plattforms-eller användar initierade händelser som påverkar prestanda.Your standard load balancer has platform or user initiated events impacting performance. Datasökvägens tillgänglighet har visat mindre än 90 % men högre än 25 % hälsa i minst två minuter.The Datapath Availability metric has reported less than 90% but greater than 25% health for at least two minutes. Du får medelhög prestanda påverkan.You will experience moderate to severe performance impact.
Inte tillgängligUnavailable Standard belastnings Utjämnings resursen är inte felfri.Your standard load balancer resource is not healthy. Datapath tillgänglighets mått har rapporterat färre 25% hälso tillstånd i minst två minuter.The Datapath Availability metric has reported less the 25% health for at least two minutes. Du får betydande prestanda påverkan eller brist på tillgänglighet för inkommande anslutningar.You will experience significant performance impact or lack of availability for inbound connectivity. Det kan finnas användare eller plattforms händelser som orsakar otillgänglighet.There may be user or platform events causing unavailability.
OkäntUnknown Resurs hälso status för din standard belastnings Utjämnings resurs har inte uppdaterats eller har inte tagit emot information om tillgänglighet för data Sök vägar under de senaste 10 minuterna.Resource health status for your standard load balancer resource has not been updated yet or has not received Data Path availability information for the last 10 minutes. Det här tillståndet bör vara tillfälligt och återspegla rätt status så snart data tas emot.This state should be transient and will reflect correct status as soon as data is received.

Om de mått vi använderAbout the metrics we'll use

De två mått som ska användas är tillgänglighet för data Sök väg och status för hälso avsökning och det är viktigt att förstå deras innebörd för att härleda korrekta insikter.The two metrics to be used are Data path availability and Health probe status and it is important to understand their meaning to derive correct insights.

Tillgänglighet för databanaData path availability

Data Sök vägens tillgänglighets mått genereras av ett TCP-ping var 25: e sekund på alla klient dels portar som har konfigurerat belastnings utjämning och inkommande NAT-regler.The data path availability metric is generated by a TCP ping every 25 seconds on all frontend ports that have load-balancing and inbound NAT rules configured. Den här TCP-pingen dirigeras sedan till någon av de felfria (avsöknings bara) Server dels instanserna.This TCP ping will then be routed to any of the healthy (probed up) backend instances. Om tjänsten tar emot ett svar på pingen betraktas den som lyckad och summan av måttet upprepas en gång, om det Miss lyckas.If the service receives a response to the ping, it is considered a success and the sum of the metric will be iterated once, if it fails it won't. Antalet för det här måttet är 1/100 av de totala TCP-pingarna per exempel period.The count of this metric is 1/100 of the total TCP pings per sample period. Därför vill vi överväga genomsnittet, som visar genomsnittet för summan/antalet för tids perioden.Thus, we want to consider the average, which will show the average of sum/count for the time period. Data Sök vägens tillgänglighets mått som sammanställs av genomsnitt ger oss en procent andel lyckade för TCP-ping på klient delens IP-adress: port för var och en av dina belastnings utjämnings-och inkommande NAT-regler.The data path availability metric aggregated by average thus gives us a percentage success rate for TCP pings on your frontend IP:port for each of your load-balancing and inbound NAT rules.

Status för hälsoavsökningHealth probe status

Status måttet för hälso avsökningen genereras av ett ping för det protokoll som definieras i hälso avsökningen.The health probe status metric is generated by a ping of the protocol defined in the health probe. Ping skickas till varje instans i backend-poolen och på den port som definierats i hälso avsökningen.This ping is sent to each instance in the backend pool and on the port defined in the health probe. För HTTP-och HTTPS-avsökningar kräver en lyckad ping ett HTTP 200 OK-svar, medan TCP-avsökningar betraktas som de ska.For HTTP and HTTPS probes, a successful ping requires an HTTP 200 OK response whereas with TCP probes any response is considered successful. Efter varandra följande lyckade eller misslyckade avsökningar avgör om en server dels instans är felfri och kan ta emot trafik för de belastnings Utjämnings regler som backend-poolen är tilldelad.The consecutive successes or failures of each probe then determines whether a backend instance is healthy and able to receive traffic for the load-balancing rules to which the backend pool is assigned. Precis som med data Sök vägs tillgänglighet använder vi den genomsnittliga agg regeringen, som anger det genomsnittliga antalet lyckade/totala pingar under samplings intervallet.Similar to data path availability we use the average aggregation, which tells us the average successful/total pings during the sampling interval. Detta status värde för hälso avsökning anger Server delens hälso tillstånd i isoleringen från belastningsutjämnaren genom att avsöka Server dels instanserna utan att skicka trafik via klient delen.This health probe status value indicates the backend health in isolation from your load balancer by probing your backend instances without sending traffic through the frontend.

Viktigt

Status för hälso avsökningen samplas på en minut.Health probe status is sampled on a one minute basis. Detta kan leda till smärre variationer i ett annat stadigt värde.This can lead to minor fluctuations in an otherwise steady value. Om det till exempel finns två server dels instanser, en avsökad och en avläst, kan hälso avsöknings tjänsten fånga in 7 exempel för den felfria instansen och 6 för den felaktiga instansen.For example, if there are two backend instances, one probed up and one probed down, the health probe service may capture 7 samples for the healthy instance and 6 for the unhealthy instance. Detta leder till ett tidigare stabilt värde på 50 som visas som 46,15 under ett minut intervall.This will lead to a previously steady value of 50 showing as 46.15 for a one minute interval.

Diagnostisera degraderade och ej tillgängliga belastningsutjämnareDiagnose degraded and unavailable load balancers

Som beskrivs i resurs hälso artikelnär en degraderad belastningsutjämnare en som visar mellan 25% och 90% data Sök vägs tillgänglighet, och en otillgänglig belastningsutjämnare är en med mindre än 25% tillgänglighet för data Sök vägar, under en period på två minuter.As outlined in the resource health article, a degraded load balancer is one that shows between 25% and 90% data path availability, and an unavailable load balancer is one with less than 25% data path availability, over a two-minute period. Samma steg kan vidtas för att undersöka det fel du ser i alla hälso avsöknings status eller aviseringar om tillgänglighet för data Sök vägar som du har konfigurerat.These same steps can be taken to investigate the failure you see in any health probe status or data path availability alerts you've configured. Vi kommer att utforska det fall där vi har kontrollerat vår resurs hälsa och hittat vår belastningsutjämnare för att vara otillgänglig med en tillgänglighet för data Sök väg på 0% – vår tjänst är nere.We'll explore the case where we've checked our resource health and found our load balancer to be unavailable with a data path availability of 0% - our service is down.

Först går vi till vyn detaljerade mått för vårt Load Balancer Insights-blad.First, we go to the detailed metrics view of our load balancer insights blade. Du kan göra detta via resurs bladet för belastnings utjämning eller länken i resursens hälso meddelande.You can do this via your load balancer resource blade or the link in your resource health message. Härnäst navigerar vi till fliken klient del och backend-tillgänglighet och granskar en period på trettio minuter av tids perioden när ett degraderat eller otillgängligt tillstånd har inträffat.Next we navigate to the Frontend and Backend availability tab and review a thirty-minute window of the time period when the degraded or unavailable state occurred. Om vi ser att vår data Sök vägs tillgänglighet har varit 0% vet vi att det finns ett problem som förhindrar trafik för alla våra belastnings utjämnings-och inkommande NAT-regler och kan se hur länge den här påverkan har gått ut.If we see our data path availability has been 0%, we know there's an issue preventing traffic for all of our load-balancing and inbound NAT rules and can see how long this impact has lasted.

Nästa steg är att kontrol lera status mått för hälso avsökning för att avgöra om vår data Sök väg är otillgänglig eftersom vi inte har några felfria Server dels instanser för att betjäna trafik.The next place we need to look is our health probe status metric to determine whether our data path is unavailable is because we have no healthy backend instances to serve traffic. Om vi har minst en felfri backend-instans för alla våra regler för belastnings utjämning och inkommande, vet vi att det inte är vår konfiguration som gör att våra data Sök vägar inte är tillgängliga.If we have at least one healthy backend instance for all of our load-balancing and inbound rules, we know it is not our configuration causing our data paths to be unavailable. Det här scenariot indikerar ett problem med en Azure-plattform, även om det är sällsynt, inte fret om du hittar dem som en automatiserad varning skickas till vårt team för att snabbt lösa alla plattforms problem.This scenario indicates an Azure platform issue, while rare, do not fret if you find these as an automated alert is sent to our team to rapidly resolve all platform issues.

Diagnostisera hälso avsöknings felDiagnose health probe failures

Anta att vi kontrollerar status för hälso avsökning och tar reda på om alla instanser visas som skadade.Let's say we check our health probe status and find out that all instances are showing as unhealthy. I den här artikeln förklaras varför vår data Sök väg inte är tillgänglig eftersom trafiken har nogo.This finding explains why our data path is unavailable as traffic has nowhere to go. Vi bör gå igenom följande check lista för att utesluta vanliga konfigurations fel:We should then go through the following checklist to rule out common configuration errors:

  • Kontrol lera CPU-belastningen för dina resurser för att kontrol lera om dina instanser verkligen är felfriaCheck the CPU utilization for your resources to check if your instances are in fact healthy
    • Du kan kontrol lera dettaYou can check this
  • Om du använder en HTTP-eller HTTPS-avsöknings kontroll om programmet är felfritt och svararIf using an HTTP or HTTPS probe check if the application is healthy and responsive
    • Verifiera att detta fungerar genom att direkt komma åt programmen via den privata IP-adressen eller offentliga IP-adress på instans nivå som är kopplad till din server dels instansValidate this is functional by directly accessing the applications through the private IP address or instance-level public IP address associated with your backend instance
  • Granska de nätverks säkerhets grupper som tillämpas på våra server dels resurser.Review the Network Security Groups applied to our backend resources. Se till att det inte finns några regler med högre prioritet än AllowAzureLoadBalancerInBound som kommer att blockera hälso avsökningenEnsure that there are no rules of a higher priority than AllowAzureLoadBalancerInBound that will block the health probe
    • Det kan du göra genom att gå till bladet nätverk för dina Server dels datorer eller Virtual Machine Scale SetsYou can do this by visiting the Networking blade of your backend VMs or Virtual Machine Scale Sets
    • Om du tycker att det här NSG problemet är fallet flyttar du den befintliga regeln för att tillåta eller skapar en ny regel med hög prioritet för att tillåta AzureLoadBalancer-trafikIf you find this NSG issue is the case, move the existing Allow rule or create a new high priority rule to allow AzureLoadBalancer traffic
  • Kontrol lera operativ systemet.Check your OS. Se till att de virtuella datorerna lyssnar på avsöknings porten och granska deras brand Väggs regler för att säkerställa att de inte blockerar avsöknings trafiken från IP-168.63.129.16Ensure your VMs are listening on the probe port and review their OS firewall rules to ensure they are not blocking the probe traffic originating from IP address 168.63.129.16
    • Du kan kontrol lera lyssnings portar genom att köra netstat-a Windows-Kommandotolken eller netstat-l i en Linux-terminalYou can check listening ports by running netstat -a the Windows command prompt or netstat -l in a Linux terminal
  • Placera inte en brand Väggs NVA VM i belastningsutjämnaren för belastningsutjämnaren, Använd användardefinierade vägar för att dirigera trafik till Server dels instanser via brand väggenDon't place a firewall NVA VM in the backend pool of the load balancer, use user-defined routes to route traffic to backend instances through the firewall
  • Se till att du använder rätt protokoll, om du använder HTTP för att avsöka en port som lyssnar efter ett icke-HTTP-program, Miss söker avsökningenEnsure you're using the right protocol, if using HTTP to probe a port listening for a non-HTTP application the probe will fail

Om du har gått igenom check listan och fortfarande hittar hälso avsöknings fel kan det hända att sällsynta plattforms problem påverkar avsöknings tjänsten för dina instanser.If you've gone through this checklist and are still finding health probe failures, there may be rare platform issues impacting the probe service for your instances. I det här fallet har Azure din tillbaka och en automatiserad avisering skickas till vårt team för att snabbt lösa alla plattforms problem.In this case, Azure has your back and an automated alert is sent to our team to rapidly resolve all platform issues.

Nästa stegNext steps