Problemen met Azure Stream Analytics-uitvoer oplossen

In dit artikel worden veelvoorkomende problemen beschreven met Azure Stream Analytics uitvoerverbindingen en hoe u deze kunt oplossen. Problemen die worden behandeld, zijn taken die geen uitvoer produceren, vertraagde eerste uitvoer, uitvoer die achterloopt, Azure SQL Database sleutelschendingen en gedrag voor opnieuw proberen van SQL. Voor veel stappen voor probleemoplossing moeten resource- en andere diagnostische logboeken worden ingeschakeld voor uw Stream Analytics-taak. Als u geen resourcelogboeken hebt ingeschakeld, zie Problemen met Azure Stream Analytics oplossen met behulp van resourcelogboeken.

De taak produceert geen uitvoer

  1. Controleer de verbinding met elke uitvoer met de knop Verbinding testen.

  2. Bekijk De Stream Analytics-taak controleren met Azure-portal op het tabblad Monitor. Omdat de waarden worden geaggregeerd, lopen de metrische gegevens enkele minuten achter.

    • Als de waarde voor invoerevenementen groter is dan nul, kan de taak de invoergegevens lezen. Als de waarde voor invoerevenementen 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, past u splitsen op logische naam toe wanneer u de metrische gegevens voor invoergebeurtenissen bekijkt. 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 van Gegevensconversiefouten groter is dan nul en toeneemt, raadpleegt u Gegevensfouten in Azure Stream Analytics voor gedetailleerde informatie over gegevensconversiefouten.
    • Als de waarde runtimefouten groter is dan nul, ontvangt uw taak gegevens, maar genereert deze fouten tijdens het verwerken van de query. Als u de fouten wilt vinden, gaat u naar de auditlogboeken en filtert u vervolgens op de status Mislukt .
    • Als de waarde voor invoerevenementen groter is dan nul en de waarde voor uitvoer gebeurtenissen gelijk is aan nul, is een van de volgende instructies waar:
      • De queryverwerking heeft geresulteerd in nul uitvoer gebeurtenissen.
      • Gebeurtenissen of velden zijn mogelijk ongeldig, wat resulteert in een nuluitvoer na de verwerking van de query.
      • De taak kan om connectiviteits- of verificatieredenen geen gegevens naar de uitvoersink pushen.

    In logboekberichten van bewerkingen worden aanvullende details uitgelegd, inclusief wat er gebeurt, behalve in gevallen waarin de querylogica alle gebeurtenissen filtert. Als bij het verwerken van meerdere gebeurtenissen fouten worden gegenereerd, worden de fouten elke tien minuten samengevoegd.

De eerste uitvoer is vertraagd

Wanneer een Stream Analytics-taak wordt gestart, worden de invoer gebeurtenissen gelezen. Er kan echter een vertraging optreden in de uitvoer, in bepaalde omstandigheden.

Grote tijdwaarden in tijdelijke query-elementen kunnen bijdragen aan de uitvoervertraging. Om over grote tijdvensters de correcte uitvoer te genereren, leest de streamingtaak gegevens vanaf het laatst mogelijke tijdstip om het tijdvenster op te vullen. De gegevens kunnen maximaal zeven dagen voorbij zijn. Er wordt geen uitvoer gegenereerd totdat de openstaande invoergebeurtenissen zijn gelezen. Dit probleem kan optreden wanneer het systeem de streamingtaken bijwerkt. Wanneer er een upgrade plaatsvindt, wordt de taak opnieuw gestart. Dergelijke upgrades vinden over het algemeen elke paar maanden plaats.

Gebruik discretie bij het ontwerpen van uw 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 queryparallellisatietechnieken, zoals het partitioneren van de gegevens. U kunt ook meer streamingeenheden toevoegen om de doorvoer te verbeteren totdat de taak weer bij is. Zie Overwegingen bij het maken van Stream Analytics-taken voor meer informatie.

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

  • Het gebruik van aggregaties over vensters, zoals een GROUP BY-clausule met tumbling-, hopping- en schuivende vensters:

    • Voor aggregaties van tumbling- of hoppingvensters worden de resultaten aan het einde van het tijdsvenster gegenereerd.
    • Voor een schuifvenster worden de resultaten gegenereerd wanneer een gebeurtenis het schuifvenster binnenkomt of verlaat.
    • Als u van plan bent om een groot venster te gebruiken, zoals meer dan één uur, kunt u het beste een hopping- of schuifvenster kiezen. Met deze venstertypen kunt u de uitvoer vaker zien.

  • Het gebruik van tijdelijke joins, zoals JOIN met DATEDIFF:

    • Matches ontstaan zodra beide kanten van de gekoppelde gebeurtenissen zijn binnengekomen.
    • Gegevens die geen overeenkomst hebben, zoals LEFT OUTER JOIN, worden aan het einde van het DATUMEDIFF-venster gegenereerd 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.

Uitvoer valt achter met toenemende latentie

Tijdens de normale werking van een taak kan de uitvoer langere en langere latentieperioden hebben. Als de output op die manier achterblijft, kunt u de onderliggende oorzaken achterhalen door de volgende factoren te bekijken:

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

Als u de uitvoergegevens wilt bekijken, selecteert u de streamingtaak in Azure Portal en selecteert u vervolgens Taakdiagram. Voor elke invoer is er een metrische waarde voor backlog-gebeurtenissen per partitie. Als de metrische waarde blijft toenemen, is het een indicator dat de systeembronnen worden beperkt. De toename wordt mogelijk veroorzaakt door throttling van de outputsink of hoog CPU-gebruik. Zie Gegevensgestuurde foutopsporing met behulp van het taakdiagram voor meer informatie.

Waarschuwing over schending van de sleutel met Azure SQL Database-uitvoer

Wanneer u een Azure SQL-database configureert als uitvoer voor een Stream Analytics-taak, worden records bulksgewijs in de doeltabel ingevoegd. Over het algemeen garandeert Azure Stream Analytics ten minste eenmaal levering aan de uitvoersink. U kunt nog steeds exact-once-levering realiseren naar een SQL-uitvoer wanneer voor een SQL-tabel een unieke constraint is gedefinieerd.

Wanneer u unieke sleutelbeperkingen voor de SQL-tabel instelt, verwijdert Azure Stream Analytics dubbele records. Hiermee worden de gegevens gesplitst in batches en worden de batches recursief ingevoegd totdat één dubbele record wordt gevonden. Het splits- en invoegproces negeert de duplicaten één voor één. Voor een streamingtaak met veel dubbele rijen is het proces inefficiënt en tijdrovend. Als u waarschuwingsberichten over meerdere belangrijke schendingen in uw activiteitenlogboek ziet voor het afgelopen uur, is het waarschijnlijk dat uw SQL-uitvoer de hele taak vertraagt.

U kunt dit probleem oplossen door de index te configureren die de sleutelschending veroorzaakt door de optie IGNORE_DUP_KEY in te schakelen. Met deze optie kan SQL dubbele waarden negeren tijdens bulksgewijs invoegen. Azure SQL Database produceert gewoon een waarschuwingsbericht in plaats van een fout. Als gevolg hiervan geeft Azure Stream Analytics geen fouten meer vanwege schending van de primaire sleutel.

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

  • U kunt IGNORE_DUP_KEY niet instellen op een primaire sleutel of een unieke beperking die GEBRUIKMAAKT van ALTER INDEX. U moet de index verwijderen en opnieuw maken.
  • U kunt IGNORE_DUP_KEY instellen met ALTER INDEX voor een unieke index. Dit exemplaar verschilt van de beperking PRIMARY KEY/UNIQUE en wordt gemaakt met behulp van een CREATE INDEX- of INDEX-definitie.
  • De optie IGNORE_DUP_KEY is niet van toepassing op kolomopslagindexen omdat u er geen uniekheid op kunt afdwingen.

logica voor nieuwe pogingen voor uitvoer van Azure SQL Database

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

  1. De taak probeert verbinding te maken met SQL.
  2. De taak haalt het schema van de doeltabel op.
  3. De taak valideert kolomnamen en -typen op basis van het doeltabelschema.
  4. De taak maakt een datatabel in het geheugen aan op basis van de uitvoerrecords in de batch.
  5. De taak schrijft de gegevenstabel naar SQL met behulp van bulkcopy-API.

Tijdens deze stappen kan de SQL-uitvoer de volgende typen fouten ondervinden:

  • Tijdelijke fouten waarvoor een retrystrategie met exponentieel toenemende wachttijd wordt gebruikt. Het minimale interval voor opnieuw proberen is afhankelijk van de afzonderlijke foutcode, maar de intervallen zijn doorgaans minder dan 60 seconden. De bovengrens kan maximaal vijf minuten duren.

    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-fouten en schendingen van schemabeperkingen, worden verwerkt met uitvoerfoutbeleid. Deze fouten worden afgehandeld door batches steeds opnieuw binair te splitsen totdat de individuele record die de fout veroorzaakt, wordt afgehandeld door deze over te slaan of opnieuw te proberen. Schending van primaire unieke sleutelbeperkingen wordt altijd afgehandeld.

  • Niet-tijdelijke fouten kunnen optreden wanneer er problemen zijn met de SQL-service of interne codefouten. Wanneer bijvoorbeeld fouten optreden, zoals dat een Elastic Pool de opslaglimiet heeft bereikt (code 1132), kunnen nieuwe pogingen de fout niet verhelpen. In deze scenario's ondervindt de Stream Analytics-taak degradatie.

  • BulkCopy timeouts kunnen optreden tijdens BulkCopy in stap 5. BulkCopy kan af en toe time-outs tijdens bewerkingen ondervinden. De standaard minimaal geconfigureerde time-out is vijf minuten en wordt verdubbeld wanneer deze opeenvolgend wordt bereikt. Zodra de time-out hoger is dan 15 minuten, wordt de hint BulkCopy voor maximale batchgrootte beperkt tot de helft totdat er 100 gebeurtenissen per batch overblijven.

    Belangrijk

    Voor niet-netwerkinjectieve ASA-taken vertrouwt u niet op het bron-IP-adres van verbindingen die afkomstig zijn van ASA. Ze kunnen openbare of privé-IP-adressen zijn, afhankelijk van bewerkingen van de service-infrastructuur die van tijd tot tijd plaatsvinden.

Kolomnamen zijn kleine letters in Azure Stream Analytics (1.0)

Wanneer u het oorspronkelijke compatibiliteitsniveau (1.0) gebruikt, worden kolomnamen in kleine letters gewijzigd in Azure Stream Analytics. Dit gedrag is opgelost in latere compatibiliteitsniveaus. Als u het geval 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-vragenpagina voor Azure Stream Analytics voor meer hulp.

Volgende stappen

  • Last updated on