Co to są dzienniki sieci kontenerów?

Dzienniki sieci kontenerów w usłudze Advanced Container Networking Services dla Azure Kubernetes Service (AKS) ułatwiają badanie, które obciążenia komunikowały się, do których lokalizacji docelowych dotarły i czy ruch został przesłany dalej, czy porzucony. Użyj metryk, aby wykryć problem z siecią, a następnie użyj dzienników, aby zbadać powiązany ruch. Sam wynik przepływu nie określa, czy żądanie aplikacji zakończyło się pomyślnie.

W zależności od typu przepływu, konfiguracji widoczności i zachowanych pól agregacji dzienniki mogą obejmować:

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

W przypadku przechowywanych dzienników agregacja dzienników przepływu z możliwością dostosowywania pomaga równoważyć widoczność operacyjną z ilością danych i kosztami. Agregacja podsumowuje podobne obserwacje, zachowując wzorce komunikacji obciążenia i liczbę przesłanych dalej lub porzuconych obserwacji. Dodaj pola grupowania oprócz domyślnych pól usługi, aby dostosować te podsumowania do Twoich potrzeb. Zmniejszenie woluminu zależy od tego, ile ruchu współdzieli te same wartości grupowania. Aby uzyskać więcej informacji, zobacz Agregacja dzienników przepływu.

Wybierz tryb zbierania

Rozpocznij od skonfigurowania dzienników sieci kontenera. Przewodnik oddziela kolekcję, opcjonalne przekazywanie do Azure Monitor i weryfikację.

Przechowywane dzienniki

W obsługiwanym klastrze Cilium z włączoną usługą ACNS zdefiniuj ruch do zebrania, zanim będzie można oczekiwać zapisanych dzienników. Włączenie samej usługi nie wybiera ruchu ani nie konfiguruje długoterminowego przechowywania.

Aby rozpocząć zbieranie dzienników, zdefiniuj ContainerNetworkLog zasoby niestandardowe, które wybierają ruch według przestrzeni nazw, poda, etykiet, adresu IP, numerycznej tożsamości zabezpieczeń Cilium, protokołu lub werdyktu. Gdy konfiguracja dotrze do agentów, węzły obserwujące pasujący ruch zapisują wybrane dzienniki. Wiele zasobów może jednocześnie obsługiwać ruch.

Użyj filtrów, aby skupić się na przepływach, które są ważne. Użyj agregacji dzienników przepływu, aby podsumować te przepływy i dostosować pola grupowania, aby zachować różnice, których wymagają Twoje analizy. Razem te kontrolki umożliwiają dostosowanie zbieranych danych i sposobu ich podsumowania. Przejrzyj wynikowy wolumen danych: węższe filtry mogą ograniczyć ilość zbieranych danych, podczas gdy więcej pól grupowania może zwiększyć liczbę rekordów.

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

Użyj Azure Monitor do zintegrowanych zapytań i pulpitów nawigacyjnych lub zachowaj istniejący potok logów.

Bez potoku przekazywania logów dzienniki pozostają w rotujących plikach lokalnych na węzłach i nie są przechowywane na potrzeby długoterminowych badań.

Kluczowe możliwości trybu przechowywanych dzienników

Dostosuj obserwowalność do swoich potrzeb: wybierz ruch, który ma być zbierany, oraz które szczegóły rozróżniać podczas grupowania go w przechowywane dzienniki.

• Filtry dostosowywalne. Zdefiniuj zasoby niestandardowe ContainerNetworkLog, aby wybrać ruch według źródłowej lub docelowej przestrzeni nazw, zasobnika, etykiety, adresu IP lub zakresu CIDR, tożsamości zabezpieczeń Cilium, protokołu lub werdyktu. Ruch zgodny z filtrami skonfigurowanych zasobów może być zbierany, co zapewnia kontrolę nad tym, co jest zbierane, i ułatwia zarządzanie ilością pozyskiwania.

• Konfigurowalna agregacja logów przepływu. Użyj agregacji, aby zmniejszyć objętość przechowywanych dzienników przy zachowaniu szczegółów potrzebnych do dochodzeń sieciowych. Domyślnie agregacja łączy obserwacje przepływu z pasującymi wartościami pól grupowania w podsumowane rekordy co 30 sekund. Dodaj pola grupowania, aby zachować szczegóły wykraczające poza domyślne ustawienia usługi. Więcej pól grupowania może wygenerować więcej rekordów, dlatego należy połączyć agregację z ukierunkowanymi filtrami, aby zrównoważyć potrzeby badania z kosztami ingestii danych i magazynowania. Dowiedz się więcej o agregacji 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. Wysyłaj zapytania i analizuj dzienniki w usłudze Log Analytics lub użyj pulpitu nawigacyjnego dla planu tej tabeli. Przed jego wybraniem zapoznaj się z możliwościami planu w zakresie wykonywania zapytań i przechowywania. Aby uzyskać szczegółowe informacje, zobacz Wizualizuj dzienniki w portalu Azure.

