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 coverage gaps.

Constraints & caveats

• Read-only. Nothing in this skill changes Azure. You can read metrics, logs, health, and recommendations — you cannot acknowledge alerts, apply Advisor fixes, or restart resources. If asked to act on a finding, state that clearly and hand off.
• Scope. Most calls need a subscription ID and often a resource ID or resource group — resolve these first via the subscription and group namespaces (see the cost-and-capacity skill).
• KQL workspace access. Log Analytics queries require the service principal to have Reader inheritance to the workspace. If a query returns an authorization error, the workspace is outside the granted RBAC scope.
• Advisor freshness. Advisor recommendations refresh periodically, not in real time — a recommendation may lag a recent change by hours.