Skip to main content
HealOps queries Azure Monitor Log Analytics through the public Query REST API to surface relevant logs during alert investigations. Each query is bounded by a take clause so result sets stay capped at a safe row limit.

Prerequisites

  • Azure subscription with at least one Log Analytics Workspace collecting logs
  • A Microsoft Entra ID (Azure AD) app registration authorized to query the workspace
  • The Log Analytics Reader role granted on the workspace (or its resource group / subscription) to the app’s service principal
  • Network access from the HealOps environment to https://api.loganalytics.io (or the sovereign cloud equivalent) over HTTPS

Setup

Option 1: Environment variables

Add to your .env:

Option 2: Persistent store

Credentials are persisted to ~/.config/healops/integrations.json with 0o600 permissions:

Getting credentials

1. Find the Workspace ID

  1. In the Azure portal, open Log Analytics workspaces and select your workspace.
  2. On the workspace Overview page, copy Workspace ID (a GUID).

2. Register an Azure AD application

  1. Open Microsoft Entra IDApp registrationsNew registration.
  2. Give the app a name (e.g. healops-log-analytics) and register it as a single-tenant app.
  3. From the app’s Overview page, copy the Application (client) ID and the Directory (tenant) ID.
  4. Open Certificates & secretsNew client secret, copy the secret value (it is shown only once).

3. Grant Log Analytics Reader on the workspace

  1. Open the Log Analytics workspace in the portal.
  2. Go to Access control (IAM)AddAdd role assignment.
  3. Pick the Log Analytics Reader role and assign it to the service principal created above.

4. Obtain a bearer token (client credentials flow)

Set the resulting token as AZURE_LOG_ANALYTICS_TOKEN. Tokens expire (usually after 60 minutes) — see the Token rotation note in Security best practices.

Investigation tool

HealOps exposes one tool against an Azure Monitor workspace:

query_azure_monitor_logs

POSTs a KQL query to <endpoint>/v1/workspaces/<workspace_id>/query and returns the first table flattened into row dicts. Arguments the planner supplies:
  • query — KQL query text. If omitted, HealOps falls back to AppTraces | order by TimeGenerated desc | take <limit>.
  • time_range_minutes — sent as the timespan (PT<N>M); defaults to 60.
  • limit — per-query row cap; defaults to 50 and is clamped to max_results (hard limit 200).
HealOps always appends a | take <limit> clause to the query if one is not present, so the workspace never returns more rows than the configured cap.

Verify

Expected output:
The verify step is a credential-shape check — it does not call the workspace. To exercise the live path, point HealOps at a synthetic alert that names azure as the source and inspect the resulting evidence.

Example KQL queries

Recent application errors:
Error count by severity over the last hour:
Failed dependency calls correlated with a request id:

Troubleshooting

Security best practices

  • Use a dedicated app registration for HealOps — do not reuse a personal token or a broadly-scoped service principal.
  • Grant only Log Analytics Reader on the workspace; HealOps only needs read access to query data.
  • Keep the client secret out of source control — store it in .env or in a secret manager and only export it long enough to mint a token.
  • Rotate the bearer token before its 60-minute expiry. Long-lived deployments should re-mint the token from the client secret on a schedule rather than pasting a static token into .env.
  • The integration is read-only: HealOps only issues POST /v1/workspaces/<id>/query requests with a take-bounded KQL string.