Modelowanie kondycji dla obciążeń

Aplikacje w chmurze generują duże ilości danych operacyjnych, co sprawia, że trudno jest szybko wskazać i rozwiązać problemy. Częstą przyczyną tego wyzwania jest brak punktu odniesienia kondycji dostosowanego do funkcjonalności obciążenia i brak możliwości wykrywania dryfu od tego punktu odniesienia.

Modelowanie kondycji to ćwiczenie z obserwacją, które łączy kontekst biznesowy z nieprzetworzonymi danymi monitorowania w celu określenia ogólnej kondycji obciążenia. Ułatwia to ustawienie planu bazowego, dla którego można monitorować obciążenie. Należy wziąć pod uwagę dane, takie jak dane telemetryczne ze składników infrastruktury i aplikacji. Modelowanie kondycji może również zawierać inne informacje niezbędne do osiągnięcia celów dotyczących jakości obciążenia.

Problemy z wydajnością lub obniżenie wydajności mogą spowodować dryf z oczekiwanego stanu operacyjnego. Modelując kondycję obciążenia, można zidentyfikować dryf i podejmować świadome decyzje operacyjne, które uwzględniają wpływ na działalność biznesową.

Modelowanie kondycji łączy różnicę między plemienną wiedzą operacyjną i praktycznymi szczegółowymi informacjami. Ułatwia efektywne zarządzanie problemami krytycznymi. Koncepcja jest niezbędna do zmaksymalizowania niezawodności i skuteczności operacyjnej.

Ten przewodnik zawiera praktyczne wskazówki dotyczące modelowania kondycji, w tym sposób tworzenia modelu, który ocenia kondycję środowiska uruchomieniowego obciążenia i wszystkich jego podsystemów.

Terminologia	Definicja
Modelowanie kondycji	Ćwiczenie dotyczące obserwacji, które używa kontekstu biznesowego do interpretowania danych monitorowania jako stanów kondycji.
Health model (Model kondycji)	Graficzna reprezentacja jednostek logicznych i ich relacji dla danego zakresu. Każdy węzeł ma definicję stanu kondycji, aby racjonalizować dane monitorowania w modelu.
Jednostka kondycji	Składnik logiczny reprezentujący pojedynczą jednostkę systemu, logiczną kombinację wielu powiązanych jednostek lub ogólny system.
Kondycja	Zdefiniowany i wymierny stan, który zapewnia znaczący wgląd operacyjny w kondycję jednostki.
Sygnał kondycji	Poszczególne strumienie danych, które zapewniają wgląd w zachowanie operacyjne jednostki.
Model modeli	Zagregowany zakres modelowania, w którym jednostki reprezentują odrębne modele kondycji dla systemów składowych.

Zalecamy obejrzenie tego filmu wideo, aby uzyskać ogólne informacje na temat modelowania kondycji.

Co to jest kondycja, modelowanie kondycji i model kondycji?

Termin kondycja odnosi się do stanu operacyjnego jednostki i jej zależności. Ta jednostka może być pojedynczą jednostką systemu, logiczną kombinacją wielu powiązanych jednostek lub ogólnego systemu.

Zalecamy reprezentowanie kondycji w jednym z trzech stanów:

• W dobrej kondycji: działa optymalnie i spełnia oczekiwania dotyczące jakości

• Obniżona wydajność: Wykazuje mniej niż zdrowe zachowanie, co wskazuje na potencjalne problemy

• W złej kondycji: w stanie krytycznym i wymaga natychmiastowej uwagi

Uwaga

Możesz reprezentować kondycję z wynikiem zamiast stanów, aby zapewnić większą stopień szczegółowości danych.

Stany kondycji są tworzone przez połączenie danych monitorowania z informacjami o domenie. Każdy stan musi być zdefiniowany i musi być wymierny. Stany kondycji są obliczane przy użyciu sygnałów kondycji, które są poszczególnymi strumieniami danych, które zapewniają wgląd w zachowanie operacyjne jednostki. Sygnały mogą obejmować metryki, dzienniki, ślady lub inne cechy jakości. Na przykład sygnał kondycji jednostki maszyny wirtualnej może śledzić metrykę wykorzystania procesora CPU. Inne sygnały dla tej jednostki mogą obejmować użycie pamięci, opóźnienie sieci lub współczynniki błędów.

