Azure Metadata szolgáltatás: A Linux rendszerű virtuális gépek ütemezett eseményei
A következőkre vonatkozik: ✔️ Linux rendszerű virtuális gépek ✔️ Rugalmas méretezési csoportok ✔️ Egységes méretezési csoportok
Az ütemezett események egy Azure Metadata-szolgáltatás, amely időt biztosít az alkalmazásának a virtuális gépek (VM) karbantartására való felkészülésre. Információkat nyújt a várható karbantartási eseményekről (például újraindításról), így az alkalmazása felkészülhet rájuk, és megelőzheti a fennakadásokat. Minden Azure Virtual Machines-típushoz elérhető, beleértve a PaaS-t és az IaaS-t is, Windows és Linux rendszeren egyaránt.
A Windows rendszerű ütemezett eseményekről további információt a Windows rendszerű virtuális gépek ütemezett eseményei című témakörben talál.
Az ütemezett események proaktív értesítéseket nyújtanak a közelgő eseményekről, a már megtörtént eseményekre vonatkozó reaktív információkért lásd az Azure Resource Graph virtuális gép rendelkezésre állási adatait, valamint az Azure-beli virtuális gépek rendelkezésre állási riasztási szabályának létrehozását.
Feljegyzés
Az ütemezett események általában minden Azure-régióban elérhetők. A legújabb kiadási információkért tekintse meg a Verzió és a Régió rendelkezésre állása című témakört.
Miért érdemes ütemezett eseményeket használni?
Számos alkalmazás számára előnyös lehet a virtuális gép karbantartására való felkészülési idő. Az idő felhasználható olyan alkalmazásspecifikus feladatok végrehajtására, amelyek javítják a rendelkezésre állást, a megbízhatóságot és a működőképesség helyreállítását, beleértve a következőket:
- Ellenőrzőpont és visszaállítás.
- Kapcsolatkiürítés.
- Feladatátvétel az elsődleges replikán.
- Eltávolítás terheléselosztó-készletből.
- Eseménynaplózás.
- Szabályos leállítás.
Az ütemezett eseményekkel az alkalmazás értesülhet arról, mikor történik karbantartás, és feladatokat indíthat el a hatás csökkentése érdekében.
Az ütemezett események a következő használati esetekben biztosítanak eseményeket:
- A platform által kezdeményezett karbantartás (például a virtuális gép újraindítása, az élő áttelepítés vagy a gazdagép memóriamegőrző frissítései).
- A virtuális gép csökkentett teljesítményű gazdagéphardvereken fut, amelyek várhatóan hamarosan meghibásodnak.
- A virtuális gép hardverhibát szenvedett gazdagépen futott.
- Felhasználó által kezdeményezett karbantartás (például egy felhasználó újraindítja vagy újra üzembe helyezi a virtuális gépet).
- Kihasználatlan virtuális gép és kihasználatlan méretezési csoport példányának kizárása.
Az alapok
A Metaadat-szolgáltatás a virtuális gépek futtatásával kapcsolatos információkat egy, a virtuális gépről elérhető REST-végpont használatával teszi elérhetővé. Az információk nem átirányítható IP-címen keresztül érhetők el, és nem érhetők el a virtuális gépen kívül.
Hatókör
Az ütemezett események az alábbiak szerint érkeznek és nyugtázhatók:
- Önálló virtuális gépek.
- Egy Azure-felhőszolgáltatás összes virtuális gépe (klasszikus).
- Egy rendelkezésre állási csoport összes virtuális gépe.
- A méretezési csoport elhelyezési csoportjának összes virtuális gépe.
Egy teljes rendelkezésre állási csoportban vagy egy virtuálisgép-méretezési csoport elhelyezési csoportjában lévő összes virtuális gép ütemezett eseményei az ugyanabban a csoportban lévő összes többi virtuális gépre vagy készletre érkeznek, függetlenül a rendelkezésre állási zóna használatától.
Ennek eredményeképpen ellenőrizze az Resources esemény mezőjét annak megállapításához, hogy mely virtuális gépek érintettek.
Feljegyzés
A GPU gyorsított virtuális gépei egy 1 tartalék tartományt használó méretezési csoportban (FD = 1) csak az érintett erőforrás ütemezett eseményeit fogadják. Az események nem lesznek továbbítva az ugyanabban az elhelyezési csoportban lévő összes virtuális gépre.
Végpontfelderítés
A VNET-kompatibilis virtuális gépek esetében a Metaadat-szolgáltatás statikus, nemroutable IP-címről érhető el. 169.254.169.254 Az ütemezett események legújabb verziójának teljes végpontja a következő:
http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01
Ha a virtuális gép nem virtuális hálózaton, a felhőszolgáltatások és a klasszikus virtuális gépek alapértelmezett esetein belül jön létre, további logikára van szükség a használni kívánt IP-cím felderítéséhez. A gazdagépvégpont felderítésének módjáról ebben a példában olvashat.
Verzió és régió rendelkezésre állása
Az Ütemezett események szolgáltatás verziószámozott. A verziók kötelezőek; az aktuális verzió.2020-07-01
| Verzió | Kiadás típusa | Régiók | Release Notes (Kibocsátási megjegyzések) |
|---|---|---|---|
| 2020-07-01 | Általános rendelkezésre állás | Mind | |
| 2019-08-01 | Általános rendelkezésre állás | Mind | |
| 2019-04-01 | Általános rendelkezésre állás | Mind | |
| 2019-01-01 | Általános rendelkezésre állás | Mind | |
| 2017-11-01 | Általános rendelkezésre állás | Mind | |
| 2017-08-01 | Általános rendelkezésre állás | Mind | |
| 2017-03-01 | Előnézet | Mind |
Feljegyzés
Az ütemezett események korábbi előzetes kiadásai támogatták a(z) {latest} api-verziót. Ez a formátum már nem támogatott, és a jövőben elavulttá válik.
Ütemezett események engedélyezése és letiltása
Az ütemezett események akkor lesznek engedélyezve a szolgáltatás számára, amikor először kér eseményeket. Az első hívásban legfeljebb két perc késéssel kell reagálnia, és 5 percen belül megkezdheti az események fogadását. Az ütemezett események le vannak tiltva a szolgáltatás számára, ha 24 órán keresztül nem küld kérelmet a végpontra.
Felhasználó által kezdeményezett karbantartás
A felhasználó által kezdeményezett virtuális gépek azure portalon, API-val, parancssori felülettel vagy PowerShell-lel végzett karbantartása ütemezett eseményt eredményez. Ezután tesztelheti a karbantartás-előkészítési logikát az alkalmazásban, és az alkalmazás felkészülhet a felhasználó által kezdeményezett karbantartásra.
Ha újraindít egy virtuális gépet, a rendszer ütemez egy ilyen típusú Reboot eseményt. Ha újra üzembe helyezi a virtuális gépet, a rendszer ütemez egy ilyen típusú Redeploy eseményt. A felhasználói eseményforrással rendelkező események általában azonnal jóváhagyhatók a felhasználó által kezdeményezett műveletek késleltetésének elkerülése érdekében. Azt javasoljuk, hogy egy elsődleges és másodlagos virtuális gép kommunikáljon, és jóváhagyja a felhasználó által létrehozott ütemezett eseményeket, ha az elsődleges virtuális gép nem válaszol. Az események azonnali jóváhagyása megakadályozza az alkalmazás megfelelő állapotba való helyreállításának késleltetését.
A virtuálisgép-méretezési csoportok vendég operációs rendszerének frissítéséhez vagy újraimálásához ütemezett események olyan általános célú virtuálisgép-méretek esetén támogatottak, amelyek csak a memóriamegőrző frissítéseket támogatják. G, M, N és H sorozat esetén nem működik. A virtuálisgép-méretezési csoportok vendég operációsrendszer-frissítéseinek és újraimáinak ütemezett eseményei alapértelmezés szerint le vannak tiltva. Ahhoz, hogy ezekhez a műveletekhez ütemezett eseményeket engedélyezhessen támogatott virtuálisgép-méretekben, először engedélyezze őket az OSImageNotificationProfile használatával.
Az API használata
Magas szintű áttekintés
Az ütemezett események kezeléséhez, az előkészítéshez és a helyreállításhoz két fő összetevő áll rendelkezésre. A virtuális gépet érintő összes aktuális ütemezett esemény az IMDS Ütemezett események végponton keresztül olvasható. Amikor az esemény elérte a terminálállapotot, az el lesz távolítva az események listájából. Az alábbi ábra azokat a különböző állapotáttűnéseket mutatja be, amelyeket egyetlen ütemezett esemény tapasztalhat:
Az EventStatus:"Ütemezett" állapotú események esetében lépéseket kell tennie a számítási feladat előkészítéséhez. Miután az előkészítés befejeződött, az ütemezett esemény API használatával jóvá kell hagynia az eseményt. Ellenkező esetben az esemény automatikusan jóvá lesz hagyva a NotBefore idő elérésekor. Ha a virtuális gép megosztott infrastruktúrán van, a rendszer ezután megvárja, amíg az ugyanazon a hardveren lévő összes többi bérlő is jóváhagyja a feladatot vagy az időtúllépést. Ha az összes érintett virtuális gépről jóváhagyásokat gyűjt, vagy a NotBefore időpont elérése után az Azure létrehoz egy új ütemezett esemény hasznos adatait az EventStatus:"Started" használatával, és elindítja a karbantartási esemény kezdetét. Amikor az esemény elérte a terminálállapotot, az el lesz távolítva az események listájából. Ez azt jelzi, hogy az ügyfél helyreállítsa a virtuális gépeit.
Az alábbiakban egy psudeo-kódot mutatunk be, amely bemutatja az alkalmazás ütemezett eseményeinek olvasását és kezelését:
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
Mivel az ütemezett eseményeket gyakran használják magas rendelkezésre állási követelményekkel rendelkező alkalmazásokhoz, figyelembe kell venni néhány kivételes esetet:
- Az ütemezett esemény befejezése és a tömbből való eltávolítása után nem lesz további hatás új esemény nélkül, beleértve egy másik EventStatus-eseményt is: "Ütemezett" esemény
- Az Azure a teljes flotta karbantartási műveleteit figyeli, és ritka körülmények között azt határozza meg, hogy egy karbantartási művelet túl magas kockázattal jár-e. Ebben az esetben az ütemezett esemény közvetlenül az "Ütemezett" helyről kerül eltávolításra az eseménytömbből
- Hardverhiba esetén az Azure átadja az "Ütemezett" állapotot, és azonnal áttér az EventStatus:"Started" állapotra.
- Bár az esemény továbbra is EventStatus:"Started" állapotban van, előfordulhat, hogy az ütemezett eseményben meghirdetettnél rövidebb időtartamú hatás is előfordulhat.
Az Azure rendelkezésre állási garanciája részeként a különböző tartalék tartományokban lévő virtuális gépeket nem érintik a rendszeres karbantartási műveletek. Előfordulhat azonban, hogy a műveletek egymás után szerializáltak. Az egyik tartalék tartományban lévő virtuális gépek az EventStatus:"Ütemezett" eseményekkel röviddel egy másik tartalék tartomány karbantartása után fogadhatnak ütemezett eseményeket. Függetlenül attól, hogy milyen architektúrát választott, mindig ellenőrizze a virtuális gépeken függőben lévő új eseményeket.
Bár az események pontos időzítése eltérő, az alábbi diagram egy hozzávetőleges útmutatást nyújt egy tipikus karbantartási művelet folytatásához:
- EventStatus:"Ütemezett" jóváhagyási időtúllépés: 15 perc
- Ütközés időtartama: 7 másodperc
- EventStatus:"Started" to Completed (event removed from Events array): 10 perc
A virtuális gépek rendelkezésre állását befolyásoló összes művelet ütemezett eseményt eredményez, de nem minden ütemezett esemény jelenik meg más Azure-felületeken, például az Azure-tevékenységnaplókban vagy a Resource Healthben. Az ütemezett események rendszeres ellenőrzése biztosítja, hogy a lehető legfrissebb információkkal rendelkezzen a virtuális gépekre gyakorolt esetleges jövőbeli hatásokról.
Fejlécek
A metaadat-szolgáltatás lekérdezéséhez meg kell adnia a fejlécet Metadata:true , hogy a kérés ne legyen véletlenül átirányítva. A Metadata:true fejléc minden ütemezett eseménykéréshez szükséges. Ha nem adja meg a fejlécet a kérelemben, a metaadat-szolgáltatás "Hibás kérés" választ eredményez.
Események lekérdezése
Az ütemezett eseményeket a következő hívással kérdezheti le:
Bash-minta
curl -H Metadata:true http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01
PowerShell-minta
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-minta
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
A válasz ütemezett események tömbje. Az üres tömb azt jelenti, hogy jelenleg nincs ütemezve esemény. Abban az esetben, ha vannak ütemezett események, a válasz eseménytömböt tartalmaz.
{
"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},
}
]
}
Esemény tulajdonságai
| Tulajdonság | Leírás |
|---|---|
| Dokumentum inkarnációja | Egész szám, amely az események tömbjének változásakor növekszik. Az azonos inkarnációval rendelkező dokumentumok ugyanazokat az eseményadatokat tartalmazzák, és az inkarnáció növekszik, amikor egy esemény megváltozik. |
| EventId | Az esemény globálisan egyedi azonosítója. Példa:
|
| EventType | Az esemény okainak befolyásolásához. Értékrend:
|
| ResourceType | Az esemény által érintett erőforrás típusa. Értékrend:
|
| Források | Az esemény által érintett erőforrások listája. Példa:
|
| EventStatus | Az esemény állapota. Értékrend:
Completed vagy hasonló állapotban van megadva. Az esemény már nem lesz visszaadva, ha az esemény befejeződött. |
| NotBefore | Az esemény indításának időpontja. Az esemény garantáltan nem indul el ez előtt az időpontig. Üres lesz, ha az esemény már elindult Példa:
|
| Leírás | Az esemény leírása. Példa:
|
| EventSource | Az esemény kezdeményezője. Példa:
|
| DurationInSeconds | Az esemény által okozott megszakítás várható időtartama. Az ütközési időszak alatt előfordulhatnak rövidebb időtartamú másodlagos hatások. Példa:
|
Eseményütemezés
Minden eseményt a rendszer a jövőben az esemény típusától függően minimálisan ütemez. Ez az idő egy esemény tulajdonságában jelenik meg NotBefore .
| EventType | Minimális értesítés |
|---|---|
| Befagyasztás | 15 perc |
| Újraindítás | 15 perc |
| Ismételt üzembe helyezés | 10 perc |
| Leállítás | Felhasználó által konfigurálható: 5–15 perc |
Ez azt jelenti, hogy az esemény jövőbeli ütemezését legalább az esemény bekövetkezése előtti minimális értesítési idővel észlelheti. Az esemény ütemezése után az állapotba kerül, Started miután jóváhagyták, vagy az NotBefore idő eltelik. Ritkán azonban az Azure még a kezdés előtt megszakítja a műveletet. Ebben az esetben az esemény el lesz távolítva az Események tömbből, és a hatás nem a korábban ütemezett módon fog bekövetkezni.
Feljegyzés
Bizonyos esetekben az Azure képes előre jelezni a gazdagép meghibásodását a csökkentett hardver miatt, és egy migrálás ütemezésével megkísérli enyhíteni a szolgáltatás zavarait. Az érintett virtuális gépek egy ütemezett eseményt NotBefore kapnak, amely általában néhány nap múlva lesz. A tényleges idő az előrejelzett hibakockázat-értékeléstől függően változik. Az Azure 7 napos előzetes értesítést próbál adni, ha lehetséges, de a tényleges idő változó, és kisebb lehet, ha az előrejelzés szerint nagy az esélye annak, hogy a hardver hamarosan meghibásodik. A szolgáltatás kockázatának minimalizálása érdekében, ha a hardver a rendszer által kezdeményezett migrálás előtt meghibásodik, javasoljuk, hogy a lehető leghamarabb telepítse újra a virtuális gépet.
Feljegyzés
Ha a gazdacsomópont hardverhibát tapasztal, az Azure megkerüli a minimális értesítési időszakot, és azonnal megkezdi az érintett virtuális gépek helyreállítási folyamatát. Ez csökkenti a helyreállítási időt abban az esetben, ha az érintett virtuális gépek nem tudnak válaszolni. A helyreállítási folyamat során egy esemény jön létre az összes érintett virtuális géphez EventType = Reboot és EventStatus = Started.
Lekérdezés gyakorisága
A végpontot a kívánt gyakran vagy ritkán lekérdezheti a frissítésekhez. Minél hosszabb idő telik el a kérések között, annál több időt veszthet el, hogy reagáljon egy közelgő eseményre. A legtöbb eseménynek 5–15 percnyi előzetes értesítése van, bár bizonyos esetekben az előzetes értesítés akár 30 másodperc is lehet. Annak érdekében, hogy a lehető legtöbb ideje legyen az enyhítő műveletekre, javasoljuk, hogy másodpercenként egyszer kérdezi le a szolgáltatást.
Esemény indítása
Miután megismert egy közelgő eseményt, és befejezte a logikát a kecses leállításhoz, jóváhagyhatja a kiemelkedő eseményt a Metadata Service meghívásával POST EventId. Ez a hívás azt jelzi az Azure-nak, hogy lerövidítheti a minimális értesítési időt (ha lehetséges). Előfordulhat, hogy az esemény nem indul el azonnal a jóváhagyás után, bizonyos esetekben az Azure megköveteli a csomóponton üzemeltetett összes virtuális gép jóváhagyását, mielőtt továbblép az eseményre.
A kérelem törzsében a POST következő JSON-minta várható. A kérelemnek tartalmaznia kell egy listát a következőről StartRequests: . Mindegyik StartRequest tartalmazza EventId a felgyorsítani kívánt eseményt:
{
"StartRequests" : [
{
"EventId": {EventId}
}
]
}
A szolgáltatás mindig 200 sikeres kódot ad vissza, ha érvényes eseményazonosítót adott át, még akkor is, ha egy másik virtuális gép már jóváhagyta az eseményt. A 400-ás hibakód azt jelzi, hogy a kérelem fejléce vagy a hasznos adat helytelenül lett formázva.
Feljegyzés
Az események csak akkor folytatódnak, ha post üzenetben vagy a NotBefore-idő leteltével jóváhagyják őket. Ide tartoznak a felhasználó által aktivált események, például a virtuális gép újraindítása az Azure Portalról.
Bash-minta
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
PowerShell-minta
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-minta
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
Feljegyzés
Az esemény nyugtázása lehetővé teszi, hogy az esemény az esemény minden Resources területén folytatódjon, nem csak az eseményt nyugtázó virtuális gép számára. Ezért választhat egy vezetőt a nyugtázás koordinálásához, amely a mező első gépéhez Resources hasonlóan egyszerű is lehet.
Példaválaszok
Az alábbi események olyan példák, amelyeket két virtuális gép látott, amelyeket élőben migráltak egy másik csomópontra.
A DocumentIncarnation változás minden alkalommal változik, amikor új információ található a fájlban Events. Az esemény jóváhagyása lehetővé tenné, hogy a befagyasztás WestNO_0 és WestNO_1 is folytatódjon. A DurationInSeconds -1 azt jelzi, hogy a platform nem tudja, mennyi ideig tart a művelet.
{
"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-minta
Az alábbi minta lekérdezi a Metadata Service szolgáltatást az ütemezett eseményekhez, és jóváhagyja az egyes kiemelkedő eseményeket:
#!/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()
Következő lépések
- Tekintse át az Ütemezett események kódmintákat az Azure Instance Metadata Ütemezett események GitHub-adattárában.
- Tekintse át az Node.js ütemezett események kódmintáit az Azure Samples GitHub-adattárban.
- További információ a példány metaadat-szolgáltatásában elérhető API-król.
- Ismerje meg a Linux rendszerű virtuális gépek tervezett karbantartását az Azure-ban.
- Megtudhatja, hogyan naplózhatja az ütemezett eseményeket az Azure Event Hubs használatával az Azure Samples GitHub-adattárban.