Co to są dzienniki sieci kontenerów?

Logi sieci kontenerów w ramach usługi Advanced Container Networking Services dla Azure Kubernetes Service (AKS) dają wgląd w każdy przepływ sieci w obrębie klastra. Metryki informują o tym , co dzieje się w sieci (użycie przepustowości, współczynniki błędów). Dzienniki informują, dlaczego: kto zainicjował połączenie, jakie protokoły były używane i czy ruch był dozwolony, czy blokowany.

Te dzienniki przechwytują metadane dla każdego przepływu sieci:

  • Źródłowe i docelowe adresy IP, nazwy zasobników i nazwy usług
  • Przestrzenie nazw, porty i protokoły
  • Zarządzanie ruchem i decyzje polityczne

W tym kontekście można skorelować zachowanie sieci z określonymi obciążeniami, rozwiązywać problemy z łącznością, weryfikować zasady zabezpieczeń i przeprowadzać analizę kryminalistyczną. Dzienniki sieci kontenerów obejmują ruch warstwy 3 (IP), warstwy 4 (TCP/UDP) i warstwy 7 (HTTP/gRPC/Kafka).

Aby zarządzać ilością danych i kosztami, dzienniki sieci kontenerów obsługują agregację dzienników przepływu, która grupuje podobne przepływy w podsumowane rekordy zamiast przechowywać jeden rekord na zdarzenie połączenia. Zachowujesz potrzebne wzorce operacyjne, jednocześnie obniżając koszty magazynowania i przetwarzania. Aby uzyskać więcej informacji, zobacz Agregacja dzienników przepływu.

Dzienniki sieci kontenerów oferują dwa tryby:

  • Przechowywane dzienniki — kolekcja ciągła z niestandardowymi filtrami i agregacją przepływu. Najlepsze w przypadku długoterminowego monitorowania i analizy.
  • Dzienniki na żądanie — przechwytywanie w czasie rzeczywistym za pośrednictwem Hubble CLI i Hubble UI. Najlepsze rozwiązanie w przypadku rozwiązywania problemów ad hoc.

Użyj przechowywanych logów, gdy potrzebujesz trwałych rekordów na potrzeby zgodności, analizy trendu lub automatycznego alertowania. Użyj dzienników na żądanie, gdy aktywnie debugujesz problem z łącznością lub wydajnością i potrzebujesz natychmiastowego wglądu w ruch na żywo.

Przechowywane dzienniki

Tryb przechowywanych dzienników jest włączany automatycznie za każdym razem, gdy usługa Advanced Container Networking Services jest włączona w klastrze. Ta funkcja jest dostępna, ale nie są generowane żadne dzienniki, dopóki nie poinformujesz usługi ACNS o tym, co należy przechwycić.

Aby rozpocząć zbieranie logów, zdefiniuj ContainerNetworkLog zasoby niestandardowe, które określają ruch do monitorowania: według przestrzeni nazw, podu, usługi, protokołu lub werdyktu. Po zastosowaniu CRD agent Cilium zaczyna generować przepływy odpowiadające filtrom agenta i zapisywać je w każdym węźle. Kolekcja pozostaje aktywna do momentu usunięcia identyfikatorów CRD lub wyłączenia usługi ACNS.

Ponieważ kontrolujesz dokładnie, który ruch jest rejestrowany za pośrednictwem filtrów CRD, możesz skoncentrować się na przepływach, które mają znaczenie i uniknąć zbierania niepotrzebnych danych. W połączeniu z agregacją dzienników przepływu takie podejście zapewnia przewidywalne i ukierunkowane na analizę kosztów magazynu.

Jak działa tryb przechowywanych dzienników

Usługa Advanced Container Networking Services używa technologii eBPF z Cilium do przechwytywania przepływów sieciowych na każdym węźle. Po włączeniu usługi ACNS i zastosowaniu zasobu niestandardowego ContainerNetworkLog agent Cilium zbiera ruch zgodny z filtrem i zapisuje dzienniki w formacie JSON na /var/log/acns/hubble/events.log każdym hoście. Generowanie dzienników jest uruchamiane w całości wewnątrz klastra i nie zależy od Azure Monitor.

W przypadku użycia w środowisku produkcyjnym zalecamy włączenie dodatku Azure Monitor. Po włączeniu agenci Container Insights zbierają dzienniki lokalne hosta, stosują limity ograniczania przepustowości i wysyłają je do obszaru roboczego Log Analytics, w którym uzyskujesz długoterminowe przechowywanie, zapytania w KQL oraz wbudowany portal Azure i pulpity nawigacyjne narzędzia Grafana. Jest to najbardziej zintegrowana ścieżka i tę ścieżkę powinno wybrać większość klientów.

Jeśli twój zespół ma istniejący potok obserwacji, możesz zamiast tego przekazywać te same dzienniki lokalne hosta do dowolnego modułu zbierającego lub usługi rejestrowania zgodnego z protokołem OpenTelemetry — obok Azure Monitor lub zamiast niego.

Diagram przedstawiający sposób działania dzienników sieci kontenerów.

Aby uzyskać więcej informacji na temat ograniczania przepustowości i usługi Container Insights, zobacz dokumentację usługi Container Insights.

Używanie dzienników sieci kontenerów z lub bez Azure Monitor

Dzienniki sieciowe kontenerów można używać na dwa sposoby. Właściwy wybór zależy od tego, czy chcesz korzystać z Azure w natywnym środowisku, czy masz już pipeline obserwacji, którego chcesz używać.

Path Co otrzymujesz Kiedy należy go wybrać
Azure Monitor dodatek (zalecane) Usługa Container Insights zbiera dzienniki lokalne hosta w obszarze roboczym Log Analytics. Długoterminowe przechowywanie, KQL, wbudowane konsolki portalu Azure oraz zarządzane pulpity Grafana są dostępne od razu. Potrzebujesz najbardziej zintegrowanej, gotowej do produkcji funkcjonalności w AKS przy minimalnym nakładzie konfiguracji.
Hostowanie plików lokalnych za pomocą własnego potoku Usługa ACNS zapisuje dzienniki JSON w /var/log/acns/hubble/events.log każdym węźle. Przekazujesz je dalej do dowolnego zbieracza zgodnego z OpenTelemetry lub usługi rejestrowania — obok Monitoru Azure lub zamiast niego. Masz już scentralizowaną platformę do obserwacji i chcesz, aby dzienniki sieciowe mogły się tam znajdować.

W przypadku większości klientów zalecamy włączenie Azure Monitor. Jest to najszybszy sposób uzyskania funkcji retencji, zapytań i paneli kontrolnych bez budowania własnego potoku.

