Automatyczne wstrzymywanie zadania przy użyciu programu PowerShell i Azure Functions lub usługi Azure Automation

Niektóre aplikacje wymagają podejścia do przetwarzania strumieniowego, które jest łatwe w usłudze Azure Stream Analytics (ASA), ale nie muszą być uruchamiane w sposób ciągły. Przyczyny są różne:

  • Dane wejściowe przychodzące zgodnie z harmonogramem (góra godziny...)
  • Rozrzedny lub mała ilość danych przychodzących (kilka rekordów na minutę)
  • Procesy biznesowe, które korzystają z możliwości okien czasowych, ale są uruchamiane wsadowo według istoty (Finanse lub HR...)
  • Pokazy, prototypy lub testy, które obejmują długotrwałe zadania na małą skalę

Zaletą braku ciągłego uruchamiania tych zadań będzie oszczędność kosztów, ponieważ zadania usługi Stream Analytics są rozliczane na jednostkę przesyłania strumieniowego w czasie.

W tym artykule wyjaśniono, jak skonfigurować automatyczne wstrzymywanie zadania usługi Azure Stream Analytics. W nim konfigurujemy zadanie, które automatycznie wstrzymuje i wznawia zadanie zgodnie z harmonogramem. Jeśli używamy terminu wstrzymania, rzeczywisty stan zadania zostanie zatrzymany, aby uniknąć rozliczeń.

Najpierw omówimy ogólny projekt, a następnie omówimy wymagane składniki, a na koniec omówimy pewne szczegóły implementacji.

Uwaga

Istnieją wady automatycznego wstrzymania zadania. Głównymi z nich jest utrata możliwości niskiego opóźnienia / czasu rzeczywistego, a potencjalne ryzyko związane z zezwoleniem na wzrost listy prac zdarzeń wejściowych w celu zwiększenia nienadzorowanej podczas wstrzymania zadania. Automatyczne wstrzymanie nie powinno być brane pod uwagę w przypadku większości scenariuszy produkcyjnych działających na dużą skalę

Projekt

W tym przykładzie chcemy, aby nasze zadanie było uruchamiane przez N minut przed wstrzymaniem go przez M min. Gdy zadanie zostanie wstrzymane, dane wejściowe nie będą używane, zbierając dane nadrzędne. Po rozpoczęciu zadania nadrobi zaległości, przetworzysz dane przed ponownym zamknięciem.

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

Podczas uruchamiania zadanie nie powinno zatrzymać zadania, dopóki jego metryki nie będą w dobrej kondycji. Interesujące metryki będą listą prac wejściowych i znakiem wodnym. Sprawdzimy, czy oba te elementy znajdują się w punkcie odniesienia przez co najmniej N minut. To zachowanie przekłada się na dwie akcje:

  • Zatrzymane zadanie jest uruchamiane ponownie po minutach M
  • Uruchomione zadanie jest zatrzymywane w dowolnym momencie po upływie N minut, gdy tylko jego metryki listy prac i znaku wodnego są w dobrej kondycji

Diagram that shows the possible states of the job

Rozważmy na przykład N = 5 minut, a M = 10 minut. W przypadku tych ustawień zadanie ma co najmniej 5 minut do przetworzenia wszystkich danych odebranych w 15. Potencjalne oszczędności kosztów wynoszą do 66%.

Aby ponownie uruchomić zadanie, użyjemy opcji uruchamianiaWhen Last Stopped. Ta opcja informuje usługę ASA o przetworzeniu wszystkich zdarzeń, które zostały wycofane w górę, ponieważ zadanie zostało zatrzymane. W tej sytuacji istnieją dwa zastrzeżenia. Najpierw zadanie nie może pozostać zatrzymane dłużej niż okres przechowywania strumienia wejściowego. Jeśli uruchamiamy zadanie tylko raz dziennie, musimy upewnić się, że okres przechowywania centrum zdarzeń wynosi więcej niż jeden dzień. Po drugie, zadanie musi zostać uruchomione co najmniej raz, aby tryb When Last Stopped został zaakceptowany (w przeciwnym razie nigdy wcześniej nie został zatrzymany). Dlatego pierwszy przebieg zadania musi być ręczny lub musimy rozszerzyć skrypt, aby obsłużyć ten przypadek.

