/observability

name: "azure-mcp-observability"
description: >
  The read-only observability half of the azure-mcp connector — the monitor,
  resourcehealth, applens, and advisor namespaces: Azure Monitor metrics, Log
  Analytics KQL, alert-rule state, platform health states, AppLens detectors, and
  Advisor recommendation categories, plus the degraded-resource investigation order.
when_to_use: >-
  When investigating a degraded or unhealthy Azure resource, querying logs/metrics, checking
  alerts, or triaging Advisor recommendations across a subscription. Use when: azure monitor, log
  analytics, kql query, azure metrics, azure alerts, resource health, azure resource down,
  applens, azure diagnostics, azure advisor, or azure recommendations.

Azure Observability & Diagnostics

This skill covers the monitoring, diagnostics, and health side of the `azure-mcp` connector: the `monitor`, `resourcehealth`, `applens`, and `advisor` namespaces. All four are **read-only** — they observe and report on Azure, they never change it.

Tool names follow the Azure MCP Server's namespace convention (`azmcp` / `azure_mcp` prefixes, e.g. tools grouped under `monitor`, `resourcehealth`, `applens`, `advisor`). Describe and invoke them by capability — the connector exposes one or more tools per namespace.

Anti-triggers

• **Estimating a price or checking quota headroom** — use

`azure-mcp-cost-and-capacity`. Advisor's *Cost* recommendations do belong here; a meter rate or a usage limit does not.

• **Application logs held outside Azure** — KQL reaches Log Analytics

workspaces only. Better Stack log search is `betterstack-logging`.

• **Microsoft 365 sign-in, mailbox, or licensing signals** — unless

they are ingested into a workspace, use `microsoft-graph-querying` or `cipp-security`.

• **Alerting an MSP NOC rather than Azure** — an Azure Monitor alert

rule is not the RMM alert queue (`atera`, `ncentral`) or an uptime incident (`betterstack-incidents`).

Namespace surface

`monitor` — Azure Monitor

Azure Monitor is the workhorse. Capabilities:

• **Metrics** — query platform and custom metric series for a resource (CPU, memory, request count, latency, throttling, etc.) over a time window.
• **Log Analytics / KQL** — run Kusto Query Language queries against a Log Analytics workspace. This is how you reach application traces, `AzureDiagnostics`, `AzureActivity`, sign-in logs, and any custom tables.
• **Alerts** — list configured alert rules and their current fired/resolved state.

KQL queries should be scoped tightly — always include a `where TimeGenerated > ago(...)` bound and a column projection so results stay small and fast.

`resourcehealth` — Resource Health

Reports the platform-reported availability of an Azure resource: `Available`, `Degraded`, `Unavailable`, or `Unknown`, plus the reason (platform-initiated, customer-initiated, or unplanned) and any active health events on the subscription. This is the fastest "is it Azure's fault" check.

`applens` — AppLens diagnostics

AppLens runs Microsoft's deep diagnostic detectors against a resource — the same engine behind the Azure portal's "Diagnose and solve problems" blade. Use it when Resource Health says a resource is degraded but you need the *why*: which detector tripped, what dependency failed, what the recommended mitigation is.

`advisor` — Azure Advisor

Azure Advisor produces recommendations across five categories: **Cost**, **Security**, **Reliability**, **Performance**, and **Operational Excellence**. Each recommendation has an impact rating (High/Medium/Low) and affected resources. The `advisor` namespace lists and filters these.

Workflow patterns

Investigating a degraded resource

1. **`resourcehealth`** — check the resource's current health state. If `Unavailable`/`Degraded` with a *platform-initiated* reason, it's an Azure-side event — capture the event ID and stop; there's nothing to fix on the customer side beyond waiting or failing over. 2. **`applens`** — if Resource Health is `Available` or the reason is customer-initiated, run AppLens detectors to find the failing detector and its dependency chain. 3. **`monitor` metrics** — pull the relevant metric series around the incident window (e.g. CPU/memory for a VM, HTTP 5xx and response time for an App Service) to confirm and quantify the impact. 4. **`monitor` Log Analytics** — run a targeted KQL query against the workspace for error-level traces in the same window. 5. **`monitor` alerts** — confirm whether an alert rule already fired; if the incident was real but no alert fired, that's an alerting-coverage gap worth flagging.

Pulling KQL query results

When asked for log data, write a bounded KQL query and run it through the `monitor` namespace's Log Analytics capability:

AzureDiagnostics
| where TimeGenerated > ago(1h)
| where Level == "Error"
| project TimeGenerated, ResourceId, OperationName, Message
| order by TimeGenerated desc
| take 100

Always include a time bound, a `project` to limit columns, and a `take`/`limit`. Report the workspace and time range alongside results so the query is reproducible.

Triaging Advisor recommendations

1. **`advisor`** — list recommendations for the subscription, then group by category. 2. Sort within each category by impact (High first) and by number of affected resources. 3. Separate **Reliability** and **Security** findings (act soon) from **Cost** and **Operational Excellence** (plan and batch). 4. For each High-impact item, name the affected resources and the recommended action — but remember the connector cannot apply the fix. Report the recommendation; the actual remediation happens through a separate, write-capable path.

Alert-coverage review

Use `monitor` alerts to list configured alert rules for a subscription, then compare against the critical resources you see via the `group` and `subscription` namespaces. Resources with no alert rule covering availability or error rate are