Een taak automatisch onderbreken met PowerShell en Azure Functions of Azure Automation

Voor sommige toepassingen is een benadering voor het verwerken van stromen vereist, eenvoudig gemaakt met Azure Stream Analytics (ASA), maar hoeft u niet continu te worden uitgevoerd. De redenen zijn verschillende:

  • Invoergegevens die volgens een schema binnenkomen (top van het uur...)
  • Een sparse of een laag volume aan binnenkomende gegevens (weinig records per minuut)
  • Bedrijfsprocessen die profiteren van time-windowing-mogelijkheden, maar worden uitgevoerd in batch by essence (Financiën of HR...)
  • Demonstraties, prototypen of tests waarbij langdurige taken op lage schaal worden uitgevoerd

Het voordeel van het niet continu uitvoeren van deze taken is kostenbesparingen, omdat Stream Analytics-taken na verloop van tijd per streaming-eenheid worden gefactureerd.

In dit artikel wordt uitgelegd hoe u automatisch onderbreken instelt voor een Azure Stream Analytics-taak. Hierin configureren we een taak die automatisch een taak onderbreekt en hervat volgens een planning. Als we de term onderbreken gebruiken, wordt de werkelijke taakstatusgestopt om facturering te voorkomen.

We bespreken eerst het algehele ontwerp, doorlopen vervolgens de vereiste onderdelen en bespreken ten slotte enkele implementatiedetails.

Notitie

Er zijn nadelen voor het automatisch onderbreken van een taak. De belangrijkste zijn het verlies van de lage latentie/realtime-mogelijkheden en de potentiële risico's van het toestaan van de achterstand van invoergebeurtenissen om niet-supervisie te groeien terwijl een taak wordt onderbroken. Automatisch onderbreken moet niet worden overwogen voor de meeste productiescenario's die op schaal worden uitgevoerd

Ontwerp

In dit voorbeeld willen we dat onze taak N minuten wordt uitgevoerd voordat deze gedurende M-minuten wordt onderbroken. Wanneer de taak is onderbroken, worden de invoergegevens niet verbruikt, waarbij upstream wordt opgestapeld. Nadat de taak is gestart, wordt deze ingehaald met die achterstand, de gegevens worden verwerkt, voordat de taak opnieuw wordt afgesloten.

Diagram that illustrates the behavior of the auto-paused job over time

Wanneer de taak wordt uitgevoerd, moet de taak pas worden gestopt als de metrische gegevens in orde zijn. De metrische gegevens van belang zijn de ingevoerde achterstand en het watermerk. We controleren of beide ten minste N minuten in hun basislijn staan. Dit gedrag vertaalt zich in twee acties:

  • Een gestopte taak wordt na M-minuten opnieuw gestart
  • Een actieve taak wordt na N minuten gestopt, zodra de metrische gegevens over achterstand en watermerk in orde zijn

Diagram that shows the possible states of the job

Laten we bijvoorbeeld N = 5 minuten en M = 10 minuten overwegen. Met deze instellingen heeft een taak ten minste 5 minuten om alle gegevens te verwerken die in 15 zijn ontvangen. Potentiële kostenbesparingen zijn maximaal 66%.

Als u de taak opnieuw wilt starten, gebruiken we de When Last Stoppedstartoptie. Met deze optie moet ASA alle gebeurtenissen verwerken die backstream zijn geregistreerd sinds de taak is gestopt. Er zijn twee opmerkingen in deze situatie. Ten eerste kan de taak niet langer worden gestopt dan de bewaarperiode van de invoerstroom. Als we de taak slechts één keer per dag uitvoeren, moeten we ervoor zorgen dat de bewaarperiode van de Event Hub meer dan één dag is. Ten tweede moet de taak minstens één keer zijn gestart om de modus When Last Stopped te accepteren (anders is deze letterlijk nooit eerder gestopt). De eerste uitvoering van een taak moet dus handmatig zijn, of we moeten het script uitbreiden om dit geval te behandelen.

De laatste overweging is om deze acties idempotent te maken. Op deze manier kunnen ze worden herhaald zonder bijwerkingen, voor zowel gebruiksgemak als tolerantie.

Onderdelen

API-aanroepen

We verwachten dat er op de volgende aspecten moet worden gecommuniceerd met ASA:

  • De huidige taakstatus ophalen (ASA Resource Management)
    • Als deze wordt uitgevoerd
      • De tijd sinds de start ophalen (logboeken)
      • De huidige metrische waarden ophalen (metrische gegevens)
      • Stop indien van toepassing de taak (ASA Resource Management)
    • Als deze is gestopt
      • De tijd ophalen sinds gestopt (logboeken)
      • Start de taak (ASA Resource Management) indien van toepassing

Voor ASA Resource Management kunnen we de REST API, de .NET SDK of een van de CLI-bibliotheken (Az CLI, PowerShell) gebruiken.

Voor metrische gegevens en logboeken wordt in Azure alles gecentraliseerd onder Azure Monitor, met een vergelijkbare keuze aan API-oppervlakken. We moeten onthouden dat logboeken en metrische gegevens altijd 1 tot 3 minuten achterblijven bij het uitvoeren van query's op de API's. Als u N instelt op 5, betekent dit meestal dat de taak in werkelijkheid 6 tot 8 minuten wordt uitgevoerd. Een ander ding om rekening mee te houden is dat metrische gegevens altijd worden verzonden. Wanneer de taak is gestopt, retourneert de API lege records. We moeten de uitvoer van onze API-aanroepen opschonen om alleen naar relevante waarden te kijken.

Scripttaal

Voor dit artikel hebben we besloten om automatisch onderbreken in PowerShell te implementeren. De eerste reden is dat PowerShell nu platformoverschrijdend is. Het kan worden uitgevoerd op elk besturingssysteem, waardoor implementaties eenvoudiger worden. De tweede reden is dat objecten worden gebruikt en geretourneerd in plaats van tekenreeksen. Met objecten kunt u eenvoudig parseren en verwerken voor automatiseringstaken.

In PowerShell gebruiken we de Az PowerShell-module , die Az.Monitor en Az.StreamAnalytics begint, voor alles wat we nodig hebben:

Hostingservice

Voor het hosten van onze PowerShell-taak hebben we een service nodig die geplande uitvoeringen biedt. Er zijn veel opties, maar er zijn serverloze opties:

  • Azure Functions, een serverloze berekeningsengine die vrijwel elk stukje code kan uitvoeren. Functions bieden een timertrigger die tot elke seconde kan worden uitgevoerd
  • Azure Automation, een beheerde service die is gebouwd voor het uitvoeren van cloudworkloads en -resources. Dit past bij de factuur, maar waarvan het minimale planningsinterval 1 uur is (minder met tijdelijke oplossingen).

Als we de tijdelijke oplossing niet erg vinden, is Azure Automation de eenvoudigere manier om de taak te implementeren. Maar om te kunnen vergelijken, schrijven we eerst een lokaal script. Zodra we een functionerend script hebben, implementeren we het script zowel in Functions als in een Automation-account.

Hulpprogramma's voor ontwikkelaars

We raden lokale ontwikkeling ten zeerste aan met BEHULP van VSCode, zowel voor Functions als ASA. Met behulp van een lokale IDE kunnen we broncodebeheer gebruiken en eenvoudig implementaties herhalen. Maar omwille van de beknoptheid illustreren we hier het proces in de Azure Portal.

Het PowerShell-script lokaal schrijven

De beste manier om het script te ontwikkelen, is lokaal. PowerShell is platformoverschrijdend, het script kan worden geschreven en getest op elk besturingssysteem. Op Windows kunnen we Windows Terminal gebruiken met PowerShell 7 en Az PowerShell.

Het laatste script dat wordt gebruikt, is beschikbaar voor Functions (en Azure Automation). Het is anders dan hieronder uitgelegd, omdat deze is bekabeld naar de hostingomgeving (Functions of Automation). We bespreken dat aspect later. Laten we eerst een versie doorlopen die alleen lokaal wordt uitgevoerd.

Dit script is opzettelijk geschreven in een eenvoudige vorm, zodat het door iedereen kan worden begrepen.

Bovenaan stellen we de vereiste parameters in en controleren we de initiële taakstatus:


# Setting variables
$restartThresholdMinute = 10 # This is M
$stopThresholdMinute = 5 # This is N

$maxInputBacklog = 0 # The amount of backlog we tolerate when stopping the job (in event count, 0 is a good starting point)
$maxWatermark = 10 # The amount of watermark we tolerate when stopping the job (in seconds, 10 is a good starting point at low SUs)

$subscriptionId = "<Replace with your Subscription Id - not the name>"
$resourceGroupName = "<Replace with your Resource Group Name>"
$asaJobName = "<Replace with your ASA job name>"

$resourceId = "/subscriptions/$($subscriptionId )/resourceGroups/$($resourceGroupName )/providers/Microsoft.StreamAnalytics/streamingjobs/$($asaJobName)"

# If not already logged, uncomment and run the 2 following commands
# Connect-AzAccount
# Set-AzContext -SubscriptionId $subscriptionId

# Check current ASA job status
$currentJobState = Get-AzStreamAnalyticsJob  -ResourceGroupName $resourceGroupName -Name $asaJobName | Foreach-Object {$_.JobState}
Write-Output "asaRobotPause - Job $($asaJobName) is $($currentJobState)."

Als de taak wordt uitgevoerd, controleren we of de taak ten minste N minuten, de achterstand en het watermerk is uitgevoerd.


# Switch state
if ($currentJobState -eq "Running")
{
    # First we look up the job start time with Get-AzActivityLog
    ## Get-AzActivityLog issues warnings about deprecation coming in future releases, here we ignore them via -WarningAction Ignore
    ## We check in 1000 record of history, to make sure we're not missing what we're looking for. It may need adjustment for a job that has a lot of logging happening.
    ## There is a bug in Get-AzActivityLog that triggers an error when Select-Object First is in the same pipeline (on the same line). We move it down.
    $startTimeStamp = Get-AzActivityLog -ResourceId $resourceId -MaxRecord 1000 -WarningAction Ignore | Where-Object {$_.EventName.Value -like "Start Job*"}
    $startTimeStamp = $startTimeStamp | Select-Object -First 1 | Foreach-Object {$_.EventTimeStamp}

    # Then we gather the current metric values
    ## Get-AzMetric issues warnings about deprecation coming in future releases, here we ignore them via -WarningAction Ignore
    $currentBacklog = Get-AzMetric -ResourceId $resourceId -TimeGrain 00:01:00 -MetricName "InputEventsSourcesBacklogged" -DetailedOutput -WarningAction Ignore
    $currentWatermark = Get-AzMetric -ResourceId $resourceId -TimeGrain 00:01:00 -MetricName "OutputWatermarkDelaySeconds" -DetailedOutput -WarningAction Ignore

    # Metric are always lagging 1-3 minutes behind, so grabbing the last N minutes means checking N+3 actually. This may be overly safe and fined tune down per job.
    $Backlog =  $currentBacklog.Data |
                    Where-Object {$_.Maximum -ge 0} | # We remove the empty records (when the job is stopped or starting)
                    Sort-Object -Property Timestamp -Descending |
                    Where-Object {$_.Timestamp -ge $startTimeStamp} | # We only keep the records of the latest run
                    Select-Object -First $stopThresholdMinute | # We take the last N records
                    Measure-Object -Sum Maximum # We sum over those N records
    $BacklogSum = $Backlog.Sum

    $Watermark = $currentWatermark.Data |
                    Where-Object {$_.Maximum -ge 0} |
                    Sort-Object -Property Timestamp -Descending |
                    Where-Object {$_.Timestamp -ge $startTimeStamp} |
                    Select-Object -First $stopThresholdMinute |
                    Measure-Object -Average Maximum # Here we average
    $WatermarkAvg = [int]$Watermark.Average # Rounding the decimal value casting it to integer

    # Since we called Get-AzMetric with a TimeGrain of a minute, counting the number of records gives us the duration in minutes
    Write-Output "asaRobotPause - Job $($asaJobName) is running since $($startTimeStamp) with a sum of $($BacklogSum) backlogged events, and an average watermark of $($WatermarkAvg) sec, for $($Watermark.Count) minutes."

    # -le for lesser or equal, -ge for greater or equal
    if (
        ($BacklogSum -ge 0) -and ($BacklogSum -le $maxInputBacklog) -and ` # is not null and is under the threshold
        ($WatermarkAvg -ge 0) -and ($WatermarkAvg -le $maxWatermark) -and ` # is not null and is under the threshold
        ($Watermark.Count -ge $stopThresholdMinute) # at least N values
        )
    {
        Write-Output "asaRobotPause - Job $($asaJobName) is stopping..."
        Stop-AzStreamAnalyticsJob -ResourceGroupName $resourceGroupName -Name $asaJobName
    }
    else {
        Write-Output "asaRobotPause - Job $($asaJobName) is not stopping yet, it needs to have less than $($maxInputBacklog) backlogged events and under $($maxWatermark) sec watermark for at least $($stopThresholdMinute) minutes."
    }
}

Als de taak is gestopt, kijken we in het logboek wanneer dit de laatste actie Taak stoppen was:


elseif ($currentJobState -eq "Stopped")
{
    # First we look up the job start time with Get-AzActivityLog
    ## Get-AzActivityLog issues warnings about deprecation coming in future releases, here we ignore them via -WarningAction Ignore
    ## We check in 1000 record of history, to make sure we're not missing what we're looking for. It may need adjustment for a job that has a lot of logging happening.
    ## There is a bug in Get-AzActivityLog that triggers an error when Select-Object First is in the same pipeline (on the same line). We move it down.
    $stopTimeStamp = Get-AzActivityLog -ResourceId $resourceId -MaxRecord 1000 -WarningAction Ignore | Where-Object {$_.EventName.Value -like "Stop Job*"}
    $stopTimeStamp = $stopTimeStamp | Select-Object -First 1 | Foreach-Object {$_.EventTimeStamp}

    # Get-Date returns a local time, we project it to the same time zone (universal) as the result of Get-AzActivityLog that we extracted above
    $minutesSinceStopped = ((Get-Date).ToUniversalTime()- $stopTimeStamp).TotalMinutes

    # -ge for greater or equal
    if ($minutesSinceStopped -ge $restartThresholdMinute)
    {
        Write-Output "asaRobotPause - Job $($jobName) was paused $([int]$minutesSinceStopped) minutes ago, set interval is $($restartThresholdMinute), it is now starting..."
        Start-AzStreamAnalyticsJob -ResourceGroupName $resourceGroupName -Name $asaJobName -OutputStartMode LastOutputEventTime
    }
    else{
        Write-Output "asaRobotPause - Job $($jobName) was paused $([int]$minutesSinceStopped) minutes ago, set interval is $($restartThresholdMinute), it will not be restarted yet."
    }
}
else {
    Write-Output "asaRobotPause - Job $($jobName) is not in a state I can manage: $($currentJobState). Let's wait a bit, but consider helping is that doesn't go away!"
}

Aan het einde registreren we de voltooiing van de taak:


# Final ASA job status check
$newJobState = Get-AzStreamAnalyticsJob  -ResourceGroupName $resourceGroupName -Name $asaJobName | Foreach-Object {$_.JobState}
Write-Output "asaRobotPause - Job $($asaJobName) was $($currentJobState), is now $($newJobState). Job completed."

Optie 1: de taak hosten in Azure Functions

Ter referentie onderhoudt het Azure Functions team een uitgebreide PowerShell-ontwikkelaarshandleiding.

Eerst hebben we een nieuwe functie-app nodig. Een functie-app is vergelijkbaar met een oplossing die meerdere functies kan hosten.

De volledige procedure is hier, maar de kern is om naar de Azure Portal te gaan en een nieuwe functie-app te maken met:

  • Publiceren: Code
  • Runtime: PowerShell Core
  • Versie: 7+

Zodra deze is ingericht, beginnen we met de algehele configuratie.

Beheerde identiteit voor Azure Functions

De functie heeft machtigingen nodig om de ASA-taak te starten en te stoppen. We wijzen deze machtigingen toe via een beheerde identiteit.

De eerste stap is het inschakelen van een door het systeem toegewezen beheerde identiteit voor de functie, volgens die procedure.

Nu kunnen we de juiste machtigingen verlenen aan die identiteit voor de ASA-taak die we automatisch willen onderbreken. Hiervoor voegt u in de portal voor de ASA-taak (niet de functie) in Toegangsbeheer (IAM) een roltoewijzing toe aan de rolbijdrager voor een lid van het type Beheerde identiteit, waarbij u de naam van de bovenstaande functie selecteert.

Screenshot of IAM settings for the ASA job

In het PowerShell-script kunnen we een controle toevoegen die ervoor zorgt dat de beheerde identiteit correct is ingesteld (het uiteindelijke script is hier beschikbaar)


# Check if managed identity has been enabled and granted access to a subscription, resource group, or resource
$AzContext = Get-AzContext -ErrorAction SilentlyContinue
if (-not $AzContext.Subscription.Id)
{
    Throw ("Managed identity is not enabled for this app or it has not been granted access to any Azure resources. Please see /azure/app-service/overview-managed-identity for additional details.")
}

We voegen ook enkele logboekgegevens toe om ervoor te zorgen dat de functie wordt geactiveerd:


$currentUTCtime = (Get-Date).ToUniversalTime()

# Write an information log with the current time.
Write-Host "asaRobotPause - PowerShell timer trigger function is starting at time: $currentUTCtime"

Parameters voor Azure Functions

De beste manier om onze parameters door te geven aan het script in Functions is door de toepassingsinstellingen van de functie-app te gebruiken als omgevingsvariabelen.

Hiervoor bevindt de eerste stap zich op de pagina Functie-app om onze parameters te definiëren als App-Instellingen na die procedure. We hebben het volgende nodig:

Name Waarde
maxInputBacklog De hoeveelheid achterstand die we tolereren bij het stoppen van de taak (in het geval aantal is 0 een goed uitgangspunt)
maxWatermark De hoeveelheid watermerk die we tolereren bij het stoppen van de taak (in seconden is 10 een goed startpunt bij lage RU's)
restartThresholdMinute M: de tijd (in minuten) totdat een gestopte taak opnieuw wordt gestart
stopThresholdMinute N: de tijd (in minuten) van afkoelen totdat een actieve taak is gestopt. De achterstand van de invoer moet gedurende die tijd 0 blijven
subscriptionId De SubscriptionId (niet de naam) van de ASA-taak die automatisch moet worden onderbroken
resourceGroupName De naam van de resourcegroep van de ASA-taak die automatisch moet worden onderbroken
asaJobName De naam van de ASA-taak die moet worden onderbroken

We moeten later het PowerShell-script bijwerken om de variabelen dienovereenkomstig te laden:

$maxInputBacklog = $env:maxInputBacklog
$maxWatermark = $env:maxWatermark

$restartThresholdMinute = $env:restartThresholdMinute
$stopThresholdMinute = $env:stopThresholdMinute

$subscriptionId = $env:subscriptionId
$resourceGroupName = $env:resourceGroupName
$asaJobName = $env:asaJobName

Vereisten voor PowerShell-modules

Op dezelfde manier moesten we Az PowerShell lokaal installeren om de ASA-opdrachten te gebruiken (zoals Start-AzStreamAnalyticsJob), moeten we deze toevoegen aan de functie-app-host.

Hiervoor kunnen we naar Functions>App files de pagina Functie-app gaan, de regel 'Az' = '6.*'selecteren requirements.psd1en opmerkingen opheffen. Om deze wijziging van kracht te laten worden, moet de hele app opnieuw worden opgestart.

Screenshot of the app files settings for the Function App

De functie maken

Zodra alle configuratie is voltooid, kunnen we de specifieke functie maken, in de functie-app, waarmee ons script wordt uitgevoerd.

We ontwikkelen in de portal, een functie die is geactiveerd op een timer (elke minuut met0 */1 * * * *, die 'op seconde 0 van elke 1 minuut' leest):

Screenshot of creating a new timer trigger function in the function app

Indien nodig kunnen we de timerwaarde wijzigen door Integrationhet schema bij te werken:

Screenshot of the integration settings of the function

Code + TestVervolgens kunnen we ons script run.ps1 kopiëren en testen. Het volledige script kan hier worden gekopieerd, de bedrijfslogica is verplaatst naar een TRY/CATCH-instructie om de juiste fouten te genereren als er iets mislukt tijdens de verwerking.

Screenshot of Code+Test for the function

We kunnen controleren of alles prima werkt via Testen/Uitvoeren in het Code + Test deelvenster. We kunnen ook naar het Monitor deelvenster kijken, maar het is altijd laat van een aantal uitvoeringen.

Screenshot of the output of a successful run

Een waarschuwing instellen voor de uitvoering van de functie

Ten slotte willen we een melding ontvangen via een waarschuwing als de functie niet succesvol wordt uitgevoerd. Waarschuwingen hebben een kleine kosten, maar kunnen duurdere situaties voorkomen.

Voer op de pagina Functie-app , onder Logs, de volgende query uit die alle niet-geslaagde uitvoeringen in de afgelopen 5 minuten retourneert:

requests
| where success == false
| where timestamp > ago(5min)
| summarize failedCount=sum(itemCount) by operation_Name
| order by failedCount desc

Kies New alert rulein de queryeditor . Definieer in het volgende scherm de meting als:

  • Meting: failedCount
  • Aggregatietype: Totaal
  • Aggregatiegranulariteit: 5 minuten

Stel vervolgens de waarschuwingslogica als volgt in:

  • Operator: Groter dan
  • Drempelwaarde: 0
  • Frequentie van evaluatie: 5 minuten

Hier kunt u een nieuwe actiegroep opnieuw gebruiken of maken en vervolgens de configuratie voltooien.

Om te controleren of de waarschuwing correct is ingesteld, kunnen we overal in het PowerShell-script toevoegen throw "Testing the alert" en 5 minuten wachten om een e-mail te ontvangen.

Optie 2: de taak hosten in Azure Automation

Eerst hebben we een nieuw Automation-account nodig. Een Automation-account is vergelijkbaar met een oplossing die meerdere runbooks kan hosten.

De procedure is hier. Hier kunnen we ervoor kiezen om rechtstreeks op het tabblad een door het advanced systeem toegewezen beheerde identiteit te gebruiken.

Ter referentie heeft het Automation-team een goede zelfstudie om aan de slag te gaan met PowerShell-runbooks.

Parameters voor Azure Automation

Met een runbook kunnen we de klassieke parametersyntaxis van PowerShell gebruiken om argumenten door te geven:

Param(
    [string]$subscriptionId,
    [string]$resourceGroupName,
    [string]$asaJobName,

    [int]$restartThresholdMinute,
    [int]$stopThresholdMinute,

    [int]$maxInputBacklog,
    [int]$maxWatermark
)

Beheerde identiteit voor Azure Automation

Het Automation-account moet een beheerde identiteit hebben ontvangen tijdens het inrichten. Maar indien nodig kunnen we er een inschakelen met behulp van die procedure.

Net als voor de functie moeten we de juiste machtigingen verlenen voor de ASA-taak die we automatisch willen onderbreken.

Hiervoor voegt u in de portal voor de ASA-taak (niet op de pagina Automation) in Toegangsbeheer (IAM) een roltoewijzing toe aan de rolbijdrager voor een lid van het type Beheerde identiteit, waarbij u de naam van het Bovenstaande Automation-account selecteert.

Screenshot of IAM settings for the ASA job

In het PowerShell-script kunnen we een controle toevoegen die ervoor zorgt dat de beheerde identiteit correct is ingesteld (het uiteindelijke script is hier beschikbaar)

# Ensures you do not inherit an AzContext in your runbook
Disable-AzContextAutosave -Scope Process | Out-Null

# Connect using a Managed Service Identity
try {
        $AzureContext = (Connect-AzAccount -Identity).context
    }
catch{
        Write-Output "There is no system-assigned user identity. Aborting.";
        exit
    }

Het runbook maken

Zodra de configuratie is voltooid, kunnen we het specifieke runbook maken, in het Automation-account, waarmee ons script wordt uitgevoerd. Hier hoeven we Az PowerShell niet als vereiste toe te voegen. Deze is al ingebouwd.

Selecteer in de portal, onder Procesautomatisering, selecteer Runbooksen selecteer Create a runbookPowerShell vervolgens als runbooktype en eventuele bovenstaande 7 versie als de versie (op dit moment7.1 (preview)).

We kunnen ons script nu plakken en testen. Het volledige script kan hier worden gekopieerd, de bedrijfslogica is verplaatst naar een TRY/CATCH-instructie om de juiste fouten te genereren als er iets mislukt tijdens de verwerking.

Screenshot of the runbook script editor in Azure Automation

We kunnen controleren of alles goed is bekabeld in de Test Pane.

Daarna moeten Publish we de taak uitvoeren, zodat we het runbook kunnen koppelen aan een planning. Het maken en koppelen van de planning is een eenvoudig proces dat hier niet wordt besproken. Het is nu een goed moment om te onthouden dat er tijdelijke oplossingen zijn om planningsintervallen van minder dan 1 uur te bereiken.

Ten slotte kunnen we een waarschuwing instellen. De eerste stap is het inschakelen van logboeken via de diagnostische instellingen van het Automation-account. De tweede stap is het vastleggen van fouten via een query zoals voor Functions.

Resultaat

Als u onze ASA-taak bekijkt, kunnen we zien dat alles op twee plaatsen wordt uitgevoerd zoals verwacht.

In het activiteitenlogboek:

Screenshot of the logs of the ASA job

En via de metrische gegevens:

Screenshot of the metrics of the ASA job

Zodra het script is begrepen, is het eenvoudig om het te herwerken om het bereik ervan uit te breiden. Het kan eenvoudig worden bijgewerkt om een lijst met taken te richten in plaats van één. Grotere bereiken kunnen worden gedefinieerd en verwerkt via tags, resourcegroepen of zelfs hele abonnementen.

Ondersteuning krijgen

Probeer onze Microsoft Q&A-vragenpagina voor Azure Stream Analytics voor meer hulp.

Volgende stappen

U hebt de basisbeginselen van het gebruik van PowerShell geleerd om het beheer van Azure Stream Analytics-taken te automatiseren. Lees de volgende artikelen voor meer informatie: