Vad är containernätverksloggar?

Containernätverksloggar i Avancerade containernätverkstjänster för Azure Kubernetes Service (AKS) ger dig insyn i varje nätverksflöde i klustret. Mått visar vad som händer i nätverket (bandbreddsanvändning, felfrekvens). Loggar visar varför: vem som initierade en anslutning, vilka protokoll som användes och om trafiken tilläts eller blockerades.

Dessa loggar samlar in metadata för varje nätverksflöde:

• Käll- och mål-IP-adresser, poddnamn och tjänstnamn
• Namnområden, portar och protokoll
• Trafikriktning och principutlåtanden

Med den här kontexten kan du korrelera nätverksbeteendet med specifika arbetsbelastningar, felsöka anslutningar, verifiera säkerhetsprinciper och utföra kriminalteknisk analys. Containernätverksloggar täcker Layer 3-trafik (IP), Layer 4 (TCP/UDP) och Layer 7-trafik (HTTP/gRPC/Kafka).

För att hantera datavolym och kostnader stöder containernätverksloggar flödesloggaggregering, som grupperar liknande flöden i sammanfattade poster i stället för att lagra en post per anslutningshändelse. Du behåller de driftsmönster du behöver samtidigt som du minskar kostnaderna för lagring och inmatning. Mer information finns i Agregering av flödesloggar.

Containernätverksloggar erbjuder två lägen:

• Lagrade loggar – Kontinuerlig samling med anpassade filter och flödesaggregering. Bäst för långsiktig övervakning och analys.
• Loggar på begäran – Realtidsinsamling via Användargränssnittet för Hubble CLI och Hubble. Bäst för ad hoc-felsökning.

Använd lagrade loggar när du behöver beständiga poster för efterlevnad, trendanalys eller automatisk avisering. Använd loggar på begäran när du aktivt felsöker ett anslutningsproblem eller prestandaproblem och behöver omedelbar insyn i livetrafik.

Lagrade loggar

Läget för lagrade loggar aktiveras automatiskt när avancerade containernätverkstjänster är aktiverat i ett kluster. Funktionen är på plats, men inga loggar genereras förrän du berättar för ACNS vad som ska avbildas.

Om du vill börja samla in loggar definierar du ContainerNetworkLog anpassade resurser som anger vilken trafik som ska övervakas: efter namnrymd, podd, tjänst, protokoll eller bedömning. När en CRD har tillämpats börjar Cilium-agenten generera flöden som matchar dess filter och skriver dem till varje nod. Samlingen förblir aktiv tills du tar bort CRD:erna eller inaktiverar ACNS.

Eftersom du styr exakt vilken trafik som loggas via CRD-filter kan du fokusera på de flöden som är viktiga och undvika att samla in onödiga data. I kombination med flödesloggaggregering håller den här metoden lagringskostnaderna förutsägbara och analysfokuserade.

Så här fungerar läget för lagrade loggar

Advanced Container Networking Services använder eBPF-teknik med Cilium för att samla in nätverksflöden på varje nod. När ACNS har aktiverats och en ContainerNetworkLog anpassad resurs har tillämpats samlar Cilium-agenten in trafik som matchar filtret och skriver loggar i JSON-format till /var/log/acns/hubble/events.log på varje värd. Logggenereringen körs helt i klustret och är inte beroende av Azure Monitor.

För produktionsanvändning rekommenderar vi att du aktiverar Azure Monitor tillägg. När det är aktiverat samlar Container Insights-agenter in värdlokala loggar, tillämpar strypningsgränser och skickar dem till en Log Analytics-arbetsyta, där du får långsiktig kvarhållning, KQL-frågor och de inbyggda Azure-portalen och Grafana-instrumentpanelerna. Det här är den mest integrerade sökvägen och den som de flesta kunder bör välja.

Om ditt team har en befintlig pipeline för observerbarhet kan du i stället vidarebefordra samma värdlokala loggar till valfri OpenTelemetry-kompatibel insamlare eller loggningstjänst – antingen tillsammans med Azure Monitor eller i stället för den.

Mer information om strypning och Container Insights finns i dokumentationen om Container Insights.

Använda containernätverksloggar med eller utan Azure Monitor

Du kan använda containernätverksloggar på två sätt. Rätt val beror på om du vill ha en integrerad Azure-intern upplevelse eller om du redan har en observerbarhetspipeline som du vill fortsätta använda.

För de flesta kunder rekommenderar vi att du aktiverar Azure Monitor. Det är det snabbaste sättet att få kvarhållnings-, fråge- och instrumentpanelfunktioner utan att behöva bygga en egen pipeline.

Viktiga funktioner i lagrat loggläge

• Anpassningsbara filter. Definiera ContainerNetworkLog anpassade resurser för att filtrera efter namnområde, podd, tjänst, port, protokoll, bedömning eller trafikriktning. Endast matchande trafik loggas, så du får exakt kontroll över vad som samlas in och vad det kostar.

• Aggregering av flödeslogg. Liknande flöden grupperas automatiskt i sammanfattade poster var 30:e sekund, vilket minskar datavolymen samtidigt som driftsignaler som tjänstkommunikationsmönster, felfrekvenser och säkerhetsutslag bevaras. I kombination med riktade filter kan du med aggregering upprätthålla bred synlighet utan orimliga inmatningskostnader. Mer information finns i Agregering av flödesloggar.

• Alternativ för logglagring. ACNS skriver alltid loggar lokalt på varje nod. Därifrån kan du välja hur du ska använda dem:

  • Värdlokala filer (alltid på): Loggar lagras på värdnoder på /var/log/acns/hubble. Filer roteras automatiskt vid 50 MB och äldre loggar skrivs över. Använd detta direkt för kortsiktig övervakning i realtid eller vidarebefordra filerna till valfri OpenTelemetry-kompatibel insamlare eller loggningstjänst för ytterligare logghantering.

  • Azure Monitor (rekommenderas): Aktivera Azure Monitor-tillägget för att samla in och lagra loggar på en Log Analytics arbetsyta. Du får säker, kompatibel lagring med långsiktig kvarhållning, KQL-frågor, avvikelseidentifiering, historisk analys och aviseringar via den hanterade tjänsten för Prometheus. Logggenereringen körs fortfarande via Cilium-agenten och ContainerNetworkLog CRD; Azure Monitor lägger till förbrukningsskiktet ovanpå.

    Tabellen ContainerNetworkLogs använder analysnivån som standard. Du kan växla till Basic-nivån för lägre inmatnings- och kvarhållningskostnader samtidigt som du behåller en liknande observerbarhetsupplevelse. Varje nivå har en dedikerad Azure portalinstrumentpanel som är optimerad för dess frågefunktioner. Mer information om tabellplaner finns i Log Analytics tabellplaner. Information om hur du anger tabellplanen finns i Ange tabellplanen.

• Visualisering i Azure-portalen. Fråga efter och analysera loggar direkt i Log Analytics eller använd de inbyggda instrumentpanelerna för Azure portalen. En dedikerad instrumentpanel är tillgänglig för varje tabellnivå, så du får samma observerbarhetsupplevelse oavsett vilken nivå du väljer. Mer information finns i Visualize-loggar i Azure-portalen.

Visualisera loggar i Azure-portalen

Du kan visualisera, fråga och analysera flödesloggar i Azure-portalen på Log Analytics arbetsytan för klustret.

Containernätverksloggar innehåller inbyggda instrumentpaneler i Azure-portalen för visualisering av flödesdatan. En separat instrumentpanel är tillgänglig för varje Log Analytics tabellnivå:

Båda instrumentpanelerna visar vilka AKS-arbetsbelastningar som kommunicerar med varandra, inklusive nätverksförfrågningar, svar, bortfall och fel. Använd instrumentpanelen som matchar den tabellnivå som konfigurerats för tabellen ContainerNetworkLogs .

