Condividi tramite


Gestire runbook in Automazione di Azure

Per aggiungere un runbook ad Automazione di Azure, è possibile creare un nuovo runbook oppure importarne uno esistente da un file o dalla raccolta di runbook. Questo articolo fornisce informazioni per la gestione di un runbook e dei modelli consigliati e delle procedure consigliate con la progettazione di runbook. È possibile ottenere tutti i dettagli sull'accesso ai runbook e ai moduli della community in Raccolte di runbook e moduli per l'Automazione di Azure.

Creare un runbook

Creare un nuovo runbook in Automazione di Azure usando il portale di Azure o PowerShell. Dopo che il runbook è stato creato, è possibile modificarlo usando le informazioni negli articoli seguenti:

Creare un runbook nel portale di Azure

  1. Accedere al portale di Azure.
  2. Cercare e selezionare Account di Automazione.
  3. Nella pagina Account di automazione selezionare l'account di Automazione dall'elenco.
  4. Nell'account di Automazione selezionare Runbook in Automazione processi per aprire l'elenco dei runbook.
  5. Fare clic su Crea un runbook.
    1. Denominare il runbook.
    2. Dall'elenco a discesa Tipo runbook . Selezionarne il tipo. Il nome del runbook deve iniziare con una lettera e può contenere lettere, numeri, caratteri di sottolineatura e trattini
    3. Selezionare la versione di runtime
    4. Immettere la descrizione applicabile
  6. Fare clic su Crea per creare il runbook.

Creare un runbook con PowerShell

Usare il cmdlet New-AzAutomationRunbook per creare un runbook vuoto. Usare il parametro Type per specificare uno dei tipi di runbook definiti per New-AzAutomationRunbook.

L'esempio seguente illustra come creare un nuovo runbook vuoto.

$params = @{
    AutomationAccountName = 'MyAutomationAccount'
    Name                  = 'NewRunbook'
    ResourceGroupName     = 'MyResourceGroup'
    Type                  = 'PowerShell'
}
New-AzAutomationRunbook @params

Importare un runbook

È possibile importare uno script powerShell o un flusso di lavoro PowerShell (ps1), un runbook grafico (.graphrunbook) o uno script Python 2 o Python 3 (con estensione py) per creare un runbook personalizzato. Specificare il tipo di runbook creato durante l'importazione, tenendo conto delle considerazioni seguenti.

  • È possibile importare un file .ps1 che non contiene un flusso di lavoro in un runbook di PowerShell oppure in un runbook del flusso di lavoro di PowerShell. Se il file viene importato in un runbook del flusso di lavoro PowerShell, questo viene convertito in un flusso di lavoro. In questo caso, i commenti vengono inclusi nel runbook per descrivere le modifiche apportate.

  • È possibile importare solo un file .ps1 che contiene un flusso di lavoro di PowerShell Workflow in un runbook del flusso di lavoro di PowerShell. Se il file contiene più flussi di lavoro di PowerShell, l'importazione avrà esito negativo. È necessario salvare ogni flusso di lavoro nel proprio file e importarlo separatamente.

  • Non importare un file .ps1 che contiene un flusso di lavoro di PowerShell in un runbook di PowerShell, perché il motore di script di PowerShell non è in grado di riconoscerlo.

  • Importare solo un file .graphrunbook in un nuovo runbook grafico.

Importare un runbook dal portale di Azure

È possibile usare la procedura seguente per importare un file di script in Automazione di Azure.

Nota

È possibile importare solo un file con estensione .ps1 in un runbook del flusso di lavoro PowerShell tramite il portale.

  1. Nel portale di Azure cercare e selezionare Account di Automazione.
  2. Nella pagina Account di automazione selezionare l'account di Automazione dall'elenco.
  3. Nell'account di Automazione selezionare Runbook in Automazione processi per aprire l'elenco dei runbook.
  4. Fare clic su Importa un runbook. È possibile selezionare una delle opzioni seguenti:
    1. Cerca file : seleziona un file dal computer locale.
    2. Sfoglia da Raccolta : è possibile esplorare e selezionare un runbook esistente dalla raccolta.
  5. Seleziona il file.
  6. Se il campo Nome è abilitato, è possibile modificare il nome del runbook. Il nome deve iniziare con una lettera e può includere lettere, numeri, caratteri di sottolineatura e trattini.
  7. Il tipo di runbook viene popolato automaticamente, ma è possibile modificare il tipo dopo aver preso in considerazione le restrizioni applicabili.
  8. La versione del runtime è popolata automaticamente o seleziona la versione dall'elenco a discesa.
  9. Fare clic su Importa. Il nuovo runbook viene visualizzato nell'elenco dei runbook per l'account di automazione.
  10. Prima di poter eseguire il runbook, è necessario pubblicarlo.

Nota

Dopo aver importato un runbook grafico, è possibile convertirlo in un runbook di altro tipo. Non è tuttavia possibile convertire un runbook grafico in un runbook testuale.

Importare un runbook con PowerShell

Usare il cmdlet Import-AzAutomationRunbook per importare un file di script come un runbook in formato bozza. Se il runbook esiste già, l'importazione ha esito negativo a meno che non si usi il parametro Force con il cmdlet.

L'esempio seguente illustra come importare un file di script in un runbook.

$params = @{
    AutomationAccountName = 'MyAutomationAccount'
    Name                  = 'Sample_TestRunbook'
    ResourceGroupName     = 'MyResourceGroup'
    Type                  = 'PowerShell'
    Path                  = 'C:\Runbooks\Sample_TestRunbook.ps1'
}
Import-AzAutomationRunbook @params

Gestire risorse

Se il runbook crea una risorsa, lo script deve verificare se la risorsa esiste già prima di tentare di crearla. Di seguito viene indicato un esempio di base.

$vmName = 'WindowsVM1'
$rgName = 'MyResourceGroup'
$myCred = Get-AutomationPSCredential 'MyCredential'

$vmExists = Get-AzResource -Name $vmName -ResourceGroupName $rgName
if (-not $vmExists) {
    Write-Output "VM $vmName does not exist, creating"
    New-AzVM -Name $vmName -ResourceGroupName $rgName -Credential $myCred
} else {
    Write-Output "VM $vmName already exists, skipping"
}

Recuperare i dettagli dal log attività

È possibile recuperare i dettagli di un runbook, ad esempio la persona o l'account che ha avviato un runbook, dal log attività per l'account di automazione. L'esempio di PowerShell seguente consente di ottenere l'ultimo utente che ha eseguito il runbook specificato.

$rgName = 'MyResourceGroup'
$accountName = 'MyAutomationAccount'
$runbookName = 'MyRunbook'
$startTime = (Get-Date).AddDays(-1)

$params = @{
    ResourceGroupName = $rgName
    StartTime         = $startTime
}
$JobActivityLogs = (Get-AzLog @params).Where( { $_.Authorization.Action -eq 'Microsoft.Automation/automationAccounts/jobs/write' })

$JobInfo = @{}
foreach ($log in $JobActivityLogs) {
    # Get job resource
    $JobResource = Get-AzResource -ResourceId $log.ResourceId

    if ($null -eq $JobInfo[$log.SubmissionTimestamp] -and $JobResource.Properties.Runbook.Name -eq $runbookName) {
        # Get runbook
        $jobParams = @{
            ResourceGroupName     = $rgName
            AutomationAccountName = $accountName
            Id                    = $JobResource.Properties.JobId
        }
        $Runbook = Get-AzAutomationJob @jobParams | Where-Object RunbookName -EQ $runbookName

        # Add job information to hashtable
        $JobInfo.Add($log.SubmissionTimestamp, @($Runbook.RunbookName, $Log.Caller, $JobResource.Properties.jobId))
    }
}
$JobInfo.GetEnumerator() | Sort-Object Key -Descending | Select-Object -First 1

Registrazione dell'avanzamento

È consigliabile creare i runbook in modo che siano modulari per natura, con la logica che può essere usata nuovamente e riavviata facilmente. Il monitoraggio dello stato di avanzamento in un runbook garantisce che la logica di runbook venga eseguita correttamente in caso di problemi.

È possibile tenere traccia dello stato di avanzamento di un runbook usando un'origine esterna, ad esempio un account di archiviazione, un database o file condivisi. Creare la logica nel runbook per verificare innanzitutto lo stato dell'ultima azione eseguita. In base ai risultati del controllo, la logica può quindi ignorare o continuare attività specifiche nel runbook.

Evitare i processi simultanei

Alcuni runbook si comportano in modo strano se vengono eseguiti in più processi contemporaneamente. In questo caso, è importante che un runbook implementi la logica per determinare se esiste già un processo in esecuzione. Di seguito viene indicato un esempio di base.

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

# Connect to Azure with system-assigned managed identity 
$AzureContext = (Connect-AzAccount -Identity).context

# set and store context 
$AzureContext = Set-AzContext -SubscriptionName $AzureContext.Subscription -DefaultProfile $AzureContext

# Check for already running or new runbooks 
$runbookName = "runbookName" 
$resourceGroupName = "resourceGroupName" 
$automationAccountName = "automationAccountName"

$jobs = Get-AzAutomationJob -ResourceGroupName $resourceGroupName -AutomationAccountName $automationAccountName -RunbookName $runbookName -DefaultProfile $AzureContext

# Ranking all the active jobs
$activeJobs = $jobs | where {$_.status -eq 'Running' -or $_.status -eq 'Queued' -or $_.status -eq 'New' -or $_.status -eq 'Activating' -or $_.status -eq 'Resuming'} | Sort-Object -Property CreationTime 
$jobRanking = @() 
$rank = 0 
ForEach($activeJob in $activeJobs) 
{         
    $rank = $rank + 1 
    $activeJob | Add-Member -MemberType NoteProperty -Name jobRanking -Value $rank -Force 
    $jobRanking += $activeJob 
}
    
$AutomationJobId = $PSPrivateMetadata.JobId.Guid 
$currentJob = $activeJobs | where {$_.JobId -eq $AutomationJobId} 
$currentJobRank = $currentJob.jobRanking 

# Only allow the Job with Rank = 1 to start processing. 
If($currentJobRank -ne "1") 
{ 
    Write-Output "$(Get-Date -Format yyyy-MM-dd-hh-mm-ss.ffff) Concurrency check failed as Current Job Ranking is not 1 but $($currentJobRank) therefore exiting..." 
    Exit 
} Else
{
    Write-Output "$(Get-Date -Format yyyy-MM-dd-hh-mm-ss.ffff) Concurrency check passed. Start processing.." 
} 

Se si vuole che il runbook venga eseguito con l'identità gestita assegnata dal sistema, lasciare invariato il codice. Se si preferisce usare un'identità gestita assegnata dall'utente, procedere come illustrato di seguito:

  1. Dalla riga 5 rimuovere $AzureContext = (Connect-AzAccount -Identity).context,
  2. Sostituirlo con $AzureContext = (Connect-AzAccount -Identity -AccountId <ClientId>).contexte
  3. Immettere l'ID client.

Nota

Per i processi ibridi di PowerShell 7.2, apportare modifiche alla riga 28. Sostituisci $PSPrivateMetadata.JobId.Guid con $env:PSPrivateMetaData.

Gestire errori temporanei in uno script dipendente dal tempo

I runbook devono essere affidabili e in grado di gestire errori, ad esempio gli errori temporanei che possono causare il riavvio o un esito negativo. Se un runbook ha esito negativo, Automazione di Azure lo ripete.

Se il runbook viene eseguito in genere all'interno di un vincolo temporale, fare in modo che lo script implementi la logica per controllare il tempo di esecuzione. Questo controllo garantisce l'esecuzione di operazioni come l'avvio, l'arresto o la scalabilità orizzontale solo in momenti specifici.

Nota

L'ora locale nel processo sandbox di Azure è impostata sull'ora UTC. I calcoli relativi a data e ora nei runbook devono tenere in considerazione questo aspetto.

Logica di ripetizione dei tentativi nel runbook per evitare errori temporanei

I runbook spesso effettuano chiamate a sistemi remoti, ad esempio Azure tramite ARM, Azure Resource Graph, servizi SQL e altri servizi Web. Quando il sistema che i runbook chiamano è occupato, temporaneo non disponibile o implementazione della limitazione in fase di caricamento, le chiamate sono vulnerabili a errori di runtime. Per creare resilienza nei runbook, è necessario implementare la logica di ripetizione dei tentativi quando si effettuano le chiamate in modo che i runbook possano gestire un problema temporaneo senza errori.

Per altre informazioni, vedere Criteri di ripetizione dei tentativi e Linee guida generali su REST e ripetizione dei tentativi.

Esempio 1: se il runbook effettua solo una o due chiamate

$searchServiceURL = "https://$searchServiceName.search.windows.net"
$resource = Get-AzureRmResource -ResourceType "Microsoft.Search/searchServices" -ResourceGroupName $searchResourceGroupName -ResourceName  $searchServiceName -ApiVersion 2015-08-19
$searchAPIKey = (Invoke-AzureRmResourceAction -Action listAdminKeys -ResourceId $resource.ResourceId -ApiVersion 2015-08-19 -Force).PrimaryKey

Quando si chiama Invoke-AzureRmResourceAction, è possibile osservare errori temporanei. In questo scenario, è consigliabile implementare il modello di base seguente per la chiamata al cmdlet .

$searchServiceURL = "https://$searchServiceName.search.windows.net"
$resource = Get-AzureRmResource -ResourceType "Microsoft.Search/searchServices" -ResourceGroupName $searchResourceGroupName -ResourceName  $searchServiceName -ApiVersion 2015-08-19

    # Adding in a retry
    $Stoploop = $false
    $Retrycount = 0
 
    do {
        try   {
               $searchAPIKey = (Invoke-AzureRmResourceAction -Action listAdminKeys -ResourceId $resource.ResourceId -ApiVersion 2015-08-19 -Force).PrimaryKey
               write-verbose "Invoke-AzureRmResourceAction on $resource.ResourceId completed"
               $Stoploop = $true
              }
        catch {
               if ($Retrycount -gt 3)
                 {
                  Write-verbose "Could not Invoke-AzureRmResourceAction on $resource.ResourceId after 3 retrys."
                  $Stoploop = $true
                 }
               else  
                 {
                  Write-verbose "Could not Invoke-AzureRmResourceAction on $resource.ResourceId retrying in 30 seconds..."
                  Start-Sleep -Seconds 30
                  $Retrycount = $Retrycount + 1
                 }
               }
        }
    While ($Stoploop -eq $false)

Nota

Il tentativo di ripetere la chiamata è fino a tre volte, dormendo per 30 secondi ogni volta.

Esempio 2: se il runbook esegue frequenti chiamate remote

Se il runbook esegue frequenti chiamate remote, potrebbe verificarsi problemi di runtime temporanei. Creare una funzione che implementa la logica di ripetizione dei tentativi per ogni chiamata effettuata e passare la chiamata da eseguire come blocco di script da eseguire.

Function ResilientRemoteCall {

         param(
               $scriptblock
               )
        
         $Stoploop = $false
         $Retrycount = 0
 
         do {
             try   {
                    Invoke-Command -scriptblock $scriptblock 
                    write-verbose "Invoked $scriptblock completed"
                    $Stoploop = $true
                   }
             catch {
                    if ($Retrycount -gt 3)
                      {
                       Write-verbose "Invoked $scriptblock failed 3 times and we will not try again."
                       $Stoploop = $true
                      }
                    else  
                      {
                       Write-verbose "Invoked $scriptblock failed  retrying in 30 seconds..."
                       Start-Sleep -Seconds 30
                       $Retrycount = $Retrycount + 1
                      }
                    }
             }
         While ($Stoploop -eq $false)
}

È quindi possibile passare ogni chiamata remota alla funzione come

ResilientRemoteCall { Get-AzVm }
oppure

ResilientRemoteCall { $searchAPIKey = (Invoke-AzureRmResourceAction -Action listAdminKeys -ResourceId $resource.ResourceId -ApiVersion 2015-08-19 -Force).PrimaryKey}

Usare più sottoscrizioni

Il runbook deve essere in grado di funzionare con le sottoscrizioni. Per gestire più sottoscrizioni, ad esempio, il runbook usa il cmdlet Disable-AzContextAutosave. Tale cmdlet garantisce che il contesto di autenticazione non venga recuperato da un altro runbook in esecuzione nello stesso sandbox.

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

# Connect to Azure with system-assigned managed identity
$AzureContext = (Connect-AzAccount -Identity).context

# set and store context
$AzureContext = Set-AzContext -SubscriptionName $AzureContext.Subscription `
    -DefaultProfile $AzureContext

$childRunbookName = 'childRunbookDemo'
$resourceGroupName = "resourceGroupName"
$automationAccountName = "automationAccountName"

$startParams = @{
    ResourceGroupName     = $resourceGroupName
    AutomationAccountName = $automationAccountName
    Name                  = $childRunbookName
    DefaultProfile        = $AzureContext
}
Start-AzAutomationRunbook @startParams

Se si vuole che il runbook venga eseguito con l'identità gestita assegnata dal sistema, lasciare invariato il codice. Se si preferisce usare un'identità gestita assegnata dall'utente, procedere come illustrato di seguito:

  1. Dalla riga 5 rimuovere $AzureContext = (Connect-AzAccount -Identity).context,
  2. Sostituirlo con $AzureContext = (Connect-AzAccount -Identity -AccountId <ClientId>).contexte
  3. Immettere l'ID client.

Usare uno script personalizzato

Nota

Non è in genere possibile eseguire script personalizzati e runbook nell'host con un agente di Log Analytics installato.

Per usare uno script personalizzato:

  1. Creare un account di Automazione.
  2. Distribuire il ruolo di lavoro ibrido per runbook.
  3. Se si usa un computer Linux, sono necessari privilegi elevati. Accedi per disattivare i controlli delle firme.

Testare un runbook

Quando si testa un Runbook, viene eseguita la Versione bozza e le azioni eseguite vengono completate. Non viene creata alcuna cronologia dei processi, ma l'output e i flussi di avviso e di errore vengono visualizzati nel riquadro Outputtest. I messaggi per il flusso dettagliato vengono visualizzati solo se nel pannello di output la variabile VerbosePreference è impostata su Continue.

Anche se la versione bozza è in esecuzione, il runbook viene comunque eseguito normalmente ed esegue qualsiasi azione sulle risorse nell'ambiente. Per questo motivo, è necessario testare i runbook solo con risorse non di produzione.

Nota

Tutte le azioni di esecuzione del runbook vengono registrate nel log attività dell'account di automazione con il nome dell'operazione Crea un processo Automazione di Azure. Tuttavia, l'esecuzione del runbook in un riquadro di test in cui viene eseguita la versione bozza del runbook verrà registrata nei log attività con il nome dell'operazione Scrivere una bozza di runbook Automazione di Azure. Selezionare la scheda Operation and JSON (Operazione e JSON) per visualizzare l'ambito che termina con .. /runbooks/(runbook name)/draft/testjob.

La procedura per testare ogni tipo di runbook è la stessa. Non esiste alcuna differenza nei test tra l'editor di testo e l'editor grafico nel portale di Azure.

  1. Aprire la versione bozza del runbook nell'editor di testo o o nell'editor grafico.
  2. Fare clic su Test per aprire la pagina Test .
  3. Se il runbook dispone di parametri, questi ultimi verranno elencati nel riquadro sinistro, dove è possibile specificare valori da usare per il test.
  4. Se si desidera eseguire il test su un ruolo di lavoro ibrido per runbook, per l'opzione Impostazioni di esecuzione specificare il valore Ruolo di lavoro ibrido e selezionare il nome del gruppo di destinazione. In caso contrario, mantenere l'impostazione predefinita Azure per eseguire il test nel cloud.
  5. Fare clic su Avvia per avviare il test.
  6. È possibile usare i pulsanti nel riquadro Output per arrestare o sospendere un flusso di lavoro PowerShell o un runbook grafico durante il test. Quando si sospende il runbook, esso completa l'attività corrente prima di essere sospeso. Una volta che il runbook viene sospeso, è possibile arrestarlo o riavviarlo.
  7. Esaminare l'output del runbook nel riquadro Output .

Pubblicare un runbook

Quando si crea o si importa un nuovo runbook, è necessario pubblicarlo prima di poterlo eseguire. Ogni runbook in Automazione di Azure include una versione bozza e una versione pubblicata. È possibile eseguire solo la versione pubblicata, mentre è possibile modificare solo la versione bozza. La versione pubblicata non è interessata dalle modifiche apportate alla versione bozza. Quando la versione bozza deve essere resa disponibile, è possibile pubblicarla, sovrascrivendo la versione pubblicata corrente con la versione bozza.

Pubblicare un runbook nel portale di Azure

  1. Nel portale di Azure cercare e selezionare Account di Automazione.
  2. Nella pagina Account di automazione selezionare l'account di Automazione dall'elenco.
  3. Aprire il runbook nell'account di Automazione.
  4. Fare clic su Modifica.
  5. Fare clic su Pubblica e quindi selezionare in risposta al messaggio di verifica.

Pubblicare un runbook con PowerShell

Usare il cmdlet Publish-AzAutomationRunbook per pubblicare il runbook.

$accountName = "MyAutomationAccount"
$runbookName = "Sample_TestRunbook"
$rgName = "MyResourceGroup"

$publishParams = @{
    AutomationAccountName = $accountName
    ResourceGroupName     = $rgName
    Name                  = $runbookName
}
Publish-AzAutomationRunbook @publishParams

Pianificare un runbook nel portale di Azure

Dopo che il runbook è stato pubblicato, è possibile pianificarlo per l'operazione:

  1. Nel portale di Azure cercare e selezionare Account di Automazione.
  2. Nella pagina Account di automazione selezionare l'account di Automazione dall'elenco.
  3. Selezionare il runbook dall'elenco dei runbook.
  4. Selezionare Pianificazioni in Risorse.
  5. Selezionare Aggiungi pianificazione.
  6. Nel riquadro Pianifica runbook selezionare Collega una pianificazione al runbook.
  7. Scegliere Crea una nuova pianificazione nel riquadro Pianificazione .
  8. Immettere un nome, una descrizione e altri parametri nel riquadro Nuova pianificazione .
  9. Dopo aver creato la pianificazione, evidenziarla e fare clic su OK. A questo punto la pianificazione dovrebbe essere collegata a runbook.
  10. Nella cassetta postale cercare un messaggio di notifica relativo allo stato del runbook.

Ripristinare un runbook eliminato

È possibile ripristinare un runbook eliminato tramite script di PowerShell. Per ripristinare un runbook, verificare che siano soddisfatte le condizioni seguenti:

  • I runbook da ripristinare sono stati eliminati negli ultimi 29 giorni.
  • L'account di Automazione per il runbook esistente.
  • L'autorizzazione del ruolo Collaboratore automazione viene concessa all'identità gestita assegnata dal sistema dell'account di Automazione.

Script di PowerShell

  • Eseguire lo script di PowerShell come processo nell'account di Automazione per ripristinare i runbook eliminati.
  • Scaricare lo script di PowerShell da GitHub. In alternativa, è possibile importare lo script di PowerShell denominato Ripristina runbook di Automazione da Runbook Gallery. Specificare il nome del runbook da ripristinare ed eseguirlo come processo in Automazione di Azure per ripristinare i runbook eliminati.
  • Scaricare lo script da GitHub o importare lo script di PowerShell denominato List Deleted Automation Runbook from Runbook Gallery per identificare i nomi dei runbook eliminati negli ultimi 29 giorni.

Ottenere gli stati del processo

Visualizzare gli stati nel portale di Azure

I dettagli della gestione dei processi in Automazione di Azure sono presenti in Processi. Quando si è pronti per visualizzare i processi di runbook, accedere all'account di automazione nel portale di Azure. A destra è possibile visualizzare un riepilogo di tutti i processi di runbook in Statistiche del processo.

Job Statistics tile

Il riepilogo visualizza un conteggio e una rappresentazione grafica dello stato per ogni processo eseguito.

Se si fa clic sul riquadro, viene visualizzata la pagina Processi, che include un elenco riepilogativo di tutti i processi eseguiti. In questa pagina vengono visualizzati lo stato, il nome del runbook e l'ora di inizio e di completamento di ogni processo.

Screenshot of the Jobs page.

È possibile filtrare l'elenco dei processi selezionando Filtra processi. Applicare il filtro in base a un runbook specifico, allo stato del processo oppure a una scelta nell'elenco a discesa e specificare l'intervallo di tempo per la ricerca.

Filter job status

In alternativa, è possibile visualizzare i dettagli di riepilogo dei processi per un runbook specifico selezionandolo nella pagina Runbook nel proprio account di Automazione e quindi selezionare il riquadro Processi. Viene visualizzata la pagina Processi. In tale pagina è possibile fare clic su un record del processo per visualizzarne i dettagli e l'output.

Screenshot of the Jobs page with the Errors button highlighted.

Recuperare gli stati del processo tramite PowerShell

Usare Get-AzureAutomationJob per recuperare i processi creati per un runbook e i dettagli di un processo specifico. Se si avvia un runbook usando Start-AzAutomationRunbook, viene restituito il processo risultante. Usare Get-AzAutomationJobOutput per recuperare l'output del processo.

Nell'esempio seguente viene ottenuto l'ultimo processo per un runbook di esempio e ne vengono visualizzati lo stato, i valori specificati per i parametri del runbook e l'output del processo.

$getJobParams = @{
    AutomationAccountName = 'MyAutomationAccount'
    ResourceGroupName     = 'MyResourceGroup'
    Runbookname           = 'Test-Runbook'
}
$job = (Get-AzAutomationJob @getJobParams | Sort-Object LastModifiedDate -Desc)[0]
$job | Select-Object JobId, Status, JobParameters

$getOutputParams = @{
    AutomationAccountName = 'MyAutomationAccount'
    ResourceGroupName     = 'MyResourceGroup'
    Id                    = $job.JobId
    Stream                = 'Output'
}
Get-AzAutomationJobOutput @getOutputParams

L'esempio seguente recupera l'output di un processo specifico e restituisce ogni record. Se è presente un'eccezione per uno dei record, lo script scrive l'eccezione anziché il valore. Questo comportamento è utile perché le eccezioni possono fornire informazioni aggiuntive che possono non essere registrate normalmente durante l'output.

$params = @{
    AutomationAccountName = 'MyAutomationAccount'
    ResourceGroupName     = 'MyResourceGroup'
    Stream                = 'Any'
}
$output = Get-AzAutomationJobOutput @params

foreach ($item in $output) {
    $jobOutParams = @{
        AutomationAccountName = 'MyAutomationAccount'
        ResourceGroupName     = 'MyResourceGroup'
        Id                    = $item.StreamRecordId
    }
    $fullRecord = Get-AzAutomationJobOutputRecord @jobOutParams

    if ($fullRecord.Type -eq 'Error') {
        $fullRecord.Value.Exception
    } else {
        $fullRecord.Value
    }
}

Passaggi successivi