Modelowanie kondycji i obserwowanie obciążeń o znaczeniu krytycznym na platformie Azure

Modelowanie kondycji i możliwość obserwacji to podstawowe pojęcia mające na celu zmaksymalizowanie niezawodności, która koncentruje się na niezawodnej i kontekstowej instrumentacji i monitorowaniu. Te pojęcia zapewniają krytyczny wgląd w kondycję aplikacji, promowanie szybkiej identyfikacji i rozwiązywania problemów.

Większość aplikacji o krytycznym znaczeniu ma znaczenie zarówno pod względem skali, jak i złożoności, a zatem generuje duże ilości danych operacyjnych, co sprawia, że trudno jest ocenić i określić optymalne działanie operacyjne. Modelowanie kondycji dąży ostatecznie do zmaksymalizowania wglądu poprzez rozszerzanie pierwotnych dzienników monitorowania i metryk o kluczowe wymagania biznesowe w celu ilościowego określania kondycji aplikacji, co pozwala na zautomatyzowaną ocenę stanów kondycji w celu osiągnięcia spójnych i przyspieszonych operacji.

Ten obszar projektowania koncentruje się na procesie definiowania niezawodnego modelu kondycji, mapowania kwantyfikowanych stanów kondycji aplikacji za pomocą możliwości obserwacji i konstrukcji operacyjnych w celu osiągnięcia dojrzałości operacyjnej.

Ważne

Ten artykuł jest częścią serii obciążeń azure Well-Architected o znaczeniu krytycznym . Jeśli nie znasz tej serii, zalecamy rozpoczęcie od tego, co to jest obciążenie o znaczeniu krytycznym?

Istnieją trzy główne poziomy dojrzałości operacyjnej podczas dążenia do maksymalizacji niezawodności.

1. Wykrywanie i reagowanie na problemy w miarę ich wystąpienia.
2. Zdiagnozuj problemy występujące lub już wystąpiły.
3. Przewidywanie i zapobieganie problemom przed ich rozpoczęciem.

Wideo: Definiowanie modelu kondycji dla obciążenia o znaczeniu krytycznym

Kondycja aplikacji warstwowych

Aby utworzyć model kondycji, najpierw zdefiniuj kondycję aplikacji w kontekście kluczowych wymagań biznesowych, kwantyfikując stany "w dobrej kondycji" i "w złej kondycji" w warstwowym i mierzalnym formacie. Następnie dla każdego składnika aplikacji uściślij definicję w kontekście stanu stałego działania i zagregowane zgodnie z przepływami użytkownika aplikacji. Zastępowanie kluczowymi wymaganiami biznesowymi dotyczącymi niefunkcjonalnych wymagań biznesowych dotyczących wydajności i dostępności. Na koniec zagreguj stany kondycji dla każdego przepływu poszczególnych użytkowników, aby utworzyć akceptowalną reprezentację ogólnej kondycji aplikacji. Po ustanowieniu te warstwowe definicje kondycji powinny służyć do informowania o krytycznych metrykach monitorowania we wszystkich składnikach systemu i weryfikowaniu kompozycji podsystemu operacyjnego.

Ważne

Podczas definiowania stanów "w złej kondycji" reprezentują wszystkie poziomy aplikacji. Ważne jest rozróżnienie między przejściowymi i nie przejściowymi stanami awarii w celu zakwalifikowania degradacji usługi w stosunku do niedostępności.

Zagadnienia dotyczące projektowania

• Proces modelowania kondycji jest odgórnym działaniem projektowym, które rozpoczyna się od ćwiczenia architektonicznego w celu zdefiniowania wszystkich przepływów użytkownika i mapowania zależności między składnikami funkcjonalnymi i logicznymi, a tym samym niejawnie mapowania zależności między zasobami platformy Azure.

• Model kondycji jest całkowicie zależny od kontekstu reprezentowanego rozwiązania i dlatego nie można go rozwiązać "out-of-the-box", ponieważ "jeden rozmiar nie pasuje do wszystkich".

  • Aplikacje różnią się składem i zależnościami
  • Metryki i progi metryk dla zasobów muszą być również precyzyjnie dostosowane pod względem wartości reprezentujących stany w dobrej kondycji i złej kondycji, które są silnie pod wpływem funkcji aplikacji i docelowych wymagań niefunkcjonalnych.

• Model kondycji warstwowej umożliwia śledzenie kondycji aplikacji z powrotem do zależności niższego poziomu, co pomaga szybko spowodować obniżenie poziomu usług.

• Aby przechwycić stany kondycji dla pojedynczego składnika, odrębne cechy operacyjne tego składnika muszą być zrozumiałe w stanie stabilnym, który odzwierciedla obciążenie produkcyjne. W związku z tym testowanie wydajnościowe to kluczowa możliwość definiowania i ciągłego oceniania kondycji aplikacji.

• Błędy w rozwiązaniu w chmurze mogą nie występować w izolacji. Awaria w jednym składniku może prowadzić do niedostępności kilku funkcji lub dodatkowych składników.

  • Takie błędy mogą nie być natychmiast zauważalne.

Zalecenia dotyczące projektowania

• Zdefiniuj mierzalny model kondycji jako priorytet, aby zapewnić jasne zrozumienie operacyjne całej aplikacji.

  • Model kondycji powinien być warstwowy i odzwierciedlany w strukturze aplikacji.
  • Warstwa podstawowa powinna uwzględniać poszczególne składniki aplikacji, takie jak zasoby platformy Azure.
  • Podstawowe składniki powinny być agregowane wraz z kluczowymi wymaganiami niefunkcjonalnymi w celu utworzenia obiektywu kontekstowego biznesowego w kondycję przepływów systemu.
  • Przepływy systemowe powinny być agregowane z odpowiednimi wagami na podstawie krytycznego działania firmy, aby utworzyć znaczącą definicję ogólnej kondycji aplikacji. Należy określić priorytety przepływów użytkowników o znaczeniu finansowym lub dla klientów.
  • Każda warstwa modelu kondycji powinna przechwytywać stany "w dobrej kondycji" i "w złej kondycji".
  • Upewnij się, że model heath może odróżnić przejściowe i nie przejściowe stany złej kondycji, aby odizolować degradację usługi od niedostępności.

