Obserwowanie usług dla platformy Kubernetes z obsługą usługi Azure Arc

  • Artykuł

Obserwowanie to cecha aplikacji, która odnosi się do tego, jak dobrze można zrozumieć stan wewnętrzny lub stan systemu z jego danych wyjściowych zewnętrznych. Mierzymy systemy komputerowe, obserwując czas procesora CPU, pamięć, miejsce na dysku, opóźnienie, błędy i inne metryki. Tym bardziej zauważalny jest system, tym łatwiej nam zrozumieć, co robi, oglądając go.

Zauważalność systemu ma znaczący wpływ na jego koszt operacyjny. Obserwowane systemy dają znaczące, możliwe do działania dane operatorom, co pozwala im osiągnąć korzystne wyniki i mieć mniej przestojów. Więcej informacji niekoniecznie przekłada się na bardziej zauważalny system. W rzeczywistości czasami ilość informacji generowanych przez system może utrudnić identyfikację cennych sygnałów kondycji z szumu generowanego przez aplikację.

Możliwość obserwowania usługi jest ważna, ponieważ ułatwia zrozumienie wydajności i problemów w systemach rozproszonych i w chmurze opartych na architekturach dynamicznych.

Zaimplementowanie rozwiązania umożliwiającego obserwowanie usług może pomóc:

  • Upewnij się, że użytkownicy końcowi mogą korzystać z aplikacji i oczekiwań biznesowych.
  • Poznaj cały system i sposób, w jaki działa razem przy użyciu jednego okienka szkła.
  • Ustanów punkt odniesienia dla systemu i dowiedz się, jak różne okoliczności wpływają na wydajność systemu.
  • Generowanie elementów akcji na podstawie nieoczekiwanych scenariuszy i zachowań.

Platforma Kubernetes z włączoną usługą Azure Arc udostępnia dwie zintegrowane opcje rozszerzenia, które ułatwiają obserwowanie usług: Open Service Mesh i Self-hosted API Management Gateway. Te opcje zostały szczegółowo omówione w poniższych sekcjach zagadnień projektowych.

Architektura

Na poniższym diagramie przedstawiono trzy filary obserwowania usług z wpływem ilości danych.

A diagram depicting Services Observability Pillars.

Na poniższym diagramie przedstawiono różne składniki usługi Open Service Mesh uruchomione w klastrze Kubernetes z obsługą usługi Arc. Pokazuje również przykładową aplikację włączoną w siatce usług, która jest automatycznie konfigurowana przy użyciu kontenera samochodu bocznego usługi Envoy.

A diagram depicting Open Service Mesh running in Azure Arc-enabled Kubernetes.

Uwagi dotyczące projektowania

Trzy filary obserwacji to metryki, dzienniki i ślady. Uwzględnij je w strategii obserwacji, aby ułatwić obserwowanie systemu.

  • Metryki to wartości liczbowe , które opisują jakiś aspekt systemu w określonym momencie w czasie i są zawsze zbierane w regularnych odstępach czasu.

Poniższy zrzut ekranu przedstawia wizualizację przykładowej metryki żądania HTTP dla usługi. Metryka w tym przykładzie jest wyświetlana jako częstotliwość żądań HTTP na minutę w określonym przedziale czasu.

A screenshot showing H T T P request metric for a service.

  • Dzienniki mogą przechowywać różne typy danych, które mają własne struktury. Dziennik zawiera szczegółowe informacje o transakcjach, które umożliwiają uzyskanie bardziej kompletnego scenariusza dla danego zdarzenia. Dzienniki aplikacji zwykle obejmują znaczniki czasu, poziomy dziennika i wszelkie informacje niezbędne do zrozumienia kontekstu zdarzenia. Dzienniki są zbierane i wysyłane do usługi dziennika na potrzeby magazynowania i analizy.

  • Śledzenie rozproszone to technika diagnostyczna, która ułatwia użytkownikom lokalizowanie błędów i problemów z wydajnością w aplikacjach, zwłaszcza tych, które są rozproszone na wielu maszynach lub procesach. Ta technika śledzi żądania za pośrednictwem aplikacji, korelując pracę wykonywaną przez różne składniki aplikacji i oddzielając je od innych zadań, które aplikacja może wykonywać w przypadku żądań współbieżnych.

Poniższy zrzut ekranu przedstawia wizualizację kompleksowej transakcji przy użyciu usługi Application Szczegółowe informacje. Ta wizualizacja umożliwia łatwe zrozumienie czasów odpowiedzi, kodów odpowiedzi i wszelkich wyjątków występujących między żądaniami w łańcuchu transakcji.

