Automatisches Anhalten eines Auftrags mithilfe von PowerShell und Azure Functions oder Azure Automation

Einige Anwendungen erfordern einen Ansatz für die Datenstromverarbeitung (wie durch Azure Stream Analytics), müssen aber nicht unbedingt kontinuierlich ausgeführt werden. Zu den Gründen gehören die folgenden:

Eingabedaten, die nach einem Zeitplan eintreffen (z. B. zu Beginn jeder Stunde)
Weniger oder geringe Menge an eingehenden Daten (wenige Datensätze pro Minute)
Geschäftsprozesse, die von Zeitfensterfunktionen profitieren, aber im Wesentlichen im Batch ausgeführt werden (z. B. Finanzen oder Personalwesen)
Demonstrationen, Prototypen oder Tests, die zeitintensive Aufträge in geringem Umfang umfassen

Der Vorteil davon, dass diese Aufträge nicht kontinuierlich ausgeführt werden, sind Kosteneinsparungen, da Stream Analytics-Aufträge im Laufe der Zeit pro Streamingeinheit abgerechnet werden.

In diesem Artikel wird erläutert, wie Sie das automatische Anhalten für einen Azure Stream Analytics-Auftrag einrichten. Sie konfigurieren eine Aufgabe, die automatisch nach einem Zeitplan anhält und wieder fortsetzt. Anhalten bedeutet, dass der Status des Auftrags Angehalten ist, um eine Abrechnung zu vermeiden.

In diesem Artikel werden das allgemeine Design, die erforderlichen Komponenten und einige Details bei der Implementierung erläutert.

Hinweis

Es gibt Nachteile beim automatischen Anhalten eines Auftrags. Zu den wichtigsten Nachteilen zählen der Verlust der Funktionen für niedrige Latenz/Echtzeit und die potenziellen Risiken, die sich daraus ergeben, dass der Backlog des Eingabeereignisses unbeaufsichtigt wächst, während ein Auftrag angehalten wird. Organisationen sollten das automatische Anhalten für die meisten Produktionsszenarien, die im großen Stil ausgeführt werden, nicht in Betracht ziehen.

Design

Im Beispiel in diesem Artikel soll Ihr Auftrag N Minuten lang ausgeführt werden, bevor er für M Minuten angehalten wird. Wenn der Auftrag angehalten wird, werden die Eingabedaten nicht genutzt und Upstream akkumuliert. Nachdem der Auftrag gestartet wurde, wird er mit diesem Backlog aufholen und die eingehenden Daten verarbeiten, bevor er erneut heruntergefahren wird.

Diagramm, das das Verhalten eines automatisch angehaltenen Auftrags im Laufe der Zeit veranschaulicht

Die Aufgabe sollten den ausgeführten Auftrag erst anhalten, wenn seine Metriken fehlerfrei sind. Die wichtigsten Metriken sind der Eingabebacklog und das Wasserzeichen. Sie werden überprüfen, ob beide mindestens N Minuten lang an der Baseline sind. Dieses Verhalten führt zu zwei Aktionen:

Ein angehaltener Auftrag wird nach M Minuten neu gestartet.
Ein ausgeführter Auftrag wird jederzeit nach N Minuten angehalten, sobald der Backlog und die Wasserzeichenmetriken fehlerfrei sind.

Diagramm, das die möglichen Status eines Auftrags zeigt

Gehen wir beispielsweise davon aus, dass N = 5 Minuten und M = 10 Minuten ist. Mit diesen Einstellungen hat ein Auftrag mindestens 5 Minuten Zeit, alle in 15 Minuten empfangenen Daten zu verarbeiten. Die potenziellen Kosteneinsparungen liegen bei bis zu 66 %.

Um den Auftrag neu zu starten, verwenden Sie die StartoptionZeitpunkt der letzten Beendigung. Diese Option weist Stream Analytics an, alle Ereignisse zu verarbeiten, die seit dem Ende des Auftrags im Upstream protokolliert wurden.

