fix(observability): bind managed Prometheus datasource for AIO Grafana dashboard

[bindsi]

fix(observability): bind managed Prometheus datasource for AIO Grafana dashboard

Description

The AIO sample dashboard imported by the observability component rendered every panel empty with the error Datasource ${DS_MANAGED_PROMETHEUS_INSTANCE} was not found.

The dashboard is pulled from the upstream source (Azure/azure-iot-operations samples/grafana-dashboard/aio.sample.json), which is a Grafana export. Its panels and the cluster template variable reference the datasource through the __inputs placeholder "uid": "${DS_MANAGED_PROMETHEUS_INSTANCE}". az grafana dashboard import only auto-binds that placeholder when a matching Prometheus datasource is Grafana's default, which is never the case in Azure Managed Grafana where the managed Prometheus datasource comes from the Azure Monitor Workspace integration. The placeholder was therefore imported literally and no panel could resolve its datasource.

This change resolves the managed Prometheus datasource at import time and binds every placeholder reference before importing.

Related Issue

Fixes #673

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Blueprint modification or addition
• Component modification or addition
• Documentation update
• CI/CD pipeline change
• Other (please describe):

Implementation Details

The fix lives in the import script, with a small supporting change in Terraform.

Dashboard import script

src/000-cloud/020-observability/scripts/import-grafana-dashboards.sh was reworked so the remote AIO dashboard is bound to a real datasource before import:

• Added resolve_prometheus_datasource_uid(), which lists Grafana datasources (az grafana data-source list ... -o json) and, via jq, selects the uid of the datasource whose name matches MONITOR_WORKSPACE_NAME, falling back to the first datasource of type prometheus, then to empty.
• Captured the resolved uid into DS_UID through the existing retry wrapper.
• When a uid resolves, the script now downloads the dashboard with curl -fsSL, uses jq walk(...) to replace every object .uid equal to the ${DS_MANAGED_PROMETHEUS_INSTANCE} placeholder with the resolved uid, deletes .__inputs, and imports the transformed local file. Temp files are created with mktemp -d and removed via an EXIT trap.
• When no uid resolves, the script prints a warning and imports the dashboard as-is from the remote URL, preserving the previous behavior as a fallback.
• Routed both retry() diagnostic messages to stderr so they cannot pollute the DS_UID value captured through command substitution.

Terraform provisioner

src/000-cloud/020-observability/terraform/main.tf passes MONITOR_WORKSPACE_NAME (azurerm_monitor_workspace.monitor.name) into the local-exec provisioner environment so the script can select the correct datasource by name.

Testing Performed

• Terraform plan/apply
• Blueprint deployment test
• Unit tests
• Integration tests
• Bug fix includes regression test (see Test Policy)
• Manual validation
• Other:

The jq transform was validated against the live upstream dashboard: __inputs removed, zero remaining ${DS_MANAGED_PROMETHEUS_INSTANCE} placeholders, and all 63 datasource references bound. The updated script was run against a deployed Azure Managed Grafana instance and the AIO sample dashboard imported successfully with panels bound to the managed Prometheus datasource.

Validation Steps

1. Deploy or re-run the import for src/000-cloud/020-observability (or run the script directly with GRAFANA_NAME, RESOURCE_GROUP_NAME, and MONITOR_WORKSPACE_NAME).
2. Open AIO Sample Dashboard in Azure Managed Grafana.
3. Confirm the Datasource ${DS_MANAGED_PROMETHEUS_INSTANCE} was not found error is gone and panels render. Select a value in the Cluster dropdown so the cluster="$cluster" filters resolve.

Checklist

• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed
• I have run terraform fmt on all Terraform code
• I have run terraform validate on all Terraform code
• I have run az bicep format on all Bicep code
• I have run az bicep build to validate all Bicep code
• I have checked for any sensitive data/tokens that should not be committed
• Lint checks pass (run applicable linters for changed file types)

Security Review

• No credentials, secrets, or tokens are hardcoded or logged
• RBAC and identity changes follow least-privilege principles
• No new network exposure or public endpoints introduced without justification
• Dependency additions or updates have been reviewed for known vulnerabilities
• Container image changes use pinned digests or SHA references

Both DS_UID and MONITOR_WORKSPACE_NAME are passed to jq via parameterized --arg rather than string-interpolated into the program, avoiding injection. The ${DS_MANAGED_PROMETHEUS_INSTANCE} literal sits inside single-quoted jq programs, so it is not subject to shell expansion. The remote fetch uses curl -fsSL over HTTPS. No secrets are introduced or logged.

Additional Notes

No Terraform resource changes beyond adding one environment variable to the existing local-exec provisioner; the shell script carries the fix. The fix is resilient to the upstream 2510-release dashboard change (Azure/azure-iot-operations#80) that surfaced the issue.

terraform fmt -check and terraform validate were run against the observability component and both passed. The broader lint checkbox is left unchecked pending CI running the full linter suite (tflint, shellcheck) against this branch.