Zalecenia dotyczące instrumentowania aplikacji
Dotyczy tego zalecenia z listy kontrolnej dotyczącej doskonałości operacyjnej platformy Azure Well-Architected Framework:
OE:07 | Projektowanie i implementowanie systemu monitorowania w celu weryfikowania wyborów projektowych i informowania o przyszłych decyzjach projektowych i biznesowych. Ten system przechwytuje i uwidacznia operacyjne dane telemetryczne, metryki i dzienniki emitujące dane z infrastruktury i kodu obciążenia. |
---|
Przewodnik pokrewny: 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.
Uwaga
Aby automatycznie instrumentować aplikację, możesz użyć narzędzi takich jak Application Insights, Dynatrace i Elastic Application monitor wydajności. Te narzędzia ułatwiają instrumentację, ale mogą również ograniczać. Jeśli używasz narzędzia do instrumentacji automatycznej, możesz w razie potrzeby dodać więcej możliwości za pomocą instrumentacji ręcznej.
Używanie dzienników strukturalnych i ś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 marnować 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 funkcji śledzenia zdarzeń dla systemu Windows (ETW). Dzienniki systemowe generują zawartość dziennika śledzenia ze zdarzeń w infrastrukturze, takich jak serwer internetowy. Zawartość dziennika tekstowego została zaprojektowana tak, aby była czytelna dla ludzi, ale należy upewnić się, że jest ona zapisywana w formacie, który może być również analizowany przez zautomatyzowany system.
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, które mają inne wymagania dotyczące zabezpieczeń, takie jak informacje inspekcji i dane debugowania, do tego samego dziennika.
Uwaga
Dziennik może zostać zaimplementowany jako plik w systemie plików lub może być przechowywany w innym formacie, takim jak obiekt blob w magazynie obiektów blob. Informacje dziennika mogą być również przechowywane w magazynie ustrukturyzowanym, takim jak wiersze w tabeli.
Przechwytywanie metryk aplikacji
Metryki lub przykłady są liczbą 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 znaczącego zdarzenia. Odpowiednia częstotliwość przechwytywania danych może się różnić w zależności 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 ono spójne w ciągu wielu minut.
Ułatwianie korelacji między składnikami
Można łatwo monitorować poszczególne i systemowe liczniki wydajności, przechwytywać metryki zasobów i uzyskiwać informacje o śledzonej aplikacji z różnych plików dziennika. Niektóre monitorowanie wymaga korelacji danych podczas etapu analizy i diagnostyki w potoku monitorowania. Te dane mogą mieć kilka form, a proces analizy musi być dostarczany z wystarczającą ilością danych instrumentacji, aby zamapować te różne formularze. Na przykład na poziomie platformy aplikacji identyfikator wątku może identyfikować 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 mapa 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ć sprawy, 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.
Uwaga
Komputery działające w różnych strefach czasowych i sieciach mogą nie być synchronizowane. Nie należy zależeć od samych sygnatur czasowych w celu korelowania danych instrumentacji obejmujących wiele maszyn.
Przechwytywanie odpowiednich danych
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 personelu ds. operacji i inżynierów 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 wykonaną 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ą być również 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 złej 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, aby wdrożyć różne części systemu.
Zbierz dane, takie jak wolumin wejściowy/wyjściowy, liczba żądań i pamięć, 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ż zależności zewnętrzne
Rejestruje wszystkie wywołania usługi zewnętrznej. Wywołania zewnętrzne mogą być wykonywane do:
- Systemy baz danych.
- Usługi sieci Web.
- Inne usługi na poziomie systemu, które są częścią infrastruktury.
Rejestruj 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 zwykle niezależny od dowolnej konkretnej aplikacji lub technologii.
Systemy telemetryczne używają zdefiniowanych schematów do analizowania informacji. Schemat określa kontrakt, który definiuje pola danych i typy, które system telemetrii może pozyskiwać. Uogólnij schemat, aby umożliwić pobieranie danych z różnych platform i urządzeń. Wspólny 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
- Application ID
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ć dystrybucję roamingu lub między urządzeniami. Schemat może również zawierać odpowiednie pola domeny dla określonego scenariusza, który jest wspólny 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 generują ten sam zestaw zdarzeń, aby utworzyć zestaw typowych raportów i analiz w aplikacjach. Może być konieczne skonfigurowanie schematu zawierającego pola niestandardowe służące do przechwytywania szczegółów zdarzeń specyficznych dla aplikacji.
OpenTelemetry to neutralna dla 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 typu open source i komercyjnymi. Firma Microsoft wdraża platformę OpenTelemetry jako standardowe narzędzie do instrumentacji.
Optymalizowanie kodu instrumentacji
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 znaczniku czasu, gdy każdy rekord dziennika jest zapisywany.
Użyj tej samej strefy czasowej i formatu dla wszystkich sygnatur czasowych.
Kategoryzuj dzienniki i zapisuj komunikaty w odpowiednim miejscu.
Nie ujawniaj poufnych informacji o systemie ani danych osobowych użytkowników. Wyczyść te informacje przed jego zarejestrowaniem, ale zachowaj wszelkie istotne szczegóły.
Rejestruj 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 wyzwalania i zapominania , 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.
Korzystanie z profilowania aplikacji
Zaimplementuj profilowanie tylko wtedy, gdy jest to konieczne, ponieważ może narzucić znaczne obciążenie systemu. Przy użyciu instrumentacji profilowanie rejestruje zdarzenie, takie jak wywołanie metody, za każdym razem, gdy wystąpi. Jednak próbkowanie rejestruje tylko wybrane zdarzenia.
Wybór profilowania może być oparty 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
Automatycznainstrumentacja 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.
Pokrewne łącza
- 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 rozproszone śledzenie i korelacja telemetrii?
Linki społecznościowe
Lista kontrolna doskonałości operacyjnej
Zapoznaj się z pełnym zestawem zaleceń.