Kluczowe możliwości trybu przechowywanych dzienników

  • Filtry dostosowywalne. Zdefiniuj ContainerNetworkLog zasoby niestandardowe do filtrowania według przestrzeni nazw, podu, usługi, portu, protokołu, werdyktu lub kierunku ruchu. Rejestrowany jest tylko pasujący ruch, dzięki czemu uzyskasz dokładną kontrolę nad zebranymi danymi i kosztami.

  • Agregacja logów przepływu. Podobne przepływy są automatycznie grupowane w podsumowane rekordy co 30 sekund, obniżając ilość danych przy jednoczesnym zachowaniu sygnałów operacyjnych, takich jak wzorce komunikacji usług, współczynniki błędów i werdykty zabezpieczeń. W połączeniu z filtrami docelowymi agregacja pozwala utrzymać szeroką widoczność bez nadmiernych kosztów pozyskiwania danych. Aby uzyskać więcej informacji, zobacz Agregacja dzienników przepływu.

  • Opcje magazynowania logów. ACNS zawsze zapisuje dzienniki lokalnie na każdym węźle. W tym miejscu możesz wybrać sposób ich korzystania:

    • Pliki lokalne hosta (zawsze włączone): Dzienniki są przechowywane w węzłach hosta pod adresem /var/log/acns/hubble. Pliki automatycznie obracają się po osiągnięciu 50 MB, a starsze dzienniki są nadpisywane. Użyj tego bezpośrednio w celu monitorowania krótkoterminowego, monitorowania w czasie rzeczywistym lub przekazywania plików do dowolnego modułu zbierającego lub usługi rejestrowania zgodnego z biblioteką OpenTelemetry w celu dodatkowego zarządzania dziennikami.

    • Azure Monitor (zalecane): Włącz dodatek Azure Monitor w celu zbierania i przechowywania dzienników w obszarze roboczym Log Analytics. Uzyskujesz bezpieczny, zgodny magazyn z długoterminowym przechowywaniem, zapytaniami KQL, wykrywaniem anomalii, analizą historyczną i alertami za pośrednictwem usługi zarządzanej dla rozwiązania Prometheus. Generowanie dziennika nadal działa przez agenta Cilium i ContainerNetworkLog CRD; Azure Monitor dodaje warstwę zużycia na górze.

      Tabela ContainerNetworkLogs domyślnie używa warstwy Analiza . Możesz przełączyć się do warstwy Podstawowa , aby uzyskać niższe koszty pozyskiwania i przechowywania przy zachowaniu podobnego środowiska obserwacji. Każda warstwa ma dedykowany pulpit nawigacyjny portalu Azure zoptymalizowany pod kątem możliwości zapytań. Aby uzyskać więcej informacji na temat planów tabel, zobacz plany tabel Log Analytics. Aby dowiedzieć się, jak ustawić plan tabeli, zobacz Ustawianie planu tabeli.

  • Wizualizacja w portalu Azure. Wykonywanie zapytań i analizowanie dzienników bezpośrednio w Log Analytics lub korzystanie z wbudowanych pulpitów nawigacyjnych portalu Azure. Dedykowany pulpit nawigacyjny jest dostępny dla każdej warstwy tabeli, więc uzyskasz takie samo środowisko obserwacji, niezależnie od wybranej warstwy. Aby uzyskać szczegółowe informacje, zobacz Wizualizuj dzienniki w portalu Azure.

Wizualizuj logi w portalu Azure

Dzienniki przepływu można wizualizować, wykonywać zapytania i analizować w portalu Azure w obszarze roboczym Log Analytics dla klastra.

 Zrzut ekranu przedstawiający dzienniki sieciowe kontenera w obszarze roboczym Log Analytics.

Dzienniki sieci kontenerów obejmują wbudowane pulpity nawigacyjne portalu Azure służące do wizualizowania danych przepływu. Oddzielny pulpit nawigacyjny jest dostępny dla każdej warstwy tabeli Log Analytics:

Dashboard Path Poziom tabeli
Dzienniki przepływu — warstwa podstawowa (identyfikator: 23155) Azure>Insights>Containers>Networking>Flow Logs — warstwa podstawowa Basic
Dzienniki przepływu — warstwa analizy (identyfikator: 23156) Azure>Insights>Containers>Networking>Flow Logs — Warstwa analizy Analiza (wartość domyślna)

Oba pulpity pokazują, które obciążenia AKS komunikują się ze sobą, w tym żądania sieciowe, odpowiedzi, odrzucenia i błędy. Użyj pulpitu nawigacyjnego zgodnego z poziomem tabeli skonfigurowanym dla tabeli ContainerNetworkLogs.

Wskazówka

Tabela ContainerNetworkLogs jest domyślnie przypisana do warstwy analitycznej. Jeśli chcesz zmniejszyć koszty, możesz przełączyć się do wersji podstawowej i użyć odpowiedniego pulpitu nawigacyjnego wersji podstawowej bez utraty możliwości monitorowania. Aby uzyskać więcej informacji, zobacz plany tabel Log Analytics.

Pulpity nawigacyjne portalu Azure mają następujące główne składniki:

  • Omówienie kondycji sieci. W górnej sekcji przedstawiono metryki podsumowania (łączna liczba dzienników przepływów, unikatowe żądania, porzucone żądania i przekazane żądania), dzięki czemu można szybko wykrywać anomalie. Statystyki są podzielone według protokołu: odrzucone żądania DNS, odpowiedzi HTTP z kodami 2xx, współczynniki żądań i odpowiedzi warstwy 4 oraz liczby odrzuceń. Wykres zależności usługi pokazuje, które usługi komunikują się ze sobą, co ułatwia identyfikowanie wąskich gardeł i nieoczekiwanych ścieżek ruchu.

    Zrzut ekranu przedstawiający statystyki dzienników przepływu i wykres zależności usługi.

  • Dzienniki przepływów i dzienniki błędów. Konsola oddziela logi przepływu od logów błędów na osobne widoki, co pozwala na skupienie się na błędach bez przeszukiwania normalnego ruchu. Użyj wbudowanych filtrów, aby zawęzić wyniki według protokołu, przestrzeni nazw lub werdyktu. Aby na przykład rozwiązać problemy z błędami rozpoznawania nazw DNS, przefiltruj dzienniki błędów według protokołu DNS.

    Zrzut ekranu przedstawiający dzienniki przepływu i dzienniki błędów.

    Każdy wpis dziennika zawiera etykiety, znaczniki czasu i szczegóły źródła/miejsca docelowego, aby ułatwić wskazanie określonych zdarzeń podczas badania.

    Zrzut ekranu dostępnych filtrów w pulpitach nawigacyjnych Azure Portal.

  • Najważniejsze przestrzenie nazw, obciążenia i błędy DNS. W tej sekcji przedstawiono najbardziej aktywne przestrzenie nazw, obciążenia o najwyższym natężeniu ruchu, użycie portów i najczęstsze błędy DNS. Służy do identyfikowania obciążeń generujących najwięcej ruchu, wykrywania porzuconych żądań i porównywania dystrybucji protokołów (na przykład TCP i UDP). Nietypowe wzorce, takie jak nieoczekiwane skoki lub nieznane miejsca docelowe, mogą wskazywać na błędy konfiguracji lub problemy z zabezpieczeniami.

    Zrzut ekranu przedstawiający najważniejsze przestrzenie nazw i metryki podów.

Agregacja dziennika przepływu

Przepływy sieciowe szybko się sumują. Klaster z 200 mikrousługami może generować setki tysięcy rekordów przepływu co 30 sekund. Przechowywanie wszystkich danych pierwotnych jest kosztowne.

Na przykład powiedzmy, że client-1 i client-2 komunikują się z pod server przez TCP. W 30-sekundowym oknie nieprzetworzone rekordy przepływu w węźle wyglądają następująco:

Źródło Port źródłowy Destination Port docelowy Protokół Flaga
client-1 12345 serwer 80 TCP SYN
serwer 80 client-1 12345 TCP SYN-ACK
client-1 12345 serwer 80 TCP potwierdzenie
client-1 12345 serwer 80 TCP PSH
serwer 80 client-1 12345 TCP potwierdzenie
client-2 23456 serwer 80 TCP SYN
serwer 80 client-2 23456 TCP SYN-ACK
client-2 23456 serwer 80 TCP potwierdzenie
client-2 23456 serwer 80 TCP PSH
serwer 80 client-2 23456 TCP potwierdzenie

W przypadku agregacji te 10 rekordów stają się dwa:

Źródło Port źródłowy Destination Port docelowy Protokół Wysłane przepływy Odebrane przepływy
client-1 12345 serwer 80 TCP 4 6
client-2 23456 serwer 80 TCP 4 6

Agregacja dzienników przepływu rozwiązuje ten problem, grupując podobne przepływy w podsumowane rekordy. W każdym 30-sekundowym oknie przepływy współużytkujące te same pola klucza agregacji są łączone w jeden rekord z liczbą przepływów, które reprezentuje.

Następujące pola składają się na klucz agregacji:

Pole Description
verdict PRZESŁANA DALEJ, PORZUCONA LUB BŁĄD
is_reply Czy przepływ jest żądaniem (fałsz), czy odpowiedzią (prawda)
drop_reason_desc Przyczyna odrzucenia pakietów
source.namespace Przestrzeń nazw zasobnika źródłowego
destination.namespace Namespace docelowego zasobnika
source.workloads Obciążenie źródłowe (Wdrożenie, StatefulSet lub DaemonSet)
destination.workloads Obciążenie docelowe (Deployment, StatefulSet lub DaemonSet)
source.identity Tożsamość źródłowych zabezpieczeń (zawsze obecna jako zapasowa)
destination.identity Tożsamość zabezpieczeń miejsca docelowego (zawsze obecna jako rezerwowa)
l4.TCP.destination_port Port docelowy TCP
l4.UDP.destination_port Port docelowy UDP
l7.http.code Kod odpowiedzi HTTP (200, 404, 500 itp.)
l7.dns.rcode Kod odpowiedzi DNS (NOERROR, NXDOMAIN itp.)
IP.ipVersion Protokół IPv4 lub IPv6
IP.encrypted Czy przepływ jest zaszyfrowany (WireGuard/IPsec)
source.cluster_name Nazwa klastra źródłowego
destination.cluster_name Nazwa klastra docelowego

Przepływy dopasowane na podstawie wszystkich tych pól w 30-sekundowym oknie są scalane w jeden rekord. Pozwala to zachować potrzebne sygnały (które usługi komunikują się, jak często występują błędy, czy ruch był dozwolony, czy blokowany) podczas znacznego cięcia ilości danych. W przeciwieństwie do próbkowania, które losowo odrzuca przepływy danych i może przegapić rzadkie incydenty bezpieczeństwa, agregacja zachowuje 100% informacji o wzorcu.

Najważniejsze kwestie:

  • Agregacja jest domyślnie włączona i skonfigurowana. Zmniejsza to koszty przechowywania i pozyskiwania logów bez potrzeby ręcznej konfiguracji.
  • Kontrolujesz, który trafik jest przechwytywany przez includeFilters w ContainerNetworkLog CRD.
  • Węższe filtry (określone pary nazw lub usługi) zwykle zapewniają lepszą kompresję, ponieważ przechwycone przepływy są bardziej podobne.
  • Zagregowane dzienniki pomijają atrybuty o wysokiej kardynalności i przepływu (na przykład poszczególne znaczniki czasowe, adresy IP zasobników, adresy URL HTTP, nazwy zapytań DNS) w celu zminimalizowania kosztów przetwarzania i magazynowania. Są one przeznaczone do wykrywania problemów wysokiego poziomu. Używaj dzienników na żądanie do szczegółowej analizy przepływów i badania.

Uwaga / Notatka

Rzeczywista redukcja magazynu różni się w zależności od konfiguracji filtru, różnorodności obciążeń i wzorców ruchu.

Dzienniki na żądanie

Dzienniki na żądanie umożliwiają przechwytywanie i inspekcję dzienników przepływów w czasie rzeczywistym bez wcześniejszej konfiguracji lub magazynu trwałego. Używaj dzienników na żądanie, gdy aktywnie rozwiązujesz problem z łącznością lub wydajnością i potrzebujesz natychmiastowej widoczności.

Usługa ACNS udostępnia dwa narzędzia do przechwytywania na żądanie. Aby skonfigurować jedną z tych narzędzi, zobacz Konfigurowanie trybu dzienników na żądanie.

Interfejs wiersza polecenia Hubble CLI

Interfejs wiersza polecenia hubble umożliwia wykonywanie zapytań, filtrowanie i analizowanie dzienników przepływu bezpośrednio z terminalu. Jest to szczególnie przydatne, gdy potrzebujesz precyzyjnych filtrów, na przykład do izolowania ruchu według przestrzeni nazw, etykiety podu lub wyniku podczas aktywnej sesji debugowania.

Zrzut ekranu Hubble CLI.

Interfejs użytkownika platformy Hubble

Interfejs użytkownika hubble'a zapewnia graficzny widok komunikacji między usługami. Jest to dobre rozwiązanie, gdy chcesz wizualnie śledzić ścieżki ruchu, identyfikować usługi komunikujące się i wykrywać anomalie bez konieczności pisania poleceń interfejsu wiersza polecenia.

Zrzut ekranu przedstawiający interfejs użytkownika hubble'a.

Najważniejsze korzyści wynikające z dzienników na żądanie

  • Nie jest wymagana wcześniejsza konfiguracja. Natychmiastowe przechwytywanie przepływów bez definiowania zasobów niestandardowych lub konfigurowania magazynu.
  • Widoczność w czasie rzeczywistym. Sprawdź aktualny ruch sieciowy i wyświetl metadane pakietów w momencie pojawiania się problemów.
  • Szybkie rozwiązywanie problemów. Filtruj przepływy interaktywnie za pomocą interfejsu wiersza poleceń Hubble lub przeglądaj mapy usług wizualnie w interfejsie użytkownika Hubble.
  • Niskie obciążenie. Nie jest wymagany magazyn trwały, więc nie ma żadnych bieżących kosztów dla badań ad hoc.

Zalecenia dotyczące przechowywanych dzienników

  1. Zacznij od szerokich filtrów, a następnie zawęź. Kiedy po raz pierwszy włączysz dzienniki przepływu, użyj szerokich filtrów, aby przechwycić ruch w kluczowych przestrzeniach nazw. Uruchom konfigurację przez kilka dni i przejrzyj zebrane dane w Log Analytics. Przyjrzyj się ilości danych, kosztowi i zastanów się, czy przechwycone przepływy odpowiadają Twoim rzeczywistym potrzebom. Następnie zaciśnij, includeFilters aby skupić się na ruchu o wysokiej wartości i wyciąć hałas.

  2. Najpierw użyj wstępnie utworzonych pulpitów nawigacyjnych. Wbudowane pulpity nawigacyjne portalu Azure obejmują typowe przypadki użycia, takie jak wzorce komunikacji usług, współczynniki błędów i błędy DNS. Zacznij tam. Dodaj niestandardowe panele lub zapytania Log Analytics tylko wtedy, gdy potrzebujesz widoczności, której nie zapewniają wcześniej zbudowane pulpity nawigacyjne.

  3. Okresowo przeglądaj. W miarę zmiany obciążeń i wzorców ruchu filtry mogą wymagać aktualizacji. Okresowo sprawdzaj ilość danych i pokrycie przepływów, aby upewnić się, że nadal przechwytujesz odpowiedni ruch przy rozsądnym koszcie.

Ograniczenia

Wymagania dotyczące płaszczyzny danych i funkcji:

  • Tryb zapisanych logów działa tylko z warstwą danych Cilium.
  • Dzienniki przepływu warstwy 7 są przechwytywane tylko wtedy, gdy jest włączona obsługa zasad warstwy 7. Aby uzyskać więcej informacji, zobacz Konfigurowanie zasad warstwy 7.
  • Przepływy i metryki DNS są przechwytywane tylko wtedy, gdy zastosowane są zasady sieciowe Cilium dla w pełni kwalifikowanej nazwy domeny (FQDN). Aby uzyskać więcej informacji, zobacz Konfigurowanie zasad nazwy FQDN.

Kompromisy agregacji:

  • Agregacja dzienników przepływów nie zachowuje znaczników czasowych poszczególnych przepływów, adresów IP poszczególnych podzasobników ani pól o wysokiej kardynalności, takich jak URL-e HTTP i nazwy zapytań DNS. Użyj dzienników na żądanie na potrzeby badania poszczególnych przepływów.

Pamięć i platforma:

  • Plik lokalny względem hosta w /var/log/acns/hubble/ jest ograniczony do 50 MB na węzeł i automatycznie się rotuje. Jeśli potrzebujesz długoterminowego przechowywania, włącz Azure Monitor (zalecane) lub prześlij plik do własnej usługi rejestrowania.
  • Plan tabeli dzienników pomocniczych nie jest obsługiwany.

Ceny

Ważne

Zaawansowane usługi sieciowe kontenerów to oferta płatna.

Aby uzyskać więcej informacji na temat cen, zobacz Advanced Container Networking Services — cennik.