Ostatnią kwestią jest wykonanie tych akcji idempotentnych. W ten sposób można je powtórzyć bez skutków ubocznych, zarówno dla łatwości stosowania, jak i odporności.

Składniki

Wywołania interfejsu API

Przewidujemy konieczność interakcji z usługą ASA w następujących aspektach:

  • Pobieranie bieżącego stanu zadania (usługa ASA Resource Management)
    • Jeśli jest uruchomiona
      • Uzyskaj czas od rozpoczęcia (dzienniki)
      • Pobieranie bieżących wartości metryk (metryki)
      • Jeśli ma to zastosowanie, zatrzymaj zadanie (zarządzanie zasobami asa)
    • Jeśli zatrzymano
      • Pobieranie czasu od zatrzymania (dzienniki)
      • Jeśli ma to zastosowanie, uruchom zadanie (zarządzanie zasobami ASA)

W przypadku usługi ASA Resource Management możemy użyć interfejsu API REST, zestawu .NET SDK lub jednej z bibliotek interfejsu wiersza polecenia (Az CLI, PowerShell).

W przypadku metryk i dzienników na platformie Azure wszystko jest scentralizowane w usłudze Azure Monitor z podobnym wyborem powierzchni interfejsu API. Podczas wykonywania zapytań dotyczących interfejsów API należy pamiętać, że dzienniki i metryki są zawsze od 1 do 3 minut. Dlatego ustawienie N na 5 zwykle oznacza, że zadanie będzie działać od 6 do 8 minut w rzeczywistości. Kolejną rzeczą, którą należy wziąć pod uwagę, jest to, że metryki są zawsze emitowane. Po zatrzymaniu zadania interfejs API zwraca puste rekordy. Musimy wyczyścić dane wyjściowe wywołań interfejsu API, aby przyjrzeć się tylko odpowiednim wartościom.

Język skryptów

W tym artykule postanowiliśmy zaimplementować automatyczne wstrzymywanie w programie PowerShell. Pierwszym powodem jest to, że program PowerShell jest teraz międzyplatformowy. Może działać w dowolnym systemie operacyjnym, co ułatwia wdrażanie. Drugą przyczyną jest to, że przyjmuje i zwraca obiekty, a nie ciągi. Obiekty ułatwiają analizowanie i przetwarzanie zadań automatyzacji.

W programie PowerShell użyjemy modułu Az programu PowerShell , który rozpoczyna moduł Az.Monitor i Az.StreamAnalytics, aby uzyskać wszystko, czego potrzebujemy:

Usługa hostingu

Aby hostować nasze zadanie programu PowerShell, potrzebujemy usługi, która oferuje zaplanowane uruchomienia. Istnieje wiele opcji, ale patrząc na bezserwerowe:

  • Azure Functions bezserwerowy aparat obliczeniowy, który może uruchamiać prawie dowolny fragment kodu. Funkcje oferują wyzwalacz czasomierza , który może być uruchamiany do każdej sekundy
  • Azure Automation, usługa zarządzana utworzona na potrzeby obciążeń i zasobów w chmurze operacyjnej. To pasuje do rachunku, ale którego minimalny interwał harmonogramu wynosi 1 godzinę (mniej z obejściami).

Jeśli nie mamy nic przeciwko obejściem, usługa Azure Automation jest łatwiejszym sposobem wdrożenia zadania. Ale aby móc porównać, w tym artykule najpierw napiszemy skrypt lokalny. Po utworzeniu działającego skryptu wdrożymy go zarówno w usłudze Functions, jak i na koncie usługi Automation.

Narzędzia dla deweloperów

Zdecydowanie zalecamy programowanie lokalne przy użyciu programu VSCode, zarówno dla usług Functions , jak i ASA. Użycie lokalnego środowiska IDE umożliwia korzystanie z kontroli źródła i łatwe powtarzanie wdrożeń. Ale ze względu na zwięzłość, tutaj zilustrujemy proces w Azure Portal.