Podczas definiowania sygnałów kondycji należy uwzględnić wymagania niefunkcjonalne dla obciążenia. W przykładzie wykorzystania procesora CPU uwzględnij oczekiwane progi dla każdego stanu kondycji. Jeśli użycie przekroczy tolerowany próg zgodnie z wymaganiami dotyczącymi obciążenia, system przechodzi ze dobrej kondycji na obniżoną lub złą kondycję. Te zmiany stanu wyzwalają odpowiednie alerty lub akcje.

Modelowanie kondycji wymaga, aby jednostki miały dobrze zdefiniowane stany pochodzące z wielu sygnałów kondycji i są kontekstowe dla obciążenia. Na przykład definicja kondycji maszyny wirtualnej może być następująca:

• W dobrej kondycji: kluczowe wymagania i cele niefunkcjonalne, takie jak czas odpowiedzi, wykorzystanie zasobów i ogólna wydajność systemu, są w pełni spełnione. Na przykład 95% żądań jest przetwarzanych w ciągu 500 milisekund. Obciążenie korzysta z zasobów maszyn wirtualnych, takich jak procesor CPU, pamięć i magazyn, optymalnie i utrzymuje równowagę między zapotrzebowaniem na obciążenia i dostępną pojemnością. Środowisko użytkownika jest na oczekiwanych poziomach.

• Obniżona wydajność: Zasoby nie działają optymalnie, ale nadal działają. Na przykład na dysku magazynu występują problemy z ograniczaniem przepustowości. Użytkownicy mogą doświadczać powolnych odpowiedzi.

• W złej kondycji: degradacja wykracza poza tolerowane limity. Zasoby nie są już dynamiczne ani dostępne, a system nie spełnia już akceptowalnych poziomów wydajności. Środowisko użytkownika jest poważnie dotknięte.

Wynikiem modelowania kondycji jest model lub graficzna reprezentacja jednostek logicznych i ich relacji dla architektury obciążenia. Każdy węzeł ma definicję stanu kondycji.

Ważne

Modelowanie kondycji to abstrakcyjna koncepcja, którą można zaimplementować i zastosować w różnych zakresach, jeśli dobrze rozumiesz scenariusze biznesowe.

Na obrazie:

• Jednostki są logicznymi składnikami obciążenia, które reprezentują aspekty systemu. Mogą to być składniki infrastruktury, takie jak serwery, bazy danych i sieci. Mogą one być również konkretnymi modułami aplikacji, zasobnikami, usługami lub mikrousługami. Jednostki mogą również przechwytywać interakcje użytkowników i przepływy systemowe w ramach obciążenia.

  Uwaga

  Przepływy użytkowników i systemów zawierają podsumowanie niefunkcjonalnych wymagań w scenariuszach biznesowych obejmujących składniki aplikacji i infrastruktury. To podsumowanie odzwierciedla wartość biznesową aplikacji.

• Relacje między jednostkami odzwierciedlają łańcuchy zależności w systemie. Na przykład moduł aplikacji może wywoływać określone składniki infrastruktury, które tworzą relację.

Rozważmy scenariusz, w którym obciążenie handlu elektronicznego powoduje wzrost liczby komunikatów o niepomyślnych błędach w kolejce usługi Azure Service Bus, co powoduje niepowodzenie płatności. Ten problem ma kluczowe znaczenie dla organizacji ze względu na domniemaną utratę przychodów. Chociaż deweloper aplikacji może zrozumieć wpływ tego skoku metryk na płatności, ta wiedza plemienna nie jest często udostępniana przez zespół operacyjny.

Model kondycji może dać operatorom natychmiastowy wgląd w problem i jego skutki. Przepływ płatności zależy od usługi Service Bus, która jest jednym ze składników obciążenia. Wizualizacja przedstawia obniżony stan wystąpienia usługi Service Bus i jego wpływ na przepływ płatności. Operatorzy mogą zrozumieć znaczenie problemu i skupić swoje wysiłki naprawcze na tym konkretnym składniku.

