Vad är containernätverksloggar?

Containernätverksloggar i Advanced Container Networking Services för Azure Kubernetes Service (AKS) hjälper dig att undersöka vilka arbetsbelastningar som kommunicerade, vilka mål de nådde och om trafiken vidarebefordrades eller blockerades. Använd mått för att upptäcka ett nätverksproblem och använd sedan loggar för att undersöka trafiken. Enbart en flödesbedömning fastställer inte om en programförfrågan lyckades.

Beroende på flödestyp, synlighetskonfiguration och behållna aggregeringsfält kan loggarna innehålla:

• 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).

För lagrade loggar hjälper anpassningsbar flödesloggaggregering dig att balansera driftsynlighet med datavolym och kostnad. Aggregering sammanfattar liknande observationer, bevarar arbetsbelastningens kommunikationsmönster och antalet vidarebefordrade eller kasserade observationer. Lägg till grupperingsfält utöver tjänstens standardvärden för att skräddarsy dessa sammanfattningar efter dina behov. Volymminskningen beror på hur mycket trafik som delar samma grupperingsvärden. Mer information finns i Agregering av flödesloggar.

Välj ett insamlingsläge

Börja med Konfigurera containernätverksloggar. Guiden skiljer mellan insamling, valfri vidarebefordran till Azure Monitor och verifiering.

Lagrade loggar

I ett Cilium-kluster som stöds med ACNS aktiverat definierar du vilken trafik som ska samlas in innan du förväntar dig lagrade loggar. Att enbart aktivera tjänsten väljer inte trafik eller konfigurerar långsiktig kvarhållning.

Om du vill börja samla in loggar definierar du ContainerNetworkLog anpassade resurser som väljer trafik efter namnrymd, podd, etiketter, IP-adress, numerisk Cilium-säkerhetsidentitet, protokoll eller verdict. När konfigurationen når agenterna skriver noder som observerar matchande trafik de valda loggarna. Flera resurser kan samla in trafik samtidigt.

Använd filter för att fokusera på de flöden som är viktiga. Använd flödesloggaggregering för att sammanfatta dessa flöden och anpassa dess grupperingsfält för att bevara de distinktioner som dina undersökningar behöver. Tillsammans gör de här kontrollerna att du kan skräddarsy vad du samlar in och hur det sammanfattas. Granska den resulterande datavolymen: smalare filter kan minska insamlingen, medan fler grupperingsfält kan öka antalet poster.

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

Använd Azure Monitor för integrerade frågor och instrumentpaneler eller behåll din befintliga loggningspipeline.

Utan en pipeline för vidarebefordran finns loggar kvar i roterande lokala nodfiler och behålls inte för långsiktiga undersökningar.

Viktiga funktioner i lagrat loggläge

Anpassa din observabilitet så att den matchar dina behov: välj vilken trafik som ska samlas in och vilken information som ska särskiljas när du grupperar den i lagrade loggar.

• Anpassningsbara filter. Definiera anpassade ContainerNetworkLog-resurser för att välja trafik efter käll- eller målnamnrymd, podd, etikett, IP-adress eller CIDR-intervall, Cilium-säkerhetsidentitet, protokoll eller domslut. Trafik som matchar filtren för någon konfigurerad resurs är berättigad till insamling, vilket ger dig kontroll över vad du samlar in och hjälper dig att hantera inmatningsvolymen.

• Anpassningsbar flödesloggaggregering. Använd aggregering för att minska den lagrade loggvolymen samtidigt som du behåller den information du behöver för nätverksundersökningar. Som standard kombinerar aggregering flödesobservationer med matchande grupperingsfältvärden i sammanfattade poster var 30:e sekund. Lägg till grupperingsfält för att behålla information utöver tjänstens standardvärden. Fler grupperingsfält kan skapa fler poster, så kombinera aggregering med riktade filter för att balansera undersökningsbehov med inmatnings- och lagringskostnader. Läs mer om aggregering 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. Köra frågor mot och analysera loggar i Log Analytics, eller använd instrumentpanel för din tabellplan. Granska planens fråge- och funktioner för lagringstid innan du väljer den. Mer information finns i Visualize-loggar i Azure-portalen.

Visualisera loggar i Azure-portalen

För detaljerade undersökningar öppnar du Övervakning> på AKS-klustrets sida i Azure-portalen. I den mottagande Log Analytics-arbetsytan kör du en fråga mot ContainerNetworkLogs-tabellen.

På AKS-klustrets sida i Azure-portalen väljer du Övervakning>instrumentpaneler med Grafana för att visa de inbyggda instrumentpanelerna för flödesloggar. Du behöver ingen Azure Managed Grafana-instans och det tillkommer ingen extra kostnad för instrumentpaneler. ACNS och avgifter för logginsamling och lagring gäller fortfarande.

