Możliwość obserwowania i analiza w usłudze Azure Operator 5G Core (wersja zapoznawcza)

Możliwość obserwacji ma trzy filary: metryki, śledzenie i dzienniki. Usługa Azure Operator 5G Core w wersji zapoznawczej zawiera te narzędzia do obserwowania, które ułatwiają identyfikowanie, badanie i rozwiązywanie problemów. Ponadto alerty platformy Azure Operator 5G Core udostępniają powiadomienia na podstawie metryk i dzienników.

Omówienie możliwości obserwacji

Następujące składniki zapewniają zauważalność dla platformy Azure Operator 5G Core:

Obserwowanie składników typu open source

Platforma Azure Operator 5G Core używa następujących składników typu open source na potrzeby funkcji obserwacji.

Parametry obserwacji	Składniki typu open source
Metryki	Prometheus, AlertManager, Grafana
Dzienniki	Elasticsearch, Fluentd i Kibana (EFK); Elastalert
Śledzenie	Jaeger, OpenTelemetry Collector

Struktura rejestrowania

Elasticsearch, Fluentd i Kibana (EFK) udostępnia rozproszony system rejestrowania używany do zbierania i wizualizowania dzienników w celu rozwiązywania problemów z mikrousługami.

Architektura

Na poniższym diagramie przedstawiono architekturę platformy EFK:

Uwaga

Sekcje następującej połączonej zawartości są dostępne tylko dla klientów z bieżącą umową pomocy technicznej aplikacji Afirmed Networks. Aby uzyskać dostęp do zawartości, musisz mieć poświadczenia logowania afirmowane sieci. Jeśli potrzebujesz pomocy, skontaktuj się z zespołem pomocy technicznej aplikacji Afirmed Networks.

Struktura rejestrowania zawiera następujące składniki:

• Fluentd — Fluentd to moduł zbierający dzienniki typu open source. Aplikacja Fluentd umożliwia ujednolicenie zbierania i używania danych w celu lepszego wykorzystania i zrozumienia danych. Rozwiązanie Fluentd jest wdrażane jako element DaemonSet w klastrze Kubernetes. Zbiera dzienniki w każdym węźle K8s i przesyła strumieniowo dzienniki do usługi Elasticsearch. Zobacz Dzienniki obsługiwane przez usługę Fluentd.

• Elasticsearch — elasticsearch to zaplecze typu open source, rozproszone, w czasie rzeczywistym. Usługa Elasticsearch bezpiecznie przechowuje dzienniki i oferuje interfejs internetowy HTTP na potrzeby analizy dzienników.

• Kibana — Kibana służy do wizualizacji dzienników przechowywanych w usłudze Elasticsearch. Kibana ściąga dzienniki z usługi Elasticsearch.

  Aby uzyskać więcej informacji na temat narzędzi Elasticsearch i Kibana, zobacz dokumentację elastic.

• ElastAlert — ElastAlert to prosta struktura do zgłaszania alertów dotyczących anomalii, skoków lub innych wzorców zainteresowania danych w usłudze Elasticsearch. Działa on przez połączenie usługi Elasticsearch z dwoma typami składników: typami reguł i alertami. Usługa Elasticsearch jest okresowo odpytywane, a dane są przekazywane do typu reguły, który określa, kiedy zostanie znalezione dopasowanie. Gdy wystąpi dopasowanie, co najmniej jeden alert jest wyzwalany na podstawie dopasowania.

  Aby uzyskać więcej informacji na temat elastAlert, zobacz dokumentację ElastAlert.

Funkcje

Struktura rejestrowania udostępnia następujące funkcje:

• Zbieranie dzienników i przesyłanie strumieniowe — fluentd zbiera i przesyła strumieniowo dzienniki do usługi Elasticsearch.

