Azure Metadata Service: zaplanowane zdarzenia dla maszyn wirtualnych z systemem Windows

Dotyczy: ✔️ Maszyny wirtualne z systemem Windows ✔️ Elastyczne zestawy skalowania ✔️ Jednolite zestawy skalowania

Usługa Scheduled Events to usługa podrzędna usługi Azure Metadata Service, która zapewnia aplikacji czas na przygotowanie się do konserwacji maszyny wirtualnej. Udostępnia informacje o nadchodzących zdarzeniach konserwacji (na przykład ponownym rozruchu), dzięki czemu aplikacja może przygotować się do nich i ograniczyć przerwy w działaniu. Jest dostępna dla wszystkich typów usługi Azure Virtual Machines, w tym PaaS i IaaS, zarówno w systemie Windows, jak i Linux.

Aby uzyskać informacje o zaplanowanych zdarzeniach w systemie Linux, zobacz Zaplanowane zdarzenia dla maszyn wirtualnych z systemem Linux.

Zaplanowane zdarzenia zapewniają proaktywne powiadomienia dotyczące nadchodzących zdarzeń, aby uzyskać reaktywne informacje o zdarzeniach, które wystąpiły w przeszłości, zobacz Informacje o dostępności maszyny wirtualnej w usłudze Azure Resource Graph i Tworzenie reguły alertu dotyczącego dostępności dla maszyny wirtualnej platformy Azure.

Dlaczego warto używać zaplanowanych zdarzeń?

Wiele aplikacji może skorzystać z czasu na przygotowanie się do konserwacji maszyny wirtualnej. Czas może służyć do wykonywania zadań specyficznych dla aplikacji, które zwiększają dostępność, niezawodność i możliwości obsługi, w tym:

• Punkt kontrolny i przywracanie.
• Opróżnianie połączenia.
• Przełączenie awaryjne repliki podstawowej.
• Usuwanie z puli modułu równoważenia obciążenia.
• Rejestrowanie zdarzeń.
• Łagodne zamknięcie.

Dzięki zaplanowanym zdarzeniom twoja aplikacja może rozpoznać, kiedy nastąpi konserwacja, i wyzwolić zadania w celu ograniczenia ich wpływu.

Zdarzenia zaplanowane udostępniają zdarzenia w następujących przypadkach użycia:

• Zainicjowana konserwacja platformy (na przykład ponowne uruchomienie maszyny wirtualnej, migracja na żywo lub aktualizacje zachowujące pamięć dla hosta).
• Maszyna wirtualna działa na uszkodzonym sprzęcie hosta, który ma wkrótce zawieść.
• Maszyna wirtualna była uruchomiona na hoście, który doznał awarii sprzętu.
• Konserwacja zainicjowana przez użytkownika (na przykład ponowne uruchomienie lub ponowne wdrożenie maszyny wirtualnej przez użytkownika).
• Eksmisje wystąpień maszyn wirtualnych typu spot i zestawu skalowania typu spot.

Podstawy

Usługa Metadata Service udostępnia informacje o uruchamianiu maszyn wirtualnych przy użyciu punktu końcowego REST dostępnego z poziomu maszyny wirtualnej. Te informacje są dostępne za pośrednictwem nieroutowalnego adresu IP i nie są widoczne poza maszyną wirtualnej.

Zakres

Zaplanowane zdarzenia są dostarczane i mogą być potwierdzane przez:

• Autonomiczne maszyny wirtualne.
• Wszystkie maszyny wirtualne w usłudze w chmurze platformy Azure (wersja klasyczna)
• Wszystkie maszyny wirtualne w grupie dostępności.
• Wszystkie maszyny wirtualne w grupie rozmieszczenia zestawu skalowania.

Zaplanowane zdarzenia dla wszystkich maszyn wirtualnych w całym zestawie dostępności lub grupie umieszczania w zestawie skalowania maszyn wirtualnych są przekazywane do wszystkich pozostałych maszyn wirtualnych w tej samej grupie lub zestawie, niezależnie od tego, czy strefa dostępności jest używana.

W związku z tym sprawdź Resources pole w zdarzeniu, w celu określenia, które maszyny wirtualne są dotknięte.

Odnajdywanie punktów końcowych

W przypadku maszyn wirtualnych z włączoną siecią wirtualną, usługa metadanych jest dostępna na podstawie statycznego nieroutowalnego adresu IP, 169.254.169.254. Pełny punkt końcowy dla najnowszej wersji zaplanowanych zdarzeń to:

http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01

Jeśli maszyna wirtualna nie została utworzona w ramach sieci wirtualnej, domyślne przypadki usług w chmurze i klasycznych maszyn wirtualnych wymagają innej logiki, aby odnaleźć adres IP do użycia. Aby dowiedzieć się, jak odnaleźć punkt końcowy hosta, zobacz ten przykład.

Dostępność wersji i regionu

Usługa Zaplanowane zdarzenia jest wersjonowana. Wersje są obowiązkowe; bieżąca wersja to 2020-07-01.

Włączanie i wyłączanie zaplanowanych zdarzeń

Funkcja planowania zdarzeń jest włączana dla twojej usługi przy pierwszym zapytaniu o zdarzenia. Należy oczekiwać opóźnienia odpowiedzi podczas pierwszego wywołania do dwóch minut i rozpoczniesz odbieranie zdarzeń w ciągu 5 minut. Zaplanowane zdarzenia są wyłączone dla usługi, jeśli nie wysyła żądania do punktu końcowego przez 24 godziny.

Konserwacja inicjowana przez użytkownika

Konserwacja maszyny wirtualnej zainicjowana przez użytkownika za pośrednictwem witryny Azure Portal, interfejsu API, interfejsu wiersza polecenia lub programu PowerShell powoduje wystąpienie zaplanowanego zdarzenia. Następnie można przetestować logikę przygotowywania konserwacji w aplikacji, a aplikacja może przygotować się do konserwacji zainicjowanej przez użytkownika.

Jeśli uruchomisz ponownie maszynę wirtualną, zaplanowane jest zdarzenie o typie Reboot . Jeśli ponownie wdrożysz maszynę wirtualną, zaplanowane jest zdarzenie o typie Redeploy . Zazwyczaj zdarzenia ze źródłem zdarzeń użytkownika można natychmiast zatwierdzić, aby uniknąć opóźnień w akcjach inicjowanych przez użytkownika. Zalecamy komunikację podstawowej i pomocniczej maszyny wirtualnej oraz zatwierdzanie zaplanowanych zdarzeń generowanych przez użytkownika w przypadku, gdy podstawowa maszyna wirtualna przestanie odpowiadać. Natychmiastowe zatwierdzanie zdarzeń zapobiega opóźnieniom przywracania aplikacji do właściwego stanu.

Zaplanowane zdarzenia dla uaktualnień lub tworzenia obrazów systemu operacyjnego gościa skalowanych zestawów maszyn wirtualnych są obsługiwane tylko dla rozmiarów maszyn wirtualnych ogólnego przeznaczenia, które obsługują jedynie aktualizacje z zachowaniem danych w pamięci. Nie działa w przypadku serii G, M, N i H. Zaplanowane zdarzenia dotyczące uaktualnień systemu operacyjnego gościa oraz przywracania obrazów w zestawach skalowania maszyn wirtualnych są domyślnie wyłączone. Aby włączyć zaplanowane zdarzenia dla tych operacji na obsługiwanych rozmiarach maszyn wirtualnych, najpierw włącz je, używając OSImageNotificationProfile.

Użyj interfejsu API

Przegląd ogólny

Istnieją dwa główne elementy w obsłudze zaplanowanych zdarzeń: przygotowanie i odzyskiwanie. Wszystkie bieżące zaplanowane zdarzenia wpływające na maszynę wirtualną są dostępne do odczytu za pośrednictwem punktu końcowego zaplanowanych zdarzeń usługi IMDS. Gdy zdarzenie osiągnie stan końcowy, zostanie usunięte z listy zdarzeń. Na poniższym diagramie przedstawiono różne zmiany stanu, które może przechodzić pojedyncze zaplanowane zdarzenie.

