Använd Advanced Container Networking Services för att diagnostisera och lösa nätverksproblem

Den här guiden hjälper dig att navigera i Advanced Container Networking Services (ACNS) som den primära lösningen för att hantera verkliga nätverksanvändningsfall i Azure Kubernetes Service (AKS). Oavsett om du felsöker PROBLEM med DNS-matchning, optimerar inkommande och utgående trafik eller säkerställer efterlevnad av nätverksprinciper, visar den här handboken hur du kan utnyttja instrumentpaneler för ACNS-observerbarhet, containernätverksloggar, containernätverksmått och visualiseringsverktyg för att diagnostisera och lösa problem på ett effektivt sätt.

Advanced Container Networking Services är Microsofts omfattande nätverksobservabilitet och säkerhetsplattform i företagsklass som tillhandahåller de mest avancerade funktionerna för övervakning, analys och felsökning av nätverkstrafik i dina AKS-kluster. Den innehåller fördefinierade Grafana-instrumentpaneler, realtidsmått, detaljerade loggar och AI-baserade insikter som hjälper dig att få djup insyn i nätverksprestanda, snabbt identifiera problem och optimera din containernätverksmiljö med fullständig Microsoft-support.

Översikt över instrumentpaneler för Advanced Container Networking Services

Vi har skapat exempelinstrumentpaneler för Advanced Container Networking Services som hjälper dig att visualisera och analysera nätverkstrafik, DNS-begäranden och paketförluster i dina Kubernetes-kluster. Dessa instrumentpaneler är utformade för att ge insikter om nätverksprestanda, identifiera potentiella problem och hjälpa till med felsökning. Information om hur du konfigurerar dessa instrumentpaneler finns i Konfigurera containernätverksobservabilitet för Azure Kubernetes Service (AKS) – Azure-hanterad Prometheus och Grafana.

Sviten med instrumentpaneler innehåller:

• Flödesloggar: Visar nätverkstrafikflöden mellan poddar, namnområden och externa slutpunkter.
• Flödesloggar (extern trafik): Visar nätverkstrafikflöden mellan poddar och externa slutpunkter.
• Kluster: Visar mått på nodnivå för dina kluster.
• DNS (kluster): Visar DNS-mått på ett kluster eller val av noder.
• DNS (arbetsbelastning): Visar DNS-mått för den angivna arbetsbelastningen (till exempel poddar för en DaemonSet eller distribution, till exempel CoreDNS).
• Drops (Workload): Visar droppar till/från den angivna arbetsbelastningen (till exempel poddar för en distribution eller DaemonSet).
• Poddflöden (namnområde): Visar L4/L7-paketflöden till/från det angivna namnområdet (det vill: Poddar i namnområdet).
• Poddflöden (arbetsbelastning): Visar L4/L7-paketflöden till/från den angivna arbetsbelastningen (till exempel poddar för en distribution eller DaemonSet).
• L7-flöden (namnområde): Visar HTTP-, Kafka- och gRPC-paketflöden till/från det angivna namnområdet (dvs. poddar i namnområdet) när en Layer 7-baserad princip tillämpas. Detta är endast tillgängligt för kluster med Cilium-dataplanet.
• L7-flöden (arbetsbelastning): Visar HTTP-, Kafka- och gRPC-flöden till/från den angivna arbetsbelastningen (till exempel poddar för en distribution eller DaemonSet) när en Layer 7-baserad princip tillämpas. Detta är endast tillgängligt för kluster med Cilium-dataplanet.

Användningsfall 1: Tolka problem med domännamnsserver (DNS) för grundorsaksanalys (RCA)

DNS-problem på poddnivå kan orsaka misslyckad tjänstidentifiering, långsamma programsvar eller kommunikationsfel mellan poddar. Dessa problem uppstår ofta på grund av felkonfigurerade DNS-principer, begränsad frågekapacitet eller svarstid vid matchning av externa domäner. Om CoreDNS-tjänsten till exempel är överbelastad eller om en överordnad DNS-server slutar svara kan det leda till fel i beroende poddar. För att lösa dessa problem krävs inte bara identifiering utan djup insyn i DNS-beteendet i klustret.

Anta att du har konfigurerat ett webbprogram i ett AKS-kluster och att webbprogrammet nu inte kan nås. Du får DNS-fel, till exempel DNS_PROBE_FINISHED_NXDOMAIN eller SERVFAIL, medan DNS-servern löser webbprogrammets adress.

Steg 1: Undersöka DNS-mått i Grafana-instrumentpaneler

Vi har redan skapat två DNS-instrumentpaneler för att undersöka DNS-mått, begäranden och svar: DNS (kluster), som visar DNS-mått på ett kluster eller val av noder, och DNS (arbetsbelastning), som visar DNS-mått för en viss arbetsbelastning (till exempel poddar för en DaemonSet eller distribution, till exempel CoreDNS).

1. Kontrollera instrumentpanelen för DNS-kluster för att få en ögonblicksbild av alla DNS-aktiviteter. Den här instrumentpanelen ger en översikt över DNS-begäranden och -svar, till exempel vilka typer av frågor som saknar svar, den vanligaste frågan och det vanligaste svaret. Den visar även de främsta DNS-felen och noderna som genererar de flesta av dessa fel.

   

2. Rulla ned för att ta reda på poddar med de flesta DNS-begäranden och -fel i alla namnområden.

   

   När du har identifierat de poddar som orsakar flest DNS-problem kan du gå vidare till instrumentpanelen för DNS-arbetsbelastning för en mer detaljerad vy. Genom att korrelera data mellan olika paneler på instrumentbrädan kan du systematiskt begränsa orsakerna till problemen.

3. I avsnitten DNS-begäranden och DNS-svar kan du identifiera trender, till exempel en plötslig minskning av svarsfrekvensen eller en ökning av saknade svar. Ett högt antal begäranden utan svar % kan indikera potentiella problem med uppströms DNS-servern eller en överbelastning av frågor. I följande skärmbild av exempelinstrumentbrädan kan du se en plötslig ökning av begäranden och svar omkring 15.22.

   

4. Sök efter DNS-fel efter typ och sök efter toppar i specifika feltyper (till exempel NXDOMAIN för obefintliga domäner). I det här exemplet finns det en betydande ökning av fel som nekats av frågan, vilket tyder på ett matchningsfel i DNS-konfigurationer eller frågor som inte stöds.

   

5. Använd avsnitt som DNS-svars-IP-adresser som returneras för att säkerställa att förväntade svar bearbetas. Det här diagrammet visar hastigheten för lyckade DNS-frågor som bearbetas per sekund. Den här informationen är användbar för att förstå hur ofta DNS-frågor löses för den angivna arbetsbelastningen.

   • En ökad hastighet kan tyda på en ökning av trafiken eller en potentiell DNS-attack (till exempel DDoS (Distributed Denial of Service).
   • En minskad hastighet kan innebära problem med att nå den externa DNS-servern, ett CoreDNS-konfigurationsproblem eller en oåtkomlig arbetsbelastning från CoreDNS.

   

6. Genom att undersöka de vanligaste DNS-frågorna kan du identifiera mönster i nätverkstrafiken. Den här informationen är användbar för att förstå arbetsbelastningsdistribution och identifiera ovanliga eller oväntade frågebeteenden som kan kräva uppmärksamhet.

   

7. DNS-svarstabellen hjälper dig med rotorsaksanalys för DNS-problem genom att markera frågetyper, svar och felkoder som SERVFAIL (serverfel). Den identifierar problematiska frågor, felmönster eller felkonfigurationer. Genom att observera trender i returkoder och svarsfrekvenser kan du hitta specifika noder, arbetsbelastningar eller frågor som orsakar DNS-störningar eller avvikelser.

   I följande exempel kan du se att för AAAA-poster (IPV6) finns det inget fel, men det finns ett serverfel med en A-post (IPV4). Ibland kan DNS-servern konfigureras för att prioritera IPv6 framför IPv4. Detta kan leda till situationer där IPv6-adresser returneras korrekt, men IPv4-adresser stöter på problem.

   

8. När det bekräftas att det finns ett DNS-problem identifierar följande diagram de tio främsta slutpunkterna som orsakar DNS-fel i en specifik arbetsbelastning eller namnrymd. Du kan använda detta för att prioritera felsökning av specifika slutpunkter, identifiera felkonfigurationer eller undersöka nätverksproblem.

   

Steg 2: Analysera DNS-matchningsproblem med containernätverksloggar

1. Nätverksloggar för containrar ger detaljerade insikter om DNS-frågor och deras svar i både lagrade lägen och lägen på begäran. Med containernätverksloggar kan du analysera DNS-relaterad trafik för specifika poddar och visa information som DNS-frågor, svar, felkoder och svarstid. Om du vill visa DNS-flöden på Log Analytics-arbetsytan använder du följande KQL-fråga:

   RetinaNetworkFlowLogs
   | where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
   | where Layer4.UDP.destination_port == 53
   | where Layer7.type == "REQUEST" 
   | where Reply == false or isnull(Reply)
   | project TimeGenerated, SourcePodName, DestinationPodName, Layer7.dns.query, Layer7.dns.qtypes, Verdict, TrafficDirection, AdditionalFlowData.Summary, NodeName, SourceNamespace, DestinationNamespace
   | order by TimeGenerated desc
   

   Ersätt <start-time> och <end-time> med önskat tidsintervall i formatet 2025-08-12T00:00:00Z.

   Container Network Logs ger omfattande insikter om DNS-frågor och deras svar, vilket kan hjälpa dig att diagnostisera och felsöka DNS-relaterade problem. Varje loggpost innehåller information som frågetypen (till exempel A eller AAAA), det efterfrågade domännamnet, DNS-svarskoden (till exempel Query Refused, Non-Existent Domain eller Server Failure) och källan och målet för DNS-begäran.

2. Identifiera frågestatus: Undersök fältet Bedömning för svar som DROPPED eller FORWARDED, vilket indikerar problem med nätverksanslutning eller principframtvingande.

3. Kontrollera källan och målet: Kontrollera att poddnamnen som anges i fälten SourcePodName och DestinationPodName är korrekta och att kommunikationssökvägen förväntas.

4. Spåra trafikmönster: Titta på fältet Bedömning för att förstå om begäranden vidarebefordrades eller togs bort. Avbrott i vidarebefordran kan tyda på nätverksproblem eller konfigurationsproblem.

5. Analysera tidsstämplar: Använd fältet TimeGenerated för att korrelera specifika DNS-problem med andra händelser i systemet för en omfattande diagnos.

6. Filtrera efter poddar och namnområden: Använd fält som SourcePodName, DestinationPodName och SourceNamespace för att fokusera på specifika arbetsbelastningar som har problem.

Steg 3: Visualisera DNS-trafik med instrumentpaneler för containernätverksloggar

Container Network Logs innehåller avancerade visualiseringsfunktioner via Azure-portals instrumentpaneler och Azure Managed Grafana. Visualiseringen av tjänstberoende och flödesloggar kompletterar den detaljerade logganalysen genom att ge visuella insikter om DNS-relaterad trafik och beroenden:

• Diagram över tjänstberoenden: Visualisera vilka poddar eller tjänster som skickar stora mängder DNS-frågor och deras relationer
• Instrumentpaneler för flödesloggar: Övervaka DNS-begärandemönster, felfrekvenser och svarstider i realtid
• Analys av trafikflöde: Identifiera borttagna DNS-paket och kommunikationsvägar till CoreDNS eller externa DNS-tjänster

Du kan komma åt dessa visualiseringar via:

• Azure-portalen: Gå till ditt AKS-kluster → Insights → Nätverksflödesloggar →
• Azure Managed Grafana: Använd de förkonfigurerade instrumentpanelerna "Flödesloggar" och "Flödesloggar (extern trafik)"

Med de kombinerade kapaciteterna hos Grafana-instrumentpaneler, lagrat läge för containernätverksloggar för historisk analys och loggar på begäran för felsökning i realtid kan du identifiera DNS-problem och utföra grundorsaksanalys effektivt.

Användningsfall 2: Identifiera paketförluster på kluster- och poddnivå på grund av felkonfigurerade nätverksprinciper eller problem med nätverksanslutningen

Problem med anslutning och tvingande av nätverksprinciper beror ofta på felkonfigurerade Kubernetes-nätverksprinciper, inkompatibla CNI-plugin-program (Container Network Interface), överlappande IP-intervall eller försämrad nätverksanslutning. Sådana problem kan störa programfunktionerna, vilket resulterar i avbrott i tjänsten och försämrade användarupplevelser.

När ett paket släpps samlar eBPF-program in händelsen och genererar metadata om paketet, inklusive släpporsaken och dess plats. Dessa data bearbetas av ett användarutrymmesprogram som parsar informationen och konverterar den till Prometheus-mått. Dessa mått ger viktiga insikter om de bakomliggande orsakerna till paketförluster, vilket gör det möjligt för administratörer att identifiera och lösa problem som felkonfigurationer av nätverksprinciper på ett effektivt sätt.

Förutom problem med tvingande principer kan problem med nätverksanslutningen orsaka att paketen sjunker på grund av faktorer som TCP-fel eller återöverföringar. Administratörer kan felsöka dessa problem genom att analysera tabeller för TCP-återöverföring och felloggar som hjälper dig att identifiera försämrade nätverkslänkar eller flaskhalsar. Genom att använda de här detaljerade måtten och felsökningsverktygen kan teamen säkerställa smidiga nätverksåtgärder, minska stilleståndstiden och upprätthålla optimala programprestanda.

Anta att du har ett mikrotjänstbaserat program där klientdelspodden inte kan kommunicera med en serverdelspodd på grund av en alltför restriktiv nätverksprincip som blockerar inkommande trafik.

Steg 1: Undersök prestationsavvikelser i Grafana-dashboards

1. Om det finns paketförluster börjar du din undersökning med dashboarden Pod Flows (Namespace). Den här översikten har paneler som hjälper dig att identifiera namnområden med störst antal droppar och sedan poddar inom de namnområden som har störst antal droppar. Låt oss till exempel granska heatmapen för utgående droppar för poddar med högsta källa eller för de främsta målpoddarna för att identifiera vilka poddar som påverkas mest. Ljusare färger anger högre frekvenser av fall. Jämför över tid för att identifiera mönster eller toppar i specifika poddar.

   

2. När de översta poddarna med högst droppar har identifierats går du till instrumentpanelen Drops (Workload). Du kan använda den här instrumentpanelen för att diagnostisera problem med nätverksanslutningen genom att identifiera mönster i utgående trafik som släpps från specifika poddar. Visualiseringarna belyser vilka poddar som drabbas mest, frekvensen för dessa droppar och orsakerna bakom dem, till exempel principförnekelser. Genom att korrelera spikar i bortfallsfrekvenser med specifika poddar eller tidsramar kan du hitta felkonfigurationer, överbelastade tjänster eller problem med tillämpning av policyer som kan störa anslutningen.

   

3. Gå igenom avsnittet Ögonblicksbild av arbetsbelastning för att identifiera poddar med utgående paketförluster. Fokusera på måtten Max utgående droppar och Minsta utgående droppar för att förstå problemets allvarlighetsgrad (i det här exemplet visas 1,93 paket per sekund). Prioritera undersökning av poddar med konsekvent höga paketförlustfrekvenser.

   

4. Använd diagrammet Tappad in-/utgående trafik efter orsak för att identifiera grundorsaken till bortfallen trafik. I det här exemplet är orsaken att policyn nekas, vilket innebär felkonfigurerade nätverkspolicyer som blockerar utgående trafik. Kontrollera om något specifikt tidsintervall visar en topp i droppar för att begränsa när problemet startade.

   

5. Använd värmekarta över inkommande droppar från de viktigaste käll-/målpoddarna för att identifiera vilka poddar som påverkas mest. Ljusare färger anger högre frekvenser av fall. Jämför över tid för att identifiera mönster eller toppar i specifika poddar.

   

6. Använd diagrammet Staplade (totalt) utgående/inkommande förluster per källpodd för att jämföra borttappningsfrekvenser mellan berörda poddar. Identifiera om specifika poddar konsekvent visar större tapp (till exempel kapinger-bad-6659b89fd8-zjb9k på 26,8 p/s). Här refererar p/s till att släppa paket per sekund. Korsreferensera dessa poddar med deras arbetsbelastningar, etiketter och nätverksprinciper för att diagnostisera potentiella felkonfigurationer.

   

Steg 2: Analysera paketförluster med containernätverksloggar

Nätverksloggar för containrar ger omfattande insikter om paketförluster som orsakas av felkonfigurerade nätverksprinciper med detaljerade data i realtid och historiska data. Du kan analysera borttagna paket genom att undersöka specifika släpporsaker, mönster och berörda arbetsbelastningar.

Använd följande KQL-fråga på Log Analytics-arbetsytan för att identifiera paketförluster:

RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where Verdict == "DROPPED" 
| summarize DropCount = count() by SourcePodName, DestinationPodName, SourceNamespace, bin(TimeGenerated, 5m)
| order by TimeGenerated desc, DropCount desc

För realtidsanalys av borttagna paket kan du också filtrera efter specifika poddar eller namnområden:

RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where Verdict == "DROPPED" 
| where SourceNamespace == "<namespace-name>"
| project TimeGenerated, SourcePodName, DestinationPodName, SourceNamespace, DestinationNamespace, Verdict, TrafficDirection
| order by TimeGenerated desc

Ersätt <start-time> och <end-time> med önskat tidsintervall i formatet 2025-08-12T00:00:00Z.

Container Network Logs ger detaljerade insikter om borttagna paket, vilket hjälper dig att identifiera felkonfigurerade nätverksprinciper och verifiera korrigeringar. Loggarna innehåller detaljerad information om släpporsaker, berörda poddar och trafikmönster som kan vägleda felsökningsarbetet.

Steg 3: Visualisera paketförluster med dashboards för containernätverksloggar

Container Network Logs ger visuell representation av trafikflöden och borttagna paket via Azure-portalens instrumentpaneler och Azure Managed Grafana. Flödesloggar-instrumentpaneler visar interaktioner mellan poddar inom samma namnområde, poddar i andra namnområden och trafik utifrån klustret.

Viktiga visualiseringsfunktioner är:

• Analys av bortfall efter orsak: Identifiera varför paket släpps (policy avvisad, anslutningsspårning osv.)
• Trafikflödeskartor: Visuell representation av tillåtna och nekade trafikflöden
• Information om namnområde och poddnivå: Detaljerade vyer av käll- och målrelationer
• Tidsserieanalys: Historiska trender för paketfall och deras orsaker

Dessa data är avgörande för att granska nätverksprinciper som tillämpas i klustret, så att administratörer snabbt kan identifiera och åtgärda eventuella felkonfigurerade eller problematiska principer genom omfattande logganalyser och visuella representationer.

Användningsfall 3: Identifiera trafikobalanser inom arbetsbelastningar och namnområden

Trafikobalans uppstår när vissa poddar eller tjänster inom en arbetsbelastning eller namnrymd hanterar en oproportionerligt hög volym av nätverkstrafik jämfört med andra. Detta kan leda till resurskonkurration, försämrad prestanda för överbelastade poddar och underutnyttjande av andra. Sådana obalanser uppstår ofta på grund av felkonfigurerade tjänster, ojämn trafikfördelning av lastbalanserare eller oväntade användningsmönster. Utan observerbarhet är det svårt att identifiera vilka poddar eller namnområden som är överbelastade eller underutnyttjanta. Advanced Container Networking Services kan hjälpa dig genom att övervaka trafikmönster i realtid på poddnivå, tillhandahålla mått för bandbreddsanvändning, begärandefrekvens och svarstid, vilket gör det enkelt att hitta obalanser.

Anta att du har en onlinebutiksplattform som körs i ett AKS-kluster. Plattformen består av flera mikrotjänster, inklusive en produktsökningstjänst, en användarautentiseringstjänst och en orderbearbetningstjänst som kommunicerar via Kafka. Under en säsongsförsäljning upplever produktsökningstjänsten en ökning av trafiken, medan de andra tjänsterna förblir inaktiva. Lastbalanseraren dirigerar oavsiktligt fler begäranden till en delmängd poddar i produktsökningsdistributionen, vilket leder till överbelastning och ökad svarstid för sökfrågor. Samtidigt underutnyttjas andra poddar i samma implementering.

Steg 1. Undersöka poddtrafik via Grafana-instrumentpanelen

1. Visa instrumentpanelen poddflöden (arbetsbelastning ). Ögonblicksbilden av arbetsbelastningen visar olika statistik, till exempel utgående och inkommande trafik och utgående och inkommande droppar.

   

2. Granska variationerna i trafiken för varje spårningstyp. Betydande variationer i de blå och gröna linjerna indikerar ändringar i trafikvolymen för program och tjänster, vilket kan bidra till överbelastning. Genom att identifiera perioder med hög trafik kan du hitta tidpunkter för överbelastning och undersöka ytterligare. Jämför dessutom mönster för utgående och inkommande trafik. Om det finns en betydande obalans mellan utgående och inkommande trafik kan det tyda på nätverksbelastning eller flaskhalsar.

3. Heatmaps representerar trafikflödesmått på poddnivå i ett Kubernetes-kluster. Heatmap för utgående trafik för toppkällpoddar visar utgående trafik från de 10 främsta källpoddarna, medan Heatmap för inkommande trafik för de främsta målpoddarna visar inkommande trafik till de 10 främsta målpoddarna. Färgintensiteten anger trafikvolymen, med mörkare nyanser som representerar högre trafik. Konsekventa mönster markerar poddar som genererar eller tar emot betydande trafik, till exempel standard-/tcp-client-0, som kan fungera som en central nod.

   Den följande värmekartan visar att högre trafik tas emot och kommer ut från den enda modulen. Om samma podd (t.ex. standard/tcp-client-0) visas i båda värmekartorna med hög trafikintensitet kan det tyda på att den både skickar och tar emot en stor mängd trafik, vilket potentiellt fungerar som en central nod i arbetsbelastningen. Variationer i intensitet mellan poddar kan tyda på ojämn trafikdistribution, där vissa poddar hanterar oproportionerligt mycket mer trafik än andra.

   

4. Övervakning av TCP-återställningstrafik är avgörande för att förstå nätverksbeteende, felsöka problem, framtvinga säkerhet och optimera programprestanda. Den ger värdefulla insikter om hur anslutningar hanteras och avslutas, vilket gör det möjligt för nätverks- och systemadministratörer att upprätthålla en felfri, effektiv och säker miljö. Dessa mått visar hur många poddar som aktivt deltar i att skicka eller ta emot TCP RST-paket, vilket kan signalera instabila anslutningar eller felkonfigurerade poddar som orsakar nätverksbelastning. Höga återställningshastigheter indikerar att poddar kan vara överbelastade av anslutningsförsök eller resurskonkurrering.

   

5. Värmekarta över utgående TCP RST från de främsta källpoddarna visar vilka källpoddar som genererar flest TCP RST-paket och när aktivitetstoppar inträffar. Om husdjur/rabbitmq-0 konsekvent visar höga utgående återställningar under trafiktoppar i följande exempel, kan det tyda på att programmet eller dess underliggande resurser (CPU, minne) är överbelastade. Lösningen kan vara att optimera poddens konfiguration, skala resurser eller distribuera trafik jämnt över repliker.

   

6. Heatmap för inkommande TCP RST av de främsta målpoddarna identifierar målpoddar som tar emot flest TCP RST-paket, vilket pekar på potentiella flaskhalsar eller anslutningsproblem hos dessa poddar. Om husdjur/mongodb-0 ofta tar emot RST-paket kan det vara en indikator på överbelastade databasanslutningar eller felaktiga nätverkskonfigurationer. Lösningen kan vara att öka databaskapaciteten, implementera hastighetsbegränsning eller undersöka överordnade arbetsbelastningar som orsakar för höga anslutningar.

   

7. Diagrammet Stacked (Total) Outgoing TCP RST by Source Pod (Staplad (totalt) utgående TCP RST efter källpodd ger en aggregerad vy över utgående återställningar över tid, vilket visar trender eller avvikelser.

   

8. Diagrammet Staplade (totalt) inkommande TCP RST per målpodd aggregerar inkommande återställningar, som visar hur nätverksbelastning påverkar målpoddar. En ihållande ökning av återställningar för husdjur/rabbitmq-0 kan till exempel tyda på att den här tjänsten inte kan hantera inkommande trafik effektivt, vilket leder till tidsgränser.

   

Analysera trafikobalanser med containernätverksloggar

Förutom att använda Grafana-instrumentpaneler kan du använda containernätverksloggar för att analysera trafikmönster och identifiera obalanser via KQL-frågor:

// Identify pods with high traffic volume (potential imbalances)
RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend TCP = parse_json(Layer4).TCP
| extend SourcePort = TCP.source_port, DestinationPort = TCP.destination_port
| summarize TotalConnections = count() by SourcePodName, SourceNamespace
| top 10 by TotalConnections desc

// Analyze TCP reset patterns to identify connection issues
RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend TCP = parse_json(Layer4).TCP
| extend Flags = TCP.flags
| where Flags contains "RST"
| summarize ResetCount = count() by SourcePodName, DestinationPodName, bin(TimeGenerated, 5m)
| order by TimeGenerated desc, ResetCount desc

Ersätt <start-time> och <end-time> med önskat tidsintervall i formatet 2025-08-12T00:00:00Z.

De här frågorna hjälper dig att identifiera trafikobalanser och anslutningsproblem som kanske inte visas direkt i instrumentpanelens visualiseringar.

Användningsfall 4: Realtidsövervakning av klustrets nätverkshälsa och prestanda

Att presentera ett klusters nätverkshälsomått på en hög nivå är viktigt för att säkerställa systemets övergripande stabilitet och prestanda. Mått på hög nivå ger en snabb och omfattande vy över klustrets nätverksprestanda, så att administratörer enkelt kan identifiera potentiella flaskhalsar, fel eller ineffektivitet utan att ta del av detaljerad information. Dessa mått, till exempel svarstid, dataflöde, paketförlust och felfrekvens, ger en ögonblicksbild av klustrets hälsa, vilket möjliggör proaktiv övervakning och snabb felsökning.

Vi har en exempelinstrumentpanel som representerar klustrets övergripande hälsa: Kubernetes/Nätverk/Kluster. Nu ska vi gå djupare in på den övergripande instrumentpanelen.

1. Identifiera flaskhalsar i nätverket: Genom att analysera graferna Vidarebefordrade byte och Vidarebefordrade paket kan du identifiera om det finns några plötsliga droppar eller toppar som indikerar potentiella flaskhalsar eller överbelastningar i nätverket.

   

2. Identifiera paketförlust: Avsnitten Borttagna paket och borttagna byte hjälper dig att identifiera om det uppstår betydande paketförluster i specifika kluster, vilket kan tyda på problem som felaktig maskinvara eller felkonfigurerade nätverksinställningar.

   

3. Övervaka trafikmönster: Du kan övervaka trafikmönster över tid för att förstå normalt kontra onormalt beteende, vilket hjälper till med proaktiv felsökning. Genom att jämföra högsta och lägsta inkommande/utgående byte och paket kan du analysera prestandatrender och avgöra om vissa tider på dagen eller specifika arbetsbelastningar orsakar prestandaförsämring.

   

4. Diagnostisera släpporsaker: Avsnitten Byte som släppts av orsak och paket som släppts av orsak hjälper dig att förstå de specifika orsakerna till att paketen tas bort, till exempel principavslag eller okända protokoll.

   

5. Nodspecifik analys: De byte som släppts av noden och paket som släppts av noddiagram ger insikter om vilka noder som upplever flest paketförluster. Detta hjälper dig att hitta problematiska noder och vidta korrigerande åtgärder för att förbättra nätverksprestanda.

   

6. Distribution av TCP-anslutningar: Diagrammet här betecknar fördelningen av TCP-anslutningar mellan olika tillstånd. Om diagrammet till exempel visar ett ovanligt stort antal anslutningar i SYN_SENT tillståndet kan det tyda på att klusternoderna har problem med att upprätta anslutningar på grund av nätverkssvarstid eller felkonfiguration. Å andra sidan kan ett stort antal anslutningar i tillståndet TIME_WAIT tyda på att anslutningar inte släpps korrekt, vilket kan leda till resursutmattning.

   

Användningsfall 5: Diagnostisera nätverksproblem på programnivå

L7-trafikobservabilitet åtgärdar kritiska nätverksproblem på programnivå genom att ge djup insyn i HTTP-, gRPC- och Kafka-trafik. Dessa insikter hjälper till att identifiera problem som höga felfrekvenser (till exempel 4xx-klientsidan eller 5xx-fel på serversidan), oväntade trafikförluster, svarstidstoppar, ojämn trafikdistribution mellan poddar och felkonfigurerade nätverksprinciper. Dessa problem uppstår ofta i komplexa mikrotjänstarkitekturer där beroenden mellan tjänster är invecklade och resursallokeringen är dynamisk. Till exempel kan plötsliga ökningar av borttagna Kafka-meddelanden eller fördröjda gRPC-anrop signalera flaskhalsar i meddelandebearbetning eller nätverksbelastning.

Anta att du har en e-handelsplattform distribuerad i ett Kubernetes-kluster, där klientdelstjänsten förlitar sig på flera serverdelsmikrotjänster, inklusive en betalningsgateway (gRPC), en produktkatalog (HTTP) och en orderbearbetningstjänst som kommunicerar via Kafka. Nyligen har användare rapporterat ökade utcheckningsfel och långsamma sidinläsningstider. Nu ska vi gå djupare in på hur du utför RCA för det här problemet med hjälp av våra förkonfigurerade instrumentpaneler för L7-trafik: Kubernetes/Networking/L7 (namnområden) och Kubernetes/Networking/L7 (arbetsbelastning).

1. Identifiera mönster för borttagna och vidarebefordrade HTTP-begäranden. I följande diagram segmenteras den utgående HTTP-trafiken efter domen, vilket belyser om begäranden "vidarebefordras" eller "tas bort". För e-handelsplattformen kan det här diagrammet hjälpa dig att identifiera potentiella flaskhalsar eller fel i utcheckningsprocessen. Om det finns en märkbar ökning av borttagna HTTP-flöden kan det tyda på problem som felkonfigurerade nätverksprinciper, resursbegränsningar eller anslutningsproblem mellan klientdels- och serverdelstjänsterna. Genom att korrelera det här diagrammet med specifika tidsramar för användarklagomål kan administratörer fastställa om dessa droppar överensstämmer med utcheckningsfel.

   

2. Följande linjediagram visar hastigheten för utgående HTTP-begäranden över tid, kategoriserade efter deras statuskoder (till exempel 200, 403). Du kan använda det här diagrammet för att identifiera toppar i felfrekvenser (till exempel 403 otillåtna fel), vilket kan tyda på problem med autentisering eller åtkomstkontroll. Genom att korrelera dessa toppar med specifika tidsintervall kan du undersöka och lösa underliggande problem, till exempel felkonfigurerade säkerhetsprinciper eller problem på serversidan.

   

3. Följande heatmap anger vilka poddar som har utgående HTTP-begäranden som resulterade i 4xx-fel. Du kan använda den här värmekartan för att snabbt identifiera problematiska poddar och undersöka orsakerna till felen. Genom att åtgärda dessa problem på poddnivå kan du förbättra den övergripande prestandan och tillförlitligheten för deras L7-trafik.

   

4. Använd följande diagram för att kontrollera vilka poddar som får mest trafik. Detta hjälper dig att identifiera överbelastade poddar.

   • Utgående HTTP-begäranden för de 10 främsta källpoddarna visar som standard ett stabilt antal utgående HTTP-begäranden över tid för de tio främsta källpoddarna. Linjen förblir nästan platt, vilket indikerar konsekvent trafik utan betydande toppar eller droppar.
   • Heatmap för borttagna utgående HTTP-begäranden för de 10 främsta källpoddarna i standardinställningen använder färgkodning för att representera antalet borttagna begäranden. Mörkare färger anger ett högre antal borttagna begäranden, medan ljusare färger indikerar färre eller inga borttagna begäranden. De alternerande mörka och ljusa banden tyder på periodiska mönster i nedgången av förfrågningar.

   Dessa diagram ger dig värdefulla insikter om deras nätverkstrafik och prestanda. Det första diagrammet hjälper dig att förstå konsekvensen och volymen för deras utgående HTTP-trafik, vilket är avgörande för att övervaka och upprätthålla optimala nätverksprestanda. Med det andra diagrammet kan du identifiera mönster eller perioder när det finns problem med borttagna begäranden, vilket kan vara avgörande för att felsöka nätverksproblem eller optimera prestanda.

   

Viktiga faktorer att fokusera på vid rotorsaksanalys för L7-trafik

1. Trafikmönster och volym: Analysera trafiktrender för att identifiera ökningar, droppar eller obalans i trafikfördelningen. Överlagrade noder eller tjänster kan leda till flaskhalsar eller borttagna begäranden.

   Diagram över L7-trafik i Grafana.

2. Felfrekvenser: Spåra trender i fel med 4xx (ogiltiga begäranden) och 5xx (serverdelsfel). Beständiga fel indikerar felaktiga klientkonfigurationer eller resursbegränsningar på serversidan.

3. Borttagna begäranden: Undersök droppar vid specifika poddar eller noder. Droppar signalerar ofta anslutningsproblem eller principrelaterade avslag.

4. Principframtvingande och konfiguration: Utvärdera nätverksprinciper, mekanismer för tjänstidentifiering och belastningsutjämningsinställningar för felkonfigurationer.

5. Värmekartor och flödesmått: Använd visualiseringar som värmekartor för att snabbt identifiera felbenägna moduler eller trafikavvikelser.

Analysera L7-trafik med containernätverksloggar

Container Network Logs innehåller omfattande L7-trafikanalysfunktioner via både lagrade loggar och visuella instrumentpaneler. Använd följande KQL-frågor för att analysera HTTP, gRPC och annan trafik på programnivå:

// Analyze HTTP response codes and error rates
RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where FlowType == "L7_HTTP"
| extend HTTP = parse_json(Layer4).HTTP
| extend StatusCode = HTTP.status_code
| summarize RequestCount = count() by StatusCode, SourcePodName, bin(TimeGenerated, 5m)
| order by TimeGenerated desc

// Identify pods with high HTTP 4xx or 5xx error rates
RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where FlowType == "L7_HTTP"
| extend HTTP = parse_json(Layer4).HTTP
| extend StatusCode = tostring(HTTP.status_code)
| where StatusCode startswith "4" or StatusCode startswith "5"
| summarize ErrorCount = count(), UniqueErrors = dcount(StatusCode) by SourcePodName, DestinationPodName
| top 10 by ErrorCount desc

// Monitor gRPC traffic and response times
RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where FlowType == "L7_GRPC"
| extend GRPC = parse_json(Layer4).GRPC
| extend Method = GRPC.method
| summarize RequestCount = count() by SourcePodName, DestinationPodName, Method
| order by RequestCount desc

Ersätt <start-time> och <end-time> med önskat tidsintervall i formatet 2025-08-12T00:00:00Z.

Dessa frågor kompletterar de visuella instrumentpanelerna genom att ge detaljerade insikter om prestanda på programnivå, felmönster och trafikdistribution i mikrotjänstarkitekturen.

Nätverksobservabilitet ingår i Azure Monitoring

När du aktiverar Azure Monitor-hanterad tjänst för Prometheus i ett AKS-kluster samlas grundläggande nätverksövervakningsmått för noder in som standard via networkobservabilityRetina målet. Detta ger:

• Grundläggande nätverksmått på nodnivå: Viktig synlighet för nätverkstrafik på nodnivå
• Prometheus-standardmål: Mått för nätverksobservabilitet som automatiskt skrapas av Azure Monitor
• Azure Monitor-integrering: Sömlös integrering med Azure Monitor; mått samlas in automatiskt och kan visualiseras i Grafana
• Ingen ytterligare installation krävs: Aktiveras automatiskt när Azure Monitor-hanterad Prometheus har konfigurerats
• Microsoft-support: Stöds som en del av Azure Monitor och AKS

Obs! Detta kräver att Azure Monitor-hanterad tjänst för Prometheus aktiveras i aks-klustret, vilket kan ha associerade kostnader.

Komma igång: Aktivera Azure Monitor-hanterad tjänst för Prometheus i ditt AKS-kluster via Azure-portalen eller CLI. Mått för nätverksobservabilitet samlas in automatiskt och är tillgängliga för visualisering i Azure Managed Grafana.

Nätverksobservabilitet med Retina OSS

Även om Advanced Container Networking Services (ACNS) är ett betalerbjudande som tillhandahåller omfattande funktioner för nätverksobservabilitet, stöder Microsoft även nätverksobservabilitet med Retina OSS, en plattform för nätverksobservabilitet med öppen källkod som tillhandahåller viktiga funktioner för nätverksövervakning.

Retina OSS är den plattform för observerbarhet med öppen källkod som finns tillgänglig på retina.sh och GitHub. Den innehåller:

• eBPF-baserad nätverksobservabilitet: Använder eBPF-tekniker för att samla in insikter med minimala omkostnader
• Djup trafikanalys med Kubernetes-kontext: Omfattande avbildning och analys av nätverkstrafikflöden med fullständig Kubernetes-integrering
• Avancerad insamling av mått: Layer 4-mått, DNS-mått och funktioner för distribuerad paketinsamling
• Utökningsbarhet baserad på plugin-program: Anpassa och utöka funktioner via en plugin-arkitektur
• Prometheus-kompatibla mått: Exportera omfattande nätverksmått i Prometheus-format med konfigurerbara måttlägen
• Distribuerad paketinsamling: Paketinsamlingar på begäran över flera noder för djup felsökning
• Plattforms- och CNI-agnostik: Fungerar med alla Kubernetes-kluster (AKS, Arc-aktiverade, lokala), alla operativsystem (Linux/Windows) och alla CNI
• Community-stöd: Öppen källkod med communitybaserat stöd och bidrag
• Självhanterad: Fullständig kontroll över distribution och konfiguration
• Hubble-integrering: Integreras med Ciliums Hubble för ytterligare nätverksinsikter

Komma igång: Distribuera Retina OSS med hjälp av Helm-diagram eller Kubernetes-manifest från den officiella Retina-lagringsplatsen. Konfigurera Prometheus och Grafana för att visualisera mått, konfigurera djuptrafikanalys med Kubernetes-kontext, aktivera distribuerad paketinsamling för avancerad felsökning och anpassa funktioner med hjälp av plugin-baserad arkitektur för specifika användningsfall.

Jämförelse av erbjudanden om nätverksobservabilitet

Lära sig mer

Så här kommer du igång med nätverksobservabilitet i AKS:

Advanced Container Networking Services (ACNS)

• Konfigurera containernätverksloggar: Lär dig hur du konfigurerar containernätverksloggar för omfattande nätverksobservabilitet
• Utforska Avancerade containernätverkstjänster: Mer information om hela plattformen finns i Vad är Avancerade containernätverkstjänster för Azure Kubernetes Service (AKS)?
• Konfigurera övervakning: Konfigurera Azure Managed Grafana-integrering för avancerade visualiseringar
• Läs mer om nätverkssäkerhet: Utforska säkerhetsfunktioner för containernätverk för principframtvingande och hotidentifiering

Nätverksobservabilitet (Azure Monitor)

• Azure Monitor-integrering: Konfigurera Azure Monitor för containrar för att visa grundläggande nätverksmått

Retina OSS

• Officiell dokumentation: Besök retina.sh för omfattande dokumentation och guider
• GitHub-lagringsplats: Få åtkomst till Microsoft Retina GitHub-lagringsplatsen för installationsguider, exempel och communitysupport
• Community-stöd: Delta i diskussioner om Retina-communityn för hjälp och metodtips