• Obsługa dzienników inspekcji — fluentd odczytuje dzienniki inspekcji Kube-Apiserver z węzła głównego platformy Kubernetes i zapisuje te dzienniki w usłudze Elasticsearch. Flaga podana auditlogEnabled w pomocnikach fed-paas służy do włączania/wyłączania odczytywania dzienników inspekcji. Jeśli flaga auditlogEnabled ma wartość true, usługa Fluentd jest również wdrażana w węźle głównym wraz z węzłami procesu roboczego.

• Rejestrowanie zdarzeń — fluentd tworzy oddzielny indeks Elasticsearch dla wszystkich dzienników zdarzeń dla określonej przestrzeni nazw. Ułatwia to stosowanie reguł i wyszukiwanie dzienników zdarzeń w lepszy sposób. Indeks rozpoczyna się od prefiksu fluentd-event. Wszystkie inne regularne dzienniki debugowania przechodzą do oddzielnego indeksu Elasticsearch, poprzedzonego ciągiem fluentd-*.

• Magazyn dzienników i analiza — usługa Elasticsearch bezpiecznie przechowuje dzienniki i oferuje język zapytań do wyszukiwania i analizowania dzienników.

• Wizualizacja dziennika — Kibana ściąga dzienniki z usługi Elasticsearch i wizualizuje dzienniki. Usługa Kibana umożliwia tworzenie pulpitów nawigacyjnych w celu wizualizacji dzienników.

• Mechanizm zgłaszania alertów — ElastAlert udostępnia reguły do wykonywania zapytań w usłudze Elasticsearch dla dzienników. Gdy wystąpi dopasowanie, alerty są wyzwalane.

Dostosowywanie programu Helm

Platforma Azure Operator 5G Core udostępnia domyślny zestaw wartości programu Helm, których można użyć do wdrożenia platformy rejestrowania EFK. Możesz dostosować te wartości, aby w razie potrzeby zwiększyć skalowalność i wydajność.

Wgląd w informacje

W tej sekcji opisano funkcje obserwacji (pulpity nawigacyjne, statystyki, dzienniki i alarmy) platformy rejestrowania EFK.

Pulpity nawigacyjne

Obsługiwane są różne pulpity nawigacyjne, w tym:

• Pulpity nawigacyjne platformy Grafana (zobacz Pulpity nawigacyjne platformy rejestrowania)
• Pulpity nawigacyjne Kibana (zobacz Omówienie pulpitu nawigacyjnego Kibana)
• Pulpity nawigacyjne Grafana Kibana (zobacz pulpity nawigacyjne Kibana Grafana)
• Pulpit nawigacyjny fluentd Operator (zobacz pulpit nawigacyjny operatora Fluentd Grafana)
• Pulpit nawigacyjny narzędzia Elasticsearch Grafana (zobacz pulpit nawigacyjny usługi Elasticsearch)

Statystyki

Aby uzyskać informacje na temat obsługiwanych statystyk dotyczących składników EFK, zobacz:

• Statystyki elasticsearch
• Inne statystyki usługi Elasticsearch
• Statystyki operatorów fluentd

Aby uzyskać informacje o alertach opartych na metrykach, zobacz:

• Alerty oparte na metrykach operatora Fluentd
• Elastyczne alerty oparte na metryce

Zdarzenia

Aby uzyskać informacje o zdarzeniach elastycznych, zobacz Zdarzenia elastyczne.

Wizualizacja dziennika

Platforma agreguje dzienniki z węzłów i aplikacji działających w ramach instalacji platformy Azure Operator 5G Core. Po włączeniu rejestrowania platforma EFK używa rozwiązania Fluentd do agregowania dzienników zdarzeń ze wszystkich aplikacji i węzłów do usługi Elasticsearch. Platforma EFK udostępnia również scentralizowany internetowy interfejs użytkownika Kibana, w którym użytkownicy mogą wyświetlać dzienniki lub tworzyć rozbudowane wizualizacje i pulpity nawigacyjne za pomocą zagregowanych danych.

Struktura metryk

