Co to są metryki sieci kontenerów?

Metryki sieci kontenerów w usłudze Advanced Container Networking Services dla Azure Kubernetes Service (AKS) ułatwiają identyfikowanie utraty pakietów, śledzenie aktywności sieci i badanie zachowania usługi DNS. Zacznij od metryk na poziomie węzła, aby znaleźć problem ze stanem sieci, a następnie użyj metryk na poziomie poda, aby zidentyfikować zaangażowane obciążenia.

Kolekcja metryk jest dostępna na obsługiwanych płaszczyznach danych Cilium i innych niż Cilium. Metryki na poziomie zasobnika wymagają systemu Linux; tabele referencyjne pokazują, które metryki na poziomie węzła są również dostępne w Windows.

Błyskawiczne zbieranie metryk

Ta tabela służy do sprawdzania obsługi zbierania metryk na różnych płaszczyznach danych:

Zdolność	Klastry Cilium	Klastry inne niż Cilium
Zbieranie metryk na poziomie węzła	✅	✅
Zbieranie metryk na poziomie poda	✅ (Linux)	✅ (Linux)

W przypadku początkowej kolekcji postępuj zgodnie z instrukcjami Skonfiguruj metryki sieci kontenera. W przypadku rekordów indywidualnych szczegółów ruchu, a nie liczników, użyj dzienników sieciowych kontenerów.

Important

Począwszy od 30 listopada 2025 r., usługa Azure Kubernetes Service (AKS) nie obsługuje już ani nie zapewnia aktualizacji zabezpieczeń dla systemu Azure Linux 2.0. Obraz węzła systemu Azure Linux 2.0 jest zamrożony w wydaniu202512.06.0. Od 31 października 2026 r. obrazy węzłów zostaną usunięte i nie można skalować pul węzłów. Przeprowadź migrację do obsługiwanej wersji systemu Linux platformy Azure, uaktualniając pule węzłów do obsługiwanej wersji rozwiązania Kubernetes lub migrując do systemu osSku AzureLinux3. Aby uzyskać więcej informacji, zapoznaj się z zgłoszeniem dotyczącym wycofania na GitHubie i ogłoszeniem o wycofaniu aktualizacji platformy Azure. Aby być na bieżąco z ogłoszeniami i aktualizacjami, śledź notatki o wydaniu AKS.

Najważniejsze korzyści

Granularność na poziomie węzła i poda. Śledzenie ilości ruchu, współczynników spadku i stanów połączeń na poziomie węzła na potrzeby kondycji infrastruktury. Zanurz się w szczegóły poszczególnych podów z etykietami źródłowymi i docelowymi, aby zidentyfikować dokładne obciążenie powodujące problem.
Szybsze rozwiązywanie problemów. Gdy usługa zacznie gubić pakiety lub zapytania DNS kończą się niepowodzeniem, metryki na poziomie poda ułatwiają izolowanie problemu z określonym podem, przestrzenią nazw lub protokołem.
Wbudowana wizualizacja. Przechowuj metryki w usłudze zarządzanej Azure Monitor dla rozwiązania Prometheus i otwieraj pulpity nawigacyjne sieciowe bezpośrednio w portalu Azure przy użyciu Pulpity nawigacyjne z Grafaną. Obsługa pulpitu nawigacyjnego jest bezpłatna i nie wymaga instancji usługi Azure Managed Grafana, nadal obowiązują opłaty za pozyskiwanie oraz przechowywanie danych ACNS i metryk. Można również użyć oddzielnego wdrożenia narzędzia Grafana.

Jak to działa

Stos agenta na każdym węźle zależy od płaszczyzny danych, jak pokazano na diagramie.

Węzły Cilium systemu Linux używają warstwowego stosu opartego na eBPF: punkty zaczepienia jądra eBPF przechwytują nieprzetworzone dane ruchu, przetwarza je Cilium i Hubble udostępnia je jako metryki formatu Prometheus.

Węzły Linux bez Cilium używają haków jądra eBPF przekazujących do Microsoft Retina, z warstwą Hubble na górze do inspekcji ruchu sieciowego. Microsoft Retina obsługuje zbieranie metryk i eksportuje metryki na poziomie węzła i na poziomie podu w formacie Prometheus.

Ze wszystkich ścieżek można zbierać metryki w formacie Prometheus i pozyskiwać je do usługi Azure Monitor managed service for Prometheus lub własnego backendu Prometheus. W przypadku ścieżki zarządzanej otwórz klaster usługi AKS w portalu Azure i wybierz pozycję Monitorowanie>Pulpity nawigacyjne z narzędziem Grafana, aby wyświetlić pulpity nawigacyjne sieci. Azure Managed Grafana i własne wdrożenie narzędzia Grafana są opcjonalnymi alternatywami. Zobacz Korzystanie z pulpitów Grafana w usłudze AKS.

Aby rozpocząć, skonfiguruj metryki sieci kontenera.

Kiedy należy używać metryk sieci kontenerów

Metryki sieci kontenerów są przeznaczone dla zespołów, które wymagają skoncentrowanych, przydatnych danych sieciowych, a nie nieprzetworzonych danych telemetrycznych. Typowe scenariusze obejmują:

Debugowanie określonego obciążenia. Użyj metryk na poziomie podu, aby odizolować straty pakietów, resetowanie protokołu TCP lub błędy DNS dla konkretnej usługi.
Monitorowanie klastrów wielodzierżawnych. Użyj metryk na poziomie zasobnika, aby śledzić kondycję sieci według przestrzeni nazw i zrozumieć wzorce ruchu każdego zespołu.
Planowanie pojemności. Śledzenie liczby przesłanych dalej i porzuconych bajtów dla każdego węzła, aby zidentyfikować nasycone łącza lub niezrównoważone rozmieszczenie obciążenia.
Monitorowanie kondycji DNS. Uwidaczniaj niepowodzenia zapytań DNS i wolne czasy rozwiązywania zapytań, aby przechwycić problemy przed eskalacją błędów aplikacji.

Przed przejrzeniem tabel metryk

Pamiętaj o tych kwestiach:

Metryki na poziomie węzła są dostępne na obsługiwanych płaszczyznach danych Cilium i innych niż Cilium.
Metryki na poziomie podu są dostępne w systemie Linux.
W klastrach Cilium metryki DNS wymagają stosowania zasad sieciowych Cilium FQDN.

Referencja metryk

Metryki na poziomie węzła

Metryki na poziomie węzła zapewniają zagregowane statystyki ruchu na węzeł — przekazywane i porzucone pakiety, liczby bajtów i stany połączenia. Te metryki są przechowywane w formacie Prometheus i można je wizualizować w narzędziu Grafana.

Następujące metryki są agregowane na każdy węzeł. Wszystkie metryki obejmują następujące etykiety:

cluster
instance (nazwa węzła)

Cilium

W przypadku klastrów płaszczyzny danych Cilium metryki na poziomie węzła są dostępne tylko w systemie Linux. Cilium udostępnia następujące metryki stosowane w metrykach sieci kontenerów.

Nazwa metryki	Description	Dodatkowe etykiety	Linux	Windows
cilium_forward_count_total	Łączna liczba przekazanych pakietów	`direction`	✅	❌
cilium_forward_bytes_total	Łączna liczba przekazanych bajtów	`direction`	✅	❌
cilium_drop_count_total	Łączna liczba porzuconych pakietów	`direction`, `reason`	✅	❌
cilium_drop_bytes_total	Łączna liczba porzuconych bajtów	`direction`, `reason`	✅	❌

Non-Cilium

W przypadku scenariuszy płaszczyzny danych innych niż Cilium, metryki sieci kontenerów są dostępne zarówno dla systemu Linux, jak i Windows.

Nazwa metryki	Description	Dodatkowe etykiety	Linux	Windows
networkobservability_conntrack_bytes_rx	Liczba bajtów RX dla Conntrack		✅	❌
networkobservability_conntrack_bytes_tx	Liczba bajtów conntrack TX		✅	❌
networkobservability_conntrack_packets_rx	Liczba pakietów RX rozwiązania Conntrack		✅	❌
networkobservability_conntrack_packets_tx	Liczba pakietów Conntrack TX		✅	❌
networkobservability_conntrack_total_connections	Łączna liczba połączeń conntrack		✅	❌
networkobservability_dns_request_count	Liczba żądań DNS		✅	❌
networkobservability_dns_response_count	Liczba odpowiedzi DNS		✅	❌
networkobservability_drop_bytes	Łączna liczba porzuconych bajtów	`reason`, `direction`	✅	❌
networkobservability_drop_count	Łączna liczba porzuconych pakietów	`reason`, `direction`	✅	✅
networkobservability_forward_bytes	Łączna liczba przekazanych bajtów	`direction`	✅	✅
networkobservability_forward_count	Łączna liczba przekazanych pakietów	`direction`	✅	✅
networkobservability_infiniband_counter_stats	Statystyki licznika InfiniBand	`statistic_name`, `device`, `port`	✅	❌
networkobservability_infiniband_status_params	Parametry stanu InfiniBand	`statistic_name`, `interface_name`	✅	❌
networkobservability_interface_stats	Statystyki interfejsu (pakiety RX/TX, utracone pakiety i inne)	`interface_name`, `statistic_name`	✅	❌
networkobservability_ip_connection_stats	Statystyki połączeń IP	`statistic_name`	✅	❌
networkobservability_node_apiserver_handshake_latency	Opóźnienie nawiązywania połączenia TCP z serwerem API		✅	❌
networkobservability_node_apiserver_latency	Opóźnienie między węzłem a serwerem API		✅	❌
networkobservability_node_apiserver_no_response	Liczba braku odpowiedzi z serwera API		✅	❌
networkobservability_node_connectivity_latency_seconds	Opóźnienie łączności między węzłami	`source_node_name`, `target_node_name`	✅	✅
networkobservability_node_connectivity_status	Stan łączności między węzłami (ICMP/HTTP)	`source_node_name`, `target_node_name`	✅	✅
networkobservability_tcp_connection_remote	Liczba aktywnych gniazd TCP według zdalnego adresu IP	`address`	✅	❌
networkobservability_tcp_connection_stats	Statystyki połączeń TCP (na przykład DelayedACKs, TCPKeepAlive, TCPSackFailures)	`statistic_name`	✅	✅
networkobservability_tcp_flag_gauges	Liczba pakietów TCP według flagi	`direction`, `flag`	❌	✅
networkobservability_tcp_retransmission_count	Liczba przetransmisji PROTOKOŁU TCP		✅	❌
networkobservability_tcp_state	Liczba aktywnych gniazd TCP według stanu	`state`	✅	❌
networkobservability_udp_connection_stats	Statystyki połączeń UDP	`statistic_name`	✅	❌
networkobservability_windows_hns_stats	Statystyki HNS systemu Windows (pakiety wysyłane i odbierane)	`direction`	❌	✅

Metryki na poziomie zasobnika (metryki Hub)

Metryki na poziomie podu obejmują informacje o podzie źródłowym i docelowym, dzięki czemu można wskazać problemy z siecią na poziomie poszczególnych obciążeń roboczych. Te metryki obejmują wolumin ruchu, porzucone pakiety, resetowanie protokołu TCP i przepływy warstwy 4/Warstwy 7.

Metryki DNS (liczby zapytań, kody odpowiedzi i błędy) są domyślnie zbierane na płaszczyznach danych innych niż Cilium. Na płaszczyznach danych Cilium metryki DNS wymagają zasad sieciowych Cilium FQDN. Możesz również rozwiązywać problemy z systemem DNS w czasie rzeczywistym przy użyciu interfejsu wiersza polecenia hubble'a.

W poniższej tabeli opisano metryki, które są agregowane dla każdego zasobnika (informacje o węźle są przechowywane).

Wszystkie metryki obejmują etykiety:

cluster
instance (nazwa węzła)
source lub destination
- W przypadku ruchu wychodzącego etykieta source wskazuje przestrzeń nazw i nazwę podu źródłowego.
- W przypadku ruchu przychodzącego etykieta destination wskazuje przestrzeń nazw i nazwę zasobnika docelowego.

