New to Kestra?
Use blueprints to kickstart your first workflows.
Audit Azure Stream Analytics job state and alert Slack when a streaming job fails, degrades, or stops unexpectedly.
A Stream Analytics job that stops, fails, or degrades does not page anyone on its own, the
input stream keeps arriving and queuing up while the job sits there, and the first sign of
trouble is usually a downstream dashboard that silently stopped updating. GetJob already
reports the real jobState (Running, Degraded, Failed, Stopped, and more) and
provisioningState, this blueprint is what reads that on a schedule and turns an
unexpected state into an alert before anyone notices missing data.
probe_job_status (io.kestra.plugin.azure.streamanalytics.GetJob) reads the job's
real jobState and provisioningState, with allowFailure: true so a bad credential
or a renamed job does not stop the flow before it can be classified as PROBE_FAILED
below.classify_job_health (io.kestra.plugin.core.debug.Return) returns PROBE_FAILED when
probe_job_status produced no output at all, CRITICAL on jobState: Failed or a
Failed/Canceled provisioningState, CRITICAL or WARNING on jobState: Degraded
depending on degraded_is_critical, HEALTHY when jobState matches
expected_job_state and provisioningState is Succeeded, and WARNING for every
other combination, for example a job still Starting or Scaling.route_by_job_health (io.kestra.plugin.core.flow.Switch) branches on that status:
HEALTHY logs both real states, WARNING, CRITICAL, and PROBE_FAILED each alert
Slack with those same real states, never an invented one.log_audit_summary always runs last and logs the final classification.errors block posts to Slack if the flow itself fails outside the gate logic above.Running, not an assumption that
it still is because nobody has looked recently.jobState and provisioningState, never an
invented explanation of what went wrong.Stopped between batch windows
(expected_job_state) and for jobs with a known tolerance for brief degradation
(degraded_is_critical), instead of one fixed definition of healthy for every job.streamanalytics.GetJob and the real jobState/provisioningState values it returns.GetJob is a single point-in-time read, Stream Analytics itself has no concept of a
schedule, an expected state per job, or an alert built from what it finds. Kestra adds the
recurring check, the per-job expected-state policy, and a Slack alert built only from the
job's own reported states, all as one declarative YAML file you can version and review
like code.
Microsoft.StreamAnalytics/streamingjobs/read permission (roles/Reader on the job or
resource group is enough, this blueprint only reads).taskRunner and no Docker network to join.AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_SUBSCRIPTION_ID:
service principal credentials used by probe_job_status.
SLACK_WEBHOOK: Slack incoming webhook URL used by the alert tasks and the errors
block.
In Kestra OSS, set all five as base64-encoded environment variables, for example
SECRET_AZURE_TENANT_ID, SECRET_AZURE_SUBSCRIPTION_ID, SECRET_SLACK_WEBHOOK.
| Input | Type | Default | Allowed values |
|---|---|---|---|
resource_group |
STRING | stream-analytics-rg |
any resource group name |
job_name |
STRING | clickstream-processor |
any Stream Analytics job name |
expected_job_state |
SELECT | Running |
Running, Stopped |
degraded_is_critical |
BOOL | true |
true, false |
SLACK_WEBHOOK secrets.resource_group and job_name to a real job and run this flow manually.log_audit_summary for the real jobState and provisioningState.expected_job_state: Stopped for a job that is intentionally idle between runs.every_ten_minutes trigger.job_name values with io.kestra.plugin.core.flow.Loop
to audit every Stream Analytics job in a resource group from one flow.CRITICAL that restarts the job through the Azure CLI,
behind a manual approval task, since the Kestra plugin itself has no start or stop task
for Stream Analytics.jobState transitions over time in a Kestra KV entry to alert only when a job
newly becomes Degraded, instead of every run it stays that way.jobState and provisioningState answer different questions: a job can show
provisioningState: Succeeded while jobState is Stopped, that combination is
healthy only if expected_job_state is set to Stopped for this job.Degraded is a real, distinct jobState, not a sign the job stopped, a degraded job is
still processing, just not keeping up or not fully healthy, decide deliberately whether
that should page someone with degraded_is_critical.