Struktura metryk składa się z rozwiązań Prometheus, Grafana i AlertManager.

Prometheus (główny składnik) to system monitorowania oparty na metrykach typu open source. Udostępnia ona model danych i język zapytań do analizowania sposobu działania aplikacji i infrastruktury. Rozwiązanie Prometheus zbiera metryki z instrumentowanych zadań bezpośrednio i przechowuje wszystkie próbki ze złomowane w lokalnym magazynie zewnętrznym. Na podstawie zdefiniowanych reguł rozwiązanie Prometheus agreguje i rejestruje nowy szereg czasowy z istniejących danych lub generuje alerty. Menedżer alertów obsługuje alerty wysyłane przez aplikacje klienckie przez deduplikację, grupowanie i kierowanie ich do odpowiednich integracji odbiornika.

Aplikacja Grafana udostępnia pulpity nawigacyjne umożliwiające wizualizowanie zebranych danych.

Architektura

Na poniższym diagramie pokazano, jak różne składniki struktury metryk współdziałają ze sobą.

Podstawowe składniki struktury metryk to:

• Serwer Prometheus — serwer Prometheus zbiera metryki ze skonfigurowanych obiektów docelowych w określonych interwałach, ocenia wyrażenia reguły, wyświetla wyniki i wyzwala alerty, jeśli określone warunki są prawdziwe. Usługa Azure Operator 5G Core obsługuje integrację z serwerem Prometheus z braku możliwości, z minimalną wymaganą konfiguracją.
• Biblioteki klienckie — biblioteki klienckie instrumentację kodu aplikacji.
• AlertManager — menedżer alertów obsługuje alerty wysyłane przez aplikacje klienckie, takie jak serwer Prometheus. Obsługuje deduplikację, grupowanie i kierowanie alertów do prawidłowych integracji odbiorcy (wiadomości e-mail, slack itp.). AlertManager obsługuje również wyciszanie i hamowanie alertów.
• Grafana — Grafana udostępnia wbudowany zestaw pulpitów nawigacyjnych bogatych w 3GPP i inne kluczowe wskaźniki wydajności umożliwiające wykonywanie zapytań, wizualizowanie i zrozumienie zebranych danych. Funkcja inspekcji narzędzia Grafana udostępnia mechanizm przywracania lub ponownego tworzenia pulpitów nawigacyjnych na serwerze Grafana po ponownym uruchomieniu zasobnika serwera Grafana. Funkcja inspekcji pomaga również usunąć wszystkie nieaktualne pulpity nawigacyjne z serwera Grafana.

Funkcje

Struktura metryk obsługuje następujące funkcje:

• Wielowymiarowy model danych z danymi szeregów czasowych identyfikowanymi przez pary nazwy metryki i klucz/wartość.
• PromQL, elastyczny język zapytań korzystający z danych wielowymiarowych.
• Brak zależności od magazynu rozproszonego: pojedyncze węzły serwera są autonomiczne.
• Zbieranie szeregów czasowych przy użyciu modelu ściągania za pośrednictwem protokołu HTTP.
• Obiekty docelowe są odnajdywane za pośrednictwem odnajdywania usługi lub konfiguracji statycznej.
• Wiele trybów obsługi grafów i pulpitów nawigacyjnych.

Aby uzyskać więcej informacji na temat rozwiązania Prometheus, zobacz dokumentację rozwiązania Prometheus. Aby uzyskać więcej informacji na temat narzędzia Grafana, zobacz dokumentację oprogramowania open source platformy Grafana.

Wgląd w informacje

W tej sekcji opisano funkcje obserwacji (pulpity nawigacyjne, statystyki, dzienniki i alarmy) udostępniane przez strukturę metryk.

Pulpity nawigacyjne

Platforma metryk obsługuje następujące pulpity nawigacyjne:

• Pulpity nawigacyjne narzędzia Grafana (zobacz pulpit nawigacyjny narzędzia Grafana)
• Pulpity nawigacyjne rozwiązania Prometheus Grafana (zobacz pulpit nawigacyjny Prometheus Grafana)