• Reprezentują stany kondycji przy użyciu szczegółowego wskaźnika kondycji dla każdego odrębnego składnika aplikacji i przepływu każdego użytkownika przez agregowanie wyników kondycji dla zamapowanych składników zależnych, biorąc pod uwagę kluczowe wymagania niefunkcjonalne jako współczynniki.

  • Wynik kondycji przepływu użytkownika powinien być reprezentowany przez najniższy wynik we wszystkich zamapowanych składnikach, faktoring względny poziom osiągnięcia w stosunku do wymagań niefunkcjonalnych dla przepływu użytkownika.
  • Model używany do obliczania wyników kondycji musi spójnie odzwierciedlać kondycję operacyjną, a jeśli nie, model powinien zostać dostosowany i wdrożony ponownie w celu odzwierciedlenia nowych informacji.
  • Zdefiniuj progi oceny kondycji, aby odzwierciedlić stan kondycji.

• Ocena kondycji musi być obliczana automatycznie na podstawie bazowych metryk, które można wizualizować za pomocą wzorców obserwacji i działać zgodnie z zautomatyzowanymi procedurami operacyjnymi.

  • Wynik kondycji powinien stać się podstawą rozwiązania do monitorowania, aby zespoły operacyjne nie musiały już interpretować i mapować danych operacyjnych na kondycję aplikacji.

• Użyj modelu kondycji, aby obliczyć osiągnięcie celu poziomu usług (SLO) dostępności zamiast pierwotnej dostępności, zapewniając rozdzielenie między degradacją usługi a niedostępnością jest odzwierciedlane jako oddzielne cele SLO.

• Użyj modelu kondycji w potokach ciągłej integracji/ciągłego wdrażania i cyklach testowania, aby sprawdzić, czy kondycja aplikacji jest zachowywana po aktualizacji kodu i konfiguracji.

  • Model kondycji powinien służyć do obserwowania i weryfikowania kondycji podczas testowania obciążenia i testowania chaosu w ramach procesów ciągłej integracji/ciągłego wdrażania.

• Tworzenie i utrzymywanie modelu kondycji jest procesem iteracyjnym, a inwestycje inżynieryjne powinny być dostosowane do ciągłego ulepszania.

  • Zdefiniuj proces, aby stale oceniać i dostosowywać dokładność modelu, i rozważ inwestowanie w modele uczenia maszynowego w celu dalszego trenowania modelu.

Przykład — model kondycji warstwowej

Jest to uproszczona reprezentacja warstwowego modelu kondycji aplikacji w celach ilustracyjnych. Kompleksowy i kontekstowy model kondycji jest udostępniany w implementacjach referencyjnych Mission-Critical:

• Mission-Critical Online
• Połączenie o krytycznym znaczeniu

Podczas implementowania modelu kondycji ważne jest zdefiniowanie kondycji poszczególnych składników za pomocą agregacji i interpretacji kluczowych metryk na poziomie zasobów. Przykładem użycia metryk zasobów jest poniższy obraz:

o

Ta definicja kondycji może być następnie reprezentowana przez zapytanie KQL, jak pokazano w przykładowym zapytaniu poniżej, które agreguje insightsMetrics (szczegółowe informacje o kontenerze) i AzureMetrics (ustawienie diagnostyczne dla klastra usługi AKS) i porównuje (sprzężenie wewnętrzne) z modelowanymi progami kondycji.

// ClusterHealthStatus
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
    // Disk Usage:
    "used_percent", 50, 80,
    // Average node cpu usage %:
    "node_cpu_usage_percentage", 60, 90,
    // Average node disk usage %:
    "node_disk_usage_percentage", 60, 80,
    // Average node memory usage %:
    "node_memory_rss_percentage", 60, 80
    ];
InsightsMetrics
| summarize arg_max(TimeGenerated, *) by Computer, Name
| project TimeGenerated,Computer, Namespace, MetricName = Name, Value=Val
| extend NodeName = extract("([a-z0-9-]*)(-)([a-z0-9]*)$", 3, Computer)
| union (
    AzureMetrics
    | extend ResourceType = extract("(PROVIDERS/MICROSOFT.)([A-Z]*/[A-Z]*)", 2, ResourceId)
    | where ResourceType == "CONTAINERSERVICE/MANAGEDCLUSTERS"
    | summarize arg_max(TimeGenerated, *) by MetricName
    | project TimeGenerated, MetricName, Namespace = "AzureMetrics", Value=Average
    )
| lookup kind=inner Thresholds on MetricName
| extend IsYellow = iff(Value > YellowThreshold and Value < RedThreshold, 1, 0)
| extend IsRed = iff(Value > RedThreshold, 1, 0)
| project NodeName, MetricName, Value, YellowThreshold, IsYellow, RedThreshold, IsRed

Wynikowe dane wyjściowe tabeli można następnie przekształcić w wynik kondycji, aby ułatwić agregację na wyższych poziomach modelu kondycji.

// ClusterHealthScore
ClusterHealthStatus
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed)
| extend HealthScore = 1-(YellowScore*0.25)-(RedScore*0.5)

Te zagregowane wyniki można następnie przedstawić jako wykres zależności przy użyciu narzędzi do wizualizacji, takich jak Grafana, aby zilustrować model kondycji.

Ten obraz przedstawia przykładowy model kondycji warstwowej z implementacji odwołań online usługi Azure Mission-Critical oraz pokazuje, jak zmiana stanu kondycji podstawowego składnika może mieć kaskadowy wpływ na przepływy użytkowników i ogólną kondycję aplikacji (przykładowe wartości odpowiadają tabeli na poprzednim obrazie).

Pokaz wideo: pokaz monitorowania i modelowania kondycji

Ujednolicone ujście danych na potrzeby skorelowanej analizy

Wiele operacyjnych zestawów danych musi być zebranych ze wszystkich składników systemu, aby dokładnie reprezentować zdefiniowany model heath, biorąc pod uwagę dzienniki i metryki zarówno ze składników aplikacji, jak i podstawowych zasobów platformy Azure. Ta ogromna ilość danych ostatecznie musi być przechowywana w formacie umożliwiającym interpretację niemal w czasie rzeczywistym w celu ułatwienia szybkiego działania operacyjnego. Ponadto korelacja we wszystkich obejmujących zestawach danych jest wymagana w celu zapewnienia, że efektywna analiza jest niezwiązana, co pozwala na warstwową reprezentację kondycji.

Ujednolicone ujście danych jest wymagane w celu zapewnienia, że wszystkie dane operacyjne są szybko przechowywane i udostępniane do skorelowanej analizy w celu utworzenia reprezentacji kondycji aplikacji w jednym okienku. Platforma Azure udostępnia kilka różnych technologii operacyjnych w ramach usługi Azure Monitor, a obszar roboczy usługi Log Analytics służy jako podstawowy ujście danych natywnych dla platformy Azure do przechowywania i analizowania danych operacyjnych.

zbierania

Zagadnienia dotyczące projektowania

Azure Monitor

• Usługa Azure Monitor jest domyślnie włączona dla wszystkich subskrypcji platformy Azure, ale należy wdrożyć i skonfigurować zasoby usługi Azure Monitor (obszar roboczy usługi Log Analytics) oraz zasoby usługi Application Insights w celu uwzględnienia możliwości zbierania danych i wykonywania zapytań.

• Usługa Azure Monitor obsługuje trzy typy danych wglądu: dzienniki, metryki i rozproszone ślady.

  • Dzienniki są przechowywane w obszarach roboczych usługi Log Analytics, które są oparte na usłudze Azure Data Explorer. Zapytania dzienników są przechowywane w pakietach zapytań, które mogą być współużytkowane przez subskrypcje i służą do napędzania składników wglądu, takich jak pulpity nawigacyjne, skoroszyty lub inne narzędzia do raportowania i wizualizacji.
  • Metryki są przechowywane w wewnętrznej bazie danych szeregów czasowych. W przypadku większości zasobów platformy Azure metryki są automatycznie zbierane i przechowywane przez 93 dni. Dane metryk można również wysyłać do obszaru roboczego usługi Log Analytics przy użyciu ustawienia diagnostycznego dla zasobu.

• Wszystkie zasoby platformy Azure uwidaczniają dzienniki i metryki, ale zasoby muszą być odpowiednio skonfigurowane do kierowania danych diagnostycznych do żądanego ujścia danych.

Porada

Platforma Azure udostępnia różne wbudowane zasady , które można zastosować w celu zapewnienia, że wdrożone zasoby są skonfigurowane do wysyłania dzienników i metryk do obszaru roboczego usługi Log Analytics.

• Kontrola przepisów nie jest rzadkością, aby wymagać danych operacyjnych, pozostają w pochodzących lokalizacjach geograficznych lub krajach/regionach. Wymagania prawne mogą określać przechowywanie krytycznych typów danych przez dłuższy czas. Na przykład w bankowości regulowanej dane inspekcji muszą być przechowywane przez co najmniej siedem lat.

• Różne typy danych operacyjnych mogą wymagać różnych okresów przechowywania. Na przykład dzienniki zabezpieczeń mogą być przechowywane przez długi okres, a dane dotyczące wydajności są mało prawdopodobne, aby wymagać długoterminowego przechowywania poza kontekstem AIOps.

• Dane mogą być archiwizowane lub eksportowane z obszarów roboczych usługi Log Analytics na potrzeby długoterminowego przechowywania i/lub inspekcji.

• Dedykowane klastry zapewniają opcję wdrożenia, która umożliwia Strefy dostępności ochrony przed awariami strefowymi w obsługiwanych regionach świadczenia usługi Azure. Dedykowane klastry wymagają minimalnego dziennego zobowiązania do pozyskiwania danych.

• Obszary robocze usługi Log Analytics są wdrażane w określonym regionie świadczenia usługi Azure.

• Aby chronić przed utratą danych przed niedostępnością obszaru roboczego usługi Log Analytics, zasoby można skonfigurować przy użyciu wielu ustawień diagnostycznych. Każde ustawienie diagnostyczne może wysyłać metryki i dzienniki do oddzielnego obszaru roboczego usługi Log Analytics.

  • Dane wysyłane do każdego dodatkowego obszaru roboczego usługi Log Analytics będą ponosić dodatkowe koszty.
  • Nadmiarowy obszar roboczy usługi Log Analytics można wdrożyć w tym samym regionie świadczenia usługi Azure lub w oddzielnych regionach świadczenia usługi Azure w celu uzyskania dodatkowej nadmiarowości regionalnej.
  • Wysyłanie dzienników i metryk z zasobu platformy Azure do obszaru roboczego usługi Log Analytics w innym regionie spowoduje naliczenie kosztów ruchu wychodzącego danych między regionami.
  • Niektóre zasoby platformy Azure wymagają obszaru roboczego usługi Log Analytics w tym samym regionie co sam zasób.
  • Aby uzyskać więcej opcji dostępności dla obszaru roboczego usługi Log Analytics, zobacz Najlepsze rozwiązania dotyczące dzienników usługi Azure Monitor .

• Dane obszaru roboczego usługi Log Analytics można eksportować do usługi Azure Storage lub Azure Event Hubs w sposób ciągły, zaplanowany lub jednorazowy.

  • Eksport danych umożliwia długoterminowe archiwizowanie danych i chroni przed możliwą utratą danych operacyjnych z powodu niedostępności.
  • Dostępne miejsca docelowe eksportu to usługa Azure Storage lub Azure Event Hubs. Usługę Azure Storage można skonfigurować dla różnych poziomów nadmiarowości , w tym strefowych lub regionalnych. Eksportowanie danych do usługi Azure Storage przechowuje dane w plikach json.
  • Miejsca docelowe eksportu danych muszą znajdować się w tym samym regionie świadczenia usługi Azure co obszar roboczy usługi Log Analytics. Miejsce docelowe eksportu danych centrum zdarzeń znajduje się w tym samym regionie co obszar roboczy usługi Log Analytics. Azure Event Hubs odzyskiwania po awarii geograficznej nie ma zastosowania w tym scenariuszu.
  • Istnieje kilka ograniczeń eksportu danych. Tylko określone tabele w obszarze roboczym są obsługiwane w przypadku eksportowania danych.
  • Archiwizacja może służyć do przechowywania danych w obszarze roboczym usługi Log Analytics w celu długoterminowego przechowywania przy obniżonym koszcie bez eksportowania.

• Dzienniki usługi Azure Monitor mają limity ograniczania zapytań użytkownika, które mogą być wyświetlane jako zmniejszona dostępność dla klientów, takich jak pulpity nawigacyjne z możliwościami obserwacji.

  • Pięć współbieżnych zapytań na użytkownika: jeśli pięć zapytań jest już uruchomionych, dodatkowe zapytania są umieszczane w kolejce współbieżności poszczególnych użytkowników do momentu zakończenia uruchomionego zapytania.
  • Czas w kolejce współbieżności: jeśli zapytanie znajduje się w kolejce współbieżności przez ponad trzy minuty, zostanie zakończone i zwrócony kod błędu 429.
  • Limit głębokości kolejki współbieżności: kolejka współbieżności jest ograniczona do 200 zapytań, a dodatkowe zapytania zostaną odrzucone przy użyciu kodu błędu 429.
  • Limit szybkości zapytań: limit liczby zapytań na użytkownika wynosi 200 zapytań na 30 sekund we wszystkich obszarach roboczych.

• Pakiety zapytań to zasoby usługi Azure Resource Manager, których można użyć do ochrony i odzyskiwania zapytań dzienników, jeśli obszar roboczy usługi Log Analytics jest niedostępny.

  • Pakiety zapytań zawierają zapytania w formacie JSON i mogą być przechowywane poza platformą Azure podobnie jak inne zasoby infrastruktury jako kodu.
    • Można je wdrożyć za pomocą interfejsu API REST Microsoft.Insights.
    • Jeśli należy ponownie utworzyć obszar roboczy usługi Log Analytics, pakiet zapytań można ponownie wdrożyć z zewnętrznie przechowywanej definicji.

• Usługę Application Insights można wdrożyć w modelu wdrażania opartym na obszarze roboczym, popartym obszarem roboczym usługi Log Analytics, w którym są przechowywane wszystkie dane.

• Próbkowanie można włączyć w usłudze Application Insights, aby zmniejszyć ilość wysyłanych danych telemetrycznych i zoptymalizować koszty pozyskiwania danych.

• Wszystkie dane zebrane przez usługę Azure Monitor, w tym usługę Application Insights, są naliczane opłaty na podstawie ilości pozyskanych danych i czasu trwania przechowywania danych.

  • Dane pozyskiwane do obszaru roboczego usługi Log Analytics można przechowywać bez dodatkowych opłat do pierwszych 31 dni (90 dni, jeśli usługa Sentinel jest włączona)
  • Dane pozyskane do usługi Application Insights opartej na obszarze roboczym są przechowywane przez pierwsze 90 dni bez dodatkowych opłat.

• Model cen warstwy zobowiązania usługi Log Analytics zapewnia obniżony koszt i przewidywalne podejście do pozyskiwania opłat za dane.

  • Każde użycie powyżej poziomu rezerwacji jest rozliczane w tej samej cenie co bieżąca warstwa.

• Usługi Log Analytics, Application Insights i Azure Data Explorer używają język zapytań Kusto (KQL).

• Zapytania usługi Log Analytics są zapisywane jako funkcje w obszarze roboczym usługi Log Analytics (savedSearches).

Zalecenia dotyczące projektowania

• Użyj obszaru roboczego usługi Log Analytics jako ujednoliconego ujścia danych, aby udostępnić "pojedyncze okienko" we wszystkich zestawach danych operacyjnych.

  • Zdecentralizowanie obszarów roboczych usługi Log Analytics we wszystkich używanych regionach wdrażania. Każdy region świadczenia usługi Azure z wdrożeniem aplikacji powinien uwzględniać obszar roboczy usługi Log Analytics w celu zebrania wszystkich danych operacyjnych pochodzących z tego regionu. Wszystkie zasoby globalne powinny używać oddzielnego dedykowanego obszaru roboczego usługi Log Analytics, który powinien zostać wdrożony w regionie wdrożenia podstawowego.
    • Wysłanie wszystkich danych operacyjnych do jednego obszaru roboczego usługi Log Analytics spowoduje utworzenie pojedynczego punktu awarii.
    • Wymagania dotyczące rezydencji danych mogą uniemożliwiać opuszczenie regionu źródłowego, a obszary robocze federacyjne są domyślnie rozwiązywane dla tego wymagania.
    • Istnieje znaczny koszt ruchu wychodzącego związany z transferem dzienników i metryk w różnych regionach.
  • Wszystkie sygnatury wdrożenia w tym samym regionie mogą używać tego samego regionalnego obszaru roboczego usługi Log Analytics.

• Rozważ skonfigurowanie zasobów z wieloma ustawieniami diagnostycznymi wskazującymi różne obszary robocze usługi Log Analytics w celu ochrony przed niedostępnością usługi Azure Monitor dla aplikacji z mniejszą liczbą regionalnych sygnatur wdrażania.

• Użyj usługi Application Insights jako spójnego narzędzia do monitorowania wydajności aplikacji (APM) we wszystkich składnikach aplikacji, aby zbierać dzienniki aplikacji, metryki i ślady.

  • Wdróż usługę Application Insights w konfiguracji opartej na obszarze roboczym, aby upewnić się, że każdy regionalny obszar roboczy usługi Log Analytics zawiera dzienniki i metryki zarówno ze składników aplikacji, jak i podstawowych zasobów platformy Azure.

• Użyj zapytań między obszarami roboczymi , aby zachować ujednolicone "pojedyncze okienko" w różnych obszarach roboczych.

• Użyj pakietów zapytań , aby chronić zapytania dziennika w przypadku niedostępności obszaru roboczego.

  • Przechowuj pakiety zapytań w repozytorium git aplikacji jako zasoby infrastruktury jako kodu.

• Wszystkie obszary robocze usługi Log Analytics powinny być traktowane jako długotrwałe zasoby z innym cyklem życia dla zasobów aplikacji w ramach regionalnej sygnatury wdrożenia.

• Eksportowanie krytycznych danych operacyjnych z obszaru roboczego usługi Log Analytics na potrzeby długoterminowego przechowywania i analizy w celu ułatwienia sztucznej inteligencji i zaawansowanej analizy w celu uściślenia bazowego modelu kondycji i informowania o akcji predykcyjnej.

• Starannie oceń, który magazyn danych powinien być używany do przechowywania długoterminowego; nie wszystkie dane muszą być przechowywane w magazynie danych z możliwością wykonywania zapytań i gorącym.

  • Zdecydowanie zaleca się używanie usługi Azure Storage w konfiguracji GRS na potrzeby długoterminowego przechowywania danych operacyjnych.
    • Użyj możliwości eksportowania obszaru roboczego usługi Log Analytics, aby wyeksportować wszystkie dostępne źródła danych do usługi Azure Storage.

• Wybierz odpowiednie okresy przechowywania dla typów danych operacyjnych w usłudze Log Analytics, konfigurując dłuższe okresy przechowywania w obszarze roboczym, w którym istnieją wymagania dotyczące możliwości obserwacji "gorąca".

• Użyj Azure Policy, aby upewnić się, że wszystkie zasoby regionalne kierują dane operacyjne do prawidłowego obszaru roboczego usługi Log Analytics.

Uwaga

W przypadku wdrażania w strefie docelowej platformy Azure, jeśli istnieje wymóg scentralizowanego przechowywania danych operacyjnych, można utworzyć rozwidlenie danych podczas tworzenia wystąpienia, aby były pozyskiwane zarówno do scentralizowanych narzędzi, jak i obszarów roboczych usługi Log Analytics przeznaczonych dla aplikacji. Alternatywnie uwidaczniaj dostęp do obszarów roboczych usługi Log Analytics aplikacji, aby centralne zespoły mogły wykonywać zapytania o dane aplikacji. Ostatecznie kluczowe znaczenie ma to, że dane operacyjne pochodzące z rozwiązania są dostępne w obszarach roboczych usługi Log Analytics przeznaczonych dla aplikacji.

Jeśli wymagana jest integracja rozwiązania SIEM, nie wysyłaj nieprzetworzonych wpisów dziennika, ale zamiast tego wysyłaj alerty krytyczne.

• Skonfiguruj próbkowanie tylko w usłudze Application Insights, jeśli jest wymagane do optymalizacji wydajności lub jeśli próbkowanie nie stanie się zbyt kosztowne.

  • Nadmierne próbkowanie może prowadzić do nieodebranych lub niedokładnych sygnałów operacyjnych.

• Użyj identyfikatorów korelacji dla wszystkich zdarzeń śledzenia i rejestrowania komunikatów, aby powiązać je z danym żądaniem.

  • Zwraca identyfikatory korelacji do elementu wywołującego dla wszystkich wywołań nie tylko nieudanych żądań.

• Upewnij się, że kod aplikacji zawiera odpowiednie instrumentację i rejestrowanie, aby poinformować model kondycji i ułatwić późniejsze rozwiązywanie problemów lub analizę głównej przyczyny, jeśli jest to wymagane.

  • Kod aplikacji powinien używać usługi Application Insights w celu ułatwienia śledzenia rozproszonego, dostarczając wywołujący kompleksowy komunikat o błędzie zawierający identyfikator korelacji w przypadku wystąpienia błędu.

• Użyj rejestrowania strukturalnego dla wszystkich komunikatów dziennika.

• Dodaj znaczące sondy kondycji do wszystkich składników aplikacji.

  • W przypadku korzystania z usługi AKS skonfiguruj punkty końcowe kondycji dla każdego wdrożenia (zasobnika), aby platforma Kubernetes mogła prawidłowo określić, kiedy zasobnik jest w dobrej kondycji lub jest w złej kondycji.
  • W przypadku korzystania z Azure App Service skonfiguruj kontrole kondycji, aby operacje skalowania w poziomie nie powodowały błędów, wysyłając ruch do wystąpień, które nie są jeszcze gotowe, i upewniając się, że wystąpienia w złej kondycji są szybko poddawane ponownemu przetworzeniu.

Jeśli aplikacja jest subskrybowana do usługi Microsoft Mission-Critical Support, rozważ uwidocznienie kluczowych sond kondycji w celu pomoc techniczna firmy Microsoft, aby kondycja aplikacji mogła być dokładniej modelowana przez pomoc techniczna firmy Microsoft.

• Rejestruj pomyślne żądania kontroli kondycji, chyba że nie można tolerować zwiększonych woluminów danych w kontekście wydajności aplikacji, ponieważ zapewniają one dodatkowe szczegółowe informacje na temat modelowania analitycznego.

• Nie należy konfigurować produkcyjnych obszarów roboczych usługi Log Analytics w celu zastosowania dziennego limitu, który ogranicza dzienne pozyskiwanie danych operacyjnych, ponieważ może to prowadzić do utraty krytycznych danych operacyjnych.

  • W niższych środowiskach, takich jak programowanie i testowanie, dzienny limit można traktować jako opcjonalny mechanizm oszczędzania kosztów.

• Pod warunkiem, że woluminy pozyskiwania danych operacyjnych spełniają próg minimalnej warstwy, skonfiguruj obszary robocze usługi Log Analytics, aby używać cen opartych na warstwie zobowiązania w celu zwiększenia wydajności kosztów względem modelu cenowego "płatność zgodnie z rzeczywistym użyciem".

• Zdecydowanie zaleca się przechowywanie zapytań usługi Log Analytics przy użyciu kontroli źródła i używanie automatyzacji ciągłej integracji/ciągłego wdrażania w celu wdrożenia ich w odpowiednich wystąpieniach obszaru roboczego usługi Log Analytics.

Wizualizacja

Wizualne reprezentowanie modelu kondycji z krytycznymi danymi operacyjnymi jest niezbędne do osiągnięcia skutecznych operacji i zmaksymalizowania niezawodności. Pulpity nawigacyjne powinny być ostatecznie wykorzystywane w celu zapewnienia niemal rzeczywistego wglądu w kondycję aplikacji dla zespołów DevOps, ułatwiając szybką diagnostykę odchyleń od stanu stałego.

Firma Microsoft udostępnia kilka technologii wizualizacji danych, w tym pulpitów nawigacyjnych platformy Azure, usługi Power BI i usługi Azure Managed Grafana (obecnie w wersji zapoznawczej). Pulpity nawigacyjne platformy Azure są przygotowane do zapewnienia ściśle zintegrowanego gotowego rozwiązania do wizualizacji na potrzeby danych operacyjnych w usłudze Azure Monitor. W związku z tym odgrywa podstawową rolę w wizualnej reprezentacji danych operacyjnych i kondycji aplikacji dla obciążenia o znaczeniu krytycznym. Istnieje jednak kilka ograniczeń dotyczących pozycjonowania pulpitów nawigacyjnych platformy Azure jako całościowej platformy do obserwacji, a w rezultacie należy wziąć pod uwagę dodatkowe zastosowanie wiodących na rynku rozwiązań do obserwacji, takich jak Grafana, które jest również udostępniane jako rozwiązanie zarządzane na platformie Azure.

Ta sekcja koncentruje się na używaniu pulpitów nawigacyjnych platformy Azure i narzędzia Grafana do tworzenia niezawodnego środowiska pulpitu nawigacyjnego umożliwiającego dostarczanie obiektywów technicznych i biznesowych do kondycji aplikacji, umożliwiając zespołom DevOps i efektywną operację. Niezawodne pulpity nawigacyjne są niezbędne do diagnozowania problemów, które już wystąpiły, oraz obsługi zespołów operacyjnych w wykrywaniu i reagowaniu na problemy w miarę ich wystąpienia.

Zagadnienia dotyczące projektowania

• Podczas wizualizowania modelu kondycji przy użyciu zapytań dzienników należy pamiętać, że istnieją limity usługi Log Analytics dotyczące zapytań współbieżnych i kolejek, a także ogólny współczynnik zapytań z kolejnymi zapytaniami w kolejce i z ograniczeniami.

• Zapytania służące do pobierania danych operacyjnych używanych do obliczania i reprezentowania wyników kondycji można zapisywać i wykonywać w usłudze Log Analytics lub Azure Data Explorer.

  • Przykładowe zapytania są dostępne tutaj.

• Usługa Log Analytics nakłada kilka limitów zapytań, które należy zaprojektować podczas projektowania operacyjnych pulpitów nawigacyjnych.

• Wizualizacja nieprzetworzonych metryk zasobów, takich jak wykorzystanie procesora CPU lub przepływność sieci, wymaga ręcznej oceny przez zespoły operacyjne w celu określenia wpływu stanu kondycji i może to być trudne podczas aktywnego zdarzenia.

• Jeśli wielu użytkowników korzysta z pulpitów nawigacyjnych w ramach narzędzia takiego jak Grafana, liczba zapytań wysyłanych do usługi Log Analytics szybko się mnoży.

  • Osiągnięcie limitu zapytań współbieżnych w usłudze Log Analytics spowoduje kolejkę kolejnych zapytań, dzięki czemu środowisko pulpitu nawigacyjnego będzie działać "wolno".

Zalecenia dotyczące projektowania

• Zbieranie i prezentowanie zapytanych danych wyjściowych ze wszystkich regionalnych obszarów roboczych usługi Log Analytics i globalnego obszaru roboczego usługi Log Analytics w celu utworzenia ujednoliconego widoku kondycji aplikacji.

Uwaga

W przypadku wdrażania w strefie docelowej platformy Azure rozważ wysłanie zapytania do centralnego obszaru roboczego usługi Log Analytics , jeśli istnieją kluczowe zależności od zasobów platformy, takie jak usługa ExpressRoute na potrzeby komunikacji lokalnej.

• Model "sygnalizacji świetlnej" powinien służyć do wizualnego reprezentowania stanów "w dobrej kondycji" i "złej kondycji", z zielonym używanym do zilustrowania, kiedy kluczowe wymagania niefunkcjonalne są w pełni spełnione, a zasoby są optymalnie wykorzystywane. Użyj wartości "Green", "Amber i "Red", aby reprezentować stany "Healthy", "Degraded" i "Unavailable".

• Pulpity nawigacyjne platformy Azure umożliwiają tworzenie obiektywów operacyjnych dla zasobów globalnych i regionalnych sygnatur wdrażania, reprezentujących kluczowe metryki, takie jak liczba żądań dla usługi Azure Front Door, opóźnienie po stronie serwera dla usługi Azure Cosmos DB, komunikaty przychodzące/wychodzące dla usługi Event Hubs oraz wykorzystanie procesora CPU lub stany wdrożenia dla usługi AKS. Pulpity nawigacyjne powinny być dostosowane, aby zwiększyć efektywność operacyjną, co zwiększa wiedzę ze scenariuszy awarii w celu zapewnienia, że zespoły DevOps mają bezpośredni wgląd w kluczowe metryki.

• Jeśli pulpity nawigacyjne platformy Azure nie mogą być używane do dokładnego reprezentowania modelu kondycji i wymagań biznesowych, zdecydowanie zaleca się rozważenie rozwiązania Grafana jako alternatywnego rozwiązania do wizualizacji, zapewniającego wiodące na rynku możliwości i rozbudowany ekosystem wtyczek typu open source. Oceń ofertę zarządzanej wersji zapoznawczej narzędzia Grafana, aby uniknąć złożoności operacyjnych zarządzania infrastrukturą narzędzia Grafana.

• Podczas wdrażania własnego narzędzia Grafana należy stosować projekt o wysokiej dostępności i rozproszonej geograficznie, aby zapewnić odporność krytycznych pulpitów nawigacyjnych operacyjnych na awarie platformy regionalnej i scenariusze błędów kaskadowych.

  • Oddziel stan konfiguracji na zewnętrzny magazyn danych, taki jak Usługa Azure Database for Postgres lub MySQL, aby upewnić się, że węzły aplikacji Grafana pozostają bezstanowe.

    • Konfigurowanie replikacji bazy danych między regionami wdrażania.

  • Wdrażanie węzłów narzędzia Grafana w usłudze App Services w konfiguracji o wysokiej dostępności między węzłami w regionie przy użyciu wdrożeń opartych na kontenerach.

    • Wdrażanie wystąpień App Service w regionach wdrożenia.

    Usługa App Services udostępnia platformę kontenerów o niskim tarciu, która jest idealna dla scenariuszy o niskiej skali, takich jak operacyjne pulpity nawigacyjne, a izolowanie narzędzia Grafana z usługi AKS zapewnia wyraźne rozdzielenie kwestii między podstawową platformą aplikacji i reprezentacjami operacyjnymi dla tej platformy. Aby uzyskać dalsze zalecenia dotyczące konfiguracji, zapoznaj się z obszarem deign platformy aplikacji.

  • Usługa Azure Storage w konfiguracji grs umożliwia hostowanie niestandardowych wizualizacji i wtyczek oraz zarządzanie nimi.

  • Wdróż składniki usługi App Service i repliki do odczytu bazy danych Grafana w co najmniej dwóch regionach wdrażania i rozważ zastosowanie modelu, w którym narzędzie Grafana jest wdrażane we wszystkich regionach wdrażania.

W przypadku scenariuszy przeznaczonych dla celu >celu poziomu usługi = 99,99% cel slo należy wdrożyć narzędzie Grafana w co najmniej 3 regionach wdrażania, aby zmaksymalizować ogólną niezawodność kluczowych pulpitów nawigacyjnych operacyjnych.

• Ogranicz limity zapytań usługi Log Analytics, agregując zapytania w jedną lub niewielką liczbę zapytań, na przykład przy użyciu operatora "union" języka KQL i ustawiając odpowiednią częstotliwość odświeżania na pulpicie nawigacyjnym.

  • Odpowiedni maksymalny współczynnik odświeżania będzie zależeć od liczby i złożoności zapytań pulpitu nawigacyjnego; wymagana jest analiza wdrożonych zapytań.

• Jeśli osiągnięto limit zapytań współbieżnych usługi Log Analytics, rozważ optymalizację wzorca pobierania przez (tymczasowo) przechowywanie danych wymaganych dla pulpitu nawigacyjnego w magazynie danych o wysokiej wydajności, takim jak Azure SQL.

Automatyczna odpowiedź na zdarzenia

Chociaż wizualne reprezentacje kondycji aplikacji zapewniają bezcenne informacje operacyjne i biznesowe na potrzeby obsługi wykrywania i diagnozowania problemów, opiera się na gotowości i interpretacjach zespołów operacyjnych, a także skuteczności kolejnych odpowiedzi wyzwalanych przez człowieka. W związku z tym w celu zmaksymalizowania niezawodności konieczne jest zaimplementowanie rozbudowanego alertu w celu proaktywnego wykrywania problemów i reagowania na nie niemal w czasie rzeczywistym.

Usługa Azure Monitor udostępnia rozbudowaną strukturę alertów umożliwiającą wykrywanie, kategoryzowanie i reagowanie na sygnały operacyjne za pomocą grup akcji. W tej sekcji skoncentrujemy się na używaniu alertów usługi Azure Monitor w celu kierowania zautomatyzowanymi akcjami w odpowiedzi na bieżące lub potencjalne odchylenia od stanu aplikacji w dobrej kondycji.

Ważne

Alerty i zautomatyzowane działania mają kluczowe znaczenie dla skutecznego wykrywania i szybkiego reagowania na problemy w miarę ich występowania, zanim wystąpi większy negatywny wpływ. Alerty udostępnia również mechanizm interpretacji sygnałów przychodzących i reagowania na nie, aby zapobiec problemom przed ich wystąpieniem.

Zagadnienia dotyczące projektowania

• Reguły alertów są definiowane do uruchamiania w przypadku spełnienia kryteriów warunkowych dla sygnałów przychodzących, które mogą obejmować różne źródła danych, takie jak metryki, zapytania dziennika lub testy dostępności.

• Alerty można definiować w usłudze Log Analytics lub Azure Monitor dla określonego zasobu.

• Niektóre metryki są dostępne tylko w usłudze Azure Monitor, ponieważ nie wszystkie punkty danych diagnostycznych są udostępniane w usłudze Log Analytics.

• Interfejs API alertów usługi Azure Monitor może służyć do pobierania alertów aktywnych i historycznych.

• Istnieją limity subskrypcji związane z alertami i grupami akcji, które muszą być przeznaczone dla:

  • Istnieją limity dla liczby konfigurowalnych reguł alertów.
  • Interfejs API alertów ma limity ograniczania przepustowości, które powinny być brane pod uwagę w przypadku ekstremalnych scenariuszy użycia.
  • Grupy akcji mają kilka twardych limitów liczby konfigurowalnych odpowiedzi, które należy zaprojektować.
    • Każdy typ odpowiedzi ma limit 10 akcji oprócz poczty e-mail, który ma limit 1000 akcji.

• Alerty można zintegrować w modelu kondycji warstwowej, tworząc regułę alertu dla zapisanego zapytania przeszukiwania dzienników z funkcji oceniania "root" modelu. Na przykład przy użyciu funkcji "WebsiteHealthScore" i alertów dla wartości liczbowej reprezentującej stan "W złej kondycji".

Zalecenia dotyczące projektowania

• W przypadku alertów skoncentrowanych na zasobach utwórz reguły alertów w usłudze Azure Monitor, aby upewnić się, że wszystkie dane diagnostyczne są dostępne dla kryteriów reguły alertu.

• Konsoliduj zautomatyzowane akcje w ramach minimalnej liczby grup akcji, dopasowanych do zespołów usług w celu obsługi podejścia DevOps.

• Reagowanie na sygnały nadmiernego wykorzystania zasobów za pomocą zautomatyzowanych operacji skalowania przy użyciu natywnych funkcji automatycznego skalowania na platformie Azure, jeśli to możliwe. Jeśli wbudowane funkcje automatycznego skalowania nie mają zastosowania, użyj wskaźnika kondycji składnika do modelowania sygnałów i określ, kiedy odpowiadać za pomocą zautomatyzowanych operacji skalowania. Upewnij się, że operacje skalowania automatycznego są definiowane zgodnie z modelem pojemności, który kwantyfikuje relacje skalowania między składnikami, dzięki czemu skalowanie odpowiedzi obejmuje składniki, które muszą być skalowane w odniesieniu do innych składników.

• Akcje modelu w celu dostosowania ich do priorytetów, które powinny być określane przez wpływ na działalność biznesową.

• Użyj interfejsu API alertów usługi Azure Monitor, aby zebrać historyczne alerty w celu uwzględnienia w magazynie operacyjnym "cold" na potrzeby zaawansowanej analizy.

• W przypadku scenariuszy awarii krytycznych, których nie można spełnić z automatyczną reakcją, upewnij się, że operacyjna "automatyzacja elementu Runbook" jest w miejscu, aby prowadzić szybkie i spójne działania po podaniu ręcznej interpretacji i wylogowania. Używanie powiadomień o alertach do szybkiej identyfikacji problemów wymagających ręcznej interpretacji

• Utwórz uprawnienia w ramach przebiegów inżynieryjnych, aby zwiększyć przyrostowe ulepszenia alertów w celu zapewnienia, że nowe scenariusze awarii, które nie zostały wcześniej uwzględnione, można w pełni uwzględnić w nowych zautomatyzowanych akcjach.

• Przeprowadź testy gotowości operacyjnej w ramach procesów ciągłej integracji/ciągłego wdrażania w celu zweryfikowania kluczowych reguł alertów dotyczących aktualizacji wdrożenia.

Działania predykcyjne i operacje sztucznej inteligencji (AIOps)

Modele uczenia maszynowego można stosować do korelowania i określania priorytetów danych operacyjnych, pomagając zebrać krytyczne informacje związane z filtrowaniem nadmiernego "szumu" alertu i przewidywaniem problemów, zanim spowodują one wpływ, a także przyspieszenie reagowania na zdarzenia podczas ich wykonywania.

W szczególności metodologię AIOps można zastosować do krytycznych szczegółowych informacji na temat zachowania procesów systemu, użytkowników i metodyki DevOps. Te szczegółowe informacje mogą obejmować zidentyfikowanie problemu, który występuje teraz (wykryj), kwantyfikując przyczynę wystąpienia problemu (diagnozowanie) lub sygnalizując, co stanie się w przyszłości (przewidywanie). Takie szczegółowe informacje mogą służyć do kierowania akcjami, które dostosowują i optymalizują aplikację w celu wyeliminowania aktywnych lub potencjalnych problemów, przy użyciu kluczowych metryk biznesowych, metryk jakości systemu i metryk produktywności metodyki DevOps, aby określić priorytety zgodnie z wpływem na działalność biznesową. Prowadzone działania mogą być wprowadzane do systemu za pośrednictwem pętli sprzężeń zwrotnych, która dodatkowo trenuje bazowy model w celu zwiększenia wydajności.

o

Na platformie Azure istnieje wiele technologii analitycznych, takich jak Azure Synapse i Azure Databricks, których można użyć do tworzenia i trenowania modeli analitycznych na potrzeby sztucznej inteligencji. W tej sekcji skoncentrujemy się na tym, jak te technologie można umieścić w projekcie aplikacji, aby uwzględnić metodykę AIOps i podjąć działania predykcyjne, koncentrując się na Azure Synapse, które zmniejszają problemy dzięki połączeniu najlepszych usług danych platformy Azure wraz z zaawansowanymi nowymi funkcjami.

Metodyka AIOps służy do podejmowania działań predykcyjnych, interpretowania i korelowania złożonych sygnałów operacyjnych obserwowanych w dłuższym okresie w celu lepszego reagowania na problemy i zapobiegania im przed ich wystąpieniem.

Zagadnienia dotyczące projektowania

• usługa Azure Synapse Analytics oferuje wiele funkcji uczenia maszynowego.

  • Modele uczenia maszynowego można trenować i uruchamiać w pulach platformy Synapse Spark z bibliotekami, takimi jak MLLib, SparkML i MMLSpark, a także popularne biblioteki open source, takie jak Scikit Learn.
  • Modele uczenia maszynowego można trenować przy użyciu typowych narzędzi do nauki o danych, takich jak PySpark/Python, Scala lub .NET.

• Usługa Synapse Analytics jest zintegrowana z usługą Azure ML za pośrednictwem notesów Azure Synapse, co umożliwia trenowanie modeli uczenia maszynowego w obszarze roboczym usługi Azure ML przy użyciu zautomatyzowanego uczenia maszynowego.

• Usługa Synapse Analytics umożliwia również korzystanie z funkcji uczenia maszynowego przy użyciu usług Azure Cognitive Services w celu rozwiązywania ogólnych problemów w różnych domenach, takich jak wykrywanie anomalii. Usług Cognitive Services można używać w usługach Azure Synapse, Azure Databricks oraz za pośrednictwem zestawów SDK i interfejsów API REST w aplikacjach klienckich.

• Azure Synapse natywnie integruje się z narzędziami Azure Data Factory w celu wyodrębniania, przekształcania i ładowania (ETL) lub pozyskiwania danych w potokach aranżacji.

• Azure Synapse umożliwia zewnętrzną rejestrację zestawu danych do danych przechowywanych w usłudze Azure Blob Storage lub Azure Data Lake Storage.

  • Zarejestrowane zestawy danych mogą być używane w zadaniach analizy danych puli platformy Synapse Spark.

• Usługę Azure Databricks można zintegrować z potokami usługi Azure Synapse Analytics w celu uzyskania dodatkowych możliwości platformy Spark.

  • Usługa Synapse organizuje odczytywanie danych i wysyłanie ich do klastra usługi Databricks, gdzie można je przekształcić i przygotować do trenowania modelu uczenia maszynowego.

• Dane źródłowe zwykle muszą być przygotowane do analizy i uczenia maszynowego.

  • Usługa Synapse oferuje różne narzędzia ułatwiające przygotowywanie danych, w tym apache Spark, notesy usługi Synapse i bezserwerowe pule SQL z językiem T-SQL i wbudowanymi wizualizacjami.

• Modele uczenia maszynowego, które zostały wytrenowane, zoperacjonalizowane i wdrożone, mogą być używane do oceniania wsadowego w usłudze Synapse.

  • Scenariusze AIOps, takie jak uruchamianie regresji lub przewidywania degradacji w potoku ciągłej integracji/ciągłego wdrażania, mogą wymagać oceniania w czasie rzeczywistym .

• Istnieją limity subskrypcji dla Azure Synapse, które powinny być w pełni zrozumiałe w kontekście metodologii AIOps.

• Aby w pełni uwzględnić metody AIOps, konieczne jest ciągłe wprowadzanie danych obserwacji niemal w czasie rzeczywistym do modeli wnioskowania uczenia maszynowego w czasie rzeczywistym.

  • Możliwości, takie jak wykrywanie anomalii, powinny być oceniane w strumieniu danych z możliwością obserwacji.

Zalecenia dotyczące projektowania

• Upewnij się, że wszystkie zasoby platformy Azure i składniki aplikacji są w pełni instrumentowane, aby pełny operacyjny zestaw danych był dostępny na potrzeby trenowania modelu AIOps.

• Pozyskiwanie danych operacyjnych usługi Log Analytics z globalnych i regionalnych kont usługi Azure Storage do Azure Synapse na potrzeby analizy.

• Użyj interfejsu API alertów usługi Azure Monitor, aby pobrać historyczne alerty i przechowywać je w zimnym magazynie na potrzeby danych operacyjnych w celu późniejszego użycia w modelach uczenia maszynowego. Jeśli jest używany eksport danych usługi Log Analytics, przechowuj historyczne dane alertów na tych samych kontach usługi Azure Storage co wyeksportowane dane usługi Log Analytics.

• Po przygotowaniu pozyskanych danych do trenowania uczenia maszynowego zapisz je w usłudze Azure Storage, aby było dostępne do trenowania modelu uczenia maszynowego bez konieczności uruchamiania zasobów obliczeniowych przygotowywania danych usługi Synapse.

• Upewnij się, że operacjonalizacja modelu uczenia maszynowego obsługuje ocenianie wsadowe i w czasie rzeczywistym.

• W miarę tworzenia modeli AIOps zaimplementuj metodykę MLOps i zastosuj praktyki DevOps, aby zautomatyzować cykl życia uczenia maszynowego na potrzeby trenowania, operacjonalizacji, oceniania i ciągłego ulepszania. Utwórz iteracyjny proces ciągłej integracji/ciągłego wdrażania dla modeli uczenia maszynowego AIOps.

• Oceń usługi Azure Cognitive Services pod kątem konkretnych scenariuszy predykcyjnych ze względu na niskie koszty administracyjne i związane z integracją. Rozważ wykrywanie anomalii , aby szybko oznaczyć nieoczekiwane wariancji w strumieniach danych z możliwościami obserwacji.

Następny krok

Zapoznaj się z zagadnieniami dotyczącymi wdrażania i testowania.

Wdrażanie i testowanie