Pausar automáticamente un trabajo mediante PowerShell y Azure Functions o Azure Automation

Algunas aplicaciones requieren un enfoque de procesamiento de flujos (por ejemplo, a través de Azure Stream Analytics), pero no es estrictamente necesario ejecutarse continuamente. Entre las razones se incluyen las siguientes:

  • Datos de entrada que llegan según una programación (por ejemplo, la parte superior de la hora)
  • Un volumen disperso o bajo de datos entrantes (pocos registros por minuto)
  • Procesos empresariales que se benefician de las funcionalidades de período de tiempo, pero que se ejecutan por lotes por esencia (por ejemplo, finanzas o recursos humanos)
  • Demostraciones, prototipos o pruebas que implican trabajos de larga duración a baja escala

La ventaja de no ejecutar estos trabajos continuamente es el ahorro de costes, ya que los trabajos de análisis de flujos se facturan por unidad de flujo a lo largo del tiempo.

En este artículo se explica cómo configurar la pausa automática para un trabajo de Azure Stream Analytics. Configura una tarea que pausa y reanuda automáticamente un trabajo según una programación. El término pausar significa que el trabajo estado está detenido para evitar cualquier facturación.

En este artículo se describe el diseño general, los componentes necesarios y algunos detalles de implementación.

Nota:

Hay desventajas para pausar automáticamente un trabajo. Las principales desventajas son la pérdida de funcionalidades en tiempo real o de baja latencia y los posibles riesgos de permitir que el trabajo pendiente del evento de entrada crezca sin supervisar mientras se pausa un trabajo. Las organizaciones no deben considerar la pausa automática para la mayoría de los escenarios de producción que se ejecutan a escala.

Diseño

En el ejemplo de este artículo, quiere que el trabajo se ejecute durante N minutos antes de pausarlo durante M minutos. Cuando el trabajo está en pausa, los datos de entrada no se consumen y se acumulan en sentido ascendente. Una vez iniciado el trabajo, se pone al día con ese retraso y procesa los datos que van llegando antes de volver a apagarse.

Diagrama que muestra el comportamiento de un trabajo en pausa automáticamente a lo largo del tiempo.

Cuando el trabajo se está ejecutando, la tarea no debe detener el trabajo hasta que sus métricas sean correctas. Las métricas de interés son el trabajo pendiente de entrada y la referencia. Comprobará que ambos están en su línea base durante al menos N minutos. Este comportamiento se traduce en dos acciones:

  • Un trabajo detenido se reinicia después de M minutos
  • Un trabajo en ejecución se detiene en cualquier momento después de N minutos, en cuanto sus métricas de trabajo pendiente y referencia son correctas.

Diagrama que muestra los posibles estados de un trabajo.

Por ejemplo, considere que N = 5 minutos y M = 10 minutos. Con esta configuración, un trabajo tiene al menos 5 minutos para procesar todos los datos que se hayan recibido en 15. El posible ahorro de costos es de hasta un 66 %.

Para reiniciar el trabajo, utilice la opción de inicioCuando se detuvo por última vez. Esta opción indica a Stream Analytics que procese todos los eventos que quedaron pendientes en niveles superiores desde que se detuvo el trabajo.

Hay dos advertencias que se deben tener en cuenta en esta situación. En primer lugar, el trabajo no puede permanecer detenido más tiempo que el período de retención del flujo de entrada. Si ejecuta el trabajo solo una vez al día, debe asegurarse de que el período de retención para los eventos sea superior a un día. En segundo lugar, es necesario que el trabajo se haya iniciado al menos una vez para que se acepte el modo Cuando se detuvo por última vez (o de lo contrario, literalmente nunca se ha detenido antes). Por lo tanto, la primera ejecución de un trabajo debe ser manual o debe extender el script para cubrir ese caso.

El último aspecto a tener en cuenta es que estas acciones son idempotentes. A continuación, puede repetirlos a voluntad sin efectos secundarios, tanto para facilitar el uso como para la resistencia.

Componentes

Llamadas a API

En este artículo se prevé la necesidad de interactuar con Stream Analytics en los siguientes aspectos:

  • Obtenga el estado actual del trabajo (administración de recursos de Stream Analytics):
    • Si el trabajo se está ejecutando:
      • Obtenga la hora desde que se inició el trabajo (registros).
      • Obtenga los valores de métricas actuales (métricas).
      • Si procede, detenga el trabajo (administración de recursos de Stream Analytics).
    • Si el trabajo se detiene:
      • Obtenga la hora desde que el trabajo se detuvo (registros).
      • Si procede, inicie el trabajo (administración de recursos de Stream Analytics).

Para la administración de recursos de Stream Analytics, puede utilizar la API REST, el .NET SDK o una de las bibliotecas CLI (Azure CLI o PowerShell).

Para las métricas y los registros, todo en Azure está centralizado en Azure Monitor, con una elección similar de superficies API. Los registros y las métricas siempre tienen un retraso de 1 a 3 minutos cuando se consultan las API. Así, establecer N en 5 suele significar que el trabajo se ejecuta entre 6 y 8 minutos en realidad.

Otra consideración es que las métricas siempre se emiten. Si se detiene el trabajo, la API devuelve registros vacíos. Tiene que limpiar la salida de las llamadas API para centrarse en los valores pertinentes.

Lenguaje de scripting

En este artículo se implementa la pausa automática en PowerShell. La primera razón de esta elección es que PowerShell ahora es multiplataforma. Se puede ejecutar en cualquier sistema operativo, lo que facilita las implementaciones. La segunda razón es que PowerShell toma y devuelve objetos en lugar de cadenas. Los objetos hacen que el análisis y el procesamiento sea más fácil para las tareas de automatización.

En PowerShell, usaremos el módulo Az de PowerShell, que incluye Az.Monitor y Az.StreamAnalytics, para todo lo que necesita:

Servicio de hospedaje

Para hospedar su tarea PowerShell, necesita un servicio que ofrezca ejecuciones programadas. Hay muchas opciones, pero estas son dos sin servidor:

Si no le importan las soluciones provisionales, Azure Automation es la forma más sencilla de implementar la tarea. Pero en este artículo, primero escribirá un script local para poder compararlo. Una vez que tenga un script en funcionamiento, impleméntelo tanto en Funciones como en una cuenta de Automation.

Herramientas para desarrolladores

Recomendamos encarecidamente el desarrollo local a través de Visual Studio Code, tanto para Functions como para Stream Analytics. El uso de un entorno de desarrollo local le permite usar el control de código fuente y le ayuda a repetir fácilmente las implementaciones. Sin embargo, por motivos de brevedad, en este artículo se muestra el proceso en Azure Portal.

Escritura local del script de PowerShell

La mejor manera de desarrollar el script es localmente. Dado que PowerShell es multiplataforma, puede escribir el script y probarlo en cualquier sistema operativo. En Windows, puede usar Terminal Windows con PowerShell 7 y Azure PowerShell.

El script final que usa este artículo está disponible para Azure Functions y Azure Automation. Es diferente del siguiente script en que está conectado al entorno de hospedaje (Functions o Automation). Este artículo trata ese aspecto más adelante. En primer lugar, recorrerá una versión del script que solo se ejecuta localmente.

Este script se escribe intencionadamente en un formato sencillo, por lo que todos pueden entenderlo.

En la parte superior, establezca los parámetros necesarios y compruebe el estado inicial del trabajo:


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

Si el trabajo está en marcha, se comprueba entonces si el trabajo ha estado en marcha al menos N minutos. También comprueba su trabajo pendiente y su referencia.


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

Si se detiene el trabajo, compruebe el registro para buscar cuándo se produjo la última acción de Stop Job:


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

Al final, registre la finalización del trabajo:


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

Opción 1: Hospedar la tarea en Azure Functions

Como referencia, el equipo de Azure Functions mantiene una completa guía para desarrolladores de PowerShell.

En primer lugar, necesita una nueva aplicación de funciones. Una aplicación de funciones es similar a una solución que puede hospedar varias funciones.

Puede obtener el procedimiento completo, pero lo esencial es entrar en el Azure Portal y crear una nueva aplicación de función con:

  • Publicar: Código
  • Entorno de ejecución: PowerShell Core
  • Versión: 7+

Después de aprovisionar la aplicación de funciones, comience con su configuración general.

Identidad administrada para Azure Functions

La función necesita permisos para iniciar y detener el trabajo de Stream Analytics. Puede asignar estos permisos mediante una identidad administrada.

El primer paso es habilitar una identidad administrada asignada por el sistema para la función, siguiendo este procedimiento.

Ahora puede conceder los permisos adecuados a esa identidad en el trabajo de Stream Analytics que desea pausar automáticamente. Para esta tarea, en el área del portal para el trabajo de Análisis de flujos (no el de la función), en Control de acceso (IAM), añada una asignación de función al rol Contribuidor para un miembro de tipo Identidad administrada. Seleccione el nombre de la función anterior.

Captura de pantalla de la configuración del control de acceso para un trabajo de Stream Analytics.

En el script de PowerShell, puede agregar una comprobación para asegurarse de que la identidad administrada está establecida correctamente. (El script final está disponible en GitHub).


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

Agregue información de registro para asegurarse de que la función se está activando:


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

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

Parámetros de Azure Functions

La mejor manera de pasar los parámetros al script en Functions es usar la configuración de la aplicación de la aplicación de funciones como variables de entorno.

El primer paso es seguir el procedimiento para definir sus parámetros como Ajustes de la aplicación en la página de la aplicación de la función. Necesita:

NOMBRE Valor
maxInputBacklog Cantidad de trabajos pendientes que tolera al detener el trabajo. En el recuento de eventos, 0 es un buen punto de partida.
maxWatermark Cantidad de referencias que tolera al detener el trabajo. En segundos, 10 es un buen punto de partida en unidades de streaming bajas.
restartThresholdMinute M: el tiempo (en minutos) hasta que se reinicia un trabajo detenido
stopThresholdMinute N: el tiempo (en minutos) de finalización hasta que se detiene un trabajo en ejecución. El trabajo pendiente de entrada debe permanecer en 0 durante ese tiempo.
subscriptionId Identificador de suscripción (no el nombre) del trabajo de Stream Analytics que se va a pausar automáticamente.
resourceGroupName Nombre del grupo de recursos del trabajo de Stream Analytics que se pausará automáticamente.
asaJobName Nombre del trabajo de Stream Analytics que se va a pausar automáticamente.

A continuación, actualice el script de PowerShell para cargar las variables en consecuencia:

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

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

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

Requisitos del módulo de PowerShell

De la misma manera que tenía que instalar Azure PowerShell localmente para usar los comandos de Stream Analytics (como Start-AzStreamAnalyticsJob), debe agregarlo al host de la aplicación de funciones:

  1. En la página de la aplicación de funciones, en Functions, seleccione Archivos de aplicacióny, a continuación, seleccione requirements.psd1.
  2. Quite la marca de comentario de la línea 'Az' = '6.*'.
  3. Para que ese cambio surta efecto, reinicie la aplicación.

Captura de pantalla de la configuración de los archivos de la aplicación de funciones.

Creación de la función

Después de finalizar toda esa configuración, puede crear la función específica dentro de la aplicación de funciones para ejecutar el script.

En el portal, desarrolle una función que se desencadene en un temporizador. Asegúrese de que la función se activa cada minuto con 0 */1 * * * *, y que lee "en el segundo 0 de cada 1 minuto".

Captura de pantalla de la creación de una función de desencadenador de temporizador en una aplicación de funciones.

Si es necesario, puede cambiar el valor del temporizador en Integration actualizando la programación.

Captura de pantalla de la configuración de integración de una función.

A continuación, en código y pruebas, puede copiar el script en run.ps1 y probarlo. También puede copiar el script completo de GitHub. La lógica de negocios se movió a una instrucción try/catch para generar errores adecuados si se produce un error durante el procesamiento.

Captura de pantalla del panel Código y prueba de la función.

Puede comprobar que todo funciona correctamente seleccionando Prueba/Ejecución en el panel Código y prueba. También puede comprobar el panel Monitor, pero siempre llega con un par de ejecuciones de retraso.

Captura de pantalla del resultado de una ejecución correcta.

Establecimiento de una alerta en la ejecución de la función

Por último, quiere recibir una notificación a través de una alerta si la función no se ejecuta correctamente. Las alertas tienen un pequeño costo, pero pueden evitar situaciones más costosas.

En la página de la aplicación de funciones, en Registros, ejecute la consulta siguiente. Devuelve todas las ejecuciones incorrectas en los últimos 5 minutos.

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

En el editor de consultas, seleccione Nueva regla de alertas. En el panel que se abre, defina Medición como:

  • Medida: failedCount
  • Tipo de agregación: Total
  • Granularidad de agregación: 5 minutos

A continuación, configure la Lógica de alerta tal como se indica abajo:

  • Operador: Mayor que
  • Valor del umbral: 0
  • Frecuencia de evaluación: 5 minutos

Desde allí, reutilice o cree un nuevo grupo de acciones. A continuación, complete la configuración.

Para comprobar que ha configurado correctamente la alerta, puede agregar throw "Testing the alert" en cualquier lugar del script de PowerShell y, a continuación, esperar 5 minutos para recibir un correo electrónico.

Opción 2: Hospedar la tarea en Azure Automation

En primer lugar, necesita una nueva cuenta de Automation. Una cuenta de Automation es similar a una solución que puede hospedar varios runbooks.

Para ver el procedimiento, consulte la guía de inicio rápido Creación de una cuenta de Automation mediante Azure Portal. Puede elegir utilizar una identidad administrada asignada por el sistema directamente en la pestaña Avanzado.

Como referencia, el equipo de Automatización dispone de un tutorial para iniciarse en los runbooks de PowerShell.

Parámetros de Azure Automation

Con un runbook, puede usar la sintaxis de parámetros clásica de PowerShell para pasar argumentos:

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

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

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

Identidad administrada para Azure Automation

La cuenta de Automation debe haber recibido una identidad administrada durante el aprovisionamiento. Pero si es necesario, puede habilitar una identidad administrada mediante este procedimiento.

Al igual que hizo para la función, debe conceder los permisos adecuados en el trabajo de Stream Analytics que desea pausar automáticamente.

Para conceder los permisos, en el área del portal para el trabajo de Análisis de flujos (no la página de Automation), en Control de acceso (IAM), añada una asignación de funciones al rol Contribuidor para un miembro de tipo Identidad administrada. Seleccione el nombre de la cuenta de Automation anterior.

Captura de pantalla de la configuración del control de acceso para un trabajo de Stream Analytics.

En el script de PowerShell, puede agregar una comprobación para asegurarse de que la identidad administrada está establecida correctamente. (El script final está disponible en GitHub).

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

Creación del Runbook

Después de finalizar la configuración, puede crear el runbook específico dentro de la cuenta de Automation para ejecutar el script. Aquí no es necesario agregar Azure PowerShell como requisito. Ya está integrado.

En el portal, en automatización de procesos, seleccione Runbooks. A continuación, seleccione Crear un runbook, seleccione PowerShell como tipo de runbook y elija cualquier versión superior a 7 como versión (de momento, 7.1 (versión prelimina)).

Ahora puede pegar el script y probarlo. Puede copiar el script completo de GitHub. La lógica de negocios se movió a una instrucción try/catch para generar errores adecuados si se produce un error durante el procesamiento.

Captura de pantalla del editor de scripts del runbook en Azure Automation.

Puede comprobar que todo está conectado correctamente en el panel Prueba.

Después, debe publicar el trabajo (seleccionando Publicar) para que pueda vincular el runbook a una programación. La creación y vinculación de la programación es un proceso sencillo. Ahora es un buen momento para recordar que hay soluciones alternativas para lograr intervalos de programación inferiores a 1 hora.

Por último, puede configurar una alerta. El primer paso es habilitar los registros mediante los ajustes de diagnóstico de la cuenta de Automation. El segundo paso consiste en capturar errores mediante una consulta como hizo para Functions.

Resultado

En el trabajo de Stream Analytics, puede comprobar que todo se ejecuta según lo previsto en dos lugares.

Este es el registro de actividad:

Captura de pantalla de los registros del trabajo de Stream Analytics.

Y estas son las métricas:

Captura de pantalla de las métricas del trabajo de Stream Analytics.

Después de comprender el script, volver a trabajar para ampliar su ámbito es una tarea sencilla. Se puede actualizar fácilmente para que tenga como destino una lista de trabajos en lugar de uno solo. Puede definir y procesar ámbitos más grandes mediante etiquetas, grupos de recursos o incluso suscripciones completas.

Obtener soporte técnico

Para obtener más ayuda, consulte la página de preguntas y respuestas de Microsoft sobre Azure Stream Analytics.

Pasos siguientes

Ha aprendido los conceptos básicos del uso de PowerShell para automatizar la administración de trabajos de Azure Stream Analytics. Para más información, vea los siguientes artículos:

  • Last updated on