Välj den översiktspanel som matchar din ContainerNetworkLogs bordsplan:

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. Granska trafiksammanfattningar och vidarebefordrade eller kasserade observationer och använd sedan diagrammet över tjänstberoenden för att identifiera kommunikationsvägar som är värda att undersöka. Protokollspecifik information beror på synlighet och bevarade fält. Aggregerade antal observationer är inte antal unika begäranden.

  

• 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.

  

  Vilken information som är tillgänglig på instrumentpanelen beror på den insamlade trafiken och aggregeringskonfigurationen. Om du vill anpassa detaljnivån i dina lagrade loggar, se Anpassa flödesloggaggregering.

  Använd tillgängliga tidsstämplar och käll-/målinformation för att korrelera poster med en undersökning. En aggregerad post har ingen separat tidsstämpel för varje observation i gruppen.

  

• 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

Hårt belastade arbetslaster kan generera många upprepade flödesobservationer mellan samma slutpunkter. Om du lagrar varje observation separat ökar mängden data som du måste ta in, behålla och söka, även när din omedelbara fråga helt enkelt är vilka arbetsbelastningar som kommunicerade och om deras trafik vidarebefordrades eller blockerades.

Aggregering ger en startpunkt med lägre volymer för historiska nätverksundersökningar. Varje nod kombinerar valda flödesobservationer som delar samma grupperingsfältvärden inom ett aggregeringsintervall. I stället för att skriva varje observation separat skriver den en sammanfattad post för varje grupp, inklusive antal ingress-, egress- och okända riktningsobservationer.

Exempel: Före och efter aggregering

Överväg två klientpoddar, client-1 och client-2, som kommunicerar med en server-podd via TCP-porten 80 under ett 30-sekundersfönster. Varje podd tillhör en separat arbetsbelastning med samma namn. Följande observationer illustrerar upprättande av anslutningar, dataöverföring och svar.

Före aggregering: tio observationer

För den här illustrationen observerar en nod varje post en gång vid klientslutpunkterna: observationer från klient till server är utgående och svar är inkommande. Alla utslag är FORWARDED, och de andra standardgruppvärdena är identiska i varje grupp som visas nedan.

Efter standardaggregering: fyra sammanfattade poster

De tio observationerna blir fyra poster, vilket bevarar alla tio observationer i sina antal. Du kan fortfarande se vilka arbetsbelastningar som kommunicerade med varandra, målportarna och volymen som observerats i varje riktning utan att lagra varje TCP-flaggövergång separat.

Grupperna förblir separata av följande skäl:

• Olika arbetslaster: metadata för käll- och målarbetslast är standardfält för gruppering.
• Ursprunglig trafik och svar: slutpunktsvärden, målportar och is_reply skiljer sig åt, så att de två riktningarna inte komprimeras till en post.
• Olika destinationsportar för svar:12345 och 23456 behålls som målportar för svarstrafik. Källportar, enskilda poddnamn och TCP-flaggor behålls inte av standardkonfigurationen för gruppering.

Standardinställningar för aggregering

Aggregering är aktiverat som standard för lagrade loggar, med ett aggregeringsintervall på 30 sekunder och standardgrupperingsfälten som anges i följande tabell. Inom varje nods intervall kombineras observationer med samma värden för alla grupperingsfält till en sammanfattad post.

Ett fält kan bara innehålla ett värde när den informationen är tillgänglig i det ursprungliga flödet. Standardgruppering aktiverar inte DNS- eller HTTP-inspektion.

Dessa standardinställningar bevarar kommunikation mellan arbetslaster, målportar, utvärderingar och svarskoder. De behåller inte alla detaljer per flöde: enskilda poddnamn, käll- och mål-IP-adresser, klientkällportar, DNS-frågenamn och HTTP-URL:er finns inte i den här standardlistan.

Ytterligare fält utökar den här listan. de ersätter den inte. Använd spec.aggregation.additionalFields för att anpassa gruppering utan att ta bort standardfält eller ändra intervallet på 30 sekunder. Att upprepa ett standardfält lägger inte till ytterligare en kopia. Ändringar påverkar framtida poster och kan inte återskapa uppgifter som utelämnats från historiska loggar.

Anpassa flödesloggaggregering

Skräddarsy flödesloggaggregering efter dina drift- och undersökningskrav genom att välja ytterligare grupperingsfält utöver standardinställningarna för tjänsten. Du styr vilka distinktioner dina sammanfattade loggar bevarar, från trafikriktning och DNS-begäran/svarstyp till enskilda IP-adresser, DNS-namn eller HTTP-URL:er. Välj valfritt fält som stöds av klustrets flödesschema för att besvara de frågor som är viktiga för dig.

Lägg till fält spec.aggregation.additionalFields i i en ContainerNetworkLog resurs för att anpassa aggregering. De ytterligare fälten blir grupperingsnycklar: flöden med olika värden för dessa fält lagras i separata grupper.

Om du till exempel lägger till följande fält separeras observationer som annars skulle dela samma aggregeringsgrupp:

Dessa fält är exempel, inte en fullständig lista över tillåtna värden. Du kan ange giltiga fältsökvägar från Hubble-meddelandet Flow i Ciliums flow.proto-definition. Använd fält som stöds av Cilium-versionen som körs i klustret; den länkade main-grenen kan innehålla fält som klustret ännu inte stöder. Det ursprungliga flödet måste innehålla ett fälts värde för att det ska behållas.

Fält med högre kardinalitet, till exempel IP-adresser, enskilda poddnamn, källportar, DNS-namn och HTTP-URL:er, är tillgängliga när du behöver den detaljnivån. Eftersom de kan ha många distinkta värden kan aktivering av dem öka loggvolymen och intags- och lagringskostnaderna i klustret. Innan du aktiverar dem bör du utvärdera den förväntade volymen, kostnaden och konsekvenserna för känsliga data. Övervaka sedan användningen för att balansera den information du behöver med din budget.

Loggar som innehåller de bevarade fälten skrivs till /var/log/acns/hubble/events.log på varje nod som observerar matchande trafik. När Azure Monitor vidarebefordran har konfigurerats kan du fråga de insamlade loggarna i Log Analytics med hjälp av de kolumner som är tillgängliga i ContainerNetworkLogs tabellen, inklusive bevarade egenskaper som representeras i dess dynamiska kolumner. Använd tabellschemat för att identifiera den kolumn eller dynamiska egenskap som ska refereras till i din fråga.

Välj trafik efter säkerhetsidentitet

Använd Cilium-säkerhetsidentiteter i käll- eller målfilter för att välja vilken trafik som ska loggas. Kombinera identitetsfilter med namespace, podd, protokoll eller verdictkriterier. Välj till exempel TCP-trafik från ett namespace till endpoints som Cilium klassificerar som world.

En säkerhetsidentitet är Ciliums klassificering av en ändpunkt, inte en Azure-hanterad identitet eller en användaridentitet. Konfigurationen accepterar numeriska ID:n, inte alias som world. Se identitetsexemplet och -värdena.

Anpassningsbara filter och aggregering ger dig kompletterande kontroller: filter väljer de flöden som ska samlas in, medan ytterligare grupperingsfält anpassar hur alla valda flöden i klustret sammanfattas.

Förstå omfånget och kostnaden

Ytterligare fält gäller för alla markerade lagrade loggar i klustret. De är inte begränsade till filtren i resursen som begär dem.

Om till exempel en resurs begär l7.type och en annan begär traffic_direction, blir båda fälten en del av klustrets grupperingskonfiguration. Att ta bort den första resursen tar endast bort dess fält om ingen annan giltig resurs begär det. Fält som tillhandahålls av tjänsten finns kvar.

Fler distinkta fältvärden kan generera fler poster. Börja med de fält som behövs för din utredning, granska ingestionsvolymen och ta bort tillfälliga tillägg när du är klar. Samordna ändringar med andra team som samlar in loggar från samma kluster.

Använd Konfigurera loggar för containernätverk för fullständiga YAML-exempel och verifieringssteg.

Loggar på begäran

Med loggar på begäran kan du inspektera flödesloggar i realtid utan att definiera en resurs för lagrad logg eller konfigurera beständig lagring. Aktivera ACNS och anslut din Hubble-klient först. Använd det här läget när du behöver omedelbar synlighet under felsökningen.

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 konfiguration av lagrad logg krävs. När du har anslutit Hubble till ditt ACNS-aktiverade kluster kontrollerar du tillgängliga flöden utan att definiera en ContainerNetworkLog resurs.
• 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.
• Ingen beständig lagring krävs. Inspektera liveflöden utan att konfigurera historisk logglagring. ACNS-tjänstavgifter gäller fortfarande.

Rekommendationer för lagrade loggar

1. Börja med en arbetslast och en tydlig fråga. Välj det program och den trafik som behövs för undersökningen. Verifiera aktuella poster, granska volymen och expandera sedan samlingen om det behövs. Undvik att aktivera bred samling bara för att testa att loggning fungerar.

2. Skräddarsy aggregering efter dina driftsbehov. Välj ytterligare grupperingsfält som hjälper dig att besvara dina frågor och utvärdera deras volym- och kostnadspåverkan. Samordna klusteromfattande ändringar med andra team och ta bort tillfälliga tillägg när undersökningen avslutas. Behandla DNS-namn och URL:er som potentiellt känsliga driftdata.

3. 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.

4. 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:

• Ytterligare fält kan behålla distinktioner som käll- och mål-IP-adresser, HTTP-URL:er eller DNS-frågenamn. Det ursprungliga flödet måste innehålla data.
• Fält gäller för valda lagrade loggar i klustret och kan öka antalet poster och kostnader för datainmatning.
• Ändringar påverkar nyligen insamlade data. De återställer inte information från historiska loggar, ändrar tabellschemat eller anger en tidsstämpel för varje händelse i en aggregerad post. Använd loggar på begäran för realtidsgranskning 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

• Identifiera DNS-namn som är associerade med misslyckanden

• 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