A screenshot showing end-to-end transaction trace.

Trzy filary metryk, dzienników i śledzenia rozproszonego są połączone. Metryki są przechowywane jako wartości liczbowe w bazie danych szeregów czasowych. Są one również znacznie mniejsze niż dzienniki, co ułatwia ich ocenę i przydatne w przypadku alertów niemal w czasie rzeczywistym. Dzienniki przechwytują i przekazują znacznie więcej informacji niż metryki, co sprawia, że są one przydatne do dokładniejszego debugowania. Ślady są ograniczone do zakresu żądań i są przydatne do uzyskiwania wglądu w żądanie podczas przechodzenia przez różne składniki systemu rozproszonego.

W poniższej tabeli przedstawiono wpływ kolekcji na trzy filary.

Charakterystyka kolekcji Metryki Dzienniki Śledzenie rozproszone
Konta dla każdej transakcji tak tak nie (próbkowane)
Problemy z kardynalnością odporności nie tak tak
Koszt  Niski Wysokiej  Niski

Istnieją różne sposoby obserwowania usług. Możesz użyć siatki usług, aby to zrobić w warstwie platformy, gdzie aplikacja nie jest nieświadoma i niezmieniona. Aplikację można również instrumentować przy użyciu biblioteki, która jest często wykonywana przy użyciu narzędzia application monitor wydajności ing (APM), takiego jak Application Szczegółowe informacje. Bramy interfejsu API zapewniają wgląd w ruch północno-południowy, ale brakuje możliwości wglądu w zasobnik w komunikację zasobnika i łatwość konfiguracji na dużą skalę.

W poniższych sekcjach opisano, jak za pomocą siatki usług i własnej bramy interfejsu API dostępnej dla usługi Azure Arc można uzyskać wgląd w usługi.

Siatka usług

Siatka usług zapewnia funkcje, takie jak zarządzanie ruchem, odporność, wymuszanie zasad, zabezpieczenia transportu, zabezpieczenia tożsamości i możliwość obserwowania obciążeń. Aplikacja jest oddzielona od tych możliwości operacyjnych; siatka usług przenosi je z warstwy aplikacji i w dół do warstwy infrastruktury. Odbywa się to za pośrednictwem serwera proxy o wysokiej wydajności, który pośredniczy dla całego ruchu przychodzącego i wychodzącego do usługi.

  • Platforma Kubernetes z obsługą usługi Azure Arc obsługuje platformę Open Service Mesh (OSM), projekt Cloud Native Computing Foundation (CNCF), który jest wdrażany jako rozszerzenie. Open Service Mesh to uproszczona, rozszerzalna, natywna dla chmury siatka usług, która umożliwia użytkownikom jednolite zarządzanie, zabezpieczanie i uzyskiwanie wbudowanych funkcji obserwacji w środowiskach wysoce dynamicznych mikrousług.
  • Inne popularne siatki usług, które wymagają obsługi dostawcy, to Istio, Consul Połączenie i Linkerd.
  • W zależności od funkcji używanych podczas implementowania siatki usług dodatkowa odpowiedzialność może zostać umieszczona na operatorach aplikacji w celu zdefiniowania konfiguracji dla każdej usługi (na przykład reguł dostępu i usług dołączania). Ponadto operatorzy klastrów muszą zarządzać kontrolerem siatki usług i być świadomi go. Ze względu na sposób, w jaki siatka usług używa wzorca samochodu bocznego, dzienniki dostępu z płaszczyzny sterowania siatki usług i przyczepki są potrzebne podczas debugowania ruchu wychodzącego i ruchu przychodzącego.

Obserwowalność siatki usług

Możliwość obserwacji jest ważną funkcją wśród wielu, które zapewniają siatki usług. Wybierz usługę Service Mesh, która spełnia minimalne wymagania dotyczące obserwacji, aby zmniejszyć złożoność i składniki, z którymi może pochodzić siatka usług i które wymagają skonfigurowania. Oceń następujące typowe cechy i przypadki użycia obserwowania zapewniane przez siatki usług:

  • Generowanie metryk, w tym cztery złote sygnały: opóźnienie, ruch, błędy i nasycenie.
  • Metoda RED (Rates-calls/sec, Errors, Duration-call latencies), która jest podzbiorem czterech złotych sygnałów i służy do mierzenia usług. Siatka usług powinna zapewnić ustandaryzowany sposób zbierania metryk RED, śladów itp.
  • Obserwowanie zwiększa się, od zwiększania zasięgu zasięgu do wszystkich usług, które są częścią siatki usług.
  • Funkcje zwiększające możliwość obserwowania dzięki automatycznej instrumentowaniu wszystkich usług.
  • Silna integracja z filarami obserwacji usług. Siatka usług powinna mieć możliwość złomowania metryk i zbierania dzienników, które są udostępniane w rozwiązaniu do monitorowania. Upewnij się, że kolekcja danych telemetrycznych usługi Service Mesh obsługuje potrzeby biznesowe i dobrze integruje się z istniejącym rozwiązaniem do monitorowania.

Na poniższym diagramie przedstawiono przykład funkcji serwera proxy usługi Service Mesh zbierania i przekazywania danych.

A diagram depicting an example observability with a Service Mesh Proxy.

Własna brama usługi API Management

Dzięki integracji między usługą Azure API Management i usługą Azure Arc na platformie Kubernetes możesz wdrożyć składnik bramy usługi API Management jako rozszerzenie w klastrze Kubernetes z obsługą usługi Azure Arc. Dzięki temu konteneryzowana wersja bramy usługi API Management może być uruchamiana w klastrze. Wszystkie bramy self-hosted są zarządzane z poziomu usługi API Management, z którą są federacyjne, zapewniając widoczność i ujednolicone środowisko zarządzania we wszystkich wewnętrznych i zewnętrznych interfejsach API.

Skonfigurowanie własnej bramy w celu akceptowania ruchu przychodzącego do kierowania do usług wymaga utworzenia zasad. Jego zarządzanie może stać się bardziej złożone w miarę zwiększania skali usługi.

Aby uzyskać więcej informacji, zobacz omówienie własnej bramy

Możliwość obserwowania własnej bramy usługi API Management

Brama hostowana samodzielnie emituje metryki, dzienniki stdout i dzienniki stderr. Emitowane metryki można skonfigurować za pomocą obiektu ConfigMap w klastrze. Aby uzyskać informacje na temat zaawansowanego monitorowania za pomocą usługi API Management, zobacz Zaawansowane monitorowanie.

Samoobsługowa brama umożliwia obserwowanie ruchu zewnętrznego (północ-południe) przychodzącego do klastra, ale nie zapewnia wglądu w ruch zasobnik-zasobnik wewnątrz klastra (wschód-zachód).

Metryki i dzienniki w chmurze: Metryki są domyślnie emitowane do usługi Azure Monitor. Usługa Log Analytics umożliwia zbieranie i wyświetlanie dzienników kontenerów własnej bramy przy użyciu usługi Azure Monitor dla kontenerów. Aby uzyskać więcej informacji, zobacz Konfigurowanie lokalnych metryk i dzienników dla własnej bramy usługi Azure API Management.

Lokalne metryki i dzienniki: Metryki i dzienniki z własnej bramy można zintegrować z lokalnymi narzędziami monitorowania lub emitowanymi przez mapę konfiguracji. Metryki można skonfigurować do publikowania na serwerach metryk. Dzienniki bramy są domyślnie emitowane do stdout i stderr. Aby uzyskać więcej informacji, zobacz Konfigurowanie lokalnych metryk i dzienników dla własnej bramy usługi Azure API Management.

Tabela porównania technologii

W poniższej tabeli przedstawiono różnice między opcjami implementacji, które ułatwiają wybranie metody uzyskiwania możliwości obserwowania usług.

Możliwość Service Mesh Monitor wydajności aplikacji Własna brama interfejsu API
Obsługiwany ruch wschodnio-zachodni tak tak nie
Możliwości metryk tak tak tak
Możliwość rejestrowania tak tak implementacja niestandardowa
Możliwość śledzenia rozproszonego tak tak tak
Warstwa implementacji network aplikacja network
Obsługiwane protokoły http(s), tcp, gRPC Nie dotyczy http(s), websockets
Odpowiedzialność za konfigurację Operatorzy klastra Deweloperzy aplikacji Operatory aplikacji i operatory klastra
Złożoność konfiguracji pod kątem obserwacji  Niski Wysokiej  Średni

Zalecenia dotyczące projektowania

