Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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.
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
ContainerNetworkLogzasoby 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
ContainerNetworkLogCRD; Azure Monitor dodaje warstwę zużycia na górze.Tabela
ContainerNetworkLogsdomyś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.
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.
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.
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.
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.
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
includeFilterswContainerNetworkLogCRD. - 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.
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.
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
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,
includeFiltersaby skupić się na ruchu o wysokiej wartości i wyciąć hałas.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.
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.
Treści powiązane
- Konfigurowanie dzienników sieci kontenerów
- Zaawansowane usługi sieciowe dla kontenerów w AKS
- Obserwowanie sieci kontenerów w usługach Advanced Container Networking Services
- Zabezpieczenia sieci kontenerów w usłudze Advanced Container Networking Services