Azure Metadata Service: Geplande gebeurtenissen voor Linux-VM’s
Van toepassing op: ✔️ Flexibele schaalsets ✔️ voor Linux-VM's ✔️ Uniform-schaalsets
Geplande gebeurtenissen is een Azure Metadata Service die uw toepassing tijd geeft om het onderhoud van virtuele machines (VM' s) voor te bereiden. Het bevat informatie over geplande onderhoudsevenementen (bijvoorbeeld opnieuw opstarten), zodat uw toepassing zich hierop kan voorbereiden en onderbrekingen kan beperken. Deze is beschikbaar voor alle typen Azure Virtual Machines, waaronder PaaS en IaaS op zowel Windows als Linux.
Zie Geplande gebeurtenissen voor Windows-VM's voor meer informatie over geplande gebeurtenissen in Windows.
Geplande gebeurtenissen bieden proactieve meldingen over aanstaande gebeurtenissen, voor reactieve informatie over gebeurtenissen die al zijn gebeurd, zie beschikbaarheidsinformatie voor VM's in Azure Resource Graph en regel voor beschikbaarheidswaarschuwingen maken voor virtuele Azure-machines.
Notitie
Geplande gebeurtenissen zijn algemeen beschikbaar in alle Azure-regio's. Zie De beschikbaarheid van versie en regio voor de meest recente release-informatie.
Waarom geplande gebeurtenissen gebruiken?
Veel toepassingen kunnen profiteren van tijd om het VM-onderhoud voor te bereiden. De tijd kan worden gebruikt om toepassingsspecifieke taken uit te voeren die de beschikbaarheid, betrouwbaarheid en servicebaarheid verbeteren, waaronder:
- Controlepunt en herstel.
- Verwerkingsstop voor verbindingen.
- Failover van primaire replica.
- Verwijderen uit een load balancer-pool.
- Gebeurtenislogboeken.
- Probleemloos afsluiten.
Met geplande gebeurtenissen kan uw toepassing detecteren wanneer onderhoud plaatsvindt en taken activeren om de impact ervan te beperken.
Geplande gebeurtenissen bieden gebeurtenissen in de volgende use cases:
- Door het platform geïnitieerd onderhoud (bijvoorbeeld het opnieuw opstarten van vm's, livemigratie of updates met geheugenbehoud voor de host).
- Virtuele machine wordt uitgevoerd op gedegradeerde hosthardware die binnenkort wordt voorspeld te mislukken.
- Virtuele machine werd uitgevoerd op een host die een hardwarefout heeft geleden.
- Door de gebruiker geïnitieerd onderhoud (een gebruiker start bijvoorbeeld opnieuw op of implementeert een VIRTUELE machine opnieuw).
- Verwijderingen van spot-VM en Spot-schaalsetexemplaren .
De basisbeginselen
Metadata Service toont informatie over het uitvoeren van VM's met behulp van een REST-eindpunt dat toegankelijk is vanuit de VIRTUELE machine. De informatie is beschikbaar via een niet-routable IP en wordt niet weergegeven buiten de VIRTUELE machine.
Bereik
Geplande gebeurtenissen worden geleverd aan en kunnen worden bevestigd door:
- Zelfstandige virtuele machines.
- Alle VM's in een Azure-cloudservice (klassiek).
- Alle VM's in een beschikbaarheidsset.
- Alle VM's in een plaatsingsgroep van een schaalset.
Geplande gebeurtenissen voor alle virtuele machines (VM's) in een volledige beschikbaarheidsset of een plaatsingsgroep voor een virtuele-machineschaalset worden geleverd aan alle andere VM's in dezelfde groep of set, ongeacht het gebruik van beschikbaarheidszones.
Als gevolg hiervan controleert u het Resources veld in de gebeurtenis om te bepalen welke VM's worden beïnvloed.
Notitie
Met GPU versnelde virtuele machines in een schaalset met behulp van 1 foutdomein (FD = 1) worden alleen geplande gebeurtenissen ontvangen voor de betrokken resource. Gebeurtenissen worden niet uitgezonden naar alle VM's in dezelfde plaatsingsgroep.
Eindpuntdetectie
Voor vm's met VNET is Metadata Service beschikbaar vanaf een statisch niet-routable IP-adres. 169.254.169.254 Het volledige eindpunt voor de nieuwste versie van Geplande gebeurtenissen is:
http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01
Als de VIRTUELE machine niet in een virtueel netwerk is gemaakt, zijn de standaardcases voor cloudservices en klassieke VM's extra logica vereist om het IP-adres te detecteren dat moet worden gebruikt. Zie dit voorbeeld voor meer informatie over het detecteren van het hosteindpunt.
Beschikbaarheid van versies en regio's
De service Geplande gebeurtenissen is geversied. Versies zijn verplicht; de huidige versie is 2020-07-01.
| Versie | Uitgavetypen | Regio's | Opmerkingen bij de release |
|---|---|---|---|
| 2020-07-01 | Algemene beschikbaarheid | Alle | |
| 2019-08-01 | Algemene beschikbaarheid | Alle | |
| 01-04-2019 | Algemene beschikbaarheid | Alle | |
| 2019-01-01 | Algemene beschikbaarheid | Alle | |
| 2017-11-01 | Algemene beschikbaarheid | Alle | |
| 2017-08-01 | Algemene beschikbaarheid | Alle | |
| 2017-03-01 | Preview uitvoeren | Alle |
Notitie
Vorige preview-versies van geplande gebeurtenissen ondersteunden {latest} als api-versie. Deze indeling wordt niet meer ondersteund en wordt in de toekomst afgeschaft.
Geplande gebeurtenissen in- en uitschakelen
Geplande gebeurtenissen worden ingeschakeld voor uw service wanneer u de eerste keer een aanvraag voor gebeurtenissen indient. U kunt een vertraagd antwoord verwachten in uw eerste oproep van maximaal twee minuten en u ontvangt binnen 5 minuten gebeurtenissen. Geplande gebeurtenissen zijn uitgeschakeld voor uw service als er gedurende 24 uur geen aanvraag naar het eindpunt wordt ingediend.
Door de gebruiker geïnitieerd onderhoud
Door de gebruiker geïnitieerd VM-onderhoud via Azure Portal, API, CLI of PowerShell resulteert in een geplande gebeurtenis. Vervolgens kunt u de logica voor onderhoudsvoorbereiding in uw toepassing testen en uw toepassing kan zich voorbereiden op door de gebruiker geïnitieerd onderhoud.
Als u een virtuele machine opnieuw opstart, wordt een gebeurtenis met het type Reboot gepland. Als u een VIRTUELE machine opnieuw implementeert, wordt een gebeurtenis met het type Redeploy gepland. Gebeurtenissen met een gebruikersgebeurtenisbron kunnen doorgaans onmiddellijk worden goedgekeurd om een vertraging bij door de gebruiker geïnitieerde acties te voorkomen. We raden u aan om een primaire en secundaire VM te laten communiceren en door de gebruiker gegenereerde geplande gebeurtenissen te goedkeuren voor het geval de primaire VM niet meer reageert. Het onmiddellijk goedkeuren van gebeurtenissen voorkomt vertragingen bij het terugzetten van uw toepassing naar een goede status.
Geplande gebeurtenissen voor upgrades of installatiekopieën van gastbesturingssystemen voor virtuele-machineschaalsets worden ondersteund voor VM-grootten voor algemeen gebruik die alleen updates met geheugenbehoud ondersteunen. Het werkt niet voor de G-, M-, N- en H-serie. Geplande gebeurtenissen voor upgrades en installatiekopieën van gastbesturingssystemen voor virtuele-machineschaalsets zijn standaard uitgeschakeld. Als u geplande gebeurtenissen wilt inschakelen voor deze bewerkingen op ondersteunde VM-grootten, moet u ze eerst inschakelen met osImageNotificationProfile.
De API gebruiken
Overzicht op hoog niveau
Er zijn twee belangrijke onderdelen voor het verwerken van geplande gebeurtenissen, voorbereiding en herstel. Alle huidige geplande gebeurtenissen die van invloed zijn op een virtuele machine, zijn beschikbaar om te lezen via het eindpunt voor geplande IMDS-gebeurtenissen. Wanneer de gebeurtenis een terminalstatus heeft bereikt, wordt deze verwijderd uit de lijst met gebeurtenissen. In het volgende diagram ziet u de verschillende statusovergangen die een enkele geplande gebeurtenis kan ervaren:
Voor gebeurtenissen met de status EventStatus:"Gepland" moet u stappen uitvoeren om uw workload voor te bereiden. Zodra de voorbereiding is voltooid, moet u de gebeurtenis goedkeuren met behulp van de geplande gebeurtenis-API. Anders wordt de gebeurtenis automatisch goedgekeurd wanneer de NotBefore-tijd is bereikt. Als de VIRTUELE machine zich in een gedeelde infrastructuur bevindt, wacht het systeem tot alle andere tenants op dezelfde hardware ook de taak of time-out goedkeuren. Zodra goedkeuringen zijn verzameld van alle betrokken VM's of de NotBefore-tijd is bereikt, genereert Azure een nieuwe nettolading voor geplande gebeurtenissen met EventStatus:'Gestart' en wordt het begin van de onderhoudsgebeurtenis geactiveerd. Wanneer de gebeurtenis een terminalstatus heeft bereikt, wordt deze verwijderd uit de lijst met gebeurtenissen. Dat fungeert als het signaal voor de klant om hun VM's te herstellen.
Hieronder ziet u psudeo-code waarmee een proces wordt gedemonstreerd voor het lezen en beheren van geplande gebeurtenissen in uw toepassing:
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
Aangezien geplande gebeurtenissen vaak worden gebruikt voor toepassingen met vereisten voor hoge beschikbaarheid, zijn er enkele uitzonderlijke gevallen die in overweging moeten worden genomen:
- Zodra een geplande gebeurtenis is voltooid en verwijderd uit de matrix, zijn er geen verdere gevolgen zonder een nieuwe gebeurtenis met inbegrip van een andere EventStatus:"Scheduled" gebeurtenis
- Azure bewaakt onderhoudsbewerkingen in de hele vloot en in zeldzame omstandigheden bepaalt dat een onderhoudsbewerking te hoog risico heeft om toe te passen. In dat geval wordt de geplande gebeurtenis rechtstreeks van Gepland naar verwijderd uit de matrix met gebeurtenissen
- In het geval van een hardwarefout wordt de status Gepland overgeslagen en wordt de status 'Gestart' onmiddellijk verplaatst naar de status EventStatus: 'Gestart'.
- Hoewel de gebeurtenis nog steeds de status EventStatus:"Gestart" heeft, kan er een andere impact zijn van een kortere duur dan wat is geadverteerd in de geplande gebeurtenis.
Als onderdeel van de beschikbaarheidsgarantie van Azure worden VM's in verschillende foutdomeinen niet tegelijkertijd beïnvloed door routineonderhoudsbewerkingen. Ze kunnen echter bewerkingen na elkaar hebben geserialiseerd. VM's in het ene foutdomein kunnen geplande gebeurtenissen ontvangen met EventStatus:"Gepland" kort nadat het onderhoud van een ander foutdomein is voltooid. Ongeacht de architectuur die u hebt gekozen, moet u altijd controleren op nieuwe gebeurtenissen die in behandeling zijn voor uw VM's.
Hoewel de exacte tijdsinstellingen van gebeurtenissen variëren, biedt het volgende diagram een ruwe richtlijn voor hoe een typische onderhoudsbewerking verloopt:
- EventStatus:"Scheduled" to Approval Timeout: 15 minuten
- Impactduur: 7 seconden
- EventStatus:"Gestart" naar Voltooid (gebeurtenis verwijderd uit matrix gebeurtenissen): 10 minuten
Alle bewerkingen die van invloed zijn op de beschikbaarheid van vm's, resulteren in een geplande gebeurtenis, maar niet alle geplande gebeurtenissen worden weergegeven in andere Azure-oppervlakken, zoals Azure-activiteitenlogboeken of Resource Health. Het regelmatig controleren van geplande gebeurtenissen zorgt ervoor dat u over de meest recente informatie beschikt over toekomstige gevolgen voor uw VM's.
Kopteksten
Wanneer u metagegevensservice opvraagt, moet u de header Metadata:true opgeven om ervoor te zorgen dat de aanvraag niet onbedoeld is omgeleid. De Metadata:true header is vereist voor alle geplande gebeurtenissenaanvragen. Het niet opnemen van de header in de aanvraag resulteert in een 'Ongeldige aanvraag' reactie van de Metagegevensservice.
Query uitvoeren op gebeurtenissen
U kunt een query uitvoeren op geplande gebeurtenissen door de volgende aanroep uit te voeren:
Bash-voorbeeld
curl -H Metadata:true http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01
Voorbeeld van 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
Python-voorbeeld
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
Een antwoord bevat een matrix met geplande gebeurtenissen. Een lege matrix betekent dat er momenteel geen gebeurtenissen worden gepland. In het geval dat er geplande gebeurtenissen zijn, bevat het antwoord een matrix met gebeurtenissen.
{
"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},
}
]
}
Eigenschappen van gebeurtenis
| Eigenschappen | Beschrijving |
|---|---|
| Document incarnatie | Geheel getal dat toeneemt wanneer de gebeurtenissenmatrix wordt gewijzigd. Documenten met dezelfde incarnatie bevatten dezelfde gebeurtenisgegevens en de incarnatie wordt verhoogd wanneer een gebeurtenis wordt gewijzigd. |
| EventId | Globally unique identifier for this event. Voorbeeld:
|
| EventType | Impact op deze gebeurtenisoorzaken. Waarden:
|
| ResourceType | Het type resource dat deze gebeurtenis beïnvloedt. Waarden:
|
| Resources | Lijst met resources die deze gebeurtenis beïnvloedt. Voorbeeld:
|
| EventStatus | Status van deze gebeurtenis. Waarden:
Completed of vergelijkbare status opgegeven. De gebeurtenis wordt niet meer geretourneerd wanneer de gebeurtenis is voltooid. |
| NotBefore | Tijd waarna deze gebeurtenis kan worden gestart. De gebeurtenis wordt gegarandeerd niet voor deze tijd gestart. Is leeg als de gebeurtenis al is gestart Voorbeeld:
|
| Beschrijving | Beschrijving van deze gebeurtenis. Voorbeeld:
|
| EventSource | Initiator van de gebeurtenis. Voorbeeld:
|
| DurationInSeconds | De verwachte duur van de onderbreking die wordt veroorzaakt door de gebeurtenis. Er kunnen secundaire gevolgen zijn van een kortere duur tijdens het effectvenster. Voorbeeld:
|
Gebeurtenisplanning
Elke gebeurtenis wordt een minimale tijd in de toekomst gepland op basis van het gebeurtenistype. Deze keer wordt weergegeven in de eigenschap van NotBefore een gebeurtenis.
| EventType | Minimale kennisgeving |
|---|---|
| Vergrendeling | 15 minuten |
| Opnieuw opstarten | 15 minuten |
| Opnieuw implementeren | 10 minuten |
| Beëindigen | Configureerbare gebruiker: 5 tot 15 minuten |
Dit betekent dat u een toekomstig schema van de gebeurtenis ten minste kunt detecteren op basis van de minimale kennisgevingstijd voordat de gebeurtenis plaatsvindt. Zodra een gebeurtenis is gepland, wordt deze verplaatst naar de Started status nadat deze is goedgekeurd of de NotBefore tijd is verstreken. In zeldzame gevallen wordt de bewerking echter geannuleerd door Azure voordat deze wordt gestart. In dat geval wordt de gebeurtenis verwijderd uit de matrix Gebeurtenissen en vindt de impact niet plaats zoals eerder gepland.
Notitie
In sommige gevallen kan Azure een hostfout voorspellen vanwege gedegradeerde hardware en probeert de onderbreking van uw service te beperken door een migratie te plannen. Betrokken virtuele machines ontvangen een geplande gebeurtenis met een gebeurtenis NotBefore die doorgaans een paar dagen in de toekomst is. De werkelijke tijd varieert, afhankelijk van de voorspelde risicobeoordeling van fouten. Azure probeert 7 dagen van tevoren op de hoogte te stellen, maar de werkelijke tijd varieert en kan kleiner zijn als de voorspelling is dat er een hoge kans is dat de hardware binnenkort mislukt. Om het risico voor uw service te minimaliseren voor het geval de hardware uitvalt vóór de door het systeem geïnitieerde migratie, raden we u aan uw virtuele machine zo snel mogelijk zelf opnieuw te implementeren.
Notitie
In het geval dat het hostknooppunt een hardwarefout ondervindt, wordt de minimale kennisgevingsperiode omzeild, waarbij het herstelproces voor betrokken virtuele machines onmiddellijk wordt gestart. Dit vermindert de hersteltijd in het geval dat de betrokken VM's niet kunnen reageren. Tijdens het herstelproces wordt een gebeurtenis gemaakt voor alle betrokken VM's met EventType = Reboot en EventStatus = Started.
Pollingfrequentie
U kunt het eindpunt zo vaak of zelden als u wilt peilen naar updates. Hoe langer de tijd tussen aanvragen, hoe langer de tijd die u mogelijk verliest om te reageren op een aanstaande gebeurtenis. De meeste gebeurtenissen hebben 5 tot 15 minuten van tevoren kennisgeving, hoewel in sommige gevallen voorafgaande kennisgeving mogelijk zo klein is als 30 seconden. Om ervoor te zorgen dat u zoveel mogelijk tijd hebt om beperkende acties uit te voeren, raden we u aan om de service één keer per seconde te peilen.
Een gebeurtenis starten
Nadat u een geplande gebeurtenis hebt geleerd en uw logica hebt voltooid voor een probleemloos afsluiten, kunt u de openstaande gebeurtenis goedkeuren door een POST aanroep naar de Metadata Service met EventIdte voeren. Deze aanroep geeft aan dat azure de minimale meldingstijd (indien mogelijk) kan verkorten. De gebeurtenis wordt mogelijk niet onmiddellijk gestart na goedkeuring. In sommige gevallen vereist Azure de goedkeuring van alle VM's die op het knooppunt worden gehost voordat u doorgaat met de gebeurtenis.
Het volgende JSON-voorbeeld wordt verwacht in de POST aanvraagbody. De aanvraag moet een lijst met StartRequests. Elk StartRequest bevat EventId voor de gebeurtenis die u wilt versnellen:
{
"StartRequests" : [
{
"EventId": {EventId}
}
]
}
De service retourneert altijd een 200-geslaagde code als deze een geldige gebeurtenis-id heeft doorgegeven, zelfs als een andere VIRTUELE machine de gebeurtenis al heeft goedgekeurd. Een 400-foutcode geeft aan dat de aanvraagheader of nettolading onjuist is ingedeeld.
Notitie
Gebeurtenissen worden pas voortgezet als ze zijn goedgekeurd via een POST-bericht of de verstreken NotBefore-tijd. Dit omvat door de gebruiker geactiveerde gebeurtenissen, zoals het opnieuw opstarten van de VIRTUELE machine vanuit Azure Portal.
Bash-voorbeeld
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
Voorbeeld van 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
Python-voorbeeld
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
Notitie
Als u een gebeurtenis bevestigt, kan de gebeurtenis doorgaan voor alles Resources in de gebeurtenis, niet alleen de VIRTUELE machine die de gebeurtenis bevestigt. Daarom kunt u ervoor kiezen om een leider te kiezen om de bevestiging te coördineren, wat net zo eenvoudig kan zijn als de eerste machine in het Resources veld.
Voorbeeldantwoorden
De volgende gebeurtenissen zijn een voorbeeld dat is gezien door twee virtuele machines die live zijn gemigreerd naar een ander knooppunt.
De DocumentIncarnation wijziging verandert telkens wanneer er nieuwe informatie in Eventsstaat. Door een goedkeuring van de gebeurtenis kan de blokkering worden voortgezet voor zowel WestNO_0 als WestNO_1. De DurationInSeconds waarde -1 geeft aan dat het platform niet weet hoe lang de bewerking duurt.
{
"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": [
]
}
Python-voorbeeld
In het volgende voorbeeld wordt metagegevensservice voor geplande gebeurtenissen opgevraagd en wordt elke openstaande gebeurtenis goedgekeurd:
#!/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 have 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()
Volgende stappen
- Bekijk de codevoorbeelden geplande gebeurtenissen in de GitHub-opslagplaats met geplande gebeurtenissen in Azure Instance Metadata.
- Bekijk de codevoorbeelden voor geplande gebeurtenissen in de GitHub-opslagplaats Node.js Geplande gebeurtenissen.
- Lees meer over de API's die beschikbaar zijn in de Instance Metadata Service.
- Meer informatie over gepland onderhoud voor virtuele Linux-machines in Azure.
- Meer informatie over het vastleggen van geplande gebeurtenissen met behulp van Azure Event Hubs in de GitHub-opslagplaats met Azure Samples.