Nazwa metryki	Description	Dodatkowe etykiety	Linux	Windows
hubble_dns_queries_total	Łączna liczba żądań DNS według zapytania	`source` lub `destination`, `query`( `qtypes` typ zapytania)	✅	❌
hubble_dns_responses_total	Łączna liczba odpowiedzi DNS według zapytania/odpowiedzi	`source` lub `destination`, `query`( `qtypes` typ zapytania), `rcode` (kod zwrotny), `ips_returned` (liczba adresów IP)	✅	❌
hubble_drop_total	Łączna liczba porzuconych pakietów	`source`lub `destination`, , `protocolreason`	✅	❌
hubble_tcp_flags_total	Łączna liczba pakietów TCP według flagi	`source` lub `destination`, `flag`	✅	❌
hubble_flows_processed_total	Łączna liczba przetworzonych przepływów sieciowych (ruch warstwy 4/warstwy 7)	`source` lub `destination`, `protocol`, `verdict`, `type` i `subtype`	✅	❌

Wybieranie metryk do zebrania w klastrach Cilium

W klastrach Cilium użyj filtrowania na poziomie źródła, aby wybrać, które obserwacje przyczyniają się do poszczególnych metryk Hubble przed dotarciem do zaplecza monitorowania. To filtrowanie różni się od filtrowania pulpitu nawigacyjnego narzędzia Grafana, które zmienia tylko to, co widzisz. Zawęź kolekcję do aplikacji, a następnie selektywnie włącz metryki zewnętrznego adresu IP lub portu docelowego, gdy badanie wymaga tych szczegółów.

Filtrowanie może zmniejszyć niepotrzebne zbieranie i pomóc w kontrolowaniu kosztów pozyskiwania danych. Dodatkowe metryki mogą zwiększyć liczbę szeregów czasowych i koszty, dlatego przed ich rozszerzeniem sprawdź ich wartość i wolumin. Wcześniej utworzone serie i próbki historyczne mogą pozostać widoczne; oszczędności zależą od ruchu i konfiguracji.

Po włączeniu funkcji Container Network Observability agenci uwidaczniają domyślne metryki sieciowe usługi. W klastrach Cilium użyj zasobu niestandardowego ContainerNetworkMetric , aby wybrać ruch dla poszczególnych typów metryk.

Udostępnianie metryki w klastrze nie powoduje automatycznego udostępnienia jej w usłudze zarządzanej Azure Monitor dla rozwiązania Prometheus. Domyślnie agenci klastra uwidaczniają hubble_flows_processed_total, ale zarządzana aplikacja Prometheus wyklucza go z kolekcji, ponieważ może wygenerować dużą liczbę szeregów czasowych. Managed Prometheus również domyślnie wyklucza hubble_flows_to_world_total i hubble_port_distribution_total, nawet po włączeniu ich w klastrze. Aby zebrać i wykonać zapytanie dotyczące dowolnej z tych metryk, dodaj jej nazwę do listy dozwolonych elementów Hubble w elemencie ConfigMap ama-metrics-settings-configmap. Aby uzyskać instrukcje, zobacz Allow the metric families in managed Prometheus (Zezwalanie rodzinom metryk w zarządzanym rozwiązaniu Prometheus).

Istnieje jeden współdzielony zasób na klaster o nazwie container-network-metric. Koordynuj aktualizacje z innymi administratorami i zachowaj ustawienia metryk używanych przez inne zespoły.

Zacznij od filtrów uwzględniania, aby wybrać ruch dla aplikacji lub miejsca docelowego. Filtry wykluczania są opcjonalne: użyj ich, aby pominąć podzbiór wybranego ruchu, lub użyj filtrów tylko wykluczających, aby zachować szerokie zbieranie danych o ruchu z określonymi wyjątkami. Wykluczenie ma pierwszeństwo przed pasującym uwzględnieniem.

Filtrowanie nie jest ograniczone do opcjonalnych metryk świata oraz portu docelowego. Użyj następujących nazw konfiguracji dla istniejących metryk:

Typ metryki	`spec.filters[].metric`	Przykładowe zadanie: filtrowanie
DNS	`dns`	Wybierz obserwacje DNS z lub do klienta aplikacji.
TCP	`tcp`	Wybierz obserwacje TCP dla zasobników z określoną etykietą.
HTTP	`httpV2`	Wybierz obserwacje HTTP obejmujące aplikację.
Flow	`flow`	Wybierz obserwacje przepływu według obciążenia lub tożsamości bezpieczeństwa.
Drop	`drop`	Wybierz obserwacje porzuceń dla aplikacji; opcjonalnie wyklucz obserwacje testów obciążeniowych z ogólnego zbierania.

Te filtry mają zastosowanie, gdy metryka znajduje się w podstawowej konfiguracji usługi. Konfiguracja filtru i generowanie obserwacji są oddzielne: obserwacje metryk DNS wymagają zastosowanych zasad inspekcji DNS i ruchu DNS. Obserwacje metryk HTTP wymagają włączenia L7 na poziomie klastra, zastosowania zasad inspekcji HTTP do obciążenia roboczego oraz ruchu HTTP przechodzącego przez tę zasadę. Stan filtru nie sprawdza tych wymagań wstępnych. Filtrowanie nie umożliwia inspekcji ani odszyfrowywania ruchu HTTPS. W przypadku protokołu HTTP użyj nazwy httpV2z uwzględnieniem wielkości liter, a nie http.

Przykłady można znaleźć w temacie DNS, TCP, HTTP i filtrowanie porzuceń.

Na przykład użyj filtrów include, aby wybrać metryki przepływu dla ruchu TCP z przestrzeni nazw production do punktów końcowych, które Cilium klasyfikuje jako świat. To zmienia kolekcję metryk przepływu bez zmieniania kolekcji dla innych typów metryk. Filtry obsługują nazwy przestrzeni nazw i zasobników, etykiety, adresy IP, tożsamości zabezpieczeń Cilium, protokoły i werdykty.

Filtrowanie określa, które obserwacje przyczyniają się do metryki. Nie dodaje ani nie usuwa etykiet metryk. W przeciwieństwie do dodatkowych pól agregacji dla dzienników wymiary metryk pozostają zarządzane przez usługę.

Filtrowanie wpływa na nowe obserwacje metryk w źródle. Wybranie obciążenia w narzędziu Grafana zmienia wyświetlane wyniki, a nie konfigurację kolekcji. Wcześniej zebrane dane pozostają w backendzie metryk.

Dodatkowe metryki

Aby zebrać dowolną z poniższych metryk, dodaj wpis do zasobu klastra ContainerNetworkMetric z filtrami uwzględniania, które wybierają ruch, który chcesz monitorować. Jeśli metryka nie jest jeszcze włączona, ten element włącza ją dla wybranego ruchu. Jeśli jest już włączony, element filtruje, który ruch się do niego przyczynia, bez zmieniania jego istniejących etykiet lub opcji.

Metric	Używanie	Co zlicza
`hubble_flows_to_world_total`	Zidentyfikuj docelowe adresy IP dla wybranego ruchu TCP do punktów końcowych, które Cilium klasyfikuje jako world. Skonfiguruj jako `flows-to-world`.	Obserwacje pakietów TCP SYN bez odpowiedzi zwrotnej. W przypadku konfiguracji syn-only usługi ruch UDP nie jest liczone.
`hubble_port_distribution_total`	Sprawdź wybrany ruch według protokołu i portu docelowego. Skonfiguruj jako `port-distribution`.	Obserwacje przekazane lub przekierowane zidentyfikowane jako ruch bez odpowiedzi. Odrzucony ruch i ruch o nieznanym stanie odpowiedzi nie są liczone.

W przypadku metryk nowo włączonych za pomocą tego zasobu usługa konfiguruje etykiety źródłowego zasobnika i docelowego adresu IP dla elementu flows-to-world. Dla port-distribution konfiguruje etykiety zasobnika źródłowego i docelowego oraz kierunek ruchu. Etykiety protokołu i decyzji są uwzględniane dla flows-to-world; etykiety protokołu i portu docelowego są uwzględniane dla elementu port-distribution. Dzięki tym opcjom dostarczanym przez usługę metryka światowa nie liczy ruchu UDP ani spadków niezwiązanych z zasadami.

Te metryki zliczają obserwowane zdarzenia sieciowe, a nie unikatowe połączenia ani żądania aplikacji. Jeśli na przykład klient wysyła pakiet TCP SYN, a następnie przesyła go ponownie podczas próby nawiązania połączenia, hubble_flows_to_world_total może liczyć obie obserwacje, mimo że należą do tej samej próby połączenia. Etykiety, takie jak nazwy podów, są wypełniane tylko wtedy, gdy te informacje są dostępne dla obserwowanego ruchu.

Aby uzyskać pełny zasób niestandardowy i zrzuty ekranu obu metryk zebranych z obciążenia testowego, zobacz Przykładowa konfiguracja i przechwycone wyniki.

Zarządzaj istotnością i szumem danych

Użyj filtrowania, aby skupić się w metrykach na obciążeniach i ruchu istotnych dla monitorowania lub badania. Wykluczenie niepowiązanego ruchu zmniejsza szum danych i pomaga skupić się na sygnałach sieciowych, które mają znaczenie.

Docelowe adresy IP, nazwy zasobników i porty mogą generować wiele szeregów czasowych. Ten szczegół może być przydatny, ale zbieranie go dla niepowiązanego ruchu wprowadza szum i może zwiększyć koszty przetwarzania danych. Zacznij od określonego obciążenia lub przestrzeni nazw, sprawdź, czy metryki odpowiadają na pytania, i sprawdź wynikowy wolumin danych przed rozszerzeniem zbierania danych.

Zasób niestandardowy zgłasza ostrzeżenie dla każdej włączonej dodatkowej metryki. Ostrzeżenie identyfikuje potencjalny wzrost kosztów; nie szacuje rachunku ani nie wskazuje, że przekroczono limit. Usługa zarządza etykietami metryk i nie można ich zmienić za pomocą tego zasobu.

Usunięcie wpisu powoduje wyłączenie metryki tylko wtedy, gdy to ten wpis ją włączał. Jeśli usługa dostarcza metrykę, pozostaje włączona bez filtrów tego wpisu. Usunięcie zasobu udostępnionego powoduje usunięcie wszystkich jego filtrów i przywrócenie zbierania danych zapewnianego przez usługę, co może poszerzyć ruch uwzględniony w tych metrykach i zwiększyć szum danych i wolumen pozyskiwanych danych.

Aby zapoznać się z przykładami YAML, zapytaniami weryfikacji i krokami oczyszczania, zobacz Konfigurowanie filtrowania metryk sieci kontenera.

Limitations

Platforma i płaszczyzna danych:

Metryki na poziomie zasobnika są dostępne tylko w systemie Linux.
Płaszczyzna danych Cilium jest obsługiwana począwszy od wersji Kubernetes 1.29.
Filtrowanie metryk na poziomie źródłowym jest dostępne tylko w klastrach Cilium.
Wpisy filtru mogą włączyć flows-to-world i port-distribution, gdy usługa jeszcze ich nie dostarcza. Usługa zarządza ich etykietami; ten zasób nie uwidacznia niestandardowych wymiarów metryk.
Etykiety metryk mają subtelne różnice między klastrami Cilium i nie-Cilium.

Metryki DNS:

W klastrach Cilium metryki DNS wymagają zasad sieciowych Cilium FQDN lub można użyć interfejsu wiersza poleceń Hubble do rozwiązywania problemów z DNS w czasie rzeczywistym.

Znane problemy:

Jeśli agent węzła Hubble ulegnie awarii, przekaźnik Hubble może się zawiesić, co może przerwać sesje Hubble CLI.

Obsługa standardu FIPS (tylko płaszczyzny danych innych niż Cilium):

FiPS nie jest dostępny w węzłach Ubuntu 20.04 z powodu ograniczeń jądra. Zamiast tego użyj puli węzłów Azure Linux lub Ubuntu 22.04. To ograniczenie nie dotyczy płaszczyzn danych Cilium.

System operacyjny	Obsługa standardu FIPS
Azure Linux 3.0	Yes
Azure Linux 2.0	Yes
Ubuntu 20.04	No
Ubuntu 22.04	Yes

Skala:

Usługa zarządzana Prometheus w Azure Monitor i Azure Managed Grafana nakłada specyficzne dla usługi ograniczenia skali. Aby uzyskać więcej informacji, zobacz artykuł Scrape Prometheus metrics at scale in Azure Monitor.

Pricing