Wizualizuj logi w portalu Azure

Aby przeprowadzić szczegółową analizę, otwórz pozycję Monitorowanie> na stronie klastra usługi AKS w portalu Azure. W obszarze roboczym odbierającego Log Analytics wykonaj zapytanie względem tabeli ContainerNetworkLogs.

Na stronie klastra usługi AKS w portalu Azure wybierz pozycję Monitorowanie>Pulpity nawigacyjne z usługą Grafana, aby wyświetlić wbudowane pulpity nawigacyjne dziennika przepływu. Nie potrzebujesz wystąpienia Azure Managed Grafana i nie są naliczane dodatkowe opłaty za pulpity. Nadal obowiązują opłaty za usługę ACNS oraz za pozyskiwanie i przechowywanie dzienników.

Wybierz panel zgodny ContainerNetworkLogs z planem stołu:

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.

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

• Omówienie kondycji sieci. Przejrzyj podsumowania ruchu i przekazane lub porzucone spostrzeżenia, a następnie użyj grafu zależności usługi, aby zidentyfikować ścieżki komunikacyjne, które warto zbadać. Szczegóły specyficzne dla protokołu zależą od widoczności i zachowanych pól. Zagregowane liczby obserwacji nie są unikatowymi liczbami żądań.

  

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

  

  Szczegóły dostępne na pulpicie nawigacyjnym zależą od zebranego ruchu i konfiguracji agregacji. Aby dostosować szczegóły przechowywanych dzienników, zobacz Dostosowywanie agregacji dziennika przepływu.

  Użyj dostępnych znaczników czasu i szczegółów źródła/miejsca docelowego, aby skorelować rekordy z dochodzeniem. Zagregowany rekord nie zapewnia oddzielnego znacznika czasu dla każdej obserwacji w swojej grupie.

  

• 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

Intensywnie obciążone obciążenia robocze mogą generować wiele powtarzających się obserwacji przepływu między tymi samymi punktami końcowymi. Przechowywanie każdej obserwacji oddzielnie zwiększa ilość danych, które należy pozyskiwać, przechowywać i wyszukiwać, nawet jeśli twoje bezpośrednie pytanie brzmi po prostu, które obciążenia robocze komunikują się i czy ich ruch został przesłany dalej, czy odrzucony.

Agregacja zapewnia punkt wyjścia o mniejszym wolumenie danych dla badań historycznych sieci. Każdy węzeł łączy wybrane obserwacje przepływu, które współdzielą te same wartości pól grupowania w interwale agregacji. Zamiast oddzielnie pisać każdą obserwację, zapisuje podsumowany rekord dla każdej grupy, w tym liczby obserwacji przychodzących i wychodzących oraz obserwacji o nieznanym kierunku.

Przykład: Przed i po agregacji

Rozważmy dwa pody klienta, client-1 i client-2, które komunikują się z podem server za pośrednictwem portu TCP 80 w jednym 30-sekundowym oknie. Każdy zasobnik należy do oddzielnego workloadu o tej samej nazwie. Poniższe obserwacje ilustrują nawiązywanie połączenia, transfer danych i odpowiedzi.

Przed agregacją: dziesięć obserwacji

Na tej ilustracji jeden węzeł obserwuje każde zdarzenie raz na punktach końcowych po stronie klienta: obserwacje ruchu od klienta do serwera są wychodzące, a odpowiedzi są przychodzące. Wszystkie werdykty są oznaczone jako FORWARDED, a inne domyślne wartości grupowania są identyczne w każdej grupie pokazanej poniżej.

Po agregacji domyślnej: cztery podsumowane rekordy

Dziesięć obserwacji staje się czterema rekordami, zachowując wszystkie dziesięć obserwacji w ich zliczeniach. Nadal można zobaczyć, które obciążenia robocze komunikowały się, porty docelowe i wolumen ruchu zaobserwowany w każdym kierunku bez oddzielnego przechowywania każdego przejścia flagi TCP.

Grupy pozostają oddzielone z następujących powodów:

• Różne obciążenia: metadane obciążenia źródłowego i docelowego są domyślnymi polami grupowania.
• Oryginalny ruch i odpowiedzi: wartości punktu końcowego, porty docelowe i is_reply różnią się, więc dwa kierunki nie są zwinięte do jednego rekordu.
• Różne porty docelowe odpowiedzi:12345 i 23456 są zachowywane jako porty docelowe w ruchu odpowiedzi. Porty źródłowe, pojedyncze nazwy zasobników i flagi TCP nie są zachowywane przez domyślną konfigurację grupowania.

Domyślne ustawienia agregacji

Agregacja jest domyślnie włączona dla przechowywanych dzienników z 30-sekundowym interwałem agregacji i domyślnymi polami grupowania wymienionymi w poniższej tabeli. W ramach interwału każdego węzła obserwacje z tymi samymi wartościami dla wszystkich pól grupowania są łączone w podsumowany rekord.

Pole może zawierać wartość tylko wtedy, gdy te informacje są dostępne w oryginalnym przepływie. Domyślne grupowanie nie umożliwia inspekcji DNS ani HTTP.

Te wartości domyślne zachowują komunikację obciążeń roboczych, porty docelowe, werdykty i kody odpowiedzi. Nie zachowują one wszystkich szczegółów przepływu: poszczególne nazwy zasobników, źródłowe i docelowe adresy IP, porty źródłowe klienta, nazwy zapytań DNS i adresy URL HTTP nie znajdują się na tej liście domyślnej.

Dodatkowe pola rozszerzają tę listę; nie zastępują jej. Użyj spec.aggregation.additionalFields, aby dostosować grupowanie bez usuwania domyślnych pól ani zmiany 30-sekundowego interwału. Powtarzanie pola domyślnego nie powoduje dodania kolejnej kopii. Zmiany wpływają na przyszłe rekordy i nie pozwalają odzyskać szczegółów pominiętych z dzienników historycznych.

Dostosuj agregację dziennika przepływu

Dostosuj agregację dzienników przepływów do wymagań operacyjnych i dochodzeniowych, wybierając dodatkowe pola grupowania poza wartościami domyślnymi usługi. Określasz, które rozróżnienia są zachowywane przez podsumowane dzienniki, od kierunku ruchu i typu żądania/odpowiedzi DNS do poszczególnych adresów IP, nazw DNS lub adresów URL HTTP. Wybierz dowolne pole obsługiwane przez obiekt FlowSchema klastra, aby uzyskać odpowiedzi na pytania, które mają dla Ciebie znaczenie.

Dodaj pola do spec.aggregation.additionalFields w zasobie ContainerNetworkLog, aby dostosować agregację. Dodatkowe pola stają się kluczami grupowania: przepływy z różnymi wartościami dla tych pól są przechowywane w osobnych grupach.

Na przykład dodanie następujących pól oddziela obserwacje, które w przeciwnym razie współużytkowałyby tę samą grupę agregacji:

Te pola są przykładami, a nie wyczerpującą listą dozwolonych elementów. Prawidłowe ścieżki pól można określić z poziomu komunikatu Hubble Flow w definicji Cilium flow.proto. Użyj pól obsługiwanych przez wersję cilium uruchomioną w klastrze; połączona main gałąź może zawierać pola, których klaster jeszcze nie obsługuje. Oryginalny przepływ musi zawierać wartość pola, aby została zachowana.

Pola o wyższej kardynalności, takie jak adresy IP, poszczególne nazwy zasobników, porty źródłowe, nazwy DNS i adresy URL HTTP, są dostępne, gdy potrzebujesz tego poziomu szczegółów. Ze względu na to, że mogą mieć wiele odrębnych wartości, włączenie ich może zwiększyć ilość dzienników oraz koszty przetwarzania i magazynowania w klastrze. Przed ich włączeniem należy ocenić oczekiwany wolumen, koszt i konsekwencje dla danych wrażliwych. Następnie monitoruj użycie, aby zrównoważyć poziom szczegółowości, jakiego potrzebujesz, z budżetem.

Dzienniki zawierające zachowane pola są zapisywane do /var/log/acns/hubble/events.log w każdym węźle, który obserwuje pasujący ruch. Po skonfigurowaniu przekazywania Azure Monitor można wykonywać zapytania dotyczące zebranych dzienników w Log Analytics przy użyciu kolumn dostępnych w ContainerNetworkLogs tabeli, w tym zachowanych właściwości reprezentowanych w jej kolumnach dynamicznych. Użyj schematu tabeli, aby zidentyfikować kolumnę lub właściwość dynamiczną do odwołania w zapytaniu.

Wybierz ruch według tożsamości zabezpieczeń użytkownika

Użyj tożsamości zabezpieczeń Cilium w filtrach źródłowych lub docelowych, aby wybrać ruch do zarejestrowania. Połącz filtry tożsamości z przestrzenią nazw, podem, protokołem lub kryteriami werdyktu. Na przykład wybierz ruch TCP z przestrzeni nazw do punktów końcowych, które Cilium klasyfikuje jako świat.

Tożsamość zabezpieczeń to klasyfikacja punktu końcowego przez Cilium, a nie tożsamość zarządzana platformy Azure ani tożsamość użytkownika. Konfiguracja akceptuje identyfikatory liczbowe, a nie aliasy, takie jak world. Zobacz przykład identyfikatora i wartości.

Dostosowywalne filtry i agregacja zapewniają uzupełniające mechanizmy sterowania: filtry wybierają przepływy do zbierania, a dodatkowe pola grupowania dostosowują sposób podsumowania wszystkich wybranych przepływów w klastrze.

Poznaj zakres i koszty

Dodatkowe pola mają zastosowanie do wszystkich wybranych przechowywanych dzienników w klastrze. Nie są one ograniczone do filtrów w zasobie, który o nie żąda.

Jeśli na przykład jeden zasób żąda l7.type, a inny zasób żąda traffic_direction, oba pola stają się częścią konfiguracji grupowania klastra. Usunięcie pierwszego zasobu powoduje usunięcie pola tylko wtedy, gdy żaden inny prawidłowy zasób go nie wymaga. Pola dostarczane przez usługę pozostają na miejscu.

Więcej unikatowych wartości pól może generować więcej rekordów. Zacznij od pól potrzebnych do analizy, przejrzyj wolumen importu danych i usuń tymczasowe dodatki po zakończeniu. Koordynuj zmiany z innymi zespołami, które zbierają dzienniki z tego samego klastra.

Użyj polecenia Configure container network logs, aby uzyskać pełne przykłady kodu YAML i kroki weryfikacji.

Dzienniki na żądanie

Dzienniki na żądanie umożliwiają inspekcję dzienników przepływu w czasie rzeczywistym bez definiowania zasobu zapisanych dzienników lub konfigurowania magazynu trwałego. Włącz usługę ACNS i najpierw połącz się za pomocą klienta Hubble. Użyj tego trybu, gdy potrzebujesz natychmiastowej widoczności podczas rozwiązywania problemów.

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 żadna konfiguracja dziennika przechowywanego. Po połączeniu rozwiązania Hubble z klastrem z włączoną usługą ACNS sprawdź dostępne przepływy bez definiowania ContainerNetworkLog zasobu.
• 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.
• Trwała pamięć masowa nie jest wymagana. Sprawdź przepływy na żywo bez konfigurowania historycznego magazynu dzienników. Nadal obowiązują opłaty za usługę ACNS.

Zalecenia dotyczące przechowywanych dzienników

1. Zacznij od jednego obciążenia i jasnego pytania. Wybierz aplikację i ruch wymagane na potrzeby analizy. W razie potrzeby sprawdź ostatnio dodane rekordy, przejrzyj wolumen, a następnie rozwiń kolekcję. Unikaj włączania szerokiego zbierania danych, aby po prostu przetestować działanie rejestrowania.

2. Dostosuj agregację do swoich potrzeb operacyjnych. Wybierz dodatkowe pola grupowania, które ułatwiają odpowiadanie na pytania, oraz ocenianie ich wpływu na wolumen i koszty. Koordynuj zmiany w całym klastrze z innymi zespołami i usuwaj tymczasowe dodatki po zakończeniu dochodzenia. Traktuj nazwy DNS i adresy URL jako potencjalnie poufne dane operacyjne.

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

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

• Dodatkowe pola mogą zachowywać różnice, takie jak źródłowe i docelowe adresy IP, adresy URL HTTP lub nazwy zapytań DNS. Oryginalny przepływ musi zawierać dane.
• Pola mają zastosowanie do wybranych przechowywanych dzienników w klastrze i mogą zwiększyć liczbę rekordów i koszty pozyskiwania danych.
• Zmiany wpływają na nowo zebrane dane. Nie odzyskują szczegółów z dzienników historycznych, zmieniają schemat tabeli ani nie udostępniają znacznika czasu dla każdego zdarzenia w zagregowanym rekordzie. Używaj dzienników na żądanie do inspekcji każdego przepływu w czasie rzeczywistym.

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

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

Treści powiązane

• Identyfikowanie nazw DNS skojarzonych z awariami

• 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