Instrumentpanelerna i Azure-portalen har följande huvudkomponenter:

• Översikt över nätverkshälsa. Det översta avsnittet visar sammanfattningsmått (totalt antal flödesloggar, unika begäranden, borttagna begäranden och vidarebefordrade begäranden) så att du snabbt kan upptäcka avvikelser. Statistik delas upp efter protokoll: DNS-borttagna begäranden, HTTP 2xx-svar, Layer 4-begärande- och svarsfrekvenser samt antal borttagna. Ett diagram över tjänstberoenden visar vilka tjänster som kommunicerar med varandra, vilket gör det enklare att identifiera flaskhalsar och oväntade trafikvägar.

  

• Flödesloggar och felloggar. Instrumentpanelen separerar flödesloggar från felloggar i distinkta vyer, så att du kan fokusera på fel utan att söka igenom normal trafik. Använd de inbyggda filtren för att begränsa resultatet efter protokoll, namnrymd eller utfall. Om du till exempel vill felsöka DNS-matchningsfel filtrerar du felloggar efter DNS-protokollet.

  

  Varje loggpost innehåller etiketter, tidsstämplar och käll-/målinformation som hjälper dig att hitta specifika händelser under en undersökning.

  

• De vanligaste namnrymderna, arbetsbelastningarna och DNS-felen. I det här avsnittet visas de mest aktiva namnrymderna, arbetsbelastningar med högst trafik, portanvändning och de vanligaste DNS-felen. Använd den för att identifiera vilka arbetsbelastningar som genererar mest trafik, oanvända begäranden och jämföra protokolldistribution (till exempel TCP jämfört med UDP). Ovanliga mönster här, till exempel oväntade toppar eller okända mål, kan tyda på felkonfigurationer eller säkerhetsproblem.

  

Aggregering av flödeslogg

Nätverksflöden ökar snabbt. Ett kluster med 200 mikrotjänster kan generera hundratusentals flödesposter var 30:e sekund. Det blir dyrt att lagra alla rådata.

Anta till exempel att client-1 och client-2 pratar med en server pod via TCP. I ett 30-sekundersfönster ser rådataflödesposter på noden ut så här:

Med sammanställning blir dessa 10 poster endast två.

Flödesloggaggregering hanterar detta genom att gruppera liknande flöden i sammanfattade register. Under varje 30-sekundersfönster kombineras flöden som delar samma aggregeringsnyckelfält till en enda post med antalet flöden som den representerar.

Följande fält utgör aggregeringsnyckeln:

Flöden som matchar på alla dessa fält inom ett 30-sekunders fönster sammanfogas till en enda post. Detta bevarar de signaler du behöver (vilka tjänster som kommunicerar, hur ofta, vilka fel som inträffar, om trafiken tilläts eller blockerades) samtidigt som datavolymen minskade avsevärt. Till skillnad från sampling, som slumpmässigt tar bort flöden och kan missa sällsynta säkerhetshändelser, behåller aggregering 100% av mönsterinformationen.

Viktiga punkter:

• Sammansättning är aktiverat och konfigurerat som standard. Detta minskar kostnaderna för logglagring och inmatning utan manuell justering.
• Du styr vilken trafik som samlas in genom includeFilters i ContainerNetworkLog CRD:en.
• Smalare filter (specifika namnområde eller tjänstpar) ger vanligtvis bättre komprimering eftersom de insamlade flödena är mer lika.
• Aggregerade loggar hoppar över attribut med hög kardinalitet och per flöde (till exempel enskilda tidsstämplar, podd-IP-adresser, HTTP-URL:er, DNS-frågenamn) för att minimera inmatningsvolymen och lagringskostnaden. De är utformade för problemidentifiering på hög nivå. Använd loggar på begäran för detaljerad flödesanalys och undersökning.

Loggar på begäran

Med loggar på begäran kan du samla in och inspektera flödesloggar i realtid, utan tidigare konfiguration eller beständig lagring. Använd loggar på begäran när du aktivt felsöker ett anslutningsproblem eller prestandaproblem och behöver omedelbar synlighet.

ACNS innehåller två verktyg för avbildning på begäran. Information om hur du konfigurerar något av verktygen finns i Konfigurera loggläge på begäran.

Hubble CLI

Med Hubble CLI kan du fråga, filtrera och analysera flödesloggar direkt från terminalen. Det är särskilt användbart när du behöver detaljerade filter, till exempel isolera trafik efter namnområde, poddetikett eller bedömning under en aktiv felsökningssession.

Användargränssnittet för Hubble

Användargränssnittet för Hubble ger en grafisk vy över kommunikation från tjänst till tjänst. Det passar bra när du visuellt vill spåra trafikvägar, identifiera vilka tjänster som kommunicerar och upptäcka avvikelser utan att skriva CLI-kommandon.

Viktiga fördelar med loggar på begäran

• Ingen tidigare konfiguration krävs. Börja samla in flöden omedelbart utan att definiera anpassade resurser eller konfigurera lagring.
• Synlighet i realtid. Inspektera livetrafik och visa paketmetadata när problem inträffar.
• Snabb felsökning. Filtrera flöden interaktivt via Hubble CLI eller visa tjänstkartor visuellt i Användargränssnittet för Hubble.
• Låg omkostnad. Ingen beständig lagring krävs, så det finns ingen löpande kostnad för ad hoc-undersökningar.

Rekommendationer för lagrade loggar

1. Börja med breda filter och begränsa sedan. När du först aktiverar flödesloggar använder du breda filter för att samla in trafik över dina nyckelnamnområden. Kör konfigurationen i några dagar och granska insamlade data i Log Analytics. Titta på datavolym, kostnad och om de insamlade flödena matchar det du faktiskt behöver. Dra sedan åt din includeFilters för att fokusera på högvärdestrafik och minska bruset.

2. Använd de färdiga instrumentpanelerna först. De inbyggda instrumentpanelerna i Azure portalen omfattar vanliga användningsfall som tjänstkommunikationsmönster, felfrekvenser och DNS-fel. Börja där. Lägg bara till anpassade paneler eller Log Analytics frågor om du behöver synlighet som de fördefinierade instrumentpanelerna inte tillhandahåller.

3. Granska regelbundet. När arbetsbelastningar och trafikmönster ändras kan dina filter behöva uppdateras. Kontrollera datavolym- och flödestäckningen regelbundet för att se till att du fortfarande samlar in rätt trafik till en rimlig kostnad.

Begränsningar

Krav på dataplan och funktioner:

• Lagrat loggläge fungerar endast med Cilium-dataplanet.
• Layer 7-flödesloggar registreras endast när Layer 7-principstöd är aktiverat. Mer information finns i Konfigurera en Layer 7-princip.
• DNS-flöden och mått registreras endast när en nätverksprincip för Cilium Fullständigt domännamn (FQDN) tillämpas. Mer information finns i Konfigurera en FQDN-princip.

Avvägningar vid aggregation:

• Flödesloggaggregering bevarar inte enskilda flödestidsstämplar, IP-adresser per podd eller fält med hög kardinalitet som HTTP-URL:er och DNS-frågenamn. Använd loggar på begäran för undersökning per flöde.

Lagring och plattform:

• Den värdlokala filen på /var/log/acns/hubble/ är begränsad till 50 MB per nod och roteras automatiskt. Om du behöver långsiktig kvarhållning aktiverar du Azure Monitor (rekommenderas) eller vidarebefordrar filen till din egen loggningstjänst.
• Tabellplanen för hjälp- eller tilläggsloggar stöds inte.

Prissättning

Mer information om priser finns i Advanced Container Networking Services – Prissättning.

Relaterat innehåll

• Konfigurera containernätverksloggar
• Avancerade containernätverkstjänster för AKS
• Observerbarhet för containernätverk i Avancerade containernätverkstjänster
• Nätverkssäkerhet för containrar i Avancerade containernätverkstjänster