Lokalne pisanie skryptu programu PowerShell

Najlepszym sposobem tworzenia skryptu jest lokalnie. Program PowerShell jest międzyplatformowy, skrypt można napisać i przetestować w dowolnym systemie operacyjnym. W Windows można użyć Terminal Windows z programem PowerShell 7 i modułem Az programu PowerShell.

Ostateczny skrypt, który będzie używany, jest dostępny dla funkcji (i usługi Azure Automation). Różni się on od opisanego poniżej, który został przewodowy do środowiska hostingu (funkcje lub automatyzacja). Omówimy ten aspekt później. Najpierw przejmijmy wersję, która działa tylko lokalnie.

Ten skrypt jest celowo napisany w prostej formie, więc może być zrozumiały dla wszystkich.

U góry ustawimy wymagane parametry i sprawdzimy stan zadania początkowego:


# 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)."

Następnie, jeśli zadanie jest uruchomione, sprawdzamy, czy zadanie zostało uruchomione co najmniej N minut, jego zaległości i jego znak wodny.


# 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."
    }
}

Jeśli zadanie zostanie zatrzymane, przyjrzymy się dziennikowi, kiedy była ostatnia akcja "Zatrzymaj zadanie":


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!"
}

Na końcu rejestrujemy ukończenie zadania:


# 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."

Opcja 1. Hostowanie zadania w Azure Functions

Aby uzyskać informacje, zespół Azure Functions utrzymuje wyczerpujący przewodnik dewelopera programu PowerShell.

Najpierw będziemy potrzebować nowej aplikacji funkcji. Aplikacja funkcji jest podobna do rozwiązania, które może hostować wiele funkcji.

Pełna procedura jest tutaj, ale gist ma przejść w Azure Portal i utworzyć nową aplikację funkcji za pomocą:

  • Publikowanie: kod
  • Środowisko uruchomieniowe: PowerShell Core
  • Wersja: 7+

Po aprowizacji zacznijmy od ogólnej konfiguracji.

Tożsamość zarządzana dla Azure Functions

Funkcja musi mieć uprawnienia do uruchamiania i zatrzymywania zadania usługi ASA. Przypiszemy te uprawnienia za pośrednictwem tożsamości zarządzanej.

Pierwszym krokiem jest włączenie tożsamości zarządzanej przypisanej przez system dla funkcji, wykonując tę procedurę.

Teraz możemy udzielić odpowiednich uprawnień do tej tożsamości w zadaniu usługi ASA, które chcemy automatycznie wstrzymać. W tym celu w portalu dla zadania ASA (a nie funkcji), w obszarze Kontrola dostępu (zarządzanie dostępem i tożsamościami) dodaj przypisanie roli do roli Współautor dla elementu członkowskiego tożsamości zarządzanej, wybierając nazwę funkcji powyżej.

Screenshot of IAM settings for the ASA job

W skryscie programu PowerShell możemy dodać kontrolę, która gwarantuje, że tożsamość zarządzana jest poprawnie ustawiona (ostateczny skrypt jest dostępny tutaj)


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

Dodamy również pewne informacje rejestrowania, aby upewnić się, że funkcja jest wyzwalana:


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

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

Parametry Azure Functions

Najlepszym sposobem przekazania naszych parametrów do skryptu w usłudze Functions jest użycie ustawień aplikacji funkcji jako zmiennych środowiskowych.

W tym celu pierwszy krok znajduje się na stronie Aplikacja funkcji, aby zdefiniować nasze parametry jako app Ustawienia zgodnie z tę procedurą. Będziemy potrzebować:

Nazwa Wartość
maxInputBacklog Ilość listy prac tolerowanych podczas zatrzymywania zadania (w liczbie zdarzeń 0 jest dobrym punktem wyjścia)
maxWatermark Ilość znaku wodnego tolerowanego podczas zatrzymywania zadania (w sekundach 10 jest dobrym punktem wyjścia w niskich jednostkach SU)
restartThresholdMinute M: czas (w minutach) do momentu ponownego uruchomienia zatrzymanego zadania
stopThresholdMinute N: czas (w minutach) ochładzania do momentu zatrzymania uruchomionego zadania. W tym czasie konieczne będzie zachowanie listy prac wejściowych na poziomie 0
subscriptionId Identyfikator subskrypcji (a nie nazwa) zadania asa, które ma być automatycznie wstrzymane
resourceGroupName Nazwa grupy zasobów zadania asa, które ma zostać wstrzymane automatycznie
asaJobName Nazwa zadania asa, które ma być wstrzymane

Później musimy zaktualizować skrypt programu PowerShell, aby odpowiednio załadować zmienne:

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

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

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

Wymagania dotyczące modułu programu PowerShell

W ten sam sposób musieliśmy zainstalować program Az programu PowerShell lokalnie, aby użyć poleceń usługi ASA (na przykład Start-AzStreamAnalyticsJob), musimy dodać go do hosta aplikacji funkcji.

W tym celu możemy przejść na Functions>App files stronie Aplikacja funkcji, wybrać pozycję requirements.psd1i usunąć komentarz w wierszu .'Az' = '6.*' Aby ta zmiana weszła w życie, należy ponownie uruchomić całą aplikację.

Screenshot of the app files settings for the Function App

Tworzenie funkcji

Po zakończeniu całej konfiguracji możemy utworzyć określoną funkcję wewnątrz aplikacji funkcji, która uruchomi nasz skrypt.

Utworzymy w portalu funkcję wyzwalaną na czasomierzu (co minutę z elementem 0 */1 * * * *, który odczytuje "na sekundę 0 co 1 minutę"):

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

W razie potrzeby możemy zmienić wartość czasomierza w pliku Integration, aktualizując harmonogram:

Screenshot of the integration settings of the function

Następnie w programie Code + Testmożemy skopiować nasz skrypt i run.ps1 przetestować go. Pełny skrypt można skopiować tutaj, logika biznesowa została przeniesiona do instrukcji TRY/CATCH w celu wygenerowania odpowiednich błędów, jeśli coś nie powiedzie się podczas przetwarzania.

Screenshot of Code+Test for the function

Możemy sprawdzić, czy wszystko działa prawidłowo za pomocą polecenia Test/Uruchom w okienku Code + Test . Możemy również przyjrzeć się okienku Monitor , ale zawsze jest późno na kilka wykonań.

Screenshot of the output of a successful run

Ustawianie alertu dotyczącego wykonywania funkcji

Na koniec chcemy otrzymywać powiadomienia za pośrednictwem alertu, jeśli funkcja nie zostanie pomyślnie uruchomiona. Alerty mają niewielki koszt, ale mogą zapobiegać droższym sytuacjom.

Na stronie Aplikacja funkcji w obszarze Logsuruchom następujące zapytanie, które zwraca wszystkie nieudanych przebiegów w ciągu ostatnich 5 minut:

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

W edytorze zapytań wybierz pozycję New alert rule. Na poniższym ekranie zdefiniuj miarę jako:

  • Miara: failedCount
  • Typ agregacji: Suma
  • Stopień szczegółowości agregacji: 5 minut

Następnie skonfiguruj logikę alertu w następujący sposób:

  • Operator: większe niż
  • Wartość progowa: 0
  • Częstotliwość oceny: 5 minut

Następnie ponownie użyj lub utwórz nową grupę akcji, a następnie ukończ konfigurację.

Aby sprawdzić, czy alert został poprawnie skonfigurowany, możemy dodać throw "Testing the alert" dowolne miejsce w skryscie programu PowerShell i poczekać 5 minut na odebranie wiadomości e-mail.

Opcja 2. Hostowanie zadania w usłudze Azure Automation

Najpierw będziemy potrzebować nowego konta usługi Automation. Konto usługi Automation jest podobne do rozwiązania, które może hostować wiele elementów Runbook.

Procedura jest tutaj. W tym miejscu możemy wybrać opcję użycia tożsamości zarządzanej przypisanej przez system bezpośrednio na advanced karcie.

Aby uzyskać informacje, zespół usługi Automation ma dobry samouczek dotyczący rozpoczynania pracy z elementami Runbook programu PowerShell.

Parametry usługi Azure Automation

W przypadku elementu Runbook możemy użyć klasycznej składni parametrów programu PowerShell do przekazywania argumentów:

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

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

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

Tożsamość zarządzana dla usługi Azure Automation

Konto usługi Automation powinno otrzymać tożsamość zarządzaną podczas aprowizacji. Jednak w razie potrzeby możemy włączyć tę procedurę.

Podobnie jak w przypadku funkcji, musimy udzielić odpowiednich uprawnień w zadaniu usługi ASA, które chcemy automatycznie wstrzymać.

W tym celu w portalu zadania usługi ASA (a nie na stronie Automatyzacja) w obszarze Kontrola dostępu (zarządzanie dostępem i tożsamościami) dodaj przypisanie roli do roli Współautor dla członka typu Tożsamość zarządzana, wybierając nazwę konta usługi Automation powyżej.

Screenshot of IAM settings for the ASA job

W skryscie programu PowerShell możemy dodać kontrolę, która gwarantuje, że tożsamość zarządzana jest poprawnie ustawiona (ostateczny skrypt jest dostępny tutaj)

# 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
    }

Tworzenie elementu Runbook

Po zakończeniu konfiguracji możemy utworzyć określony element Runbook na koncie usługi Automation, który uruchomi nasz skrypt. W tym miejscu nie musimy dodawać programu PowerShell jako wymagania, ale jest on już wbudowany.

W portalu w obszarze Automatyzacja procesów wybierz pozycję Runbooks, a następnie wybierz pozycję , wybierz Create a runbookPowerShell typ elementu Runbook i dowolną wersję powyżej 7 jako wersję (w tej chwili 7.1 (preview)).

Teraz możemy wkleić nasz skrypt i przetestować go. Pełny skrypt można skopiować tutaj, logika biznesowa została przeniesiona do instrukcji TRY/CATCH w celu wygenerowania odpowiednich błędów, jeśli coś nie powiedzie się podczas przetwarzania.

Screenshot of the runbook script editor in Azure Automation

Możemy sprawdzić, czy wszystko jest prawidłowo przewodowe w obiekcie Test Pane.

Następnie musimy wykonać Publish zadanie, co pozwoli nam połączyć element Runbook z harmonogramem. Tworzenie i łączenie harmonogramu jest prostym procesem, który nie zostanie omówiony tutaj. Teraz warto pamiętać, że istnieją obejścia umożliwiające osiągnięcie interwałów harmonogramu poniżej 1 godziny.

Na koniec możemy skonfigurować alert. Pierwszym krokiem jest włączenie dzienników za pośrednictwem ustawień diagnostycznych konta usługi Automation. Drugim krokiem jest przechwycenie błędów za pośrednictwem zapytania, takiego jak w przypadku usługi Functions.

Wynik

Patrząc na nasze zadanie asa, widzimy, że wszystko działa zgodnie z oczekiwaniami w dwóch miejscach.

W dzienniku aktywności:

Screenshot of the logs of the ASA job

I za pośrednictwem jego metryk:

Screenshot of the metrics of the ASA job

Po zrozumieniu skryptu łatwo jest przerobić go w celu rozszerzenia zakresu. Można ją łatwo zaktualizować w celu kierowania listy zadań zamiast pojedynczej. Większe zakresy można definiować i przetwarzać za pomocą tagów, grup zasobów, a nawet całych subskrypcji.

Uzyskiwanie pomocy technicznej

Aby uzyskać dalszą pomoc, wypróbuj naszą stronę pytań dotyczących języka Microsoft Q&A dotyczącą usługi Azure Stream Analytics.

Następne kroki

Znasz już podstawy używania programu PowerShell do automatyzowania zarządzania zadaniami usługi Azure Stream Analytics. Więcej informacji można znaleźć w następujących artykułach: