Megosztás:

Az Azure Cosmos DB for NoSQL Azure Functions-eseményindítójával kapcsolatos problémák diagnosztizálása és hibaelhárítása

  • Alkalmazandó: ✅ NoSQL

Ez a cikk az Azure Cosmos DB for NoSQL-hez készült Azure Functions-eseményindító használatakor felmerülő gyakori problémákat, kerülő megoldásokat és diagnosztikai lépéseket ismerteti.

Függőségek

Az Azure Functions eseményindítói és kötései az Azure Cosmos DB for NoSQL-hez a Microsoft.Azure.WebJobs.Extensions.CosmosDB bővítménycsomagtól függnek az alap Azure Functions-futtatókörnyezetben. Ezeket a csomagokat mindig frissítse, mert javításokat és új funkciókat tartalmaznak, amelyek segíthetnek az esetleges problémák megoldásában.

Az Azure Cosmos DB SDK önálló használata

A bővítménycsomag fő funkciója, hogy támogatást nyújtson az Azure Functions-eseményindítóhoz és az Azure Cosmos DB kötéseihez. A csomag tartalmazza az Azure Cosmos DB .NET SDK-t is, amely akkor hasznos, ha programozott módon szeretne kommunikálni az Azure Cosmos DB-vel az eseményindító és a kötések használata nélkül.

Ha az Azure Cosmos DB SDK-t szeretné használni, győződjön meg arról, hogy nem ad hozzá újabb NuGet-csomaghivatkozást a projekthez. Ehelyett oldja fel az SDK-referenciát az Azure Functions bővítménycsomagján keresztül. Használja az Azure Cosmos DB SDK-t az eseményindítótól és a kötésektől elkülönítve.

Emellett, ha manuálisan hozza létre az Azure Cosmos DB SDK-ügyfél saját példányát, kövesse az ügyfél egyetlen példányának létrehozását és az egytonos minta megközelítést. Ez a folyamat elkerüli a lehetséges socket-problémákat a műveletek során.

Gyakori forgatókönyvek és kerülő megoldások

Az Azure-függvény meghiúsul egy hibaüzenettel, amely szerint a gyűjtemény "doesn't exist"

Az Azure-függvény a következő hibaüzenettel meghiúsul: "Vagy a forrásgyűjtemény collection-name (az adatbázisban database-name) vagy a bérletgyűjtemény collection2-name (az adatbázisban database2-name) nem létezik. A figyelő indítása előtt mindkét gyűjteménynek léteznie kell. A bérletgyűjtemény automatikus létrehozásához állítsa CreateLeaseCollectionIfNotExists következő értékre: true.

Ez a hiba azt jelenti, hogy az eseményindító működéséhez szükséges Azure Cosmos DB-tárolók egyike vagy mindkettő:

  • Nem létezik
  • Nem érhető el az Azure-függvény

Maga a hibaszöveg jelzi, hogy az eseményindító melyik Azure Cosmos DB-adatbázist és -tárolót keresi a konfigurációja alapján.

A probléma megoldása:

  1. Ellenőrizze az Connection attribútumot, és hivatkozik-e az Azure-függvényalkalmazásban létező beállításra.

    • Az attribútum értéke nem maga a kapcsolati sztring, hanem a konfigurációs beállítás neve.

  2. Ellenőrizze, hogy a databaseName és containerName értékek léteznek-e az Azure Cosmos DB-fiókban.

    • Ha automatikus értékcserét használ az %settingName% minták használatával, győződjön meg arról, hogy a beállítás neve megtalálható az Azure Functions alkalmazásban.

  3. Ha nem ad meg LeaseContainerName/leaseContainerName értéket, az alapértelmezett érték a következő leases. Ellenőrizze, hogy létezik-e ilyen tároló.

    • Igény szerint beállíthatja a CreateLeaseContainerIfNotExists attribútumot az eseményindítójában, hogy true automatikusan létrehozza azt.

  4. Annak érdekében, hogy az Azure Cosmos DB-fiók ne blokkolja az Azure-függvényt, ellenőrizze az Azure Cosmos DB-fiók tűzfalkonfigurációját.

Az Azure függvénye nem indul el; a következő hibaüzenet jelenik meg: "Shared throughput collection should have a partition key"

Az Azure Cosmos DB-bővítmény korábbi verziói nem támogatták a megosztott átviteli sebességű adatbázisban létrehozott bérlettároló használatát.

A probléma megoldása:

Az Azure-függvény nem indul el, a következő hibaüzenettel: "PartitionKey must be supplied for this operation"

Ez a hiba azt jelenti, hogy jelenleg egy particionált bérletgyűjteményt használ egy régi bővítményfüggőséggel.

A probléma megoldása:

  • Frissítsen a legújabb elérhető verzióra.

Az Azure függvény a következő hibaüzenettel nem indul el: "Forbidden (403); Substatus: 5300... The given request [POST ...] can't be authorized by Microsoft Entra token in data plane"

Ez a hiba azt jelenti, hogy a függvény nem adatműveletet próbál végrehajtani Microsoft Entra-identitások használatával. Microsoft Entra-identitások használatakor nem használható CreateLeaseContainerIfNotExists = true .

Az Azure-függvény nem indul el, a következő hibaüzenettel: "The lease collection, if partitioned, must have partition key equal to id"

Ez a hiba azt jelenti, hogy az aktuális bérelési konténer particionált, de a partíciókulcs elérési útja nem /id.

A probléma megoldása:

  • Hozza létre újra a bérletek tárolóját /id partíciókulcsként.

Amikor megpróbálja futtatni az eseményindítót, a következő hibaüzenet jelenik meg: "Value can't be null. Parameter name: o" in your Azure function logs"

Ez a probléma akkor fordulhat elő, ha az Azure Portalt használja, és az eseményindítót használó Azure-függvény vizsgálatakor a Futtatás gombot választja. Az eseményindító indításához nem kell a Futtatás lehetőséget választania. A függvény üzembe helyezésekor automatikusan elindul.

A probléma megoldása:

  • Ha ellenőrizni szeretné a függvény naplóstreamjét az Azure Portalon, nyissa meg a figyelt tárolót, és szúrjon be néhány új elemet. Az eseményindító automatikusan fut.

A módosítások fogadása túl sokáig tart

Ennek a forgatókönyvnek több oka is lehet. Fontolja meg a következő megoldások vagy az összes kipróbálását:

  • Az Azure-függvény és az Azure Cosmos DB-fiók külön régiókban van üzembe helyezve? Az optimális hálózati késés érdekében az Azure-függvénynek és az Azure Cosmos DB-fióknak ugyanabban az Azure-régióban kell elhelyezkedniük.

  • Folyamatosak vagy szórványosak a változások az Azure Cosmos DB-tárolóban?

    • Ha szórványosak, előfordulhat, hogy a tárolt módosítások és az azokat összegyűjtő Azure-függvény között némi késés van. Ez a viselkedés akkor fordul elő, ha az eseményindító belsőleg ellenőrzi az Azure Cosmos DB-tároló módosításait, és nem talál olvasásra váró módosításokat. Az eseményindító ezután konfigurálható ideig (alapértelmezés szerint 5 másodpercig) alszik, mielőtt új módosításokat keres. Az eseményindító ezt a viselkedést használja a nagy kérelemegység-használat (RU) elkerülése érdekében. Az alvóidőt az FeedPollDelay/feedPollDelay eseményindító konfigurációjában megadott beállítással konfigurálhatja . Az érték várhatóan ezredmásodpercben lesz.

  • Előfordulhat, hogy az Azure Cosmos DB-tároló sebessége korlátozott.

  • Az eseményindító attribútumával PreferredLocations vesszővel tagolt Azure-régiók listáját határozhatja meg az egyéni előnyben részesített kapcsolati sorrend meghatározásához.

  • Az új módosítások feldolgozásának sebessége határozza meg, hogy az eseményindító milyen sebességgel fogadja ezeket a módosításokat. Ellenőrizze a függvény végrehajtási idejét vagy időtartamát. Ha a függvény lassú, az növeli az eseményindító új módosításokhoz szükséges idejét. Ha a legutóbbi időtartamnövekedést látja, a kód legutóbbi módosítása hatással lehet rá. Ha az Azure Cosmos DB-tárolón a műveletek fogadásának sebessége gyorsabb, mint az eseményindító sebessége, az folyamatosan lemarad. Érdemes lehet megvizsgálni a függvény kódját, hogy meghatározza a leg időigényesebb műveletet, és hogyan optimalizálhatja azt.

  • A hibakeresési naplók segítségével ellenőrizheti a diagnosztika használatát, és ellenőrizheti, hogy vannak-e hálózati késések.

Egyes módosítások ismétlődnek a triggerben

A módosítás fogalma egy elemre irányuló művelet. Az ugyanazon elemhez tartozó események fogadásának leggyakoribb forgatókönyvei a következők:

  • A függvény végrehajtása során meghiúsul. Ha az újrapróbálkozási szabályzatok engedélyezve vannak a függvényhez, vagy ha a függvény végrehajtása túllépi az engedélyezett végrehajtási időt, ugyanazt a módosítási köteget ismét kézbesítheti a függvénynek. Ez a hiba várható, és terv szerint tekintse meg a függvénynaplókat a hibák jelzéséhez, és győződjön meg arról, hogy engedélyezte az eseményindítónaplókat a további részletekért.

  • A bérletek terhelése egyenletesen oszlik el a példányok között. Ha a példányok növekednek vagy csökkennek, a terheléselosztás ugyanazt a módosítási köteget több függvénypéldányra is átadhatja. Ez a terheléselosztás várható és tervezhető, és átmenetinek kell lennie. Az eseményindító-naplók tartalmazzák azokat az eseményeket, amikor egy példány bérleteket szerez be és bocsát ki.

  • Az elem frissítése folyamatban van. A változáscsatorna több műveletet is tartalmazhat ugyanahhoz az elemhez. Ha az elem frissítéseket kap, több eseményt is átvehet (minden frissítéshez egyet). Az elemek különböző műveleteinek megkülönböztetésére az egyik egyszerű módszer az _lsn nyomon követése. Ha a tulajdonságok nem egyeznek, a módosítások eltérőek.

  • Ha az elemeket csak id azonosítja, ne feledje, hogy egy elem egyedi azonosítója csak az id és annak partíciókulcsa. (Két elem rendelkezhet azonos id-vel, de különböző partíciókulccsal).

Néhány módosítás hiányzik az eseményindítóból

Előfordulhat, hogy a függvény nem veszi fel a NoSQL-tárolóhoz készült Azure Cosmos DB-ben bekövetkezett változások némelyikét. Vagy néhány módosítás hiányzik a célhelyen a másoláskor. Ha igen, próbálkozzon az ebben a szakaszban található megoldásokkal.

  • Győződjön meg arról, hogy engedélyezve vannak a naplók . Ellenőrizze, hogy a feldolgozás során nem történik-e hiba.

  • Amikor az Azure-függvény megkapja a módosításokat, gyakran feldolgozza őket, és opcionálisan elküldheti az eredményt egy másik célhelyre. A hiányzó módosítások vizsgálatakor győződjön meg arról, hogy méri, hogy mely módosítások érkeznek a betöltési ponton. Az Azure-függvény indításakor mérje meg, ne a célhelyen.

  • Ha bizonyos módosítások hiányoznak a célhelyen, ez a viselkedés azt jelezheti, hogy hiba történik az Azure-függvény végrehajtása során a módosítások fogadása után.

    • Ebben a forgatókönyvben a legjobb megoldás az, ha blokkokat ad hozzá try/catch a kódhoz és a módosításokat feldolgozó hurkokba. A hozzáadással észlelheti az elemek egy adott részhalmazának hibáit, és ennek megfelelően kezelheti őket (további elemzés vagy újrapróbálkozás céljából elküldheti őket egy másik tárolóba). Másik lehetőségként konfigurálhatja az Azure Functions újrapróbálkozására vonatkozó szabályzatokat.

      Megjegyzés:

      Az Azure Functions NOSQL-hez készült Azure Cosmos DB-eseményindítója alapértelmezés szerint nem próbálkozik újra a módosítások kötegével, ha a kód végrehajtása során nem kezelt kivétel történt. Ez azt jelenti, hogy azért nem érkeztek meg a módosítások a célhelyre, mert nem tudta feldolgozni őket.

  • Ha a cél egy másik Azure Cosmos DB-tároló, és upsert műveleteket hajt végre az elemek másolásához, ellenőrizze mindkét tároló partíciókulcs-definícióját. A monitorozott és a céltároló partíciókulcsának meg kell egyeznie. Az Upsert-műveletek több forráselemet is menthetnek egyként a célhelyen a konfigurációs különbség miatt.

  • Ha úgy találja, hogy az eseményindító nem kapott bizonyos módosításokat, a leggyakoribb forgatókönyv az, hogy egy másik Azure-függvény fut. A másik függvény üzembe helyezhető az Azure-ban, vagy előfordulhat, hogy egy függvény helyileg fut egy fejlesztő gépén, pontosan ugyanazzal a konfigurációval. Ha igen, előfordulhat, hogy ez a függvény ellopja az Azure-függvénytől elvárható módosítások egy részét.

Emellett a forgatókönyv akkor is érvényesíthető, ha tudja, hogy hány Azure-függvényalkalmazás-példány fut. Ha megvizsgálja a bérlet-tárolót, és megszámolja a benne lévő bérleti elemek számát, a bennük lévő Owner tulajdonság különböző értékeinek meg kell egyezniük a függvényalkalmazás példányainak számával. Ha több tulajdonos van, mint az ismert Azure-függvényalkalmazás-példányok, az azt jelenti, hogy ezek a további tulajdonosok "ellopják" a módosításokat.

Ennek a helyzetnek az egyik egyszerű megoldása, ha a LeaseCollectionPrefix/leaseCollectionPrefix egy új vagy eltérő értékével alkalmazza a függvényt, vagy másik lehetőségként egy új tárolóval való tesztelést végez.

Az elejétől kezdve újra kell indítania és újra kell dolgoznia a tárolóban lévő összes elemet

A tároló összes elemének újrafeldolgozása az elejétől kezdve:

  1. Állítsa le az Azure-függvényt, ha az éppen fut.

  2. Törölje a bérletgyűjtemény dokumentumait (vagy törölje és hozza létre újra a bérletgyűjteményt, hogy üres legyen).

  3. Állítsa a StartFromBeginning CosmosDBTrigger attribútumot a függvényben a következőre true: .

  4. Indítsa újra az Azure-függvényt. A függvény mostantól az elejétől kezdve beolvassa és feldolgozza az összes változást.

A StartFromBeginningtrue beállításával az Azure-függvény az aktuális idő helyett a gyűjtemény előzményeinek elejétől kezdve kezdi meg a módosítások olvasását.

Ez a megoldás csak akkor működik, ha nincsenek már létrehozott bérletek (azaz a bérletgyűjtemény dokumentumai).

Ha ezt a tulajdonságot true értékre állítja, nincs hatása, ha már léteznek létrehozott bérletek. Ebben a forgatókönyvben egy függvény leállítása és újraindítása után a bérletgyűjteményben meghatározott utolsó ellenőrzőpontról kezdi az olvasást.

Hiba: Binding can be done only with IReadOnlyList<Document> or JArray

Ez a hiba akkor fordul elő, ha az Azure Functions-projekt tartalmaz egy manuális NuGet-csomaghivatkozást az Azure Cosmos DB SDK-ra verzióütközéssel. Ez a hiba általában azért fordul elő, mert a csomag verziója eltér az Azure Functions Azure Cosmos DB-bővítményétől.

A probléma megoldásához távolítsa el a hozzáadott manuális NuGet-hivatkozást, és hagyja, hogy az Azure Cosmos DB SDK-referencia feloldódjon az Azure Functions-csomaghoz készült Azure Cosmos DB-bővítményen keresztül.

Az Azure-függvény lekérdezési időközének módosítása a változások észleléséhez

Amint azt korábban a Módosítások szakaszában már elmagyaráztuk, az Azure-függvény konfigurálható ideig (alapértelmezés szerint 5 másodpercig) alvó állapotban van, mielőtt új módosításokat keres (a magas RU-használat elkerülése érdekében). Ezt az alvóidőt az FeedPollDelay/feedPollDelayeseményindító konfigurációjának beállításával konfigurálhatja (az érték várhatóan ezredmásodpercben lesz).

Kapcsolódó tartalom

  • Last updated on