In dieser Situation gibt es zwei Einschränkungen. Erstens kann der Auftrag nicht länger als die Beibehaltungsdauer des Eingabestreams angehalten werden. Wenn Sie Auftrag nur einmal täglich ausführen, müssen Sie sicherstellen, dass die Aufbewahrungsdauer für Ereignisse länger als einen Tag ist. Zweitens muss der Auftrag mindestens einmal gestartet worden sein, damit der Modus Zeitpunkt der letzten Beendigung akzeptiert wird (da er sonst noch zuvor nie beendet wurde). Die erste Ausführung eines Auftrags muss also manuell erfolgen. Andernfalls müssen Sie das Skript so erweitern, dass dieser Fall abgedeckt ist.

Der letzte Aspekt besteht darin, diese Aktionen idempotent zu machen. Sie können sie dann beliebig ohne Nebeneffekte wiederholen, was sowohl Benutzerfreundlichkeit als auch Resilienz sicherstellt.

Komponenten

API-Aufrufe

In diesem Artikel wird davon ausgegangen, dass im Bezug auf folgende Aspekte mit Stream Analytics interagiert werden muss:

Abrufen des aktuellen Auftragsstatus (Stream Analytics-Ressourcenverwaltung):
- Wenn der Auftrag ausgeführt wird:
  - Abrufen der Zeit seit dem Start des Auftrags (Protokolle)
  - Abrufen der aktuellen Metrikwerte (Metriken)
  - Anhalten des Auftrags (falls zutreffen) (Stream Analytics-Ressourcenverwaltung)
- Wenn der Auftrag angehalten wird:
  - Abrufen der Zeit seit dem Anhalten des Auftrags (Protokolle)
  - Starten des Auftrags (falls zutreffen) (Stream Analytics-Ressourcenverwaltung)

Für die Stream Analytics-Ressourcenverwaltung können Sie entweder die REST-API, das .NET SDK oder eine der CLI-Bibliotheken (Azure CLI oder PowerShell) verwenden.

Für Metriken und Protokolle wird in Azure alles unter Azure Monitor mit einer ähnlichen Auswahl von API-Oberflächen zentralisiert. Protokolle und Metriken liegen beim Abfragen der APIs immer 1 bis 3 Minuten zurück. Wenn Sie also N auf 5 festlegen, bedeutet dies in der Regel, dass der Auftrag tatsächlich 6 bis 8 Minuten ausgeführt wird.

Beachten Sie außerdem, dass Metriken immer ausgegeben werden. Wenn der Auftrag beendet wird, gibt die API leere Datensätze zurück. Sie müssen die Ausgabe Ihrer API-Aufrufe bereinigen, um sich auf relevante Werte konzentrieren zu können.

"Skriptsprache"

In diesem Artikel wird das automatische Anhalten in PowerShell implementiert. Der erste Grund dafür besteht darin, dass PowerShell jetzt plattformübergreifend ist. Es kann auf jedem Betriebssystem ausgeführt werden, wodurch Bereitstellungen vereinfacht werden. Der zweite Grund ist, dass Objekte anstelle von Zeichenfolgen verwendet und zurückgegeben werden. Objekte erleichtern Automatisierungsaufgaben das Parsen und die Verarbeitung.

In PowerShell verwenden Sie für alles, was Sie benötigen, das Az PowerShell-Modul (das Az.Monitor und Az.StreamAnalytics startet):

Get-AzStreamAnalyticsJob für den aktuellen Auftragsstatus
Start-AzStreamAnalyticsJob oder Stop-AzStreamAnalyticsJob
Get-AzMetric mit InputEventsSourcesBacklogged (aus Stream Analytics-Metriken)
Get-AzActivityLog für Ereignisnamen, die mit Stop Job beginnen

Hostingdienst

Zum Hosten unserer PowerShell-Aufgabe benötigen Sie einen Dienst, der geplante Ausführungen anbietet. Es gibt viele Möglichkeiten, aber hier sind zwei serverlose Optionen:

Azure Functions, eine Compute-Engine, die fast jeden Code ausführen kann. Es bietet einen Zeitgebertrigger, der bis zu jeder Sekunde ausgeführt werden kann.
Azure Automation, ein verwalteter Dienst für den Betrieb von Cloudworkloads und -ressourcen. Er wird dem gewünschten Zweck gerecht, das minimale Zeitplanintervall beträgt jedoch 1 Stunde (weniger mit Problemumgehungen).

Wenn Sie die Problemumgehungen nicht stören, ist Azure Automation die einfachere Möglichkeit, die Aufgabe bereitzustellen. In diesem Artikel schreiben Sie jedoch zuerst ein lokales Skript, damit Sie einen Vergleich vornehmen können. Sobald Sie über ein funktionierendes Skript verfügen, stellen Sie es sowohl in Functions als auch in einem Automation-Konto bereit.

Entwicklertools

Wir empfehlen sowohl für Functions als auch für Stream Analytics dringend die lokale Entwicklung mithilfe von Visual Studio Code. Mithilfe einer lokalen Entwicklungsumgebung können Sie die Quellcodeverwaltung verwenden, was ihnen hilft, Bereitstellungen auf einfache Weise zu wiederholen. Aus Gründen der Kürze veranschaulicht dieser Artikel jedoch den Prozess im Azure-Portal.

Lokales Schreiben des PowerShell-Skripts

Die beste Möglichkeit zum Entwickeln des Skripts ist die lokale Entwicklung. Da PowerShell plattformübergreifend ist, können Sie das Skript auf jedem beliebigen Betriebssystem schreiben und testen. Auf Windows können Sie Windows-Terminal mit PowerShell 7 und Azure PowerShell verwenden.

Das endgültige Skript, das dieser Artikel verwendet, ist für Azure Functions und Azure Automation verfügbar. Es unterscheidet sich von dem folgenden Skript darin, dass es mit der Hostumgebung (Functions oder Automation) verknüpft ist. Dieser Aspekt wird im weiteren Verlauf des Artikels erläutert. Zunächst durchlaufen Sie eine Version des Skripts, die nur lokal ausgeführt wird.

Dieses Skript ist absichtlich einfach gehalten, damit es leicht verständlich ist.

Zu Beginn des Skripts legen Sie die erforderlichen Parameter fest und überprüfen den anfänglichen Auftragsstatus:


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

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

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

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

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

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

Wenn der Auftrag ausgeführt wird, überprüfen Sie als Nächstes, ob der Auftrag mindestens N Minuten ausgeführt wurde. Außerdem überprüfen Sie seinen Backlog und sein Wasserzeichen.


# Switch state
if ($currentJobState -eq "Running")
{
    # First, look up the job start time with Get-AzActivityLog
    ## Get-AzActivityLog issues warnings about deprecation coming in future releases. Here you ignore them via -WarningAction Ignore.
    ## You check in 1,000 records of history, to make sure you're not missing what you're looking for. It might need adjustment for a job that has a lot of logging happening.
    ## There's a bug in Get-AzActivityLog that triggers an error when Select-Object First is in the same pipeline (on the same line). So you 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 gather the current metric values
    ## Get-AzMetric issues warnings about deprecation coming in future releases. Here you 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

    # Metrics are always lagging 1-3 minutes behind, so grabbing the last N minutes actually means checking N+3. This might be overly safe and can be fine-tuned down per job.
    $Backlog =  $currentBacklog.Data |
                    Where-Object {$_.Maximum -ge 0} | # Remove the empty records (when the job is stopped or starting)
                    Sort-Object -Property Timestamp -Descending |
                    Where-Object {$_.Timestamp -ge $startTimeStamp} | # Keep only the records of the latest run
                    Select-Object -First $stopThresholdMinute | # Take the last N records
                    Measure-Object -Sum Maximum # 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 you average
    $WatermarkAvg = [int]$Watermark.Average # Rounding the decimal value and casting it to integer

    # Because you called Get-AzMetric with a TimeGrain of a minute, counting the number of records gives you 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."
    }
}

Wenn der Auftrag angehalten wird, überprüfen Sie das Protokoll, um zu ermitteln, wann die letzte Stop Job-Aktion aufgetreten ist:


elseif ($currentJobState -eq "Stopped")
{
    # First, look up the job start time with Get-AzActivityLog
    ## Get-AzActivityLog issues warnings about deprecation coming in future releases. Here you ignore them via -WarningAction Ignore.
    ## You check in 1,000 records of history, to make sure you're not missing what you're looking for. It might need adjustment for a job that has a lot of logging happening.
    ## There's a bug in Get-AzActivityLog that triggers an error when Select-Object First is in the same pipeline (on the same line). So you 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. You project it to the same time zone (universal) as the result of Get-AzActivityLog that you extracted earlier.
    $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!"
}

Am Ende protokollieren Sie den Abschluss des Auftrags:


# Final Stream Analytics 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."

Option 1: Hosten der Aufgabe in Azure Functions

Zu Referenzzwecken verwaltet das Azure Functions-Team ein umfassendes PowerShell-Entwicklerhandbuch.

Zuerst benötigen Sie eine neue Funktions-App. Eine Funktions-App ähnelt einer Lösung, die mehrere Funktionen hosten kann.

Sie können die vollständige Prozedur abrufen, das Wichtigste ist jedoch, ins Azure-Portal zu wechseln und eine neue Funktions-App mit folgenden Eigenschaften zu erstellen:

Veröffentlichen: Code
Laufzeit: PowerShell Core
Version: 7 und höher

Starten Sie nach der Bereitstellung der Funktions-App mit der allgemeinen Konfiguration.

Verwaltete Identität für Azure Functions

Die Funktion benötigt Berechtigungen zum Starten und Anhalten des Stream Analytics-Auftrags. Sie weisen diese Berechtigungen mithilfe einer verwalteten Identität zu.

Der erste Schritt besteht darin, eine systemseitig zugewiesene verwaltete Identität für die Funktion gemäß diesem Verfahren zu aktivieren.

Nun können Sie dieser Identität im Stream Analytics-Auftrag, den Sie automatisch anhalten möchten, die passenden Berechtigungen zuweisen. Fügen Sie für diese Aufgabe im Portalbereich für den -Stream Analytics-Auftrag (nicht den Funktionsauftrag) unter Zugriffssteuerung (IAM) der Rolle Mitwirkender eine Rollenzuweisung für ein Mitglied vom Typ Verwaltete Identität hinzu. Wählen Sie den Namen der Funktion von weiter oben aus.

Screenshot der Zugriffssteuerungseinstellungen für einen Stream Analytics-Auftrag

Im PowerShell-Skript können Sie eine Überprüfung hinzufügen, um sicherzustellen, dass die verwaltete Identität ordnungsgemäß festgelegt ist. (Das endgültige Skript ist auf GitHub verfügbar.)


# Check if a 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.")
}

Fügen Sie einige Protokollierungsinformationen hinzu, um sicherzustellen, dass die Funktion ausgelöst wird:


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

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

Parameter für Azure Functions

Die beste Möglichkeit, um Ihren Parameter an das Skript in Functions zu übergeben, besteht darin, die Anwendungseinstellungen der Funktions-App als Umgebungsvariablen zu verwenden.

Der erste Schritt besteht darin, dem Verfahren zu folgen, um auf der Funktions-App-Seite Ihre Parameter als App-Einstellungen zu definieren. Voraussetzungen:

Name	Wert
`maxInputBacklog`	Die Menge an Backlog, die Sie beim Anhalten des Auftrags akzeptieren. Für die Ereignisanzahl ist `0` ein guter Ausgangspunkt.
`maxWatermark`	Die Menge an Wasserzeichen, das Sie beim Anhalten des Auftrags akzeptieren. `10` (in Sekunden) ist ein guter Ausgangspunkt bei niedrigen Streamingeinheiten.
`restartThresholdMinute`	M: Die Zeit (in Minuten), bis ein angehaltener Auftrag neu gestartet wird.
`stopThresholdMinute`	N: Die Abkühldauer (in Minuten), bis ein ausgeführter Auftrag angehalten wird. Das Eingabebacklog muss während dieser Zeit `0` bleiben.
`subscriptionId`	Die Abonnement-ID (nicht der Name) des Stream Analytics-Auftrags, der automatisch angehalten werden soll.
`resourceGroupName`	Der Name der Ressourcengruppe des Stream Analytics-Auftrags, der automatisch angehalten werden soll.
`asaJobName`	Der Name des Stream Analytics-Auftrags, der automatisch angehalten werden soll.

Aktualisieren Sie dann Ihr PowerShell-Skript, um die Variablen entsprechend zu laden:

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

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

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

Anforderungen an das PowerShell-Modul

Auf die gleiche Weise, wie Sie Azure PowerShell lokal installieren mussten, um die Stream Analytics-Befehle zu verwenden (z. B. Start-AzStreamAnalyticsJob), müssen Sie es zum Funktions-App-Host hinzufügen:

Wählen Sie auf der Seite für die Funktions-App unter FunktionenApp-Dateien und dann requirements.psd1 aus.
Löschen Sie den Kommentar in der Zeile 'Az' = '6.*'.
Starten Sie die App neu, damit die Änderungen wirksam werden.

Screenshot der App-Dateieinstellungen für die Funktions-App

Erstellen der Funktion

Nachdem Sie die gesamte Konfiguration abgeschlossen haben, können Sie die spezifische Funktion in der Funktions-App erstellen, um das Skript auszuführen.

Entwickeln Sie im Portal eine Funktion, die durch einen Selbstauslöser ausgelöst wird. Stellen Sie sicher, dass die Funktion jede Minute mit 0 */1 * * * *ausgelöst wird und dass sie als „zur Sekunde 0 jeder Minute“ angezeigt wird.

Screenshot des Erstellens einer neuen Timertriggerfunktion in einer Funktions-App

Wenn nötig, können Sie den Wert des Selbstauslösers in Integration ändern, indem Sie den Zeitplan aktualisieren.

Screenshot der Integrationseinstellungen einer Funktion

Anschließend können Sie unter Code + Test Ihr Skript in run.ps1 kopieren und testen. Alternativ können Sie das vollständige Skript aus GitHubkopieren. Die Geschäftslogik wurde in eine TRY/CATCH-Anweisung verschoben, um die richtigen Fehler zu generieren, wenn während der Verarbeitung ein Fehler auftritt.

Screenshot des Bereichs „Code und Test“ für die Funktion

Sie können überprüfen, ob alles einwandfrei ausgeführt wird, indem Sie im Bereich Code + TestTesten/Ausführen auswählen. Sie können sich auch den Bereich Überprüfung ansehen, dieser ist jedoch immer ein paar Ausführungen später dran.

Screenshot der Ausgabe einer erfolgreichen Ausführung

Festlegen einer Warnung für die Funktionsausführung

Zum Schluss möchten Sie über eine Warnung benachrichtigt werden, wenn die Funktion nicht erfolgreich ausgeführt wird. Warnungen verursachen geringfügige Kosten, können möglicherweise jedoch teurere Situationen verhindern.

Führen Sie auf der Seite für die Funktions-App unter Protokolle die folgende Abfrage aus. Sie gibt alle nicht erfolgreichen Ausführungen der letzten 5 Minuten zurück.

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

Wählen Sie im Abfrage-Editor Neue Warnungsregel aus. Definieren Sie im sich daraufhin öffnenden Bereich Measure folgendermaßen:

Measure: failedCount
Aggregationstyp: Gesamt
Aggregationsgranularität: 5 Minuten

Richten Sie als Nächstes Warnungslogik wie folgt ein:

Operator: Größer als
Schwellenwert: 0
Häufigkeit der Auswertung: 5 Minuten

Verwenden Sie von dort aus eine Aktionsgruppe erneut, oder erstellen Sie eine neue. Schließen Sie dann die Konfiguration ab.

Um zu überprüfen, ob Sie die Warnung ordnungsgemäß eingerichtet haben, können Sie throw "Testing the alert" an einer beliebigen Stelle im PowerShell-Skript hinzufügen und dann 5 Minuten warten, um eine E-Mail zu empfangen.

Option 2: Hosten der Aufgabe in Azure Automation

Zunächst benötigen wir ein neues Automation-Konto. Ein Automation-Konto ähnelt einer Lösung, die mehrere Runbooks hosten kann.

Weitere Informationen zur Vorgehensweise finden Sie im Schnellstart Erstellen eines Automation-Kontos über das Azure-Portal. Sie können sich direkt auf der Registerkarte Erweitert für die Verwendung einer systemseitig zugewiesenen verwalteten Identität entscheiden.

Das Automation-Team hat ein Tutorial für die ersten Schritte mit PowerShell-Runbooks zu Referenzzwecken bereitgestellt.

Parameter für Azure Automation

Mit einem Runbook können Sie die klassische Parametersyntax von PowerShell verwenden, um Argumente zu übergeben:

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

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

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

Verwaltete Identität für Azure Automation

Das Automation-Konto sollte während der Bereitstellung eine verwaltete Identität erhalten haben. Bei Bedarf können Sie jedoch eine verwaltete Identität mithilfe dieser Vorgehensweise aktivieren.

Wie Sie es für die Funktion getan haben, müssen im Stream Analytics-Auftrag, den Sie automatisch anhalten möchten, die passenden Berechtigungen zuweisen.

Um die Berechtigung zuzuweisen, fügen Sie im Portalbereich für den Stream Analytics-Auftrag (nicht auf der Automation-Seite) unter Zugriffssteuerung (IAM) der Rolle Mitwirkender eine Rollenzuweisung für ein Mitglied vom Typ Verwaltete Identität hinzu. Wählen Sie den Namen des Automation-Kontos von weiter oben aus.

Screenshot der Zugriffssteuerungseinstellungen für einen Stream Analytics-Auftrag

Im PowerShell-Skript können Sie eine Überprüfung hinzufügen, um sicherzustellen, dass die verwaltete Identität ordnungsgemäß festgelegt ist. (Das endgültige Skript ist auf GitHub verfügbar.)

# Ensure that you don't inherit an AzContext in your runbook
Disable-AzContextAutosave -Scope Process | Out-Null

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

Erstellen des Runbooks

Nachdem Sie die Konfiguration abgeschlossen haben, können Sie das spezifische Runbook innerhalb des Automation-Kontos erstellen, um unser Skript auszuführen. Hier müssen Sie Azure PowerShell nicht als Anforderung hinzufügen. Es ist bereits integriert.

Wählen Sie im Portal unter Prozessautomatisierung die Option Runbooks aus. Wählen Sie dann Runbook erstellen und PowerShell als Runbooktyp aus, und wählen Sie als Version eine beliebige Version höher als 7 (derzeit Version 7.1 (Vorschau)) aus.

Sie können Ihr Skript nun einfügen und testen. Sie können das vollständige Skript aus GitHubkopieren. Die Geschäftslogik wurde in eine TRY/CATCH-Anweisung verschoben, um die richtigen Fehler zu generieren, wenn während der Verarbeitung ein Fehler auftritt.

Screenshot des Runbook-Skript-Editors in Azure Automation

Sie können im Testbereich überprüfen, ob alles ordnungsgemäß verbunden ist.

Danach müssen Sie den Auftrag veröffentlichen (indem Sie Veröffentlichen auswählen), um das Runbook mit einem Zeitplan verknüpfen zu können. Das Erstellen und Verknüpfen des Zeitplans ist ein einfacher Prozess. Denken Sie nun daran, dass es Problemumgehungen gibt, um Zeitplanintervalle unter einer Stunde zu erreichen.

Zum Schluss können Sie eine Warnung einrichten. Der erste Schritt besteht darin, über die Diagnoseeinstellungen des Automation-Kontos Protokolle zu aktivieren. Im zweiten Schritt erfassen Sie wie bei Functions mithilfe einer Abfrage Fehler.

Ergebnis

In Ihrem Stream Analytics-Auftrag können Sie überprüfen, ob alles wie erwartet an zwei Stellen ausgeführt wird.

Hier das Aktivitätsprotokoll:

Screenshot der Protokolle des Stream Analytics-Auftrags

Und hier die Metriken:

Screenshot der Metriken des Stream Analytics-Auftrags

Nachdem Sie die Funktionsweise des Skripts verstanden haben, ist das Umarbeiten zum Erweitern seines Umfangs eine einfache Aufgabe. Sie können das Skript problemlos aktualisieren, um eine Liste von Aufträgen anstelle eines einzelnen Auftrags als Ziel zu verwenden. Sie können größere Bereiche können mithilfe von Tags, Ressourcengruppen oder sogar ganzen Abonnements definieren und verarbeiten.

Support

Weitere Unterstützung erhalten Sie auf der Microsoft Q&A-Seite für Azure Stream Analytics.

Nächste Schritte

Sie haben die Grundlagen der Verwendung von PowerShell kennengelernt, um die Verwaltung von Azure Stream Analytics-Aufträgen zu automatisieren. Weitere Informationen erhalten Sie in den folgenden Artikeln:

Feedback

War diese Seite hilfreich?

Last updated on 2024-03-07