Wat zijn metrische gegevens van het containernetwerk?

Metrische gegevens van containernetwerken in Advanced Container Networking Services voor Azure Kubernetes Service (AKS) helpen u bij het identificeren van pakketverlies, het bijhouden van netwerkactiviteit en het onderzoeken van DNS-gedrag. Begin met metrische gegevens op knooppuntniveau om een probleem met de netwerkstatus te vinden en gebruik vervolgens metrische gegevens op podniveau om de betrokken workloads te identificeren.

Het verzamelen van metrische gegevens is beschikbaar voor ondersteunde Cilium- en niet-Cilium-datavlakken. Metrische gegevens op podniveau vereisen Linux; in de referentietabellen ziet u welke metrische gegevens op knooppuntniveau ook beschikbaar zijn op Windows.

Verzameling van metrische gegevens in één oogopslag

Gebruik deze tabel om de ondersteuning voor metrische verzameling in gegevensvlakken te controleren:

Voor de eerste verzameling volgt u Containernetwerkmetrische gegevens instellen. Gebruik containernetwerklogboeken voor records met afzonderlijke verkeersdetails in plaats van tellers.

Belangrijkste voordelen

• Granulariteit op knooppunt- en podniveau. Houd het verkeersvolume, de dalingspercentages en de verbindingsstatussen bij op knooppuntniveau voor de status van de infrastructuur. Zoom in op afzonderlijke pods met bron- en doellabels om de exacte workload te bepalen die een probleem veroorzaakt.

• Snellere probleemoplossing. Wanneer een service pakketten begint te verliezen of DNS-query's mislukken, helpen metrische gegevens op podniveau u het probleem te isoleren tot een specifieke pod, naamruimte of protocol.

• Ingebouwde visualisatie. Sla metrische gegevens op in de beheerde service van Azure Monitor voor Prometheus en open netwerkdashboards rechtstreeks in de Azure-portal met Dashboards met Grafana. De dashboardervaring is gratis en vereist geen Azure Managed Grafana exemplaar; ACNS en metrische gegevensopname en opslagkosten zijn nog steeds van toepassing. U kunt ook een afzonderlijke Grafana-implementatie gebruiken.

Hoe werkt het?

De agentstack op elk knooppunt is afhankelijk van het gegevensvlak, zoals weergegeven in het diagram.

Linux-Cilium-knooppunten maken gebruik van een gelaagde stack op basis van eBPF: eBPF-kernelhook legt onbewerkte verkeersgegevens vast, Cilium verwerkt deze en Hubble maakt het beschikbaar als metrische gegevens van Prometheus-indeling.

Linux niet-Cilium-knooppunten gebruiken eBPF-kernelhaken die worden ingevoerd in Microsoft Retina, met een Hubble-laag bovenaan voor stroominspectie. Microsoft Retina verwerkt metrische gegevensverzameling en exporteert metrische gegevens op knooppunt- en podniveau in Prometheus-indeling.

Vanuit alle paden verzamelt u metrics in Prometheus-indeling en neemt u deze op in de door Azure Monitor beheerde service voor Prometheus of uw eigen Prometheus-back-end. Voor het beheerde pad opent u uw AKS-cluster in de Azure-portal en selecteert u Monitoring> om netwerkdashboards weer te geven. Azure Managed Grafana en uw eigen Grafana-implementatie zijn optionele alternatieven. Zie Dashboards gebruiken met Grafana met AKS.

Om aan de slag te gaan, stelt u containernetwerkmetingen in.

Wanneer gebruikt u metrische gegevens van containernetwerk

Metrische gegevens van containernetwerk zijn ontworpen voor teams die gerichte, bruikbare netwerkgegevens nodig hebben in plaats van onbewerkte telemetrie. Veelvoorkomende scenario's zijn onder andere:

• Fouten opsporen in een specifieke workload. Gebruik metrische gegevens op podniveau om pakketuitval, TCP-resets of DNS-fouten voor een bepaalde service te isoleren.
• Multitenantclusters bewaken. Gebruik metrische gegevens op podniveau om de netwerkstatus per naamruimte bij te houden en inzicht te hebben in de verkeerspatronen van elk team.
• Capaciteitsplanning. Volg doorgestuurde en gedropte byteaantallen per knooppunt om verzadigde verbindingen of onevenwichtige werkbelastingplaatsing te identificeren.
• DNS-statuscontrole. Identificeer DNS-queryfouten en trage resolutietijden om problemen te signaleren en te voorkomen voordat deze uiteinden in toepassingsfouten resulteren.

Voordat u de tabellen met metrische gegevens bekijkt

Houd rekening met deze punten:

• Metrische gegevens op knooppuntniveau zijn beschikbaar voor ondersteunde Cilium- en niet-Cilium-gegevensvlakken.
• Metrische gegevens op podniveau zijn beschikbaar in Linux.
• Voor Cilium-clusters is voor DNS-metrische gegevens een Cilium FQDN-netwerkbeleid vereist.

Referentie metrische gegevens

Metrische gegevens op knooppuntniveau

Metrische gegevens op knooppuntniveau bieden statistische verkeersstatistieken per knooppunt, doorgestuurde en verwijderde pakketten, byteaantallen en verbindingsstatussen. Deze metrische gegevens worden opgeslagen in prometheus-indeling en kunnen worden gevisualiseerd in Grafana.

De volgende metrische gegevens worden per knooppunt samengevoegd. Alle metrische gegevens bevatten deze labels:

• cluster
• instance (knooppuntnaam)

Cilium

Voor Cilium-gegevensvlakclusters zijn metrische gegevens op knooppuntniveau alleen beschikbaar op Linux. Cilium exposeert de volgende metrieken die worden gebruikt door het containernetwerk:

Niet-Cilium

Voor scenario's met niet-Cilium-gegevensvlakken zijn metrische gegevens van het containernetwerk beschikbaar voor linux en Windows.

Metrische gegevens op podniveau (Hubble-metrische gegevens)

Metrische gegevens op podniveau bevatten bron- en doelpodgegevens, zodat u netwerkproblemen op het niveau van de afzonderlijke werkbelasting kunt vaststellen. Deze metrische gegevens hebben betrekking op verkeersvolume, verwijderde pakketten, TCP-resets en Laag 4/Laag 7-stromen.

DNS-metrische gegevens (queryaantallen, antwoordcodes en fouten) worden standaard verzameld op niet-Cilium-gegevensvlakken. Voor Cilium-gegevensvlakken is voor DNS-metrische gegevens een Cilium-FQDN-netwerkbeleid vereist. U kunt ook in realtime problemen met DNS oplossen met behulp van de Hubble CLI.

In de volgende tabel worden de metrische gegevens beschreven die per pod worden geaggregeerd (knooppuntgegevens blijven behouden).

Alle metrische gegevens bevatten labels:

• cluster

• instance (knooppuntnaam)

• source of destination

  • Voor uitgaand verkeer geeft een source label de naamruimte en naam van de bronpod aan.

  • Voor binnenkomend verkeer geeft een destination label de naamruimte en naam van de doelpod aan.

Kies welke metrische gegevens moeten worden verzameld op Cilium-clusters

Op Cilium-clusters gebruikt u filteren op bronniveau om te selecteren welke waarnemingen bijdragen aan afzonderlijke Hubble-metrieken voordat ze uw monitoringbackend bereiken. Deze filtering verschilt van het filteren van een Grafana-dashboard, waarbij alleen verandert wat je ziet. Beperk de verzameling tot een toepassing en schakel vervolgens selectief metrische gegevens voor externe IP- of doelpoorten in wanneer een onderzoek dat detail nodig heeft.

Filteren kan onnodige verzameling verminderen en helpen bij het beheren van innamekosten. Aanvullende metrische data kunnen het aantal tijdreeksen en de kosten verhogen, dus controleer hoeveel meerwaarde ze bieden en in welke hoeveelheid voordat u ze uitbreidt. Eerder gemaakte reeksen en historische steekproeven kunnen zichtbaar blijven; besparingen zijn afhankelijk van uw traffic en configuratie.

Wanneer u Container Network Observability inschakelt, stellen de agents de standaardnetwerkgegevens van de service beschikbaar. Gebruik op Cilium-clusters een ContainerNetworkMetric custom resource om verkeer te selecteren voor afzonderlijke metriektypen.

Als u een metrische waarde beschikbaar maakt in het cluster, wordt deze niet automatisch beschikbaar gemaakt in Azure Monitor beheerde service voor Prometheus. Standaard stellen de clusteragents hubble_flows_processed_total beschikbaar, maar beheerde Prometheus sluit deze uit van de verzameling omdat het een groot aantal tijdreeksen kan produceren. Beheerde Prometheus sluit hubble_flows_to_world_total en hubble_port_distribution_total ook standaard uit, zelfs wanneer u ze inschakelt op het cluster. Als u een van deze metrische gegevens wilt verzamelen en er query's op wilt uitvoeren, voegt u de naam toe aan de Hubble-acceptatielijst in de ama-metrics-settings-configmap ConfigMap. Zie De metrische families in beheerde Prometheus toestaan voor stappen.

Er is één gedeelde ContainerNetworkMetric resource per cluster, met de naam container-network-metric. Coördineer updates met andere beheerders en bewaar metrische instellingen die door andere teams worden gebruikt.

Begin met inclusiefilters om verkeer voor een toepassing of bestemming te selecteren. Uitsluitingsfilters zijn optioneel: gebruik ze om een subset van geselecteerd verkeer weg te laten of gebruik filters die alleen uitsluiten om een brede verzameling met specifieke uitzonderingen te behouden. Een uitsluiting heeft voorrang op een overeenkomende inclusie.

Filteren is niet beperkt tot de optionele world- en doelpoortgegevens. Gebruik de volgende configuratienamen voor bestaande metrische gegevens:

Deze filters zijn van toepassing wanneer de metriek aanwezig is in de basisconfiguratie van de service. Filterconfiguratie en observatiegeneratie zijn gescheiden: DNS-metrische observaties vereisen een toegepast DNS-inspectiebeleid en DNS-verkeer. Http-metrische waarnemingen vereisen inschakeling op clusterniveau L7, een HTTP-inspectiebeleid dat is toegepast op de workload en HTTP-verkeer via dat beleid. De filterstatus verifieert niet of aan deze vereisten is voldaan. Filteren maakt inspectie niet mogelijk en ontsleutelt geen HTTPS-verkeer. Gebruik voor HTTP de hoofdlettergevoelige naam httpV2, niet http.

Zie DNS, TCP, HTTP en drop filtering voor voorbeelden.

Gebruik bijvoorbeeld include-filters om flowstatistieken te selecteren voor TCP-verkeer van de production naamruimte naar eindpunten die Cilium als world classificeert. Hiermee wijzigt u het verzamelen van flowmetriek zonder de verzameling voor andere metrische typen te wijzigen. Filters ondersteunen naamruimte- en podnamen, labels, IP-adressen, Cilium-beveiligingsidentiteiten, protocollen en oordelen.

Filteren bepaalt welke waarnemingen bijdragen aan een metriek. Er worden geen metrische labels toegevoegd of verwijderd. In tegenstelling tot extra aggregatievelden voor logboeken blijven metrische dimensies beheerd door de service.

Het filteren is van invloed op nieuwe metrische waarnemingen bij de bron. Als u een workload selecteert in Grafana, worden de weergegeven resultaten gewijzigd, niet de verzamelingsconfiguratie. Eerder verzamelde gegevens blijven in uw metrics-back-end.

Aanvullende metrische gegevens

Als u een van de volgende metrische gegevens wilt verzamelen, voegt u een vermelding toe aan de clusterresource ContainerNetworkMetric met includefilters die het verkeer selecteren dat u wilt bewaken. Als de metriek nog niet is ingeschakeld, schakelt de vermelding deze in voor het geselecteerde netwerkverkeer. Als deze al is ingeschakeld, filtert de vermelding welk verkeer hieraan bijdraagt zonder de bestaande labels of opties te wijzigen.

Voor metrics die via deze resource nieuw zijn ingeschakeld, configureert de service bronpod- en doel-IP-labels voor flows-to-world. Voor port-distribution worden bron- en doelpodlabels en verkeersrichting geconfigureerd. Protocol- en uitkomstlabels zijn opgenomen voor flows-to-world; protocol- en doelpoortlabels zijn opgenomen voor port-distribution. Met deze door de service geleverde opties telt de wereldmetriek UDP-verkeer of niet-beleidsgerelateerde drops niet mee.

Deze metrische gegevens tellen waargenomen netwerkgebeurtenissen, geen unieke verbindingen of toepassingsaanvragen. Als een client bijvoorbeeld een TCP SYN-pakket verzendt en het vervolgens opnieuw verzendt terwijl deze verbinding probeert te maken, kan hubble_flows_to_world_total beide waarnemingen tellen, ook al behoren ze tot dezelfde verbindingspoging. Labels zoals podnamen worden alleen ingevuld wanneer die informatie beschikbaar is voor het waargenomen verkeer.

Zie voorbeeldconfiguratie en vastgelegde resultaten voor een volledige aangepaste resource en schermopnamen van beide metrische gegevens die zijn verzameld uit een testworkload.

Relevantie en ruis van gegevens beheren

Gebruik filteren om metrische gegevens toe te spitsen op de werkbelastingen en het verkeer dat relevant is voor uw bewaking of onderzoek. Het uitsluiten van niet-gerelateerd verkeer vermindert gegevensruis en helpt u zich te concentreren op de netwerksignalen die van belang zijn.

Doel-IP-adressen, podnamen en poorten kunnen veel tijdreeksen produceren. Deze details kunnen nuttig zijn, maar het verzamelen ervan voor niet-gerelateerd verkeer voegt ruis toe en kan de kosten voor gegevensinname verhogen. Begin met een specifieke workload of naamruimte, controleer of de metrische gegevens uw vragen beantwoorden en het resulterende gegevensvolume controleren voordat u de verzameling uitbreidt.

De aangepaste resource rapporteert een waarschuwing voor elke ingeschakelde extra metriek. De waarschuwing identificeert een mogelijke kostenverhoging; er wordt geen schatting gemaakt van uw factuur of wordt aangegeven dat een limiet is overschreden. De service beheert metrieklabels en u kunt deze niet wijzigen via deze resource.

Als u een vermelding verwijdert, wordt de metrische waarde alleen uitgeschakeld als die vermelding de metrische waarde heeft ingeschakeld. Als de service de metriek levert, blijft deze ingeschakeld zonder de filters van die invoer. Als u de gedeelde resource verwijdert, worden alle filters verwijderd en wordt de door de service geleverde collectie hersteld, waardoor het verkeer dat in deze metrische gegevens is opgenomen, kan worden uitgebreid en het gegevensgeluid en opnamevolume kan toenemen.

Zie Containernetwerkmetriekfiltering configureren voor YAML-voorbeelden, verificatiequery's en opschoningsstappen.

Limitations

Platform en gegevensvlak:

• Metrische gegevens op podniveau zijn alleen beschikbaar in Linux.
• Het gegevensvlak Cilium wordt ondersteund vanaf Kubernetes versie 1.29.
• Filteren op metrische gegevens op bronniveau is alleen beschikbaar voor Cilium-clusters.
• Filtervermeldingen kunnen flows-to-world en port-distribution inschakelen wanneer de service deze nog niet levert. De service beheert hun labels; deze resource stelt geen aangepaste dimensies voor metrische gegevens beschikbaar.
• Metrische labels hebben subtiele verschillen tussen Cilium- en niet-Cilium-clusters.

DNS-metrieken:

• Voor Cilium-clusters is voor DNS-metrische gegevens een Cilium FQDN-netwerkbeleid vereist of kunt u de Hubble CLI gebruiken voor realtime DNS-probleemoplossing.

Bekende problemen:

• Als een Hubble-knooppuntagent uitvalt, kan de Hubble-relay vastlopen, waardoor Hubble CLI-sessies kunnen worden onderbroken.

FIPS-ondersteuning (alleen niet-Cilium-gegevensvlakken):

• FIPS is niet beschikbaar op Ubuntu 20.04-knooppunten vanwege kernelbeperkingen. Gebruik in plaats daarvan een Azure Linux- of Ubuntu 22.04-knooppuntgroep. Deze beperking geldt niet voor Cilium-gegevensvlakken.

Scale:

• De beheerde service voor Prometheus in Azure Monitor en Azure Managed Grafana legt servicespecifieke schaalbeperkingen op. Zie De metrische gegevens van Scrape Prometheus op schaal in Azure Monitor voor meer informatie.

Pricing

Zie Advanced Container Networking Services - Prijzen voor meer informatie over prijzen.

Verwante inhoud

• Metrische gegevens van containernetwerk instellen
• Filteren van metrische gegevens voor containernetwerk configureren
• Geavanceerde Container Networking Services voor AKS
• Containernetwerkobservatie in Geavanceerde Container Netwerkdiensten
• Container Network Security in Advanced Container Networking Services