Hibák és kivételek kezelése az Azure Logic Appsben

Cikk
12/09/2023

A következőkre vonatkozik: Azure Logic Apps (Használat + Standard)

Az, hogy az integrációs architektúra megfelelően kezeli az állásidőt vagy a függő rendszerek által okozott problémákat, kihívást jelenthet. Az Azure Logic Apps első osztályú felületet biztosít a hibák és kivételek kezeléséhez, hogy hatékony és rugalmas integrációkat hozzon létre, amelyek elegánsan kezelik a problémákat és a hibákat.

Újrapróbálkozási szabályzatok

A legalapvetőbb kivétel- és hibakezeléshez használhatja az újrapróbálkozási szabályzatot , ha egy eseményindító vagy művelet, például a HTTP-művelet támogatott. Ha az eseményindító vagy művelet eredeti kérése túllépi vagy meghiúsul, és 408, 429 vagy 5xx választ eredményez, az újrapróbálkozási szabályzat azt határozza meg, hogy az eseményindító vagy a művelet házirend-beállítások szerint újraküldi a kérést.

Szabályzatkorlátok újrapróbálkozási korlátozásai

Az újrapróbálkozási szabályzatokról, a beállításokról, a korlátokról és egyéb lehetőségekről az Újrapróbálkozási szabályzat korlátai című cikkben olvashat bővebben.

Szabályzattípusok újrapróbálkozás

Csatlakozás újrapróbálkozási szabályzatokat támogató műveletekAlapértelmezett házirend, kivéve, ha másik újrapróbálkozési szabályzatot választ.

Újrapróbálkozási szabályzat	Leírás
Alapértelmezett	A legtöbb művelet esetében az Alapértelmezett újrapróbálkozási szabályzat egy exponenciális intervallumszabályzat, amely exponenciálisan növekvő időközönként legfeljebb 4 újrapróbálkozási lehetőséget küld. Ezek az intervallumok 7,5 másodperccel skálázhatók, de 5 és 45 másodperc között vannak leképezve. Számos művelet más alapértelmezett újrapróbálkozási szabályzatot használ, például rögzített időközi szabályzatot. További információkért tekintse át az Alapértelmezett újrapróbálkozás szabályzattípust.
Nincs	Ne küldjön újra kérelmet. További információkért tekintse át a Nincs – Nincs újrapróbálkozás szabályzatot.
Exponenciális intervallum	Ez a szabályzat egy véletlenszerű időközt vár, amelyet egy exponenciálisan növekvő tartományból választ ki a következő kérés elküldése előtt. További információkért tekintse át az exponenciális intervallumszabályzat típusát.
Rögzített időköz	Ez a szabályzat megvárja a megadott időközt a következő kérés elküldése előtt. További információkért tekintse át a rögzített intervallumszabályzat típusát.

Újrapróbálkoztatási szabályzat típusának módosítása a tervezőben

Az Azure Portalon nyissa meg a logikai alkalmazás munkafolyamatát a tervezőben.
Attól függően, hogy használatalapú vagy standard munkafolyamaton dolgozik-e, nyissa meg az eseményindítót vagy a művelet Gépház.
- Felhasználás: A műveletalakzaton nyissa meg a három pontot tartalmazó menüt (...), és válassza a Gépház.
- Standard: A tervezőn válassza ki a műveletet. A részletek panelen válassza a Gépház.
Ha az eseményindító vagy művelet támogatja az újrapróbálkozási szabályzatokat, az Újrapróbálkozási szabályzat területen válassza ki a kívánt házirendtípust.

Az újrapróbálkoztatási szabályzat típusának módosítása a kódnézet-szerkesztőben

Ha szükséges, ellenőrizze, hogy az eseményindító vagy a művelet támogatja-e az újrapróbálkozási szabályzatokat a tervező korábbi lépéseinek végrehajtásával.
Nyissa meg a logikai alkalmazás munkafolyamatát a kódnézet-szerkesztőben.

Az eseményindító vagy a művelet definíciójában adja hozzá a retryPolicy JSON-objektumot az adott eseményindító vagy művelet objektumához inputs . Ellenkező esetben, ha nincs retryPolicy objektum, az eseményindító vagy a művelet az default újrapróbálkozási szabályzatot használja.

