Udostępnij za pośrednictwem

Używanie rozszerzenia Application Health z zestawami skalowania maszyn wirtualnych

  • Artykuł

Monitorowanie kondycji aplikacji jest ważnym sygnałem do zarządzania i uaktualniania wdrożenia. Zestawy skalowania maszyn wirtualnych platformy Azure zapewniają obsługę uaktualnień stopniowego, w tym automatycznych uaktualnień obrazów systemu operacyjnego i automatycznego stosowania poprawek gościa maszyn wirtualnych, które polegają na monitorowaniu kondycji poszczególnych wystąpień w celu uaktualnienia wdrożenia. Za pomocą rozszerzenia usługi Application Health można również monitorować kondycję aplikacji każdego wystąpienia w zestawie skalowania i wykonywać naprawy wystąpień przy użyciu automatycznych napraw wystąpień.

W tym artykule opisano sposób używania dwóch typów rozszerzeń usługi Application Health, Stanów kondycji binarnej lub Bogatych stanów kondycji w celu monitorowania kondycji aplikacji wdrożonych w zestawach skalowania maszyn wirtualnych.

Wymagania wstępne

W tym artykule założono, że znasz następujące elementy:

Uwaga

Rozszerzenie kondycji aplikacji oczekuje, że otrzyma spójną odpowiedź sondy na skonfigurowanym porcie tcp lub ścieżce http/https żądania, aby oznaczyć maszynę wirtualną jako w dobrej kondycji. Jeśli na maszynie wirtualnej nie jest uruchomiona żadna aplikacja lub nie możesz skonfigurować odpowiedzi sondy, maszyna wirtualna będzie wyświetlana jako w złej kondycji (stany kondycji binarnej) lub Nieznana (zaawansowane stany kondycji). Zobacz przykłady kondycji aplikacji, aby zapoznać się z przykładami odpowiedzi sondy kondycji emitowanych do lokalnego punktu końcowego.

Uwaga

Dla zestawu skalowania maszyn wirtualnych można użyć tylko jednego źródła monitorowania kondycji— rozszerzenia kondycji aplikacji lub sondy kondycji. Jeśli obie opcje są włączone, należy je usunąć przed użyciem usług orkiestracji, takich jak naprawy wystąpień lub automatyczne uaktualnienia systemu operacyjnego.

Kiedy należy używać rozszerzenia Application Health

Rozszerzenie kondycji aplikacji jest wdrażane w wystąpieniu zestawu skalowania maszyn wirtualnych i raportuje kondycję aplikacji z poziomu wystąpienia zestawu skalowania. Sondy rozszerzenia w lokalnym punkcie końcowym aplikacji i zaktualizują stan kondycji na podstawie odpowiedzi TCP/HTTP odebranych z aplikacji. Ten stan kondycji jest używany przez platformę Azure do inicjowania napraw w wystąpieniach w złej kondycji i określenia, czy wystąpienie kwalifikuje się do operacji uaktualniania.

Rozszerzenie zgłasza kondycję z poziomu maszyny wirtualnej i może być używane w sytuacjach, gdy nie można używać sondy zewnętrznej, takiej jak sondy kondycji usługi Azure Load Balancer.

Stany binarne i Bogate stany kondycji

Rozszerzenia kondycji aplikacji mają dwie dostępne opcje: Stan kondycji binarnej i Zaawansowane stany kondycji. W poniższej tabeli przedstawiono niektóre kluczowe różnice między dwiema opcjami. Zapoznaj się z końcem tej sekcji, aby uzyskać ogólne zalecenia.

Funkcje Stany kondycji binarnej Zaawansowane stany zdrowia
Dostępne stany kondycji Dwa dostępne stany: w dobrej kondycji, w złej kondycji Cztery dostępne stany: W dobrej kondycji, W złej kondycji, Inicjowanie, Nieznany1
Wysyłanie sygnałów kondycji Sygnały kondycji są wysyłane za pośrednictwem kodów odpowiedzi HTTP/HTTPS lub połączeń TCP. Sygnały kondycji protokołu HTTP/HTTPS są wysyłane za pośrednictwem kodu odpowiedzi sondy i treści odpowiedzi. Sygnały kondycji za pośrednictwem protokołu TCP pozostają niezmienione z binarnych stanów kondycji.
Identyfikowanie wystąpień w złej kondycji Wystąpienia automatycznie wpadną w stan złej kondycji, jeśli sygnał w dobrej kondycji nie zostanie odebrany z aplikacji. Wystąpienie w złej kondycji może wskazywać problem z konfiguracją rozszerzenia (na przykład niedostępnym punktem końcowym) lub problemem z aplikacją (na przykład kodem stanu innym niż 200). Wystąpienia staną się w złej kondycji tylko wtedy, gdy aplikacja emituje odpowiedź sondy w złej kondycji. Użytkownicy są odpowiedzialni za implementację logiki niestandardowej w celu identyfikowania i flagowania wystąpień z aplikacjamiw złej kondycji 2. Wystąpienia z nieprawidłowymi ustawieniami rozszerzenia (na przykład niedostępnym punktem końcowym) lub nieprawidłowe odpowiedzi sondy kondycji będą w stanie Nieznany 2.
Inicjowanie stanu dla nowo utworzonych wystąpień Stan inicjowania jest niedostępny. Nowo utworzone wystąpienia mogą zająć trochę czasu przed osiedleniem się w stanie stabilnym. Inicjowanie stanu umożliwia nowo utworzonym wystąpieniom osiedlenie się w stałym stanie kondycji przed przystąpieniem wystąpienia do uaktualniania stopniowego lub operacji naprawy wystąpienia.
Protokół HTTP/HTTPS Obsługiwane Obsługiwane
Protokół TCP Obsługiwane Ograniczona obsługa — nieznany stan jest niedostępny w protokole TCP. Zobacz tabelę protokołu Rich Health States dla zachowania stanu kondycji w protokole TCP.

1 Nieznany stan jest niedostępny w protokole TCP. 2 Dotyczy tylko protokołu HTTP/HTTPS. Protokół TCP będzie postępować zgodnie z tym samym procesem identyfikowania wystąpień w złej kondycji co w stanach kondycji binarnej.

Ogólnie rzecz biorąc, należy użyć stanów kondycji binarnej, jeśli:

  • Nie interesuje Cię konfigurowanie logiki niestandardowej w celu identyfikowania i flagowania wystąpienia w złej kondycji
  • Nie trzeba inicjować okresu prolongaty dla nowo utworzonych wystąpień

Należy użyć stanów rich health , jeśli:

  • Sygnały kondycji są wysyłane za pośrednictwem protokołu HTTP/HTTPS i mogą przesyłać informacje o kondycji za pośrednictwem treści odpowiedzi sondy
  • Chcesz użyć logiki niestandardowej do identyfikowania i oznaczania wystąpień w złej kondycji
  • Chcesz ustawić okres prolongaty inicjowania dla nowo utworzonych wystąpień, aby osiedlić się w stałym stanie kondycji przed wprowadzeniem wystąpienia kwalifikującego się do uaktualnienia stopniowego lub napraw wystąpień

Stany kondycji binarnej

Raportowanie stanu kondycji binarnej zawiera dwa stany kondycji, w dobrej kondycji i złą kondycję. W poniższych tabelach przedstawiono krótki opis sposobu konfigurowania stanów kondycji.

Protokół HTTP/HTTPS

Protokół Stan kondycji opis
http/https Dobra kondycja Aby wysłać sygnał w dobrej kondycji, aplikacja powinna zwrócić kod odpowiedzi 200.
http/https Nieprawidłowy Wystąpienie zostanie oznaczone jako W złej kondycji , jeśli kod odpowiedzi 200 nie zostanie odebrany z aplikacji.

Protokół TCP

Protokół Stan kondycji opis
TCP Dobra kondycja Aby wysłać sygnał w dobrej kondycji, należy wykonać pomyślne uzgadnianie z podanym punktem końcowym aplikacji.
TCP Nieprawidłowy Wystąpienie zostanie oznaczone jako W złej kondycji , jeśli wystąpił błąd lub niekompletne uzgadnianie z podanym punktem końcowym aplikacji.

Niektóre scenariusze, które mogą powodować złą kondycję, obejmują:

  • Gdy punkt końcowy aplikacji zwraca kod stanu inny niż 200
  • Jeśli w wystąpieniach maszyn wirtualnych nie skonfigurowano żadnego punktu końcowego aplikacji w celu zapewnienia stanu kondycji aplikacji
  • Gdy punkt końcowy aplikacji jest niepoprawnie skonfigurowany
  • Gdy punkt końcowy aplikacji nie jest osiągalny

Zaawansowane stany zdrowia

Raport Rich Health States zawiera cztery stany kondycji, inicjowanie, w dobrej kondycji, złą kondycję i nieznany. W poniższych tabelach przedstawiono krótki opis sposobu konfigurowania poszczególnych stanów kondycji.

Protokół HTTP/HTTPS

Protokół Stan kondycji opis
http/https Dobra kondycja Aby wysłać sygnał w dobrej kondycji, aplikacja powinna zwrócić odpowiedź sondy z: Kod odpowiedzi sondy: Stan 2xx, Treść odpowiedzi sondy:{"ApplicationHealthState": "Healthy"}
http/https Nieprawidłowy Aby wysłać sygnał w złej kondycji , aplikacja powinna zwrócić odpowiedź sondy z: Kod odpowiedzi sondy: Stan 2xx, Treść odpowiedzi sondy: {"ApplicationHealthState": "Unhealthy"}
http/https Inicjowanie Wystąpienie automatycznie wprowadza stan inicjowania w czasie rozpoczęcia rozszerzenia. Aby uzyskać więcej informacji, zobacz Inicjowanie stanu.
http/https Nieznane W następujących scenariuszach może wystąpić nieznany stan: gdy przez aplikację jest zwracany kod stanu inny niż 2xx, gdy limit czasu żądania sondy, gdy punkt końcowy aplikacji jest niemożliwy do osiągnięcia lub niepoprawnie skonfigurowany, gdy w treści odpowiedzi zostanie podana ApplicationHealthState brak lub nieprawidłowa wartość, lub gdy okres prolongaty wygaśnie. Aby uzyskać więcej informacji, zobacz Nieznany stan.

Protokół TCP

Protokół Stan kondycji opis
TCP Dobra kondycja Aby wysłać sygnał w dobrej kondycji, należy wykonać pomyślne uzgadnianie z podanym punktem końcowym aplikacji.
TCP Nieprawidłowy Wystąpienie zostanie oznaczone jako W złej kondycji , jeśli wystąpił błąd lub niekompletne uzgadnianie z podanym punktem końcowym aplikacji.
TCP Inicjowanie Wystąpienie automatycznie wprowadza stan inicjowania w czasie rozpoczęcia rozszerzenia. Aby uzyskać więcej informacji, zobacz Inicjowanie stanu.

Inicjowanie stanu

Ten stan dotyczy tylko stanów bogatych kondycji. Stan inicjowania występuje tylko raz w czasie rozpoczęcia rozszerzenia i można go skonfigurować za pomocą ustawień gracePeriod rozszerzenia i numberOfProbes.

Podczas uruchamiania rozszerzenia kondycja aplikacji pozostanie w stanie Inicjowanie do momentu wystąpienia jednego z dwóch scenariuszy:

  • Ten sam stan kondycji (w dobrej kondycji lub złej kondycji) jest zgłaszany kolejną liczbę razy skonfigurowaną za pośrednictwem parametru numberOfProbes
  • Wygasa gracePeriod

Jeśli ten sam stan kondycji (w dobrej kondycji lub złej kondycji) jest zgłaszany kolejno, kondycja aplikacji przejdzie z stanu Inicjowanie i do zgłoszonego stanu kondycji (w dobrej kondycji lub złej kondycji).

Przykład

Jeśli numberOfProbes = 3, oznacza to:

  • Aby przejść z inicjowania do stanu w dobrej kondycji: rozszerzenie kondycji aplikacji musi odbierać trzy kolejne sygnały w dobrej kondycji za pośrednictwem protokołu HTTP/HTTPS lub TCP
  • Aby przejść z Inicjowanie do stanu złej kondycji: rozszerzenie kondycji aplikacji musi otrzymywać trzy kolejne sygnały w złej kondycji za pośrednictwem protokołu HTTP/HTTPS lub TCP

Jeśli stan gracePeriod kondycji wygasa przed wystąpieniem kolejnej kondycji zostanie zgłoszony przez aplikację, kondycja wystąpienia zostanie określona w następujący sposób:

  • Protokół HTTP/HTTPS: kondycja aplikacji przejdzie z Inicjowanie do Nieznane
  • Protokół TCP: kondycja aplikacji przejdzie z inicjowania do złej kondycji

Nieznany stan

Ten stan dotyczy tylko stanów bogatych kondycji. Nieznany stan jest zgłaszany tylko dla sond "http" lub "https" i występuje w następujących scenariuszach:

  • Gdy przez aplikację jest zwracany kod stanu innego niż 2xx
  • Gdy żądanie sondy upłynął limit czasu
  • Gdy punkt końcowy aplikacji jest niemożliwy do osiągnięcia lub niepoprawnie skonfigurowany
  • W przypadku podania ApplicationHealthState brakującej lub nieprawidłowej wartości w treści odpowiedzi
  • Kiedy okres prolongaty wygaśnie

Wystąpienie w stanie Nieznany jest traktowane podobnie jak wystąpienie w złej kondycji . Jeśli to ustawienie zostanie włączone, naprawy wystąpień zostaną wykonane w nieznanym wystąpieniu, podczas gdy uaktualnienia stopniowe zostaną wstrzymane, dopóki wystąpienie nie powróci do stanu w dobrej kondycji.

W poniższej tabeli przedstawiono interpretację stanu kondycji dla uaktualnień stopniowego i napraw wystąpień:

Stan kondycji Interpretacja uaktualnienia stopniowego Wyzwalacz napraw wystąpień
Inicjowanie Poczekaj, aż stan będzie w dobrej kondycji, w złej kondycji lub nieznany Nie.
Dobra kondycja Dobra kondycja Nie.
Nieprawidłowy Nieprawidłowy Tak
Nieznane Nieprawidłowy Tak

Schemat rozszerzenia dla stanów kondycji binarnej

Poniższy kod JSON przedstawia schemat rozszerzenia Application Health. Rozszerzenie wymaga co najmniej żądania "tcp", "http" lub "https" z skojarzonym portem lub ścieżką żądania odpowiednio.

{
  "extensionProfile" : {
     "extensions" : [
      {
        "name": "HealthExtension",
        "properties": {
          "publisher": "Microsoft.ManagedServices",
          "type": "<ApplicationHealthLinux or ApplicationHealthWindows>",
          "autoUpgradeMinorVersion": true,
          "typeHandlerVersion": "1.0",
          "settings": {
            "protocol": "<protocol>",
            "port": <port>,
            "requestPath": "</requestPath>",
            "intervalInSeconds": 5,
            "numberOfProbes": 1
          }
        }
      }
    ]
  }
}

Wartości właściwości

Nazwisko Wartość / przykład Typ danych
apiVersion 2018-10-01 data
wydawca Microsoft.ManagedServices string
type ApplicationHealthLinux (Linux), ApplicationHealthWindows (Windows) string
typeHandlerVersion 1.0 string

Ustawienia

Nazwisko Wartość / przykład Typ danych
protokół httplub lub httpstcp string
port Opcjonalnie, gdy protokół jest http lub https, obowiązkowy, gdy protokół jest tcp int
requestPath Obowiązkowe, gdy protokół jest lub https, nie jest http dozwolony, gdy protokół jesttcp string
intervalInSeconds Opcjonalnie wartość domyślna to 5 sekund. Jest to interwał między poszczególnymi sondami kondycji. Jeśli na przykład intervalInSeconds == 5, sonda zostanie wysłana do lokalnego punktu końcowego aplikacji co 5 sekund. int
numberOfProbes Opcjonalnie wartość domyślna to 1. Jest to liczba kolejnych sond wymaganych do zmiany stanu kondycji. Jeśli na przykład numberOfProbles == 3, konieczne będzie 3 kolejne sygnały "W dobrej kondycji", aby zmienić stan kondycji z "W złej kondycji" na stan "W dobrej kondycji". To samo wymaganie dotyczy zmiany stanu kondycji na stan "W złej kondycji". int

Schemat rozszerzenia dla stanów rozbudowanej kondycji

Poniższy kod JSON przedstawia schemat rozszerzenia Rich Health States. Rozszerzenie wymaga co najmniej żądania "http" lub "https" z skojarzonym portem lub ścieżką żądania odpowiednio. Sondy TCP są również obsługiwane, ale nie będą mogły ustawić ApplicationHealthState elementu za pośrednictwem treści odpowiedzi sondy i nie będą miały dostępu do stanu Nieznany .

{
  "extensionProfile" : {
     "extensions" : [
      {
        "name": "HealthExtension",
        "properties": {
          "publisher": "Microsoft.ManagedServices",
          "type": "<ApplicationHealthLinux or ApplicationHealthWindows>",
          "autoUpgradeMinorVersion": true,
          "typeHandlerVersion": "2.0",
          "settings": {
            "protocol": "<protocol>",
            "port": <port>,
            "requestPath": "</requestPath>",
            "intervalInSeconds": 5,
            "numberOfProbes": 1,
            "gracePeriod": 600
          }
        }
      }
    ]
  }
}

Wartości właściwości

Nazwisko Wartość / przykład Typ danych
apiVersion 2018-10-01 data
wydawca Microsoft.ManagedServices string
type ApplicationHealthLinux (Linux), ApplicationHealthWindows (Windows) string
typeHandlerVersion 2.0 string

Ustawienia

Nazwisko Wartość / przykład Typ danych
protokół httplub lub httpstcp string
port Opcjonalnie, gdy protokół jest http lub https, obowiązkowy, gdy protokół jest tcp int
requestPath Obowiązkowe, gdy protokół jest lub https, nie jest http dozwolony, gdy protokół jesttcp string
intervalInSeconds Opcjonalnie wartość domyślna to 5 sekund. Jest to interwał między poszczególnymi sondami kondycji. Jeśli na przykład intervalInSeconds == 5, sonda zostanie wysłana do lokalnego punktu końcowego aplikacji co 5 sekund. int
numberOfProbes Opcjonalnie wartość domyślna to 1. Jest to liczba kolejnych sond wymaganych do zmiany stanu kondycji. Jeśli na przykład numberOfProbles == 3, będziesz potrzebować 3 kolejnych sygnałów "W dobrej kondycji", aby zmienić stan kondycji z "W złej kondycji"/"Nieznany" na stan "W dobrej kondycji". To samo wymaganie dotyczy zmiany stanu kondycji na stan "W złej kondycji" lub "Nieznany". int
gracePeriod Opcjonalne, domyślne = intervalInSeconds * numberOfProbes; maksymalny okres prolongaty wynosi 7200 sekund int

Wdrażanie rozszerzenia Application Health

Istnieje wiele sposobów wdrażania rozszerzenia Application Health w zestawach skalowania zgodnie z poniższymi przykładami.

Stany kondycji binarnej

W poniższym przykładzie dodano rozszerzenie Application Health (o nazwie myHealthExtension) do rozszerzeniaProfile w modelu zestawu skalowania zestawu skalowania opartego na systemie Windows.

Możesz również użyć tego przykładu, aby zmienić istniejące rozszerzenie z Rich Health State na Binary Health, wykonując wywołanie PATCH zamiast PUT.

PUT on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/extensions/myHealthExtension?api-version=2018-10-01`

{
  "name": "myHealthExtension",
  "location": "<location>", 
  "properties": {
    "publisher": "Microsoft.ManagedServices",
    "type": "ApplicationHealthWindows",
    "autoUpgradeMinorVersion": true,
    "typeHandlerVersion": "1.0",
    "settings": {
      "protocol": "<protocol>",
      "port": <port>,
      "requestPath": "</requestPath>"
    }
  }
}

Użyj PATCH polecenia , aby edytować już wdrożone rozszerzenie.

Uaktualnij maszyny wirtualne, aby zainstalować rozszerzenie.

POST on `/subscriptions/<subscriptionId>/resourceGroups/<myResourceGroup>/providers/Microsoft.Compute/virtualMachineScaleSets/< myScaleSet >/manualupgrade?api-version=2022-08-01`

{
  "instanceIds": ["*"]
}

Zaawansowane stany zdrowia

W poniższym przykładzie dodano rozszerzenie Application Health — Rich States (o nazwie myHealthExtension) do extensionProfile modelu w zestawie skalowania zestawu skalowania opartego na systemie Windows.

Możesz również użyć tego przykładu, aby uaktualnić istniejące rozszerzenie z plików binarnych do bogatych stanów kondycji, wykonując wywołanie PATCH zamiast put.

PUT on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/extensions/myHealthExtension?api-version=2018-10-01`

{
  "name": "myHealthExtension",
  "location": "<location>",
  "properties": {
    "publisher": "Microsoft.ManagedServices",
    "type": "ApplicationHealthWindows",
    "autoUpgradeMinorVersion": true,
    "typeHandlerVersion": "2.0",
    "settings": {
      "protocol": "<protocol>",
      "port": <port>,
      "requestPath": "</requestPath>",
      "intervalInSeconds": <intervalInSeconds>,
      "numberOfProbes": <numberOfProbes>,
      "gracePeriod": <gracePeriod>
    }
  }
}

Użyj PATCH polecenia , aby edytować już wdrożone rozszerzenie.

Uaktualnij maszyny wirtualne, aby zainstalować rozszerzenie.

POST on `/subscriptions/<subscriptionId>/resourceGroups/<myResourceGroup>/providers/Microsoft.Compute/virtualMachineScaleSets/< myScaleSet >/manualupgrade?api-version=2022-08-01`

{
  "instanceIds": ["*"]
}

Rozwiązywanie problemów

Potrzebna pomoc dotycząca konfigurowania odpowiedzi sondy

Zobacz przykłady kondycji aplikacji, aby zapoznać się z przykładami odpowiedzi sondy kondycji emitowanych do lokalnego punktu końcowego.

Wyświetlanie kondycji maszyny wirtualnej — pojedyncze wystąpienie

Get-AzVmssVM 
  -InstanceView `
  -ResourceGroupName <rgName> `
  -VMScaleSetName <vmssName> `
  -InstanceId <instanceId>

Wyświetlanie kondycji maszyny wirtualnej — wywołanie wsadowe

Jest to dostępne tylko w przypadku zestawów skalowania maszyn wirtualnych z jednolitą aranżacją.

GET on `/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Compute/virtualMachineScaleSets/<vmssName>/virtualMachines/?api-version=2022-03-01&$expand=instanceview`

Stan kondycji nie jest wyświetlany

Jeśli stan kondycji nie jest wyświetlany w witrynie Azure Portal lub za pośrednictwem wywołania GET, sprawdź, czy maszyna wirtualna została uaktualniona do najnowszego modelu. Jeśli maszyna wirtualna nie znajduje się w najnowszym modelu, uaktualnij maszynę wirtualną i zostanie wyświetlony stan kondycji.

Dziennik danych wyjściowych wykonywania rozszerzenia

Dane wyjściowe wykonywania rozszerzenia są rejestrowane w plikach znajdujących się w następujących katalogach:

C:\WindowsAzure\Logs\Plugins\Microsoft.ManagedServices.ApplicationHealthWindows\<version>\

/var/lib/waagent/Microsoft.ManagedServices.ApplicationHealthLinux-<extension_version>/status
/var/log/azure/applicationhealth-extension

Dzienniki okresowo przechwytują również stan kondycji aplikacji.

Następne kroki

Dowiedz się, jak wdrożyć aplikację w zestawach skalowania maszyn wirtualnych.