W przypadku zdarzeń w stanie EventStatus:"Scheduled" należy wykonać kroki, aby przygotować swoje obciążenie. Po zakończeniu przygotowania należy zatwierdzić zdarzenie przy użyciu interfejsu API zaplanowanego zdarzenia. W przeciwnym razie zdarzenie zostanie automatycznie zatwierdzone, gdy zostanie osiągnięty czas NotBefore. Jeśli maszyna wirtualna znajduje się w udostępnionej infrastrukturze, system będzie czekać na wszystkich innych dzierżawców na tym samym sprzęcie, aby również zatwierdzić zadanie lub przekroczenie limitu czasu. Po zebraniu zatwierdzeń ze wszystkich maszyn wirtualnych, których to dotyczy, lub gdy osiągnięto czas NotBefore, platforma Azure generuje nowy zaplanowany ładunek zdarzenia ze statusem eventu: "Started" i rozpoczyna zdarzenie konserwacji. Gdy zdarzenie osiągnie stan końcowy, zostanie usunięte z listy zdarzeń. Służy to jako sygnał dla klienta w celu odzyskania maszyn wirtualnych.

Kod psudeo demonstruje proces odczytywania zaplanowanych zdarzeń w aplikacji i zarządzania nimi:

current_list_of_scheduled_events = get_latest_from_se_endpoint()
#prepare for new events
for each event in current_list_of_scheduled_events:
  if event not in previous_list_of_scheduled_events:
    prepare_for_event(event)
#recover from completed events
for each event in previous_list_of_scheduled_events:
  if event not in current_list_of_scheduled_events:
    receover_from_event(event)
#prepare for future jobs
previous_list_of_scheduled_events = current_list_of_scheduled_events

Ponieważ zaplanowane zdarzenia są często używane dla aplikacji z wymaganiami dotyczącymi wysokiej dostępności, istnieje kilka wyjątkowych przypadków, które należy wziąć pod uwagę:

1. Po zakończeniu zaplanowanego zdarzenia i jego usunięciu z tablicy, nie będzie żadnych dalszych skutków, chyba że pojawi się nowe zdarzenie, które będzie miało status "Scheduled".
2. Platforma Azure monitoruje operacje konserwacyjne całej infrastruktury i w rzadkich okolicznościach stwierdza, że operacja konserwacyjna jest zbyt ryzykowna, aby ją przeprowadzić. W takim przypadku zaplanowane zdarzenie przechodzi bezpośrednio z "Zaplanowane" do usunięcia z tablicy zdarzeń
3. Jeśli wystąpi awaria sprzętowa, platforma Azure pomija stan "Zaplanowane" i natychmiast przechodzi do stanu EventStatus:"Started".
4. Mimo że zdarzenie jest nadal w stanie EventStatus:"Started", może wystąpić inny wpływ o krótszym czasie trwania niż było to zapowiedziane w zaplanowanym zdarzeniu.

W ramach gwarancji dostępności platformy Azure maszyny wirtualne w różnych domenach błędów nie będą mieć wpływu na rutynowe operacje konserwacji w tym samym czasie. Jednak mogą one mieć operacje serializowane jedna po drugiej. Maszyny wirtualne w jednej domenie błędów mogą odbierać zaplanowane zdarzenia o statusie "Scheduled" wkrótce po zakończeniu konserwacji w innej domenie błędów. Niezależnie od wybranej architektury zawsze sprawdzaj, czy nowe zdarzenia oczekują na Twoje maszyny wirtualne.

Mimo że dokładne chronometraż zdarzeń różnią się, na poniższym diagramie przedstawiono przybliżone wskazówki dotyczące tego, jak przebiega typowa operacja konserwacji:

• StatusWydarzenia:"Zaplanowany" do momentu upływu limitu czasu na zatwierdzenie: 15 minut
• Czas trwania wpływu: 7 sekund
• Status zdarzenia: "Rozpoczęto" do Ukończono (zdarzenie usunięte z tablicy Zdarzeń): 10 minut

Wszystkie operacje wpływające na dostępność maszyny wirtualnej tworzą zaplanowane zdarzenie, jednak nie wszystkie zaplanowane zdarzenia są wyświetlane na innych powierzchniach platformy Azure, takich jak dzienniki aktywności platformy Azure lub kondycja zasobów. Regularne sprawdzanie harmonogramu wydarzeń gwarantuje, że masz najbardziej up-to-aktualne informacje o przyszłych wpływach na Twoje maszyny wirtualne.

Nagłówki

Podczas wykonywania zapytania w usłudze Metadata Service należy podać nagłówek Metadata:true , aby upewnić się, że żądanie nie zostało przypadkowo przekierowane. Nagłówek Metadata:true jest wymagany dla wszystkich żądań zaplanowanych zdarzeń. Niepowodzenie uwzględnienia nagłówka w żądaniu spowoduje odpowiedź "Nieprawidłowe żądanie" z usługi Metadata Service.

Wykonywanie zapytań dotyczących zdarzeń

Możesz wykonywać zapytania dotyczące zaplanowanych zdarzeń, wykonując następujące wywołanie:

Przykład Bash

curl -H Metadata:true http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01

Przykładowy skrypt programu PowerShell

Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri "http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01" | ConvertTo-Json -Depth 64

Przykład języka Python

import json
import requests

metadata_url ="http://169.254.169.254/metadata/scheduledevents"
header = {'Metadata' : 'true'}
query_params = {'api-version':'2020-07-01'}

def get_scheduled_events():           
    resp = requests.get(metadata_url, headers = header, params = query_params)
    data = resp.json()
    return data

Odpowiedź zawiera tablicę zaplanowanych zdarzeń. Pusta tablica oznacza, że obecnie nie zaplanowano żadnych zdarzeń. W przypadku wystąpienia zaplanowanych zdarzeń odpowiedź zawiera tablicę zdarzeń.

{
    "DocumentIncarnation": {IncarnationID},
    "Events": [
        {
            "EventId": {eventID},
            "EventType": "Reboot" | "Redeploy" | "Freeze" | "Preempt" | "Terminate",
            "ResourceType": "VirtualMachine",
            "Resources": [{resourceName}],
            "EventStatus": "Scheduled" | "Started",
            "NotBefore": {timeInUTC},       
            "Description": {eventDescription},
            "EventSource" : "Platform" | "User",
            "DurationInSeconds" : {timeInSeconds},
        }
    ]
}

Właściwości zdarzenia

Planowanie zdarzeń

Każde zdarzenie jest zaplanowane przez minimalny czas w przyszłości na podstawie typu zdarzenia. Tym razem jest odzwierciedlony we właściwości zdarzenia NotBefore.

Oznacza to, że można wykryć przyszły harmonogram zdarzenia co najmniej o minimalny czas powiadomienia przed wystąpieniem zdarzenia. Po zaplanowaniu zdarzenia zostanie ono przeniesione do Started stanu po jego zatwierdzeniu lub upływie NotBefore czasu. Jednak w rzadkich przypadkach operacja jest anulowana przez platformę Azure przed rozpoczęciem. W takim przypadku zdarzenie zostanie usunięte z tablicy Zdarzenia, a wpływ nie wystąpi zgodnie z wcześniejszym harmonogramem.

Częstotliwość sondowania

Możesz sprawdzać punkt końcowy pod kątem aktualizacji tak często lub rzadko, jak sobie życzysz. Jednak im dłuższy czas mija między żądaniami, tym więcej czasu potencjalnie tracisz na reakcję na nadchodzące zdarzenie. Większość zdarzeń ma od 5 do 15 minut powiadomienia, chociaż w niektórych przypadkach powiadomienie może wynosić zaledwie 30 sekund. Aby upewnić się, że masz jak najwięcej czasu na podjęcie działań zapobiegawczych, zalecamy sondowanie usługi co sekundę.

Uruchamianie zdarzenia

Po zapoznaniu się z nadchodzącym wydarzeniem i zakończeniu logiki bezpiecznego zamykania możesz zatwierdzić zaległe zdarzenie, wywołując usługę POST Metadata Service za pomocą polecenia EventId. To wywołanie wskazuje na platformę Azure, że może skrócić minimalny czas powiadomienia (jeśli to możliwe). Zdarzenie może nie zostać uruchomione natychmiast po zatwierdzeniu. W niektórych przypadkach platforma Azure wymaga zatwierdzenia wszystkich maszyn wirtualnych hostowanych w węźle przed kontynuowaniem zdarzenia.

W treści żądania oczekuje się następującego przykładu JSON POST. Żądanie powinno zawierać listę StartRequests. Każda StartRequest zawiera EventId związane z wydarzeniem, które chcesz przyspieszyć.

{
	"StartRequests" : [
		{
			"EventId": {EventId}
		}
	]
}