Zaimplementuj usługę Open Service Mesh, aby uzyskać wgląd w kondycję i wydajność usług. Usługa Open Service Mesh używa serwerów proxy przyczepki wstrzykiwanych jako oddzielny kontener do tych samych zasobników, co obciążenia w celu uzyskania danych telemetrycznych. Te serwery proxy przechwytują cały przychodzący i wychodzący ruch HTTP do obciążeń i zgłaszają dane do usługi Open Service Mesh. Dzięki temu systemowi deweloperzy usług nie muszą instrumentować kodu w celu zbierania danych telemetrycznych.

Włącz usługę Open Service Mesh przy użyciu funkcji rozszerzenia klastra Kubernetes z obsługą usługi Azure Arc, która umożliwia firmie Microsoft zarządzanie płaszczyzną sterowania. Aby uzyskać więcej informacji, zobacz Wdrażanie usługi Open Service Mesh z obsługą usługi Azure Arc (wersja zapoznawcza).

Aby zmaksymalizować dostępność i wydajność aplikacji i usług, włącz Szczegółowe informacje kontenera usługi Azure Monitor. Zapewnia kompleksowe rozwiązanie do zbierania, analizowania i działania na podstawie danych telemetrycznych z chmury i środowisk lokalnych. Usługa Open Service Mesh z obsługą usługi Azure Arc jest ściśle zintegrowana z usługą Azure Monitor, co zapewnia bezproblemową metodę wyświetlania kluczowych wskaźników wydajności udostępnianych przez metryki OSM i dzienniki kontenerów aplikacji oraz reagowanie na nie. Metryki OSM można włączyć, wykonując następujące kroki. W przypadku śledzenia rozproszonego zalecamy rozwiązanie Jaeger, które można zintegrować z płaszczyzną sterowania OSM.

Usługa Open Service Mesh udostępnia również udokumentowane integracje z obserwacją metryk z rozwiązaniami Prometheus i Grafana, śledzenie za pomocą narzędzia Jaeger i przekazywanie dzienników za pomocą rozwiązania Fluent Bit. Te integracje zapewniają alternatywne opcje, jeśli nie używasz rozwiązań do monitorowania platformy Azure. Tych integracji można używać do rozszerzania na inne wewnętrzne narzędzia do monitorowania zgodnie z potrzebami.

Co najmniej należy zdefiniować następujące trzy metryki RED i zmierzyć je dla wszystkich usług:

  • Częstotliwość żądań: liczba żądań odbieranych przez usługę na sekundę.
  • Błędy: liczba żądań zakończonych niepowodzeniem lub szybkość żądań zakończonych niepowodzeniem na sekundę.
  • Czas trwania: czas potrzebny na obsługę żądania przez usługę.

Usługa Open Service Mesh udostępnia kilka wstępnie skonfigurowanych skoroszytów usług w usłudze Azure Monitor, dzięki czemu nie trzeba ręcznie konfigurować pulpitów nawigacyjnych i wykresów. Ta szczegółowa telemetria umożliwia obserwowanie zachowania usługi i umożliwia rozwiązywanie problemów, konserwowanie i optymalizowanie aplikacji. Korzystanie ze skoroszytu monitorowania OSM w usłudze Azure Monitor umożliwia:

  • Zapoznaj się z omówieniem wszystkich usług w siatkach i uzyskaj krytyczne metryki poziomu usług dla trzech z czterech złotych sygnałów monitorowania: opóźnienia, żądań i błędów.
  • Definiowanie, przeglądanie i ustawianie alertów dotyczących celów poziomu usług (SLO), które podsumowują wydajność widoczną dla użytkownika usługi.
  • Wyświetlanie wykresów metryk dla poszczególnych usług, dzięki czemu można je głęboko analizować przy użyciu filtrowania i podziału, przesiewania danych według kodu odpowiedzi, protokołu, zasobnika docelowego, źródła ruchu i nie tylko.

Użyj wizualizacji z interfejsu użytkownika usługi Jaeger, aby:

  • Obserwuj wizualizację grafu topologii, która pokazuje, które mikrousługi komunikują się ze sobą, gdzie są wysyłane żądania i jak długo trwa.
  • Sprawdź konkretne żądania i odpowiedzi, aby zobaczyć, jak i kiedy występują na potrzeby monitorowania i rozwiązywania problemów z systemami rozproszonymi.

Usługi można zaobserwować tylko jedną dyscyplinę strategii monitorowania chmury. Aby uzyskać więcej informacji na temat dyscyplin zarządzania, zapoznaj się z sekcją Zarządzanie dziedzinami krytycznymi w projekcie.

Następne kroki

Aby uzyskać więcej informacji na temat hybrydowej i wielochmurowej podróży w chmurze, zobacz następujące artykuły: