Felsöka Azure Stream Analytics-utdata

  • Artikel

Den här artikeln beskriver vanliga problem med Azure Stream Analytics-utdataanslutningar och hur du felsöker utdataproblem. Många felsökningssteg kräver att resurs- och andra diagnostikloggar aktiveras för ditt Stream Analytics-jobb. Om du inte har aktiverat resursloggar kan du läsa Felsöka Azure Stream Analytics med hjälp av resursloggar.

Jobbet producerar inte utdata

  1. Kontrollera anslutningen till utdata med hjälp av knappen Testa Anslut ion för varje utdata.

  2. Titta på Övervaka Stream Analytics-jobb med Azure-portalen på fliken Övervaka . Eftersom värdena aggregeras fördröjs måtten med några minuter.

    • Om värdet för Indatahändelser är större än noll kan jobbet läsa indata. Om värdet för Indatahändelser inte är större än noll uppstår ett problem med jobbets indata. Mer information finns i Felsöka indataanslutningar . Om ditt jobb har referensdataindata kan du använda delning efter logiskt namn när du tittar på måttet Indatahändelser . Om det inte finns några indatahändelser enbart från dina referensdata innebär det sannolikt att den här indatakällan inte har konfigurerats korrekt för att hämta rätt referensdatauppsättning.
    • Om värdet för datakonverteringsfel är större än noll och ökar, se Azure Stream Analytics-datafel för detaljerad information om datakonverteringsfel.
    • Om värdet För Körningsfel är större än noll tar jobbet emot data men genererar fel när frågan bearbetas. Om du vill hitta felen går du till granskningsloggarna och filtrerar sedan på statusen Misslyckades .
    • Om värdet för Indatahändelser är större än noll och värdet Utdatahändelser är lika med noll är något av följande uttryck sant:
      • Frågebearbetningen resulterade i noll utdatahändelser.
      • Händelser eller fält kan vara felaktiga, vilket resulterar i noll utdata efter frågebearbetningen.
      • Jobbet kunde inte skicka data till utdatamottagaren av anslutnings- eller autentiseringsskäl.

    I åtgärdsloggmeddelanden förklaras ytterligare information, inklusive vad som händer, förutom i fall där frågelogik filtrerar bort alla händelser. Om bearbetningen av flera händelser genererar fel aggregeras felen var 10:e minut.

De första utdata fördröjs

När ett Stream Analytics-jobb startar läss indatahändelserna. Men det kan finnas en fördröjning i utdata, under vissa omständigheter.

Stora tidsvärden i temporala frågeelement kan bidra till utdatafördröjningen. För att skapa rätt utdata över stora tidsfönster läser strömningsjobbet data från den senaste tiden som är möjligt för att fylla tidsfönstret. Data kan vara upp till sju dagar tidigare. Inga utdata genereras förrän de utestående indatahändelserna har lästs. Det här problemet kan uppstå när systemet uppgraderar strömningsjobben. När en uppgradering sker startas jobbet om. Sådana uppgraderingar sker vanligtvis en gång varannan månad.

Använd diskretion när du utformar Stream Analytics-frågan. Om du använder ett stort tidsfönster för temporala element i jobbets frågesyntax kan det leda till en fördröjning i de första utdata när jobbet startar eller startar om. Mer än flera timmar, upp till sju dagar, anses vara ett stort tidsfönster.

En åtgärd för den här typen av första utdatafördröjning är att använda tekniker för frågeparallellisering, till exempel partitionering av data. Eller så kan du lägga till fler strömningsenheter för att förbättra dataflödet tills jobbet kommer ikapp. Mer information finns i Överväganden när du skapar Stream Analytics-jobb.

Dessa faktorer påverkar den första utdatans aktualitet:

  • Användning av fönsterade aggregeringar, till exempel en GROUP BY-sats för rullande, hoppande och skjutbara fönster:

    • För rullande eller hoppande fönsteraggregeringar genereras resultatet i slutet av fönstrets tidsram.
    • För ett skjutfönster genereras resultatet när en händelse kommer in i eller avslutar skjutfönstret.
    • Om du planerar att använda en stor fönsterstorlek, till exempel mer än en timme, är det bäst att välja ett hopp eller skjutfönster. Med de här fönstertyperna kan du se utdata oftare.

  • Användning av temporala kopplingar, till exempel JOIN med DATEDIFF:

    • Matchningar genereras så snart båda sidor av de matchade händelserna anländer.
    • Data som saknar en matchning, till exempel LEFT OUTER JOIN, genereras i slutet av DATEIFF-fönstret för varje händelse till vänster.

  • Användning av temporala analysfunktioner, till exempel ISFIRST, LAST och LAG med LIMIT DURATION:

    • För analysfunktioner genereras utdata för varje händelse. Det finns ingen fördröjning.

Utdata hamnar efter

Under den normala driften av ett jobb kan utdata ha längre och längre svarstider. Om utdata hamnar på efterkälken kan du identifiera rotorsakerna genom att undersöka följande faktorer:

  • Om nedströmsmottagaren begränsas
  • Om den överordnade källan begränsas
  • Om bearbetningslogik i frågan är beräkningsintensiv

Om du vill se utdatainformationen väljer du direktuppspelningsjobbet i Azure-portalen och väljer sedan Jobbdiagram. För varje indata finns det ett händelsemått för kvarvarande uppgifter per partition. Om måttet fortsätter att öka är det en indikator på att systemresurserna är begränsade. Ökningen kan bero på begränsning av utdatamottagare eller hög CPU-användning. Mer information finns i Datadriven felsökning med hjälp av jobbdiagrammet.

Varning om nyckelöverträdelse med Azure SQL Database-utdata

När du konfigurerar en Azure SQL-databas som utdata till ett Stream Analytics-jobb massinfogar den poster i måltabellen. I allmänhet garanterar Azure Stream Analytics leverans minst en gång till utdatamottagaren. Du kan fortfarande uppnå leverans exakt en gång till en SQL-utdata när en SQL-tabell har en unik begränsning definierad.

När du konfigurerar unika nyckelbegränsningar i SQL-tabellen tar Azure Stream Analytics bort dubbletter av poster. Den delar upp data i batchar och infogar rekursivt batcharna tills en enda dubblettpost hittas. Delnings- och infogningsprocessen ignorerar dubbletter en i taget. För ett direktuppspelningsjobb som har många duplicerade rader är processen ineffektiv och tidskrävande. Om du ser flera varningsmeddelanden om nyckelöverträdelse i aktivitetsloggen för föregående timme är det troligt att SQL-utdata saktar ner hela jobbet.

Lös problemet genom att konfigurera det index som orsakar nyckelöverträdelsen genom att aktivera alternativet IGNORE_DUP_KEY. Med det här alternativet kan SQL ignorera dubblettvärden under massinfogningar. Azure SQL Database skapar helt enkelt ett varningsmeddelande i stället för ett fel. Därför genererar Azure Stream Analytics inte längre fel med primärnyckelöverträdelse.

Observera följande observationer när du konfigurerar IGNORE_DUP_KEY för flera typer av index:

  • Du kan inte ange IGNORE_DUP_KEY på en primärnyckel eller en unik begränsning som använder ALTER INDEX. Du måste ta bort indexet och återskapa det.
  • Du kan ange IGNORE_DUP_KEY med hjälp av ALTER INDEX för ett unikt index. Den här instansen skiljer sig från en PRIMARY KEY/UNIQUE-begränsning och skapas med hjälp av en CREATE INDEX- eller INDEX-definition.
  • Alternativet IGNORE_DUP_KEY gäller inte för kolumnlagringsindex eftersom du inte kan framtvinga unikhet för dem.

SQL-utdata försöker igen logik

När ett Stream Analytics-jobb med SQL-utdata tar emot den första batchen med händelser sker följande steg:

  1. Jobbet försöker ansluta till SQL.
  2. Jobbet hämtar schemat för måltabellen.
  3. Jobbet validerar kolumnnamn och typer mot måltabellschemat.
  4. Jobbet förbereder en minnesintern datatabell från utdataposterna i batchen.
  5. Jobbet skriver datatabellen till SQL med hjälp av BulkCopy API.

Under de här stegen kan SQL-utdata uppleva följande typer av fel:

  • Tillfälliga fel som görs om med hjälp av en återförsöksstrategi för exponentiell backoff. Det minsta återförsöksintervallet beror på den enskilda felkoden, men intervallen är vanligtvis mindre än 60 sekunder. Den övre gränsen kan vara högst fem minuter.

    Inloggningsfel och brandväggsproblem görs på nytt minst 5 minuter efter föregående försök och görs ett nytt försök tills de lyckas.

  • Datafel, till exempel gjutningsfel och schemabegränsningsöverträdelser, hanteras med utdatafelprincipen. Dessa fel hanteras genom att binärdelningsbatcherna försöker igen tills den enskilda post som orsakar felet hanteras genom att hoppa över eller försöka igen. Begränsningsöverträdelse för primär unik nyckel hanteras alltid.

  • Icke-tillfälliga fel kan inträffa när det finns problem med SQL-tjänsten eller interna kodfel. Om till exempel fel som (Kod 1132) elastisk pool når sin lagringsgräns löser inte återförsök felet. I dessa scenarier upplever Stream Analytics-jobbet försämring.

  • BulkCopy timeouter kan inträffa under BulkCopy steg 5. BulkCopy kan uppleva timeouter för åtgärder ibland. Standardvärdet för minsta konfigurerade timeout är fem minuter och den fördubblas när den slås i följd. När tidsgränsen är över 15 minuter minskas tipset för maximal batchstorlek till BulkCopy hälften tills 100 händelser per batch finns kvar.

    Viktigt!

    För asa-jobb som inte matas in i nätverket ska du inte förlita dig på käll-IP-adressen för anslutningar som kommer från ASA på något sätt. De kan vara offentliga eller privata IP-adresser beroende på tjänstinfrastrukturåtgärder som sker då och då.

Kolumnnamn är gemener i Azure Stream Analytics (1.0)

När du använder den ursprungliga kompatibilitetsnivån (1.0) ändrar Azure Stream Analytics kolumnnamn till gemener. Det här beteendet har åtgärdats i senare kompatibilitetsnivåer. Om du vill behålla ärendet går du till kompatibilitetsnivå 1.1 eller senare. Mer information finns i Kompatibilitetsnivå för Stream Analytics-jobb.

Få hjälp

Om du vill ha mer hjälp kan du prova vår frågesida för Microsoft Q&A för Azure Stream Analytics.

Nästa steg