Usługa zawsze zwraca kod powodzenia 200, jeśli został przekazany prawidłowy identyfikator zdarzenia, nawet jeśli inna maszyna wirtualna już zatwierdziła zdarzenie. Kod błędu 400 wskazuje, że nagłówek lub ładunek żądania został źle sformułowany.

Przykład Bash

curl -H Metadata:true -X POST -d '{"StartRequests": [{"EventId": "f020ba2e-3bc0-4c40-a10b-86575a9eabd5"}]}' http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01

Przykładowy skrypt programu PowerShell

Invoke-RestMethod -Headers @{"Metadata" = "true"} -Method POST -body '{"StartRequests": [{"EventId": "5DD55B64-45AD-49D3-BBC9-F57D4EA97BD7"}]}' -Uri http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01 | ConvertTo-Json -Depth 64

Przykład języka Python

import json
import requests

def confirm_scheduled_event(event_id):  
   # This payload confirms a single event with id event_id
   payload = json.dumps({"StartRequests": [{"EventId": event_id }]})
   response = requests.post("http://169.254.169.254/metadata/scheduledevents", 
                            headers =  {'Metadata' : 'true'}, 
                            params = {'api-version':'2020-07-01'}, 
                            data = payload)    
   return response.status_code

Przykładowe odpowiedzi

Następujące zdarzenia to przykład z dwóch maszyn wirtualnych, które zostały zmigrowane na żywo do innego węzła.

DocumentIncarnation zmienia się za każdym razem, gdy w Events pojawia się nowa informacja. Zatwierdzenie zdarzenia pozwoliłoby na kontynuowanie blokowania zarówno dla WestNO_0, jak i WestNO_1.

{
    "DocumentIncarnation":  1,
    "Events":  [
               ]
}

{
    "DocumentIncarnation":  2,
    "Events":  [
                   {
                       "EventId":  "C7061BAC-AFDC-4513-B24B-AA5F13A16123",
                       "EventStatus":  "Scheduled",
                       "EventType":  "Freeze",
                       "ResourceType":  "VirtualMachine",
                       "Resources":  [
                                         "WestNO_0",
                                         "WestNO_1"
                                     ],
                       "NotBefore":  "Mon, 11 Apr 2022 22:26:58 GMT",
                       "Description":  "Virtual machine is being paused because of a memory-preserving Live Migration operation.",
                       "EventSource":  "Platform",
                       "DurationInSeconds":  5
                   }
               ]
}

{
    "DocumentIncarnation":  3,
    "Events":  [
                   {
                       "EventId":  "C7061BAC-AFDC-4513-B24B-AA5F13A16123",
                       "EventStatus":  "Started",
                       "EventType":  "Freeze",
                       "ResourceType":  "VirtualMachine",
                       "Resources":  [
                                         "WestNO_0",
                                         "WestNO_1"
                                     ],
                       "NotBefore":  "",
                       "Description":  "Virtual machine is being paused because of a memory-preserving Live Migration operation.",
                       "EventSource":  "Platform",
                       "DurationInSeconds":  5
                   }
               ]
}

{
    "DocumentIncarnation":  4,
    "Events":  [
               ]
}

Przykład języka Python

Przykład korzysta z usługi Metadata Service do wyszukiwania zaplanowanych zdarzeń i zatwierdza każde niezatwierdzone zdarzenie. Kod można znaleźć w repozytorium vm-scheduled-events-mock-server w pliku Listener.py.

#!/usr/bin/python
import json
import requests
from time import sleep

# The URL to access the metadata service
metadata_url ="http://169.254.169.254/metadata/scheduledevents"
# This must be sent otherwise the request will be ignored
header = {'Metadata' : 'true'}
# Current version of the API
query_params = {'api-version':'2020-07-01'}

def get_scheduled_events():           
    resp = requests.get(metadata_url, headers = header, params = query_params)
    data = resp.json()
    return data

def confirm_scheduled_event(event_id):  
    # This payload confirms a single event with id event_id
    # You can confirm multiple events in a single request if needed      
    payload = json.dumps({"StartRequests": [{"EventId": event_id }]})
    response = requests.post(metadata_url, 
                            headers= header,
                            params = query_params, 
                            data = payload)    
    return response.status_code

def log(event): 
    # This is an optional placeholder for logging events to your system 
    print(event["Description"])
    return

def advanced_sample(last_document_incarnation): 
    # Poll every second to see if there are new scheduled events to process
    # Since some events may have necessarily short warning periods, it is 
    # recommended to poll frequently
    found_document_incarnation = last_document_incarnation
    while (last_document_incarnation == found_document_incarnation):
        sleep(1)
        payload = get_scheduled_events()    
        found_document_incarnation = payload["DocumentIncarnation"]        
        
    # We recommend processing all events in a document together, 
    # even if you won't be actioning on them right away
    for event in payload["Events"]:

        # Events that already started, logged for tracking
        if (event["EventStatus"] == "Started"):
            log(event)
            
        # Approve all user initiated events. These are typically created by an 
        # administrator and approving them immediately can help to avoid delays 
        # in admin actions
        elif (event["EventSource"] == "User"):
            confirm_scheduled_event(event["EventId"])            
            
        # For this application, freeze events less that 9 seconds are considered
        # no impact. This will immediately approve them
        elif (event["EventType"] == "Freeze" and 
            int(event["DurationInSeconds"]) >= 0  and 
            int(event["DurationInSeconds"]) < 9):
            confirm_scheduled_event(event["EventId"])
            
        # Events that may be impactful (for example reboot or redeploy) may need custom 
        # handling for your application
        else: 
            #TODO Custom handling for impactful events
            log(event)
    print("Processed events from document: " + str(found_document_incarnation))
    return found_document_incarnation

def main():
    # This will track the last set of events seen 
    last_document_incarnation = "-1"

    input_text = "\
        Press 1 to poll for new events \n\
        Press 2 to exit \n "
    program_exit = False 

    while program_exit == False:
        user_input = input(input_text)    
        if (user_input == "1"):                        
            last_document_incarnation = advanced_sample(last_document_incarnation)
        elif (user_input == "2"):
            program_exit = True       

if __name__ == '__main__':
    main()

Testowanie zaplanowanych zdarzeń

Dwa typowe sposoby testowania odpowiedzi aplikacji na zaplanowane zdarzenia to ręczne wyzwalanie zdarzeń naśladowanych przez użytkownika lub używanie pozorowanego serwera.

Możesz ręcznie wyzwalać zdarzenia ponownego wdrażania i ponownego uruchamiania poprzez witrynę Azure Portal lub Interfejs wiersza polecenia Azure, wybierając opcję "reboot" lub "redeploy" maszyny wirtualnej na panelu maszyny wirtualnej. Spowoduje to utworzenie wydarzenia i wysłanie go do twojego zadania.

Operacje, które mają wpływ na wiele maszyn wirtualnych, takich jak aktualizacje hosta, nie mogą być wyzwalane na żądanie, aby zamiast tego można było użyć pozorowanego serwera. Serwer vm-scheduled-events-mock-server udostępnia platformę do testowania odpowiedzi aplikacji na różne scenariusze przez ponowne odtworzenie rzeczywistych przepływów zdarzeń na potrzeby programowania i testowania. Domyślnie serwer obsługuje 9 różnych scenariuszy, wszystkie przechwycone z maszyn wirtualnych działających na platformie Azure i reprezentujące najbardziej typowe przypadki. Scenariusze można rozszerzyć w celu uwzględnienia większej liczby opcji w zależności od określonych cech aplikacji.

Dalsze kroki

• Zapoznaj się z przykładami kodu zaplanowanych zdarzeń w repozytorium GitHub dla zaplanowanych zdarzeń Azure.
• Zapoznaj się z przykładami kodu zdarzeń zaplanowanych Node.js w repozytorium GitHub Azure Samples.
• Przeczytaj więcej na temat interfejsów API, które są dostępne w usłudze metadanych wystąpienia.
• Dowiedz się więcej o planowanej konserwacji maszyn wirtualnych z systemem Windows na platformie Azure.
• Dowiedz się, jak monitorować zaplanowane zdarzenia dla maszyn wirtualnych za pośrednictwem usługi Log Analytics.
• Dowiedz się, jak rejestrować zaplanowane zdarzenia przy użyciu usługi Azure Event Hubs w repozytorium GitHub przykładów platformy Azure.
• Użyj serwera vm-scheduled-events-mock-server , aby przetestować odpowiedź aplikacji na typowe scenariusze zdarzeń zaplanowanych.