Zalecenia dotyczące instrumentowania aplikacji

Dotyczy tej rekomendacji dotyczącej listy kontrolnej doskonałości operacyjnej platformy Azure Well-Architected Framework:

Powiązany przewodnik: Zalecenia dotyczące projektowania i tworzenia systemu monitorowania

W tym przewodniku opisano zalecenia dotyczące włączania obserwacji aplikacji przy użyciu instrumentacji. Generowanie znaczących danych telemetrycznych, które można pozyskać i zintegrować z systemem monitorowania. Za pomocą instrumentacji można zbierać informacje bez logowania się do zdalnego serwera produkcyjnego w celu ręcznego śledzenia lub debugowania. Dane instrumentacji obejmują metryki i dzienniki, których można użyć do oceny wydajności, diagnozowania problemów i podejmowania decyzji dotyczących obciążeń.

Kluczowe strategie projektowania

Aby zoptymalizować dane telemetryczne dla obciążenia, instrumentuj aplikację w celu wygenerowania następujących danych:

• Dzienniki są sygnaturami czasowych zdarzeń dyskretnych. Istnieją trzy formy dzienników: zwykły tekst, ustrukturyzowany i binarny.

• Rozproszone dzienniki śledzenia umożliwiają wyświetlanie ścieżki żądania podczas przechodzenia przez różne usługi i składniki.

• Metryki to wartości liczbowe, które opisują aspekt systemu w określonym punkcie w czasie.

Dzienniki i rozproszone dzienniki śledzenia

Użyj rejestrowania strukturalnego, aby łatwo zintegrować dzienniki z platformami monitorowania i analizy. Instrumentuj aplikację, aby można było zmienić poziomy szczegółowości. Stałe pełne rejestrowanie może zmarnować zasoby magazynu, dlatego należy je włączyć i wyłączyć zgodnie z potrzebami w celu rozwiązywania problemów.

Dzienniki śledzenia zawierają dane tekstowe lub dane binarne utworzone na podstawie zdarzenia śledzenia, jeśli aplikacja używa śledzenia zdarzeń dla systemu Windows (ETW). Dzienniki systemowe generują zawartość dziennika śledzenia na podstawie zdarzeń w infrastrukturze, takich jak serwer internetowy. Zawartość dziennika tekstowego jest przeznaczona do odczytu przez ludzi, ale należy upewnić się, że jest ona napisana w formacie, który zautomatyzowany system może również analizować.

Kategoryzuj dzienniki i używaj oddzielnych dzienników do rejestrowania danych wyjściowych śledzenia z każdego aspektu operacyjnego systemu. W przypadku kategoryzowania dzienników można szybko filtrować komunikaty dziennika zamiast przetwarzać pojedynczy długi plik. Nigdy nie zapisuj informacji o różnych wymaganiach dotyczących zabezpieczeń, takich jak informacje inspekcji i debugowanie danych, do tego samego dziennika.

Metryki

Metryki lub przykłady to liczba niektórych aspektów lub zasobów w systemie w określonym czasie z co najmniej jednym skojarzonym tagiem lub wymiarami. Pojedyncze wystąpienie metryki nie jest przydatne w izolacji. Metryki powinny być przechwytywane w czasie. Zastanów się, które metryki należy rejestrować i jak często. Dane generowane zbyt często mogą narzucić duże obciążenie systemu, ale rzadkie przechwytywanie danych może spowodować pominięcie okoliczności, które prowadzą do istotnego zdarzenia. Odpowiednia częstotliwość przechwytywania danych może się różnić od metryki do metryki. Na przykład użycie procesora CPU na serwerze może się znacznie różnić od sekundy do sekundy, ale wysokie użycie staje się problemem tylko wtedy, gdy jest spójne przez wiele minut.

Informacje dotyczące korelacji danych

Można łatwo monitorować poszczególne liczniki wydajności na poziomie systemu, przechwytywać metryki zasobów i uzyskiwać informacje dotyczące śledzenia aplikacji z różnych plików dziennika. Niektóre monitorowanie wymaga korelacji danych podczas etapu analizy i diagnostyki w potoku monitorowania. Te dane mogą przyjmować kilka formularzy, a proces analizy musi być dostarczany z wystarczającymi danymi instrumentacji, aby mapować te różne formularze. Na przykład na poziomie platformy aplikacji identyfikator wątku może zidentyfikować zadanie. W aplikacji ta sama praca może być skojarzona z identyfikatorem użytkownika dla użytkownika, który wykonuje to zadanie.

Jest mało prawdopodobne, aby była mapą 1:1 między wątkami i żądaniami użytkowników, ponieważ operacje asynchroniczne mogą ponownie używać tych samych wątków dla więcej niż jednego użytkownika. Aby jeszcze bardziej skomplikować sprawę, pojedyncze żądanie może skorelować z więcej niż jednym wątkiem, gdy przepływa przez system. Jeśli to możliwe, należy skojarzyć każde żądanie z unikatowym identyfikatorem działania, który jest propagowany przez system jako część kontekstu żądania. Technika generowania i dołączania identyfikatorów działań w informacjach śledzenia zależy od technologii używanej do przechwytywania danych śledzenia.

Wszystkie dane monitorowania powinny być znacznikami czasu w taki sam sposób. W celu zachowania spójności należy zarejestrować wszystkie daty i godziny przy użyciu uniwersalnego czasu koordynowanego.

Informacje do uwzględnienia w danych instrumentacji

Podczas decydowania, które dane instrumentacji należy zebrać, należy wziąć pod uwagę następujące kwestie.

Dane czytelne dla człowieka

Upewnij się, że informacje przechwycone przez zdarzenia śledzenia są zarówno maszyną, jak i czytelną dla człowieka. Zastosuj dobrze zdefiniowane schematy dla tych informacji, aby ułatwić wdrożenie zautomatyzowanego przetwarzania danych dziennika w systemach oraz zapewnienie spójności dla pracowników operacyjnych i inżynieryjnych odczytując dzienniki.

Uwzględnij następujące informacje dotyczące środowiska w danych:

• Środowisko wdrażania
• Maszyna do przetwarzania
• Szczegóły procesu
• Stos wywołań

Inwestowanie w możliwość śledzenia i korelację

Podaj wystarczający kontekst, taki jak identyfikator działania skojarzony z określonym wystąpieniem żądania, aby deweloper lub administrator mógł określić źródło każdego żądania.

Kontekst danych może również zawierać informacje używane do korelowania działania z wykonywaną pracą obliczeniową i używanymi zasobami. Ta praca może przekraczać granice procesów i maszyn.

W przypadku pomiaru kontekst powinien bezpośrednio lub pośrednio zawierać odwołanie do klienta, który spowodował żądanie. Ten kontekst udostępnia cenne informacje o stanie aplikacji w czasie przechwytywania danych monitorowania.

Przechwytywanie wszystkich odpowiednich danych

Rejestruj wszystkie żądania i lokalizacje lub regiony, w których są wykonywane. Te informacje ułatwiają identyfikowanie hotspotów specyficznych dla lokalizacji. Te informacje mogą również być przydatne do określenia, czy należy ponownie partycjonować aplikację, czy dane, których używa.

Dokładnie rejestruj i przechwytuj szczegóły wyjątków. Krytyczne informacje debugowania są często tracone z powodu słabej obsługi wyjątków. Przechwyć wszystkie szczegóły wyjątku zgłaszane przez aplikację, w tym wszelkie wyjątki wewnętrzne lub inne informacje kontekstowe, takie jak stos wywołań, jeśli to możliwe.

Dążenie do spójności danych

Spójne dane mogą ułatwić analizowanie zdarzeń i korelowanie ich z żądaniami użytkowników. Rozważ użycie kompleksowego i konfigurowalnego pakietu rejestrowania w celu zebrania informacji. Pakiety rejestrowania mogą pomóc uniknąć zależności od deweloperów w celu wdrożenia różnych części systemu.