Statystyki

Aby uzyskać informacje na temat obsługiwanych statystyk dotyczących składników platformy metryk, zobacz:

• Statystyki narzędzia Grafana
• Statystyki prometheus
• Statystyki błędów serwera Prometheus

Aby uzyskać informacje na temat alertów opartych na metrykach rozwiązania Prometheus, zobacz Alerty oparte na metrykach rozwiązania Prometheus.

Zdarzenia/dzienniki

Aby uzyskać informacje o zdarzeniach struktury metryk, zobacz:

• Wydarzenia Prometheus
• Zdarzenia infrastruktury

Alerty oparte na metrykach dotyczące błędów sieci/HTTP

Reguły alertów Prometheus generują alerty, jeśli w systemie wykryto błędy protokołu HTTP/sieci. Następujące alerty są generowane dla błędów sieci.

Alerty globalne na poziomie aplikacji:

• IstioGlobalHTTP5xxRatePercentageHigh — aplikacja, która jest częścią siatki usługi Istio, odpowiada z powodu błędu 5xx, a procent współczynnika błędów jest większy niż <wartość skonfigurowana > %
• IstioGlobalHTTP4xxRatePercentageHigh — aplikacja odpowiada z błędem 4xx, a procent liczby błędów przekracza <wartość configured_value> %. IstioHTTPRequestLatencyTooHigh: Żądania trwają dłużej niż <configured_value> sekund.

Alerty na poziomie zasobnika i kontenera:

• HTTPServerError5xxPercentageTooHigh — serwer HTTP odpowiada z błędem 5xx, a procent błędu jest większy niż <configured_value> %.
• HTTPServerError4xxPercentageTooHigh — serwer HTTP odpowiada z błędem 4xx, a procent błędu jest większy niż <configured_value> %.
• HTTPServerRequestRateTooHigh — łączna liczba żądań odebranych na serwerze HTTP jest większa niż <configured_value>.
• HTTPClientRespRcvd5xxPercentageTooHigh — odpowiedź klienta HTTP odebrana z błędem 5xx i otrzymany procent błędu jest większy niż <configured_value> %.
• HTTPClientRespRcvd4xxPercentageTooHigh — odpowiedź klienta HTTP odebrana z błędem 4xx i otrzymany procent błędu jest większy niż <configured_value> %.

Struktura śledzenia

Śledzenie Jaeger przy użyciu protokołu OpenTelemetry Protocol

Usługa Azure Operator 5G Core używa protokołu OpenTelemetry Protocol (OTLP) w śledzeniu Jaeger. OTLP zastępuje agenta Jaeger w fed-paas-helpers. Usługa Azure Operator 5G Core wdraża federację fed-otel_collector. Moduł zbierający OpenTelemetry (OTEL) jest uruchamiany w ramach przestrzeni nazw fed-otel_collector:

Śledzenie Jaeger używa następującego przepływu pracy:

1. Aplikacja z biblioteką klienta OTLP wysyła ślady do modułu zbierającego OTEL w protokole OTLP GRPC. Moduł zbierający OTEL ma trzy składniki: odbiorniki, procesory i eksporterów.
2. Odbiornik OTLP GRPC w module zbierającym OTEL otrzymuje ślady i wysyła je do eksportera Jaeger.
3. Eksporter Jaeger wysyła ślady do kolekcjonera Jaeger działającego w ramach fed-jaeger.
4. Moduł zbierający Jaeger przechowuje ślady w magazynie elastycznym zaplecza (fed-elastic).

Powiązana zawartość

• Co to jest usługa Azure Operator 5G Core w wersji zapoznawczej?
• Szybki start: wdrażanie możliwości obserwowania platformy Azure Operator 5G Core (wersja zapoznawcza) w usługach Azure Kubernetes Services (AKS)

[def]: