Problemen met Azure Stream Analytics oplossen

Artikel
09/13/2021
7 minuten om te lezen

In dit artikel worden veelvoorkomende problemen met Azure Stream Analytics uitvoerverbindingen beschreven en wordt beschreven hoe u uitvoerproblemen kunt oplossen. Voor veel stappen voor probleemoplossing moeten resource- en andere diagnostische logboeken zijn ingeschakeld voor uw Stream Analytics taak. Als u geen resourcelogboeken hebt ingeschakeld, zie Problemen met Azure Stream Analytics met behulp van resourcelogboeken.

De taak produceert geen uitvoer

Controleer de verbinding met uitvoer met behulp van de knop Verbinding testen voor elke uitvoer.
Bekijk Bewaking van metrische gegevens op het tabblad Monitor. Omdat de waarden worden geaggregeerd, worden de metrische gegevens enkele minuten vertraagd.
- Als de waarde voor Invoergebeurtenissen groter is dan nul, kan de taak de invoergegevens lezen. Als de waarde voor Invoergebeurtenissen niet groter is dan nul, is er een probleem met de invoer van de taak. Zie Problemen met invoerverbindingen oplossen voor meer informatie. Als uw taak verwijzingsgegevensinvoer heeft, kunt u splitsen op logische naam toepassen wanneer u naar de metrische gegevens voor invoergebeurtenissen kijkt. Als er alleen geen invoergebeurtenissen van uw referentiegegevens zijn, betekent dit waarschijnlijk dat deze invoerbron niet juist is geconfigureerd om de juiste referentiegegevensset op te halen.
- Als de waarde voor Gegevensconversiefouten groter is dan nul en groter is, zie Azure Stream Analytics gegevensfouten voor gedetailleerde informatie over fouten met gegevensconversie.
- Als de waarde runtimefouten groter is dan nul, ontvangt uw taak gegevens, maar worden er fouten gegenereerd tijdens het verwerken van de query. Als u de fouten wilt vinden, gaat u naar de auditlogboekenen filtert u op de status Mislukt.
- Als de waarde voor Invoergebeurtenissen groter is dan nul en de waarde Uitvoergebeurtenissen gelijk is aan nul, is een van de volgende instructies waar:
  - De queryverwerking heeft geleid tot nul uitvoergebeurtenissen.
  - Gebeurtenissen of velden zijn mogelijk misvormd, wat resulteert in een nuluitvoer na het verwerken van de query.
  - De taak kan om verbindings- of verificatieredenen geen gegevens naar de uitvoer-sink pushen.
In berichten in het operations-logboek worden aanvullende details uitgelegd, waaronder wat er gebeurt, behalve in gevallen waarin met de querylogica alle gebeurtenissen worden gefilterd. Als de verwerking van meerdere gebeurtenissen fouten genereert, worden de fouten elke 10 minuten geaggregeerd.

De eerste uitvoer is vertraagd

Wanneer een Stream Analytics wordt gestart, worden de invoergebeurtenissen gelezen. Maar in bepaalde omstandigheden kan er een vertraging in de uitvoer zijn.

Grote tijdwaarden in tijdelijke query-elementen kunnen bijdragen aan de uitvoervertraging. Om de juiste uitvoer te produceren over grote tijdvensters, leest de streaming-taak gegevens van de meest recente tijd die mogelijk is om het tijdvenster te vullen. De gegevens kunnen maximaal zeven dagen achter elkaar zijn. Er wordt geen uitvoer geproduceerd totdat de openstaande invoergebeurtenissen worden gelezen. Dit probleem kan aan het oppervlak komen wanneer het systeem de streamingtaken bijwerkt. Wanneer een upgrade wordt uitgevoerd, wordt de taak opnieuw gestart. Dergelijke upgrades worden doorgaans om de paar maanden uitgevoerd.

Gebruik discretie bij het ontwerpen van Stream Analytics query. Als u een groot tijdvenster gebruikt voor tijdelijke elementen in de querysyntaxis van de taak, kan dit leiden tot een vertraging in de eerste uitvoer wanneer de taak wordt gestart of opnieuw wordt gestart. Meer dan enkele uren, maximaal zeven dagen, wordt beschouwd als een groot tijdvenster.

Een oplossing voor dit soort eerste uitvoervertraging is het gebruik van query-parallellisatietechnieken, zoals het partitioneren van de gegevens. U kunt ook meer streaming-eenheden toevoegen om de doorvoer te verbeteren totdat de taak wordt afvangt. Zie Overwegingen bij het maken van Stream Analytics taken voor meer informatie.

Deze factoren zijn van invloed op de actualiteit van de eerste uitvoer:

Het gebruik van geaggregeerde vensters, zoals een GROUP BY-component van tumbling-, hopping- en sliding windows:
- Voor tumbling- of hoppingwindows worden de resultaten gegenereerd aan het einde van het tijdsbestek van het venster.
- Voor een sliding window worden de resultaten gegenereerd wanneer een gebeurtenis de sliding window.
- Als u van plan bent om een grote venstergrootte te gebruiken, zoals meer dan een uur, kunt u het beste een hopping- of sliding window. Met deze venstertypen kunt u de uitvoer vaker zien.
Het gebruik van tijdelijke joins, zoals JOIN met DATEDIFF:
- Overeenkomsten worden gegenereerd zodra beide zijden van de overeenkomende gebeurtenissen binnenkomen.
- Gegevens zonder overeenkomst, zoals LEFT OUTER JOIN, worden gegenereerd aan het einde van het DATEDIFF-venster voor elke gebeurtenis aan de linkerkant.
Het gebruik van tijdelijke analytische functies, zoals ISFIRST, LAST en LAG met LIMIT DURATION:
- Voor analysefuncties wordt de uitvoer gegenereerd voor elke gebeurtenis. Er is geen vertraging.

De uitvoer blijft achter

Tijdens de normale werking van een taak kan de uitvoer langere en langere perioden latentie hebben. Als de uitvoer zo achter blijft, kunt u de hoofdoorzaken aanwijzen door de volgende factoren te onderzoeken:

Of de downstream-sink wordt beperkt
Of de upstream-bron wordt beperkt
Of de verwerkingslogica in de query rekenintensief is

Als u de uitvoerdetails wilt zien, selecteert u de streaming-taak in Azure Portal selecteert u vervolgens Taakdiagram. Voor elke invoer is er een metrisch gegeven voor achterstandsgebeurtenissen per partitie. Als de metrische gegevens blijven toenemen, is het een indicator dat de systeembronnen beperkt zijn. De toename wordt mogelijk veroorzaakt door sinkbeperking van de uitvoer of een hoog CPU-gebruik. Zie Gegevensgestuurde debugging met behulp van het taakdiagram voor meer informatie.

Waarschuwing over schending van sleutel met Azure SQL Database uitvoer

Wanneer u een Azure SQL database configureert als uitvoer naar een Stream Analytics taak, worden er bulksgewijs records in de doeltabel opgenomen. Over het algemeen Azure Stream Analytics gegarandeerd ten minste één levering aan de uitvoer-sink. U kunt nog steeds exact één levering aan een SQL realiseren wanneer een SQL tabel een unieke beperking heeft gedefinieerd.

Wanneer u unieke sleutelbeperkingen in de tabel SQL, Azure Stream Analytics dubbele records verwijderd. De gegevens worden gesplitst in batches en de batches worden recursief invoegt totdat er één dubbele record wordt gevonden. Het proces voor splitsen en invoegen negeert de dubbele waarden één voor één. Voor een streaming-taak met veel dubbele rijen is het proces inefficiënt en tijdrovend. Als er meerdere waarschuwingsberichten over schendingen van sleutels in het activiteitenlogboek van het afgelopen uur worden weer gegeven, vertraagt de uitvoer van uw SQL waarschijnlijk de hele taak.

U kunt dit probleem oplossen door de index te configureren die de sleutelschending veroorzaakt door de optie IGNORE_DUP_KEY in te stellen. Met deze optie SQL dubbele waarden negeren tijdens bulksgewijs invoegen. Azure SQL Database genereert gewoon een waarschuwingsbericht in plaats van een fout. Als gevolg hiervan veroorzaakt Azure Stream Analytics niet langer fouten met schendingen van de primaire sleutel.

Let op de volgende waarnemingen bij het configureren IGNORE_DUP_KEY voor verschillende typen indexen:

U kunt geen beperkingen instellen IGNORE_DUP_KEY primaire sleutel of een unieke beperking die ALTER INDEX gebruikt. U moet de index neerzetten en opnieuw maken.
U kunt een IGNORE_DUP_KEY alter index gebruiken voor een unieke index. Dit exemplaar verschilt van een PRIMAIRE SLEUTEL/UNIEKE beperking en wordt gemaakt met behulp van een CREATE INDEX- of INDEX-definitie.
De IGNORE_DUP_KEY is niet van toepassing op kolomopslagindexen omdat u er geen uniekheid voor kunt afdwingen.

SQL logica voor opnieuw proberen

Wanneer een Stream Analytics met SQL de eerste batch gebeurtenissen ontvangt, worden de volgende stappen uitgevoerd:

De taak probeert verbinding te maken met SQL.
De taak haalt het schema van de doeltabel op.
De taak valideert kolomnamen en -typen op het doeltabelschema.
De taak bereidt een gegevenstabel in het geheugen van de uitvoerrecords in de batch voor.
De taak schrijft de gegevenstabel naar SQL bulkcopy-API.

Tijdens deze stappen kan de SQL volgende typen fouten ervaren:

Tijdelijke fouten die opnieuw worden proberen met behulp van een strategie voor exponentieel opnieuw proberen. Het minimale interval voor nieuwe poging is afhankelijk van de afzonderlijke foutcode, maar de intervallen zijn doorgaans minder dan 60 seconden. De bovengrens kan maximaal vijf minuten zijn.

Aanmeldingsfouten en firewallproblemen worden ten minste vijf minuten na de vorige poging opnieuw geprobeerd en worden opnieuw geprobeerd totdat ze zijn geslaagd.
Gegevensfouten, zoals cast-cast-fouten en schendingen van schemabeperkingen, worden verwerkt met uitvoerfoutbeleid. Deze fouten worden afgehandeld door binaire gesplitste batches opnieuw uit te proberen totdat de afzonderlijke record die de fout veroorzaakt, wordt afgehandeld door overslaan of opnieuw proberen. Schending van primaire unieke sleutelbeperking wordt altijd afgehandeld.
Niet-tijdelijke fouten kunnen optreden wanneer er problemen zijn SQL service of interne codedefecten. Als bijvoorbeeld fouten zoals (Code 1132) Elastische pool de opslaglimiet hebben bereikt, kunnen nieuwe proberen de fout niet oplossen. In deze scenario's ervaart Stream Analytics een verslechtering van de taak.
BulkCopy time-outs kunnen zich tijdens BulkCopy stap 5 voor doen. BulkCopy kan af en toe time-outs van de bewerking ervaren. De standaard minimale geconfigureerde time-out is vijf minuten en deze wordt verdubbeld wanneer deze achtereenvolgens wordt aangeslagen. Zodra de time-out hoger is dan 15 minuten, wordt de maximale batchgrootte hint naar gereduceerd tot de helft totdat BulkCopy er 100 gebeurtenissen per batch over zijn.

Kolomnamen zijn kleine letters in Azure Stream Analytics (1.0)

Wanneer u het oorspronkelijke compatibiliteitsniveau (1.0) gebruikt, Azure Stream Analytics kolomnamen gewijzigd in kleine letters. Dit gedrag is opgelost in latere compatibiliteitsniveaus. Als u de case wilt behouden, gaat u naar compatibiliteitsniveau 1.1 of hoger. Zie Compatibiliteitsniveau voor Stream Analytics taken voor meer informatie.

Hulp vragen

Probeer onze Microsoft Q&A question page for Azure Stream Analyticsvoor meer Azure Stream Analytics.