Dela via

Diagnostisera och felsöka problem med Azure Functions-utlösaren för Azure Cosmos DB för NoSQL

GÄLLER FÖR: NoSQL

Den här artikeln beskriver vanliga problem, lösningar och diagnostiksteg när du använder Azure Functions-utlösaren för Azure Cosmos DB för NoSQL.

Beroenden

Azure Functions' utlösare och bindningar för Azure Cosmos DB för NoSQL är beroende av tilläggspaketet Microsoft.Azure.WebJobs.Extensions.CosmosDB ovanpå den grundläggande Azure Functions-runtime. Håll alltid dessa paket uppdaterade eftersom de innehåller korrigeringar och nya funktioner som kan hjälpa dig att åtgärda eventuella problem som du kan stöta på.

Använd Azure Cosmos DB SDK självständigt

De viktigaste funktionerna i tilläggspaketet är att ge stöd för Azure Functions-utlösaren och bindningarna för Azure Cosmos DB. Paketet innehåller även Azure Cosmos DB .NET SDK, vilket är användbart om du vill interagera med Azure Cosmos DB programmatiskt utan att använda utlösaren och bindningarna.

Om du vill använda Azure Cosmos DB SDK kontrollerar du att du inte lägger till någon annan NuGet-paketreferens i projektet. Istället, låt SDK-referensen lösas genom Azure Functions-tilläggspaketet. Använd Azure Cosmos DB SDK separat från utlösaren och bindningarna.

Om du skapar en egen instans av Azure Cosmos DB SDK-klienten manuellt bör du dessutom följa mönstret att bara ha en instans av klienten och använda en singleton-mönstermetod. Den här processen undviker potentiella socketproblem i dina operationer.

Vanliga scenarier och lösningar

Din Azure-funktion misslyckades med ett felmeddelande om att samlingen "doesn't exist"

Azure-funktionen misslyckas med följande felmeddelande: "Källsamlingen collection-name (i databasen database-name) eller lånesamlingen collection2-name (i databasen database2-name) finns inte. Båda samlingarna måste finnas innan lyssnaren startar. Om du vill skapa lånesamlingen automatiskt anger du CreateLeaseCollectionIfNotExists till true.

Det här felet innebär att en eller båda Azure Cosmos DB-containrarna som krävs för att utlösaren ska fungera antingen:

  • Finns inte
  • Kan inte nås till Azure-funktionen

Själva feltexten anger vilken Azure Cosmos DB-databas och container som utlösaren letar efter, baserat på din konfiguration.

Lös problemet så här:

  1. Connection Verifiera attributet och att det refererar till en inställning som finns i din Azure-funktionsapp.

    • Värdet för det här attributet ska inte vara själva anslutningssträng, utan namnet på konfigurationsinställningen.

  2. Kontrollera att databaseName värdena och containerName finns i ditt Azure Cosmos DB-konto.

    • Om du använder automatisk värdeersättning (med mönster %settingName% ) kontrollerar du att namnet på inställningen finns i azure-funktionsappen.

  3. Om du inte anger något LeaseContainerName/leaseContainerName värde är leasesstandardvärdet . Kontrollera att det finns en sådan container.

    • Du kan också ange CreateLeaseContainerIfNotExists attributet i utlösaren till för true att automatiskt skapa det.

  4. Kontrollera azure Cosmos DB-kontots brandväggskonfiguration för att säkerställa att ditt Azure Cosmos DB-konto inte blockerar Azure-funktionen.

Azure-funktionen startar inte med felmeddelandet "Shared throughput collection should have a partition key"

Tidigare versioner av Azure Cosmos DB-tillägget hade inte stöd för användning av en lånecontainer som skapades i en databas med delat dataflöde.

Lös problemet så här:

Azure-funktionen startar inte med felmeddelandet "PartitionKey must be supplied for this operation"

Det här felet innebär att du för närvarande använder en partitionerad lånesamling med ett gammalt tilläggsberoende.

Lös problemet så här:

  • Uppgradera till den senaste tillgängliga versionen.

Azure-funktionen startar inte med felmeddelandet "Forbidden (403); Substatus: 5300... The given request [POST ...] can't be authorized by Microsoft Entra token in data plane"

Det här felet innebär att funktionen försöker utföra en icke-dataåtgärd med hjälp av Microsoft Entra-identiteter. Du kan inte använda CreateLeaseContainerIfNotExists = true när du använder Microsoft Entra-identiteter.

Azure-funktionen startar inte med felmeddelandet "The lease collection, if partitioned, must have partition key equal to id"

Det här felet innebär att din aktuella uthyrningscontainer är partitionerad, men vägen till partitionsnyckeln är inte /id.

Lös problemet så här:

  • Återskapa lånecontainern med /id som partitionsnyckel.

När du försöker köra utlösaren får du felmeddelandet "Value can't be null. Parameter name: o" in your Azure function logs"

Det här problemet kan uppstå om du använder Azure Portal och väljer knappen Kör när du inspekterar en Azure-funktion som använder utlösaren. Utlösaren kräver inte att du väljer Kör för att starta den. Den startar automatiskt när du distribuerar funktionen.

Lös problemet så här:

  • Om du vill kontrollera funktionens loggström på Azure Portal går du till din övervakade container och infogar några nya objekt. Utlösaren körs automatiskt.

Dina ändringar tar för lång tid att ta emot

Det här scenariot kan ha flera orsaker. Överväg att prova någon eller alla av följande lösningar:

  • Distribueras din Azure-funktion och ditt Azure Cosmos DB-konto i separata regioner? För optimal nätverksfördröjning bör din Azure-funktion och ditt Azure Cosmos DB-konto samlokaleras i samma Azure-region.

  • Sker ändringarna i din Azure Cosmos DB-container kontinuerligt eller sporadiskt?

    • Om de är sporadiska kan det uppstå en viss fördröjning mellan de ändringar som lagras och den Azure-funktion som plockar upp dem. Det här beteendet inträffar när utlösaren söker internt efter ändringar i Azure Cosmos DB-containern och inte hittar några ändringar som väntar på att läsas. Utlösaren ligger sedan i viloläge under en konfigurerbar tid (5 sekunder som standard) innan den söker efter nya ändringar. Utlösaren använder det här beteendet för att undvika hög ru-förbrukning (request unit). Du kan konfigurera vilotiden genom FeedPollDelay/feedPollDelay inställningen i konfigurationen av utlösaren. Värdet förväntas vara i millisekunder.

  • Azure Cosmos DB-containern kan vara hastighetsbegränsad.

  • Du kan använda PreferredLocations attributet i utlösaren för att ange en kommaavgränsad lista över Azure-regioner för att definiera en anpassad önskad anslutningsordning.

  • Den hastighet med vilken du bearbetar nya ändringar avgör hur snabbt utlösaren tar emot ändringarna. Kontrollera funktionens körningstid eller varaktighet. Om funktionen är långsam ökar den tid det tar för utlösaren att hämta nya ändringar. Om du ser en ökning av varaktigheten nyligen kan en ny kodändring påverka den. Om den hastighet med vilken du tar emot åtgärder på din Azure Cosmos DB-container är snabbare än hastigheten för utlösaren fortsätter den att släpa efter. Du kanske vill undersöka funktionens kod för att fastställa den mest tidskrävande åtgärden och hur du optimerar den.

  • Du kan använda felsökningsloggar för att kontrollera diagnostiken och kontrollera om det finns nätverksfördröjningar.

Vissa ändringar upprepas i min utlösare

Begreppet ändring är en åtgärd för ett objekt. De vanligaste scenarierna där händelser för samma objekt tas emot är:

  • Funktionen misslyckas vid körning. Om återförsöksprinciper är aktiverade för din funktion eller om funktionskörningen överskrider den tillåtna körningstiden kan samma batch med ändringar levereras igen till funktionen. Det här felet är förväntat och ingår i designen, titta på dina funktionsloggar för indikering på fel och se till att du har aktiverat utlösarloggar för mer information.

  • Det finns en belastningsutjämning av lån mellan instanser. När instanserna ökar eller minskar kan belastningsutjämning orsaka att samma batch med ändringar levereras till flera funktionsinstanser. Den här belastningsutjämningen är förväntad och avsiktlig och bör vara tillfällig. Utlösarloggarna innehåller händelser när en instans övertar och avstår leasingavtal.

  • Objektet uppdateras. Ändringsflödet kan innehålla flera åtgärder för samma objekt. Om objektet tar emot uppdateringar kan det hämta flera händelser (en för varje uppdatering). Ett enkelt sätt att skilja mellan olika åtgärder för samma objekt är att spåra _lsnegenskapen för varje ändring. Om egenskaperna inte matchar är ändringarna annorlunda.

  • Om du bara identifierar objekt av id, ska du komma ihåg att den unika identifieraren för ett objekt är id och dess partitionsnyckel. (Två objekt kan ha samma id men en annan partitionsnyckel).

Vissa ändringar saknas i utlösaren

Du kanske upptäcker att funktionen inte hämtade några av de ändringar som inträffade i Azure Cosmos DB för NoSQL-containern. Eller så saknas vissa ändringar vid destinationen när du kopierar dem. I så fall kan du prova lösningarna i det här avsnittet.

  • Kontrollera att loggarna är aktiverade. Kontrollera att inga fel inträffar under bearbetningen.

  • När din Azure-funktion tar emot ändringarna bearbetar den dem ofta och kan eventuellt skicka resultatet till ett annat mål. När du undersöker saknade ändringar kontrollerar du att du mäter vilka ändringar som tas emot vid inmatningsplatsen. Mät när Azure-funktionen startar, inte vid målet.

  • Om vissa ändringar saknas på målet kan det här beteendet tyda på att ett fel inträffar under Azure-funktionskörningen efter att ändringarna har tagits emot.

    • I det här scenariot är det bästa sättet att lägga till try/catch block i koden och inuti de loopar som kan bearbeta ändringarna. Genom att lägga till den kan du identifiera eventuella fel för en viss delmängd av objekten och hantera dem i enlighet med detta (skicka dem till en annan lagringsplats för ytterligare analys eller försök igen). Du kan också konfigurera omförsöksprinciper för Azure Functions.

      Kommentar

      Azure Functions-utlösaren för Azure Cosmos DB för NOSQL försöker som standard inte göra några ändringar igen om det fanns ett ohanterat undantag under kodkörningen. Det innebär att anledningen till att ändringarna inte kom till målet kan bero på att du inte har bearbetat dem.

  • Om målet är en annan Azure Cosmos DB-container och du utför upsert-åtgärder för att kopiera objekten kontrollerar du partitionsnyckeldefinitionen för båda containrarna. Partitionsnyckeln på den övervakade containern och målcontainern måste vara densamma. Upsert-åtgärder kan spara flera källobjekt som ett på målet på grund av den här konfigurationsskillnaden.

  • Om du upptäcker att utlösaren inte fick några ändringar är det vanligaste scenariot att en annan Azure-funktion körs. Den andra funktionen kan distribueras i Azure eller så kan en funktion köras lokalt på en utvecklardator med exakt samma konfiguration. I så fall kan den här funktionen stjäla en delmängd av de ändringar som du förväntar dig att din Azure-funktion ska bearbeta.

Dessutom kan scenariot verifieras om du vet hur många Azure-funktionsappinstanser som du har kört. Om du inspekterar din lånecontainer och räknar antalet låneobjekt i den, bör de distinkta värdena Owner för egenskapen i dem vara lika med antalet instanser av funktionsappen. Om det finns fler ägare än kända Azure-funktionsappinstanser innebär det att dessa extra ägare "stjäl" ändringarna.

Ett enkelt sätt att kringgå den här situationen är att tillämpa en LeaseCollectionPrefix/leaseCollectionPrefix på din funktion med ett nytt eller annat värde eller, alternativt, testa med en ny lånecontainer.

Du måste starta om och bearbeta alla objekt i containern från början

Så här bearbetar du alla objekt i en container från början:

  1. Stoppa din Azure-funktion om den körs för närvarande.

  2. Ta bort dokumenten i lånesamlingen (eller ta bort och återskapa lånesamlingen så att den är tom).

  3. Ange attributet StartFromBeginning CosmosDBTrigger i funktionen till true.

  4. Starta om Azure-funktionen. Funktionen läser och bearbetar nu alla ändringar från början.

Om du anger StartFromBeginning till true uppmanas Azure-funktionen att börja läsa ändringar från början av samlingens historik i stället för den aktuella tiden.

Den här lösningen fungerar bara när det inte finns några lån som redan har skapats (d.s. dokument i lånesamlingen).

Att ställa in den här egenskapen på true har ingen effekt när lån redan har skapats. I det här scenariot, när en funktion stoppas och startas om, börjar den läsa från den sista kontrollpunkten, enligt definitionen i lånesamlingen.

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

Det här felet inträffar om ditt Azure Functions-projekt innehåller en manuell NuGet-paketreferens till Azure Cosmos DB SDK med en versionskonflikt. Det här felet uppstår ofta eftersom paketet har en annan version än den som tillhandahålls av Azure Cosmos DB-tillägget för Azure Functions.

Du kan kringgå den här situationen genom att ta bort den manuella NuGet-referensen som lades till och låta Azure Cosmos DB SDK-referensen lösas automatiskt genom Azure Cosmos DB-tillägget i Azure Functions-paketet.

Ändra Azure-funktionens avsökningsintervall för att identifiera ändringar

Som vi förklarade tidigare i avsnittet Dina ändringar tar för lång tid att ta emot, går din Azure-funktion i viloläge under en konfigurerbar tidsperiod (5 sekunder som standard) innan den kontrollerar om nya ändringar har skett (för att undvika hög RU-förbrukning). Du kan konfigurera den här vilotiden genom FeedPollDelay/feedPollDelay inställningen i utlösarkonfigurationen (värdet förväntas vara i millisekunder).

Relaterat innehåll