"inputs": {
   <...>,
   "retryPolicy": {
      "type": "<retry-policy-type>",
      // The following properties apply to specific retry policies.
      "count": <retry-attempts>,
      "interval": "<retry-interval>",
      "maximumInterval": "<maximum-interval>",
      "minimumInterval": "<minimum-interval>"
   },
   <...>
},
"runAfter": {}

Szükséges

Tulajdonság	Érték	Type	Description
`type`	<újrapróbálkozás-szabályzattípus>	Sztring	A használni kívánt újrapróbálkozás házirendtípusa: `default`, `none`, `fixed`vagy `exponential`
`count`	<újrapróbálkozási kísérletek>	Egész	`exponential` A `fixed` szabályzattípusok esetében az újrapróbálkozási kísérletek száma, amely 1 és 90 közötti érték. További információ: Rögzített időköz és Exponenciális intervallum.
`interval`	<újrapróbálkozási időköz>	Sztring	`exponential` A szabályzattípusok esetében `fixed` az újrapróbálkozási időköz értéke ISO 8601 formátumban. A szabályzathoz megadhatja a `exponential` választható maximális és minimális időközöket is. További információ: Rögzített időköz és Exponenciális intervallum. Fogyasztás: 5 másodperc (`PT5S`) és 1 nap (`P1D`). Standard: Állapotalapú munkafolyamatok esetén 5 másodperc (`PT5S`) –1 nap (`P1D`). Állapot nélküli munkafolyamatok esetén 1 másodperc (`PT1S`) –1 perc (`PT1M`).

Választható

Tulajdonság	Érték	Type	Description
`maximumInterval`	<maximális időköz>	Sztring	A `exponential` szabályzat esetében a véletlenszerűen kiválasztott intervallum legnagyobb intervalluma ISO 8601 formátumban. Az alapértelmezett érték 1 nap (`P1D`). További információkért tekintse át az exponenciális intervallumot.
`minimumInterval`	<minimális időköz>	Sztring	`exponential` A házirend esetében a véletlenszerűen kiválasztott intervallum legkisebb időköze ISO 8601 formátumban. Az alapértelmezett érték 5 másodperc (`PT5S`). További információkért tekintse át az exponenciális intervallumot.

Alapértelmezett újrapróbálkozési szabályzat

Csatlakozás újrapróbálkozási szabályzatokat támogató műveletekAlapértelmezett házirend, kivéve, ha másik újrapróbálkozési szabályzatot választ. A legtöbb művelet esetében az Alapértelmezett újrapróbálkozási szabályzat egy exponenciális intervallumszabályzat, amely exponenciálisan növekvő időközönként legfeljebb 4 újrapróbálkozási lehetőséget küld. Ezek az intervallumok 7,5 másodperccel skálázhatók, de 5 és 45 másodperc között vannak leképezve. Számos művelet más alapértelmezett újrapróbálkozási szabályzatot használ, például rögzített időközi szabályzatot.

A munkafolyamat-definícióban az eseményindító vagy a műveletdefiníció nem definiálja explicit módon az alapértelmezett szabályzatot, de az alábbi példa bemutatja, hogyan viselkedik az alapértelmezett újrapróbálkozási szabályzat a HTTP-művelethez:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "http://myAPIendpoint/api/action",
      "retryPolicy" : {
         "type": "exponential",
         "interval": "PT7S",
         "count": 4,
         "minimumInterval": "PT5S",
         "maximumInterval": "PT1H"
      }
   },
   "runAfter": {}
}

Nincs – Nincs újrapróbálkozési szabályzat

Ha meg szeretné adni, hogy a művelet vagy eseményindító ne próbálkozzon újra a sikertelen kérésekkel, állítsa az <újrapróbálkozási szabályzat típusát> a következőre none: .

Rögzített időközi újrapróbálkozási szabályzat

Ha meg szeretné adni, hogy a művelet vagy eseményindító megvárja a megadott időközt a következő kérés elküldése előtt, állítsa az <újrapróbálkozási szabályzat típusát> a következőrefixed.

Példa

Ez az újrapróbálkozási szabályzat az első sikertelen kérés után még kétszer megpróbálja lekérni a legfrissebb híreket, és 30 másodperces késéssel az egyes kísérletek között:

"Get_latest_news": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "https://mynews.example.com/latest",
      "retryPolicy": {
         "type": "fixed",
         "interval": "PT30S",
         "count": 2
      }
   }
}

Exponenciális intervallum újrapróbálkozási szabályzat

Az exponenciális időköz újrapróbálkozási szabályzata azt határozza meg, hogy az eseményindító vagy művelet véletlenszerű időközt várjon a következő kérés elküldése előtt. Ez a véletlenszerű intervallum exponenciálisan növekvő tartományból van kiválasztva. Igény szerint felülbírálhatja az alapértelmezett minimális és maximális időközöket a saját minimális és maximális időközök megadásával, attól függően, hogy használatalapú vagy standard logikai alkalmazás munkafolyamattal rendelkezik-e.

Név	Használati korlát	Standard korlát	Jegyzetek
Maximális késleltetés	Alapértelmezett: 1 nap	Alapértelmezett: 1 óra	A Használati logikai alkalmazás munkafolyamatának alapértelmezett korlátjának módosításához használja az újrapróbálkozási szabályzat paraméterét. A standard logikaialkalmazás-munkafolyamatok alapértelmezett korlátjának módosításához tekintse át az egybérlős Azure Logic Apps logikai alkalmazások gazdagép- és alkalmazásbeállításainak szerkesztését.
Minimális késés	Alapértelmezett: 5 mp	Alapértelmezett: 5 mp	A Használati logikai alkalmazás munkafolyamatának alapértelmezett korlátjának módosításához használja az újrapróbálkozási szabályzat paraméterét. A standard logikaialkalmazás-munkafolyamatok alapértelmezett korlátjának módosításához tekintse át az egybérlős Azure Logic Apps logikai alkalmazások gazdagép- és alkalmazásbeállításainak szerkesztését.

Név

Használati korlát

Standard korlát

Jegyzetek

Maximális késleltetés

Alapértelmezett: 1 nap

Alapértelmezett: 1 óra

A Használati logikai alkalmazás munkafolyamatának alapértelmezett korlátjának módosításához használja az újrapróbálkozási szabályzat paraméterét.

A standard logikaialkalmazás-munkafolyamatok alapértelmezett korlátjának módosításához tekintse át az egybérlős Azure Logic Apps logikai alkalmazások gazdagép- és alkalmazásbeállításainak szerkesztését.

Minimális késés

Alapértelmezett: 5 mp

A Használati logikai alkalmazás munkafolyamatának alapértelmezett korlátjának módosításához használja az újrapróbálkozási szabályzat paraméterét.

Véletlenszerű változótartományok

Az exponenciális időközi újrapróbálkozási szabályzat esetében az alábbi táblázat azt az általános algoritmust mutatja be, amellyel az Azure Logic Apps egységes véletlenszerű változót hoz létre a megadott tartományban minden újrapróbálkozáshoz. A megadott tartomány legfeljebb az újrapróbálkozések számát is tartalmazhatja.

Újrapróbálkozás száma	Minimális időköz	Maximális időköz
1	max(0, <minimális intervallum>)	min(interval, <maximum-interval>)
2	max(intervallum, <minimális intervallum>)	min(2 * intervallum, <maximális időköz>)
3	max(2 * intervallum, <minimális intervallum>)	min(4 * intervallum, <maximális időköz>)
4	max(4 * intervallum, <minimális intervallum>)	min(8 * intervallum, <maximális időköz>)
....	....	....

A "futtatás után" viselkedés kezelése

Amikor műveleteket ad hozzá a munkafolyamat-tervezőben, implicit módon deklarálja a műveletek futtatásához használandó sorrendet. A művelet futtatása után a művelet olyan állapottal lesz megjelölve, mint a Sikeres, a Sikertelen, a Kihagyott vagy az Időtúllépés. Alapértelmezés szerint a tervezőben hozzáadott művelet csak azt követően fut, hogy az előd sikeresen befejeződött. A művelet mögöttes definíciójában a runAfter tulajdonság azt határozza meg, hogy a megelőző műveletnek, amelyet először végre kell hajtania, és hogy az adott elődhöz engedélyezett állapotok a követő művelet futtatása előtt lefuthatnak-e.

Ha egy művelet nem kezelt hibát vagy kivételt jelez, a művelet sikertelen, a követő művelet pedig kihagyva lesz. Ha ez a viselkedés párhuzamos ágakkal rendelkező művelet esetén fordul elő, az Azure Logic Apps-motor a többi ágat követi a befejezési állapotuk meghatározásához. Ha például egy ág kihagyott művelettel végződik, az ág befejezési állapota a kihagyott művelet megelőző állapotán alapul. A munkafolyamat futtatása után a motor az összes ágállapot kiértékelésével meghatározza a teljes futtatás állapotát. Ha bármelyik ág sikertelen lesz, a teljes munkafolyamat-futtatás sikertelenként lesz megjelölve.

Conceptual diagram with examples that show how run statuses are evaluated.

Ha meg szeretné győződni arról, hogy egy művelet a megelőző állapota ellenére is futtatható, módosíthatja a művelet "futtatás után" viselkedését a megelőző sikertelen állapotainak kezeléséhez. Így a művelet akkor fut, ha az előd állapota Sikeres, Sikertelen, Kihagyott, Időtúllépés vagy mindezek az állapotok.

Ha például az Office 365 Outlook e-mail-műveletet szeretne futtatni, miután az Excel Online Sor hozzáadása táblázatelődő műveletbe sikertelenként lett megjelölve, a Sikeres helyett módosítsa a "futtatás után" viselkedést a tervező vagy a kódnézet-szerkesztő használatával.

Megjegyzés:

A tervezőben a "futtatás után" beállítás nem vonatkozik az eseményindítót azonnal követő műveletre, mivel az eseményindítónak sikeresen le kell futnia az első művelet futtatása előtt.

A "futtatás után" viselkedés módosítása a tervezőben

Standard
Használat

Az Azure Portalon nyissa meg a logikai alkalmazás munkafolyamatát a tervezőben.
A tervezőn válassza ki a műveletalakzatot. A részletek panelen válassza a Futtatás után lehetőséget.

A Futtatás után panelen az aktuálisan kijelölt művelet megelőző művelete látható.
Bontsa ki a megelőző műveleti csomópontot az összes "futtatás után" állapot megtekintéséhez.

Alapértelmezés szerint a "futtatás után" állapot sikeresnek van beállítva. A megelőző műveletnek tehát sikeresen le kell futnia, mielőtt a jelenleg kijelölt művelet lefutna.
Módosítsa a "futtatás után" viselkedést a kívánt állapotra. Az alapértelmezett beállítás törlése előtt győződjön meg arról, hogy először kiválaszt egy beállítást. Mindig ki kell jelölnie legalább egy lehetőséget.

Az alábbi példa kiválasztása sikertelen volt.
Ha meg szeretné adni, hogy az aktuális művelet fut-e, a megelőző művelet sikertelenként, kihagyva vagy időtúllépésként van-e megjelölve, jelölje ki a többi állapotot.
Ha azt szeretné, hogy egynél több megelőző művelet fusson, amelyek mindegyike saját "futtatás után" állapottal rendelkezik, bontsa ki a Műveletek kijelölése listát. Válassza ki a kívánt megelőző műveleteket, és adja meg a szükséges "futtatás után" állapotokat.
Ha elkészült, válassza a Kész lehetőséget.

A "futtatás után" viselkedés módosítása a kódnézet-szerkesztőben

Az Azure Portalon nyissa meg a logikai alkalmazás munkafolyamatát a kódnézet-szerkesztőben.

A művelet JSON-definíciójában szerkessze a runAfter tulajdonságot, amelynek szintaxisa a következő:

"<action-name>": {
   "inputs": {
      "<action-specific-inputs>"
   },
   "runAfter": {
      "<preceding-action>": [
         "Succeeded"
      ]
   },
   "type": "<action-type>"
}

Ebben a példában módosítsa a tulajdonságot a runAfter következőre SucceededFailed:

"Send_an_email_(V2)": {
   "inputs": {
      "body": {
         "Body": "<p>Failed to add row to table: @{body('Add_a_row_into_a_table')?['Terms']}</p>",
         "Subject": "Add row to table failed: @{body('Add_a_row_into_a_table')?['Terms']}",
         "To": "Sophia.Owen@fabrikam.com"
      },
      "host": {
         "connection": {
            "name": "@parameters('$connections')['office365']['connectionId']"
         }
      },
      "method": "post",
      "path": "/v2/Mail"
   },
   "runAfter": {
      "Add_a_row_into_a_table": [
         "Failed"
      ]
   },
   "type": "ApiConnection"
}

Ha meg szeretné adni, hogy a művelet fut-e, a megelőző művelet a következőként Failedvan megjelölve, Skipped vagy TimedOutadja hozzá a többi állapotot:
```
"runAfter": {
   "Add_a_row_into_a_table": [
      "Failed", "Skipped", "TimedOut"
   ]
},
```

Műveletek kiértékelése hatókörökkel és azok eredményeivel

Az egyes műveletek után a "futtatás után" beállítással végrehajtott lépésekhez hasonlóan csoportosíthatja a műveleteket egy hatókörön belül. Hatóköröket akkor használhat, ha logikailag csoportosítja a műveleteket, értékeli a hatókör összesített állapotát, és az állapot alapján hajt végre műveleteket. Miután a hatókör összes művelete befejeződött, maga a hatókör saját állapotot kap.

A hatókör állapotának ellenőrzéséhez ugyanazokat a feltételeket használhatja, mint a munkafolyamat-futtatás állapotának ellenőrzéséhez, például sikeres, sikertelen stb.

Alapértelmezés szerint, ha a hatókör összes művelete sikeres, a hatókör állapota Sikeresként van megjelölve. Ha egy hatókör utolsó művelete sikertelen vagy megszakítottként van megjelölve, a hatókör állapota Sikertelenként van megjelölve.

Ha kivételeket szeretne kifogni egy sikertelen hatókörben, és futtatni szeretné a hibákat kezelő műveleteket, használhatja a sikertelen hatókör "futtatás után" beállítását. Így, ha a hatókörben lévő műveletek sikertelenek , és a hatókörhöz a "futtatás után" beállítást használja, egyetlen műveletet hozhat létre a hibák észleléséhez.

A hatókörökre vonatkozó korlátozásokért lásd : Korlátok és konfiguráció.

Környezet és eredmények lekérése hibák esetén

Bár hasznos a hatókörből származó hibák észlelése, érdemes lehet több kontextust is használnia a pontos sikertelen műveletek, valamint az esetleges hibák vagy állapotkódok megismeréséhez. A result() függvény egy hatókörrel rendelkező művelet legfelső szintű műveleteinek eredményeit adja vissza. Ez a függvény egyetlen paraméterként fogadja el a hatókör nevét, és egy tömböt ad vissza a legfelső szintű műveletek eredményeivel. Ezek a műveleti objektumok ugyanazokat az attribútumokat adják vissza, mint a actions() függvény által visszaadott attribútumok, például a művelet kezdő időpontja, a befejezési idő, az állapot, a bemenetek, a korrelációs azonosítók és a kimenetek.

Megjegyzés:

A result() függvény csak a legfelső szintű műveletekből adja vissza az eredményeket, nem pedig mélyebb beágyazott műveletekből, például kapcsoló- vagy feltételműveletekből.

A hatókörben sikertelen műveletek kontextusának lekéréséhez használhatja a @result() kifejezést a hatókör nevével és a "futtatás után" beállítással. Ha a visszaadott tömböt a sikertelen állapotú műveletekre szeretné szűrni, hozzáadhatja a Tömbszűrő műveletet. Ha egy visszaadott sikertelen művelethez szeretne műveletet futtatni, hajtsa végre a visszaadott szűrt tömböt, és használjon minden ciklushoz egy-egy műveletet.

Az alábbi JSON-példa http POST-kérést küld a választörzsnek az My_Scope nevű hatókörműveletben meghiúsult műveletekhez. A példát egy részletes magyarázat követi.

"Filter_array": {
   "type": "Query",
   "inputs": {
      "from": "@result('My_Scope')",
      "where": "@equals(item()['status'], 'Failed')"
   },
   "runAfter": {
      "My_Scope": [
         "Failed"
      ]
    }
},
"For_each": {
   "type": "foreach",
   "actions": {
      "Log_exception": {
         "type": "Http",
         "inputs": {
            "method": "POST",
            "body": "@item()['outputs']['body']",
            "headers": {
               "x-failed-action-name": "@item()['name']",
               "x-failed-tracking-id": "@item()['clientTrackingId']"
            },
            "uri": "http://requestb.in/"
         },
         "runAfter": {}
      }
   },
   "foreach": "@body('Filter_array')",
   "runAfter": {
      "Filter_array": [
         "Succeeded"
      ]
   }
}

A következő lépések ismertetik, hogy mi történik ebben a példában:

A Szűrőtömb művelet az My_Scope belüli összes művelet eredményének lekéréséhez a következő szűrőkifejezést használja:@result('My_Scope')
A Szűrőtömb feltétel minden @result() olyan elem, amelynek állapota egyenlőFailed. Ez a feltétel szűri a My_Scope összes műveleteredményét tartalmazó tömböt egy olyan tömbre, amelyen csak a sikertelen művelet eredményei vannak.
For_each Ciklusművelet végrehajtása a szűrt tömbkimeneteken. Ez a lépés végrehajt egy műveletet minden korábban szűrt sikertelen művelet eredményéhez.

Ha a hatókör egyetlen művelete meghiúsul, a ciklusban lévő For_each műveletek csak egyszer futnak. Több sikertelen művelet meghibásodásonként egy műveletet okoz.
Http POST küldése az For_each elem válasz törzsére, azaz a @item()['outputs']['body'] kifejezésre.

Az @result() elemalakzat megegyezik az @actions() alakzatéval, és ugyanúgy elemezhető.
Adjon meg két egyéni fejlécet a sikertelen művelet nevével (@item()['name']) és a sikertelen futtatású ügyfélkövetési azonosítóval (@item()['clientTrackingId']).

Referenciaként íme egy példa egyetlen @result() elemre, amely az nameelőző példában elemzett , bodyés clientTrackingId tulajdonságokat mutatja. Egy For_each műveleten @result() kívül ezekből az objektumokból egy tömböt ad vissza.

{
   "name": "Example_Action_That_Failed",
   "inputs": {
      "uri": "https://myfailedaction.azurewebsites.net",
      "method": "POST"
   },
   "outputs": {
      "statusCode": 404,
      "headers": {
         "Date": "Thu, 11 Aug 2016 03:18:18 GMT",
         "Server": "Microsoft-IIS/8.0",
         "X-Powered-By": "ASP.NET",
         "Content-Length": "68",
         "Content-Type": "application/json"
      },
      "body": {
         "code": "ResourceNotFound",
         "message": "/docs/folder-name/resource-name does not exist"
      }
   },
   "startTime": "2016-08-11T03:18:19.7755341Z",
   "endTime": "2016-08-11T03:18:20.2598835Z",
   "trackingId": "bdd82e28-ba2c-4160-a700-e3a8f1a38e22",
   "clientTrackingId": "08587307213861835591296330354",
   "code": "NotFound",
   "status": "Failed"
}

Különböző kivételkezelési minták végrehajtásához használhatja a cikkben korábban ismertetett kifejezéseket. Dönthet úgy, hogy egyetlen kivételkezelési műveletet hajt végre azon a hatókörön kívül, amely elfogadja a hibák teljes szűrt tömbét, és eltávolítja a For_each műveletet. A válaszból \@result() a korábban ismertetett egyéb hasznos tulajdonságokat is felveheti.

Azure Monitor-naplók beállítása

Az előző minták hasznos módszerek a futtatás során előforduló hibák és kivételek kezelésére. A futtatástól függetlenül előforduló hibákat azonban azonosíthatja és megválaszolhatja. A futtatási állapotok kiértékeléséhez figyelheti a futtatások naplóit és metrikáit, vagy közzéteheti őket bármely tetszőleges monitorozási eszközben.

Az Azure Monitor például egyszerűbb módot kínál arra, hogy az összes munkafolyamat-eseményt, beleértve az összes futtatási és műveleti állapotot is elküldje egy célhelyre. Riasztásokat állíthat be adott metrikákhoz és küszöbértékekhez az Azure Monitorban. Munkafolyamat-eseményeket log Analytics-munkaterületre vagy Azure Storage-fiókba is küldhet. Vagy az összes eseményt streamelheti az Azure Event Hubson keresztül az Azure Stream Analyticsbe. A Stream Analyticsben a diagnosztikai naplók rendellenességek, átlagok vagy hibák alapján írhat élő lekérdezéseket. A Stream Analytics használatával adatokat küldhet más adatforrásoknak, például üzenetsoroknak, témaköröknek, SQL-nek, Azure Cosmos DB-nek vagy Power BI-nak.

További információkért tekintse át az Azure Monitor-naplók beállítását és az Azure Logic Apps diagnosztikai adatainak gyűjtését.

További lépések

További információ az Azure Logic Apps példáiról és forgatókönyveiről