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 ona 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ć odchylenie od 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 lukę między wiedzą operacyjną plemienną a praktycznymi szczegółowymi informacjami. Ułatwia efektywne zarządzanie problemami krytycznymi. Koncepcja jest niezbędna do maksymalizacji 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 w celu racjonalizacji danych monitorowania w modelu.
Jednostka kondycji	Składnik logiczny reprezentujący pojedynczą jednostkę systemu, logiczne połączenie wielu powiązanych jednostek lub ogólny system.
Stan kondycji	Zdefiniowany i mierzalny 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ładników.

Zalecamy watch tym filmie 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:

• Dobra kondycja: 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ą uzyskiwane 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 z "W dobrej kondycji" na Obniżona lub Zła kondycja. 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ążenie 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.

• Zła kondycja: degradacja wykracza poza tolerowane limity. Zasoby nie są już dynamiczne ani dostępne, a system nie spełnia już akceptowalnych poziomów wydajności. Poważnie wpływa to na środowisko użytkownika.

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 również być 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 wymagań niefunkcjonalnych 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 błędach w kolejce Azure Service Bus, co powoduje niepowodzenie płatności. Ten problem ma krytyczne znaczenie dla organizacji ze względu na domniemaną utratę przychodów. Chociaż deweloper aplikacji może zrozumieć wpływ tego wzrostu metryki 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. Reprezentacja wizualna ujawnia 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 korygujące na tym konkretnym składniku.

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

• Skróciło to czas wykrywania (TTD) i czasu ograniczenia (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 niepotrzebne szumy. Operatorzy otrzymali powiadomienia, które dostarczyły konkretnego kontekstu 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 zapewniał wgląd w główne przyczyny anomalii i konkretne sygnały kondycji, które były zaangażowane.

• Dane monitorowania mają znaczenie dla wszystkich członków zespołu. Wypełniła ona lukę między wiedzą plemienną a wspólnymi szczegółowymi informacjami.

• Organizacja wykorzystała model kondycji jako punkt 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 pobiera modelowanie kondycji od abstrakcyjnej koncepcji do mierzalnego rozwiązania. Modelując określone wymagania, cele i kontekst architektury, można dostosować dane kondycji do unikatowego scenariusza.

Kondycja to względna koncepcja danych. Każdy model reprezentuje dane 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 obciążeniu.

• 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 awarii tak samo. Powinno to wyraźnie rozróżniać 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.

Kontekstowe używanie 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 na potrzeby obsługi problemów związanych z każdym przepływem. Aby uzyskać więcej informacji, zobacz Optymalizowanie projektu obciążenia przy użyciu przepływów.

Uwaga

Należy pamiętać o wartości modelowania kondycji tylko wtedy, gdy uwzględniasz scenariusze biznesowe i kontekst. Następnie można zracjonalizować 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 umowy SLA i cele SLA powinny być zgodne z określonymi sygnałami kondycji branymi pod uwagę 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 slo są krytycznymi sygnałami kondycji. Tworzą one zrozumiałą definicję kondycji, która odzwierciedla poziom usług, które chcesz obsługiwać wraz z innymi atrybutami jakości. Można również zdefiniować cele kondycji usługi (SHOs), aby przechwycić kondycję, którą chcesz osiągnąć 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ą wartość procentową procesora CPU, sieć w sieci oraz operacje na dysku na sekundę. Te dane w modelu kondycji umożliwiają wykrywanie i przewidywanie potencjalnych problemów przy zachowaniu niezawodnego środowiska.

Ponadto takie podejście pomaga rozróżniać błędy przejściowe lub tymczasowe zakłócenia oraz nieprzejrzałe błędy lub trwałe problemy.

Uwaga

Najlepszym rozwiązaniem jest skonfigurowanie wszystkich zasobów aplikacji w celu kierowania dzienników diagnostycznych i metryk do wybranej technologii agregacji dzienników. Skompiluj zabezpieczenia przy użyciu 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. Poniżej przedstawiono kilka najlepszych rozwiązań dotyczących rejestrowania aplikacji:

• Użyj semantycznego lub ustrukturyzowanego rejestrowania. 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 dzienników 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.

• Oddzielenie rejestrowania aplikacji od inspekcji. Zachowaj dzienniki inspekcji niezależnie od dzienników diagnostycznych. Mimo że rekordy inspekcji obsługują wymagania dotyczące zgodności lub przepisów, zachowanie ich odrębnych uniemożliwia porzucanie transakcji.

Implementowanie śledzenia rozproszonego

Implementowanie śledzenia rozproszonego przez korelowanie danych telemetrycznych 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 interwałach. Alternatywnie można 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 dzienniki semantyczne 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ływie na ogólne środowisko użytkownika. W przeciwieństwie do monitorowania strukturalnego monitorowanie funkcjonalne nie wymaga szczegółowej wiedzy o systemie. Testuje zewnętrzne zachowanie aplikacji. Takie podejście jest przydatne do oceny umów SLA 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 propagacji stanów kondycji za pośrednictwem modelu. Na przykład składniki raportowania mogą nie być tak krytyczne jak inne składniki, co skutkuje różnymi skutkami ogólnej kondycji obciążenia.

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

Użyj ocenianych stanów kondycji, aby wyzwolić alerty i akcję zautomatyzowaną. Kondycja powinna być zintegrowana z istniejącymi operacyjnymi elementami Runbook jako podstawowym zestawem danych do obserwacji.

Zazwyczaj istnieje mapowanie "jeden do jednego" między danymi monitorowania i regułami alertów, które mogą 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ązaniu. 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 są krytyczne dla organizacji. Rozważmy scenariusz handlu elektronicznego. Alert można skonfigurować w celu 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ć alertowane 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 należy rozważyć wdrożenie podejścia do sygnalizacji świetlnej w celu natychmiastowego wglądu stanów kondycji w łańcuchy zależności.

Przypisz zielony dla zdrowego, bursztynowego dla obniżonej kondycji i czerwonego w złej kondycji. Dzięki szybkiej identyfikacji stanów kodowanych kolorami można efektywnie zlokalizować główną przyczynę degradacji aplikacji.

Uwaga

Zalecamy uwzględnienie 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 projektowe architektury.

Wdrażanie modelu kondycji

Po utworzeniu modelu kondycji należy wziąć pod uwagę następujące przypadki użycia w celu wykrywania i interpretacji błędów lub problemów operacyjnych.

Stosowanie 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łamania i narażeniem na bezpieczeństwo. Administrator bazy danych prawdopodobnie interesuje tylko podzestaw 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 kojarzone z kwantyfikacją stanów kondycji dla poszczególnych aplikacji, jego zastosowanie wykracza poza ten zakres.

Na poziomie indywidualnego obciążenia modele kondycji stanowią podstawę do obserwacji 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 swoim 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 chmurowej przy użyciu modeli kondycji jako składników w większym modelu. Modele kondycji reprezentują obciążenia w obrębie majątku jako węzły na wykresie najwyższego poziomu. Użyj relacji w tym modelu, aby przechwycić zależności między aplikacjami, w tym przepływy danych, interakcje z usługą i udostępnioną infrastrukturę.

Rozważ firmę detaliczną, która ma różne aplikacje do handlu elektronicznego, płatności i przetwarzania zamówień. Każdy 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 handlu elektronicznego stanie się w złej kondycji, ma ona kaskadowy wpływ 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 zalecane akcje.

• Analizowanie trendów kondycji w czasie w celu napędzania przewidywania problemów i uściślenia modelu.

Utrzymywanie modelu kondycji

Utrzymywanie modelu heath 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 rozwija się równolegle.

Ponadto należy traktować modele kondycji, takie jak artefakty obciążeń, 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 maleją w wartości w czasie. 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 jest ona połączona ze stanem konfiguracji modelu. Interpretowanie zmian stanu może być trudne bez tego kontekstu.

Linki pokrewne

• Aby zaimplementować sondy kondycji w ASP.NET, zobacz Sprawdzanie kondycji w 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ść obserwacji 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