Zbierz dane, takie jak wolumin wejściowy/wyjściowy, liczba żądań i pamięci, sieć i użycie procesora CPU, z kluczowych liczników wydajności. Niektóre usługi infrastruktury zapewniają własne liczniki wydajności, takie jak:

• Liczba połączeń z bazą danych.
• Stawka transakcji.
• Liczba transakcji zakończonych powodzeniem lub niepowodzeniem.

Aplikacje mogą również definiować własne liczniki wydajności.

Rozważ zewnętrzne zależności

Rejestruje wszystkie wywołania usługi zewnętrznej. Połączenia zewnętrzne mogą być wykonywane w celu:

• Systemy baz danych.
• Usługi sieci Web.
• Inne usługi na poziomie systemu, które są częścią infrastruktury.

Rejestruje informacje o czasie trwania każdego wywołania oraz powodzeniu lub niepowodzeniu wywołania. Jeśli to możliwe, przechwytuj informacje o wszystkich ponownych próbach i błędach dla wszelkich przejściowych błędów, które wystąpią.

Zapewnianie zgodności systemu telemetrii

W wielu przypadkach informacje o instrumentacji są generowane jako seria zdarzeń i przekazywane do oddzielnego systemu telemetrii na potrzeby przetwarzania i analizy. System telemetrii jest zazwyczaj niezależny od dowolnej konkretnej aplikacji lub technologii.

Systemy telemetryczne używają zdefiniowanych schematów do analizowania informacji. Schemat określa kontrakt definiujący pola danych i typy, które mogą pozyskiwać system telemetrii. Uogólnij schemat, aby umożliwić pobieranie danych z różnych platform i urządzeń. Typowy schemat powinien zawierać pola istotne dla wszystkich zdarzeń instrumentacji, takich jak:

• Nazwa zdarzenia.
• Czas zdarzenia.
• Adres IP nadawcy.
• Szczegóły wymagane do korelacji zdarzeń, w tym:
  • Identyfikator użytkownika
  • Identyfikator urządzenia
  • Identyfikator aplikacji

Należy pamiętać, że wiele urządzeń może zgłaszać zdarzenia dla tej samej aplikacji, więc schemat nie powinien zależeć od typu urządzenia. Aplikacja powinna obsługiwać roaming lub dystrybucję między urządzeniami. Schemat może również zawierać odpowiednie pola domeny dla konkretnego scenariusza, który jest typowy dla aplikacji, takich jak:

• Informacje o wyjątkach.
• Zdarzenia uruchamiania i kończenia aplikacji.
• Powodzenie lub niepowodzenie wywołań interfejsu API usługi internetowej.

Ustanów pola domeny, które tworzą ten sam zestaw zdarzeń, aby utworzyć zestaw typowych raportów i analiz w aplikacjach. Może być konieczne skonfigurowanie schematu w celu przechowywania pól niestandardowych do przechwytywania szczegółów zdarzeń specyficznych dla aplikacji.

OpenTelemetry to neutralna od dostawcy kolekcja interfejsów API, zestawów SDK i innych narzędzi. Funkcja OpenTelemetry umożliwia instrumentację aplikacji i spójne generowanie znaczących danych telemetrycznych w różnych językach. Platforma OpenTelemetry jest niezależna od narzędzi, dlatego jest zgodna z wieloma platformami do obserwacji, w tym ofertami open source i komercyjnymi. Firma Microsoft przyjmuje platformę OpenTelemetry jako standardowe narzędzie do instrumentacji.

Najlepsze rozwiązania dotyczące instrumentacji aplikacji

Poniższa lista zawiera podsumowanie najlepszych rozwiązań dotyczących instrumentowania aplikacji rozproszonej działającej w chmurze:

• Zapewnij, żeby dzienniki były łatwe do odczytu i łatwe do analizy. Użyj strukturalnego rejestrowania, jeśli jest to możliwe.

• Komunikaty dziennika powinny być zwięzłe i opisowe.