Modelowanie kondycji było ważne w poprzednim scenariuszu w następujący sposób:

• Skrócił czas wykrywania (TTD) i czasu w celu wyeliminowania problemu (TTM), umożliwiając szybszą izolację problemów, co doprowadziło do szybszego wykrywania problemów i potencjalnych poprawek.

• Operatorzy otrzymywali alerty na podstawie stanów kondycji, co zmniejszało niepotrzebne szumy. Operatorzy otrzymali powiadomienia, które dostarczyły określonego kontekstu dotyczącego wpływu działalności na płatności.

• Łańcuchy zależności pomogły operatorom w pełni zrozumieć zakres problemów operacyjnych. Ta wiedza przyspieszyła oceny wpływu i doprowadziła do priorytetowych odpowiedzi. Operatory można również łatwo zidentyfikować kaskadowo lub skorelowane problemy.

• Operatorzy przeprowadzili działania po zdarzeniu z dokładnością, ponieważ model kondycji dostarczył wgląd w główne przyczyny anomalii i określone sygnały kondycji, które były zaangażowane.

• Dane monitorowania są istotne dla wszystkich członków zespołu. To wypełnić lukę między plemienną wiedzą i udostępnionymi szczegółowymi informacjami.

• Organizacja użyła modelu kondycji jako punktu odniesienia dla przyszłych inwestycji w operacje oparte na sztucznej inteligencji w celu uzyskania inteligentnych szczegółowych informacji.

Schemat modelu kondycji

Modele kondycji zapewniają odrębny schemat danych zoptymalizowany pod kątem przypadków użycia możliwości obserwacji. Ten schemat przyjmuje modelowanie kondycji z koncepcji abstrakcyjnej do mierzalnego rozwiązania. Modelując określone wymagania, cele i kontekst architektury, możesz dostosować dane kondycji do unikatowego scenariusza.

Kondycja to względna koncepcja danych. Każdy model reprezentuje dane dotyczące kondycji, które są unikatowe i priorytetowe dla jego zakresu kontekstowego, nawet jeśli używa tego samego zestawu jednostek. To, co stanowi dobrą kondycję w konkretnym scenariuszu, może się znacznie różnić w innych kontekstach.

Rozważmy na przykład zasoby platformy Azure tego samego typu w ramach obciążenia.

• Maszyna wirtualna A uruchamia aplikację wrażliwą na procesor CPU.
• Maszyna wirtualna B obsługuje usługę intensywnie korzystającą z pamięci.

Definicje kondycji tych maszyn są różne. Metryki wykorzystania procesora CPU prawdopodobnie wpływają na stan kondycji maszyny wirtualnej A, a maszyna wirtualna B może określać priorytety metryk związanych z pamięcią.

Ważne

Model kondycji nie powinien traktować wszystkich błędów tak samo. Powinno to wyraźnie odróżnić oczekiwane lub przejściowe, ale możliwe do odzyskania awarie i prawdziwy stan awarii.

Tworzenie modelu kondycji

Pierwszym krokiem do utworzenia modelu kondycji jest logiczne ćwiczenie projektowe, które zwykle obejmuje działania opisane w poniższych sekcjach.

Ocena projektu obciążenia

Rozpocznij to ćwiczenie dotyczące projektowania logicznego, oceniając następujące składniki projektu obciążenia.

• Składniki infrastruktury, takie jak klastry obliczeniowe i bazy danych

• Składniki aplikacji uruchamiane na obliczeniach i ich odpowiednich składnikach

• Zależności logiczne lub fizyczne między składnikami

• Przepływy użytkownika i systemu

Na przykład model kondycji aplikacji handlu elektronicznego powinien reprezentować bieżący stan krytycznych procesów, takich jak logowanie użytkownika, wyewidencjonowanie i płatności.

Kontekst przy użyciu wymagań biznesowych

Oceń względne znaczenie i ogólny wpływ każdego przepływu na organizację. Rozważ czynniki, takie jak środowisko użytkownika, bezpieczeństwo i wydajność operacyjna. Na przykład w większości scenariuszy niepowodzenie procesu płatności jest prawdopodobnie bardziej znaczące niż niepowodzenie procesu raportowania.