• Zidentyfikuj źródło dziennika.

• Dodaj informacje o sygnaturze czasowej podczas zapisywania każdego rekordu dziennika.

• Użyj tej samej strefy czasowej i formatu dla wszystkich sygnatur czasowych.

• Kategoryzuj dzienniki i zapisuj komunikaty w odpowiednim miejscu.

• Nie ujawniaj poufnych informacji na temat systemu ani informacji osobistych o użytkownikach. Wyczyść te informacje przed zarejestrowaniem, ale zachowaj odpowiednie szczegóły.

• Rejestruje wszystkie wyjątki krytyczne, ale umożliwia administratorowi włączanie i wyłączanie w razie potrzeby mniejszej liczby wyjątków i ostrzeżeń.

• Przechwyć i zarejestruj wszystkie informacje logiki ponawiania. Te dane są przydatne podczas monitorowania przejściowej kondycji systemu.

• Śledzenie wywołań procesów, takich jak żądania do zewnętrznych usług internetowych lub baz danych.

• Nie mieszaj komunikatów dziennika z różnymi wymaganiami dotyczącymi zabezpieczeń w tym samym pliku dziennika.

• Upewnij się, że wszystkie wywołania rejestrowania są operacjami fire-and-forget , które nie blokują postępu operacji biznesowych. Wyklucz zdarzenia inspekcji z tej reguły, ponieważ mają krytyczne znaczenie dla firmy.

• Upewnij się, że rejestrowanie jest rozszerzalne i nie ma żadnych bezpośrednich zależności od konkretnego celu.

• Upewnij się, że wszystkie rejestrowanie jest bezpieczne w trybie fail-safe i nie wyzwala błędów kaskadowych.

• Traktuj instrumentację jako ciągły proces iteracyjny i regularnie przeglądaj dzienniki.

Zagadnienia do rozważenia

• Zaimplementuj profilowanie tylko wtedy, gdy jest to konieczne, ponieważ może narzucić znaczne obciążenie systemu. Za pomocą instrumentacji profilowanie rejestruje zdarzenie, takie jak wywołanie metody, za każdym razem, gdy występuje. Próbkowanie rejestruje jednak tylko wybrane zdarzenia.

• Opcje profilowania mogą być oparte na czasie, na przykład raz na n sekund lub na podstawie częstotliwości, na przykład raz na n żądań. Jeśli zdarzenia występują często, profilowanie może spowodować zbyt duże obciążenie systemu i wpłynąć na ogólną wydajność. W takim przypadku preferowane jest podejście do próbkowania. Jednak jeśli częstotliwość zdarzeń jest niska, próbkowanie może je pominąć. W takim przypadku profilowanie może być lepszym rozwiązaniem.

Ułatwienia platformy Azure

Autoinstrumentacja jest dostępna dla wielu typów aplikacji platformy Azure i lokalnych monitorowanych za pomocą usługi Application Insights. Funkcja autoinstrumentacji automatycznie konfiguruje aplikację w celu zapewnienia rozbudowanych danych telemetrycznych w usłudze Application Insights i zapewnia łatwy dostęp do środowisk, takich jak pulpit nawigacyjny aplikacji i mapa aplikacji. Aby uzyskać informacje o obsługiwanych platformach hostingu i językach programowania, zobacz Obsługiwane środowiska, języki i dostawcy zasobów.

Linki pokrewne

• Omówienie usługi Application Insights
• Co to jest autoinstrumentacja usługi Application Insights?
• Omówienie dzienników usługi Azure Monitor
• Omówienie metryk usługi Azure Monitor
• Zbieranie zdarzeń ETW na potrzeby analizy dzienników usługi Azure Monitor
• Zalecenia dotyczące projektowania i tworzenia struktury obserwacji
• Co to jest korelacja śledzenia rozproszonego i telemetrii?

Linki społeczności

• OpenTelemetry

Lista kontrolna doskonałości operacyjnej

Zapoznaj się z pełnym zestawem zaleceń.