Identyfikowanie ścieżek eskalacji do obsługi problemów związanych z każdym przepływem. Aby uzyskać więcej informacji, zobacz Optymalizowanie projektowania obciążeń przy użyciu przepływów.

Uwaga

Wartość modelowania kondycji jest uwzględniana tylko wtedy, gdy uwzględniasz scenariusze biznesowe i kontekst. Następnie można racjonalizować wpływ biznesowy na problemy operacyjne.

Mapuj na metryki niezawodności

Poszukaj odpowiednich metryk niezawodności w projekcie aplikacji.

Rozważ zdefiniowanie wskaźników poziomu usług (SLI) i celów poziomu usług (SLO) dla całej aplikacji i jej poszczególnych procesów biznesowych. Te wskaźniki SLA i cele SLO powinny być zgodne z określonymi sygnałami kondycji rozważanymi dla modelu kondycji. W ten sposób tworzysz kompleksową definicję kondycji, która dokładnie odzwierciedla osiągnięcie akceptowalnego poziomu usług dla aplikacji.

Ważne

Wskaźniki SLI i cele SLO są krytycznymi sygnałami kondycji. Tworzą one zrozumiałą definicję kondycji, która odzwierciedla odpowiedni poziom usługi wraz z innymi atrybutami jakości. Można również zdefiniować cele kondycji usługi (SHO), aby przechwycić kondycję, która ma zostać osiągnięta w zagregowanym zakresie czasu.

Identyfikowanie sygnałów kondycji

Aby utworzyć kompleksowy model kondycji, skoreluj różne typy danych monitorowania, w tym metryki, dzienniki i ślady. Dzięki temu należy upewnić się, że koncepcja kondycji dokładnie odzwierciedla stan środowiska uruchomieniowego określonej jednostki lub całego obciążenia.

Korzystanie z metryk i dzienników platformy

W kontekście modelowania kondycji niezbędne jest zebranie metryk i dzienników na poziomie platformy z bazowych zasobów platformy Azure. Te metryki obejmują procent procesora CPU, sieć i wyjście sieci oraz operacje dysku na sekundę. Te dane w modelu kondycji umożliwiają wykrywanie i przewidywanie potencjalnych problemów przy zachowaniu niezawodnego środowiska.

Ponadto takie podejście ułatwia odróżnienie błędów przejściowych lub tymczasowych zakłóceń oraz nietransientnych błędów lub trwałych problemów.

Uwaga

Najlepszym rozwiązaniem jest skonfigurowanie wszystkich zasobów aplikacji w celu kierowania dzienników diagnostycznych i metryk do wybranej technologii agregacji dzienników. Twórz zabezpieczenia przy użyciu usługi Azure Policy , aby zapewnić spójne ustawienia diagnostyczne w aplikacji i wymusić wybraną konfigurację dla każdej usługi platformy Azure.

Dodawanie dzienników aplikacji

Dzienniki aplikacji są ważnym źródłem danych diagnostycznych dla modelu kondycji. Oto kilka najlepszych rozwiązań dotyczących rejestrowania aplikacji:

• Użyj rejestrowania semantycznego lub strukturalnego. Dzienniki ustrukturyzowane ułatwiają automatyczne użycie i analizę danych dzienników na dużą skalę.

  Rozważ przechowywanie metryk zasobów platformy Azure i danych diagnostycznych w obszarze roboczym Dzienniki usługi Azure Monitor zamiast konta magazynu. Za pomocą tej metody można tworzyć sygnały kondycji przy użyciu zapytań Kusto w celu wydajnej oceny.

• Rejestrowanie danych w środowisku produkcyjnym. Przechwyć kompleksowe dane, gdy aplikacja działa w środowisku produkcyjnym. Wystarczające informacje są niezbędne do oceny kondycji i diagnozowania wykrytych problemów produkcyjnych.

• Rejestrowanie zdarzeń na granicach usługi. Dołącz identyfikator korelacji, który przechodzi przez granice usługi. Jeśli transakcja obejmuje wiele usług i jeden z nich zakończy się niepowodzeniem, identyfikator korelacji pomaga śledzić żądania w całej aplikacji i wskazać przyczynę awarii.

• Użyj rejestrowania asynchronicznego. Unikaj synchronicznych operacji rejestrowania, które mogą blokować kod aplikacji. Rejestrowanie asynchroniczne zapewnia dostępność, uniemożliwiając rejestrowanie żądań podczas zapisywania dzienników.

• Odseparuj rejestrowanie aplikacji od inspekcji. Zachowaj dzienniki inspekcji oddzielnie od dzienników diagnostycznych. Mimo że rekordy inspekcji spełniają wymagania dotyczące zgodności lub przepisów, zachowanie ich odrębnych elementów zapobiega porzucaniu transakcji.

Implementowanie śledzenia rozproszonego

Zaimplementuj śledzenie rozproszone, korelując dane telemetryczne między krytycznymi przepływami systemu. Skorelowane dane telemetryczne zapewniają wgląd w kompleksowe transakcje i są niezbędne do efektywnej analizy głównej przyczyny w przypadku wystąpienia awarii.

Korzystanie z sond kondycji

Zaimplementuj i uruchom sondy kondycji poza aplikacją, aby jawnie sprawdzić kondycję i czas odpowiedzi aplikacji. Użyj odpowiedzi sondy jako sygnałów w modelu kondycji.

Sondy kondycji można zaimplementować, mierząc czas odpowiedzi z aplikacji jako całości lub z poszczególnych składników. Sondy mogą uruchamiać procesy w celu mierzenia opóźnienia i sprawdzania dostępności lub wyodrębniania informacji z aplikacji. Aby uzyskać więcej informacji, zobacz Wzorzec monitorowania punktu końcowego kondycji.

Większość modułów równoważenia obciążenia obsługuje uruchamianie sond kondycji, które wysyłają polecenia ping do punktów końcowych aplikacji w skonfigurowanych odstępach czasu. Alternatywnie możesz użyć zewnętrznej usługi watchdog. Usługa watchdog agreguje kontrole kondycji z wielu składników w obciążeniu. Watchdogs może również hostować kod, który wykonuje natychmiastowe korygowanie znanych warunków zdrowotnych.

Wdrażanie technik monitorowania strukturalnego i funkcjonalnego

Monitorowanie strukturalne obejmuje wyposażenie aplikacji w semantyczne dzienniki i metryki. Aplikacja bezpośrednio zbiera te metryki, w tym bieżące zużycie pamięci, opóźnienie żądań i inne istotne dane na poziomie aplikacji.

Wzmacnianie procesów monitorowania przy użyciu monitorowania funkcjonalnego. Takie podejście koncentruje się na mierzeniu usług platformy i ich wpływu na ogólne środowisko użytkownika. W przeciwieństwie do monitorowania strukturalnego monitorowanie funkcjonalne nie wymaga szczegółowej wiedzy na temat systemu. Testuje zewnętrznie widoczne zachowanie aplikacji. Takie podejście jest przydatne do oceny celów SLO i SLI.

Modelowanie projektu

Reprezentuje zidentyfikowany projekt aplikacji jako jednostki i relacje. Mapowanie sygnałów kondycji na określone składniki w celu kwantyfikacji stanów kondycji na poziomie jednostki. Rozważ krytyczne znaczenie składników, aby określić sposób propagowania stanów kondycji za pomocą modelu. Na przykład składniki raportowania mogą nie być tak krytyczne, jak inne składniki, co powoduje różne skutki ogólnej kondycji obciążenia.

Ustawianie alertów z możliwością działania

Użyj ocenianych stanów kondycji, aby wyzwolić alerty i zautomatyzowaną akcję. Kondycja powinna być zintegrowana w istniejących elementach Runbook operacyjnych jako podstawowy zestaw danych do obserwacji.

Zazwyczaj istnieje mapowanie "jeden do jednego" między danymi monitorowania i regułami alertów, co może prowadzić do niepożądanych wyników, takich jak burze alertów i szum alertów otoczenia. Na przykład w klastrze obliczeniowym duże ilości alertów na poziomie maszyny wirtualnej oparte na wykorzystaniu procesora CPU i liczbie błędów mogą przeciążać operatory podczas awarii i powodować opóźnienia w rozwiązywaniu problemów. Podobnie, gdy istnieje duża liczba skonfigurowanych alertów, szum alertu otoczenia często powoduje pomijanie lub ignorowanie alertów.

Model kondycji wprowadza separację między danymi monitorowania i regułami alertów. Definicja kondycji agreguje wiele sygnałów w jeden stan kondycji, co zmniejsza liczbę alertów, dzięki czemu operatorzy mogą skupić się wyłącznie na alertach o wysokiej wartości, które mają krytyczne znaczenie dla organizacji. Rozważmy scenariusz handlu elektronicznego. Alert można skonfigurować do wysyłania powiadomień o zmianach w kondycji przepływu płatności procesów zamiast zmian w zasobach bazowych, takich jak kolejka usługi Service Bus.

Uwaga

Możliwość zgłaszania alertów we wszystkich warstwach modelu kondycji zapewnia elastyczność dla różnych osób obciążeń. Właściciele aplikacji i menedżerowie produktów mogą otrzymywać alerty o zmianach stanu kondycji w kluczowych scenariuszach biznesowych lub w całym obciążeniu. Operatory mogą być powiadamiane na podstawie kondycji składników infrastruktury lub aplikacji.

Wizualizacja modelu

Utwórz reprezentacje wizualne, takie jak tabele lub grafy, aby skutecznie przekazać bieżący stan i historię modelu kondycji. Upewnij się, że wizualizacja jest zgodna z kontekstem biznesowym i zapewnia szczegółowe informacje umożliwiające podejmowanie działań.

Podczas wizualizowania modelu kondycji rozważ wdrożenie podejścia do światła drogowego, aby stany kondycji były natychmiast wgląd w łańcuchy zależności.

Przypisz zielony dla zdrowej kondycji, bursztyn dla obniżonej wydajności i czerwony dla złej kondycji. Dzięki szybkiej identyfikacji stanów kodowanych kolorami można efektywnie zlokalizować główną przyczynę dowolnego pogorszenia aplikacji.

Uwaga

Zalecamy rozważenie wymagań dotyczących ułatwień dostępu dla osób, które mają niepełnosprawność wzroku podczas tworzenia pulpitu nawigacyjnego dla modelu kondycji. Aby uzyskać najlepsze rozwiązania dotyczące diagramów, zobacz Diagramy projektowania architektury.

Wdrażanie modelu kondycji

Po utworzeniu modelu kondycji rozważ następujące przypadki użycia, aby zwiększyć wykrywanie i interpretację błędów lub problemów operacyjnych.

Zastosowanie do różnych ról

Modelowanie kondycji może dostarczać informacje specyficzne dla funkcji zadań lub ról w tym samym kontekście obciążenia. Na przykład rola DevOps może wymagać informacji o kondycji operacyjnej. Oficer bezpieczeństwa może być bardziej zaniepokojony sygnałami włamań i narażeniem na bezpieczeństwo. Administrator bazy danych prawdopodobnie interesuje tylko podzbiór modelu aplikacji za pośrednictwem zasobów bazy danych.

Dostosowywanie szczegółowych informacji o kondycji dla różnych uczestników projektu. Rozważ utworzenie oddzielnych modeli od nakładających się zestawów danych.

Ciągła walidacja

Użyj modelu kondycji, aby zoptymalizować procesy testowania i walidacji, takie jak testowanie obciążenia i testowanie chaosu. Stan operacyjny środowiska uruchomieniowego można zweryfikować podczas testowania i oceny skuteczności modelu w scenariuszach skalowania i awarii, włączając modele kondycji do cyklu życia inżynieryjnego.

Kondycja organizacji

Chociaż modelowanie kondycji jest często związane z kwantyfikacją stanów kondycji dla poszczególnych aplikacji, jej zastosowanie wykracza poza ten zakres.

Na poziomie poszczególnych obciążeń modele kondycji stanowią podstawę do obserwowania aplikacji i szczegółowych informacji operacyjnych. Każda aplikacja może mieć własny model kondycji, który przechwytuje, co oznacza każdy stan kondycji w kontekście.

Można połączyć wiele modeli kondycji w konstrukcję wysokiego poziomu, tworząc model modeli. Można na przykład utworzyć zauważalny ślad jednostki biznesowej lub całej infrastruktury w chmurze przy użyciu modeli kondycji jako składników w ramach większego modelu. Modele kondycji reprezentują obciążenia w obrębie majątku jako węzły na wykresie najwyższego poziomu. Relacje w tym modelu umożliwiają przechwytywanie zależności między aplikacjami, w tym przepływów danych, interakcji z usługą i udostępnionej infrastruktury.

Rozważmy firmę handlu detalicznego, która ma różne aplikacje do handlu elektronicznego, płatności i przetwarzania zamówień. Każdą z tych aplikacji można zdefiniować jako niezależny model kondycji, aby określić, co oznacza kondycja tego obciążenia. Następnie można użyć modelu nadrzędnego, aby zamapować wszystkie te modele kondycji składników jako jednostki i przechwycić wpływ operacyjny między aplikacjami za pośrednictwem łańcuchów zależności. Na przykład jeśli aplikacja do handlu elektronicznego stanie się w złej kondycji, ma ona wpływ kaskadowy na aplikację płatności.

Trendy kondycji i sztuczna inteligencja dla operacji IT

Modelowanie kondycji zapewnia kwantyfikowany plan bazowy operacyjny dostosowany do określonego kontekstu biznesowego. Sztuczna inteligencja dla operacji IT (AIOps) to popularny sposób zwiększania wydajności operacyjnej. Dane dotyczące kondycji to podstawowe dane wejściowe dla modeli uczenia maszynowego w celu analizowania trendów kondycji. Na przykład modele uczenia maszynowego mogą:

• Wyodrębnij więcej szczegółowych informacji ze zmian stanu i zalecamy akcje.

• Analizowanie trendów kondycji w czasie w celu podsumuj przewidywanie problemów i uściślenie modelu.

Obsługa modelu kondycji

Utrzymywanie modelu ciepła to ciągłe działanie inżynieryjne, które jest zgodne z programowaniem i operacjami aplikacji. W miarę rozwoju aplikacji upewnij się, że model kondycji ewoluuje równolegle.

Ponadto należy traktować modele kondycji, takie jak artefakty obciążenia, które powinny być zintegrowane z cyklem życia programowania. Wdrażanie infrastruktury jako kodu (IaC) w celu spójnego, kontrolowanego przez wersję zarządzania modelem kondycji. Użyj automatyzacji, aby model był aktualny podczas dodawania lub usuwania składników infrastruktury i aplikacji z obciążenia.

Dane dotyczące kondycji stopniowo zmniejszają się w miarę upływu czasu. Aby zoptymalizować wydajność operacyjną i zminimalizować koszty, należy unikać przechowywania danych dotyczących kondycji poza 30 dni. W razie potrzeby można zarchiwizować dane w celu spełnienia wymagań inspekcji lub w scenariuszach obejmujących długoterminową analizę wzorców w sztucznej inteligencji na potrzeby operacji IT.

Uwaga

Podczas archiwizowania danych kondycji upewnij się, że połączysz je ze stanem konfiguracji modelu. Interpretowanie zmian stanu może być trudne bez tego kontekstu.

Pokrewne łącza

• Aby zaimplementować sondy kondycji w ASP.NET, zobacz Kontrole kondycji w usłudze ASP.NET Core.
• Aby uzyskać informacje na temat metryk monitorowania, zobacz Omówienie metryk usługi Azure Monitor.
• Aby uzyskać informacje na temat korzystania z usługi Application Insights, zobacz Application Insights.
• Aby zapoznać się z zagadnieniami i zaleceniami dotyczącymi obciążeń o znaczeniu krytycznym, zobacz Modelowanie kondycji i możliwość obserwowania obciążeń o znaczeniu krytycznym na platformie Azure.
• Aby zapoznać się z praktycznym środowiskiem, zobacz Projektowanie modelu kondycji dla obciążenia o krytycznym znaczeniu.

Następny krok

Zalecenia dotyczące projektowania niezawodnej strategii monitorowania i zgłaszania alertów