Generated banner for Azure Diagnostics
Generated logo for Azure Diagnostics

Azure Diagnostics

MicrosoftOfficialCreated by Microsoft

  • Skill
  • Workflow
  • Cloud and DevOps
  • MIT
  • Low risk
  • Has scripts

From the author

Debug Azure production issues using AppLens, Azure Monitor, resource health, and safe triage, including evidence-only diagnosis without live access. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deployment failure, troubleshoot container apps, container app 503 or target port mismatch, troubleshoot functions, function telemetry missing or stopped after a config/connection-string change, troubleshoot AKS, VM RDP, Linux SSH, VM black screen, can't connect to VM, reset VM password, NSG or firewall blocking, kubectl cannot connect, kube-system/CoreDNS failures, pod pending, crashloop, node not ready, upgrade failures, analyze logs, KQL, insights, image pull failures, cold start issues, health probe failures, resource health, root cause of errors, troubleshoot event hubs, troubleshoot service bus, messaging SDK error, AMQP connection failure, message lock lost, lock renewal during long-running processing, service bus dead letter.
— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Azure Diagnostics provides a structured, authoritative approach to investigating and resolving production issues across various Azure services. It emphasizes a systematic flow: identifying symptoms, checking resource health, reviewing logs, analyzing metrics, and investigating recent changes. The skill supports both live troubleshooting via Azure CLI and AppLens, as well as evidence-only analysis when live access is restricted. It includes specialized guidance for App Service, Container Apps, Azure Functions, AKS, VMs, and Messaging services, ensuring consistent root-cause analysis.

What it does

  • Provides a standardized diagnostic workflow for Azure production environments.
  • Integrates with AppLens and Azure Monitor for automated issue detection and log analysis.
  • Offers service-specific troubleshooting paths for App Service, AKS, VMs, and more.
  • Supports evidence-only diagnosis for secure, offline troubleshooting scenarios.
  • Includes KQL query patterns for deep-dive log and resource health analysis.
  • Facilitates the use of bundled diagnostic scripts for efficient data collection.

When to use it

  • When investigating production incidents like high CPU, deployment failures, or service crashes.
  • When troubleshooting connectivity issues such as RDP/SSH failures or network blocking.
  • When diagnosing Kubernetes-specific issues like pod crashloops or image pull failures.
  • When analyzing missing telemetry or messaging errors in Event Hubs and Service Bus.
  • When performing root-cause analysis on unhealthy or degraded Azure resources.

Advantages

  • Reduces mean time to resolution (MTTR) with a clear, step-by-step diagnostic process.
  • Ensures consistent troubleshooting practices across different Azure service types.
  • Supports secure workflows by allowing diagnosis without requiring live environment access.
  • Leverages powerful built-in tools like AppLens and Azure Resource Graph for rapid insights.
  • Provides actionable remediation steps based on identified symptoms.

Usage examples

“Troubleshoot my App Service that is experiencing high CPU usage.”
The agent will initiate the App Service diagnostic flow, run the appservice-diagnostics script, check metrics, and guide you through profiling via Kudu.
“Why is my Azure VM unreachable via SSH?”
The agent will follow the VM connectivity troubleshooting guide, checking NSG rules, firewall status, and VM agent health.
“Analyze these logs to find why my Container App is failing to pull the image.”
The agent will perform an evidence-only analysis of the provided logs to identify image pull errors or registry authentication issues.
“Check the health of my AKS cluster and identify why pods are in a crashloop.”
The agent will check resource health, query logs for the affected pods, and route to the AKS-specific troubleshooting documentation.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/microsoft/azure-diagnostics/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip azure-diagnostics.zip -d .agents/skills

Documentation by Microsoft

Azure Diagnostics

AUTHORITATIVE GUIDANCE — MANDATORY COMPLIANCE

This document is the official source for debugging and troubleshooting Azure production issues. Follow these instructions to diagnose and resolve common Azure service problems systematically.

Triggers

Activate this skill when user wants to:

  • Debug or troubleshoot production issues

  • Diagnose errors in Azure services

  • Analyze application logs or metrics

  • Fix image pull, cold start, or health probe issues

  • Investigate why Azure resources are failing

  • Find root cause of application errors

  • Troubleshoot App Service issues (high CPU, deployment failures, crashes, slow responses, TLS/custom domains)

  • Respond to prompts like "troubleshoot app service", "app service high CPU", or "app service deployment failure"

  • Troubleshoot Azure Function Apps (invocation failures, timeouts, binding errors)

  • Find the App Insights or Log Analytics workspace linked to a Function App

  • Troubleshoot AKS clusters, nodes, pods, ingress, or Kubernetes networking issues

  • Troubleshoot Azure VM connectivity issues (RDP/SSH failures, port 3389/22 timeouts, NSG or firewall blocking, credential resets)

  • Troubleshoot Azure Messaging SDK issues (Event Hubs, Service Bus connection failures, AMQP errors, message lock issues)

  • Root-cause a symptom that looks like a healthy-runtime-but-wrong-destination problem (e.g., telemetry/messages stop flowing to the expected resource after a config change) — invoke this skill for the matrix even when MCP tools could answer the surface question alone

Rules

  1. Start with systematic diagnosis flow

  2. Use supplied evidence first. If the user requests evidence-only analysis or prohibits live Azure access, do not query or modify Azure. Diagnose from the supplied logs, metrics, and timeline; identify assumptions and provide optional verification steps.

  3. Use AppLens (MCP) for AI-powered diagnostics when available

  4. Check resource health before deep-diving into logs

  5. Select appropriate troubleshooting guide based on service type

  6. Document findings and attempted remediation steps

  7. Prefer bundled diagnostic scripts over ad hoc calls for permitted live collection when identifiers are known. If supplied evidence suffices or live access is prohibited, don't run them; otherwise run the applicable script first.

  8. Route AKS incidents to the dedicated AKS troubleshooting document

  9. Keep baseline AKS diagnostics available even when the optional aks-skills add-on is absent, declined, or unsupported by the host


Quick Diagnosis Flow

  1. Identify symptoms - What's failing?

  2. Check resource health - Is Azure healthy?

  3. Review logs - What do logs show?

  4. Analyze metrics - Performance patterns?

  5. Investigate recent changes - What changed?


Troubleshooting Guides by Service

ServiceCommon IssuesReference
Container AppsImage pull failures, cold starts, health probes, port mismatchescontainer-apps/
App ServiceHigh CPU, deployment failures, crashes, slow responses, TLS/custom domainsapp-service/
Function AppsApp details, invocation failures, timeouts, binding errors, cold starts, missing app settingsfunctions/
AKSCluster access, nodes, kube-system, scheduling, crash loops, ingress, DNS, upgradesAKS Troubleshooting
ComputeVM RDP/SSH connectivity, NSG/firewall blocks, credential resets, VM agent/tooling issuesVM Connectivity Troubleshooting
MessagingEvent Hubs & Service Bus SDK errors, AMQP failures, message lock, connectivityMessaging Troubleshooting

Routing

  • Keep Container Apps and Function Apps diagnostics in this parent skill.

  • Route active AKS incidents, AKS-specific intake, evidence gathering, and remediation guidance to AKS Troubleshooting.

  • Route Azure VM RDP/SSH connectivity, NSG/firewall, credential reset, and VM agent troubleshooting to VM Connectivity Troubleshooting.

  • Route Azure Messaging SDK troubleshooting (Event Hubs, Service Bus) to Messaging Troubleshooting.


Quick Reference

Common Diagnostic Commands
# Check resource health
az resource show --ids RESOURCE_ID
# View activity log
az monitor activity-log list -g RG --max-events 20
# Container Apps logs
az containerapp logs show --name APP -g RG --follow
# Function App logs (query App Insights traces)
az monitor app-insights query --apps APP-INSIGHTS -g RG \
  --analytics-query "traces | where timestamp > ago(1h) | order by timestamp desc | take 50"
AppLens (MCP Tools)

For AI-powered diagnostics, use:

mcp_azure_mcp_applens
  intent: "diagnose issues with <resource-name>"
  command: "diagnose"
  parameters:
    resourceId: "<resource-id>"

Provides:
- Automated issue detection
- Root cause analysis
- Remediation recommendations
Azure Monitor (MCP Tools)

For querying logs and metrics:

mcp_azure_mcp_monitor
  intent: "query logs for <resource-name>"
  command: "logs_query"
  parameters:
    workspaceId: "<workspace-id>"
    query: "<KQL-query>"

See kql-queries.md for common diagnostic queries.


Check Azure Resource Health

Using MCP
mcp_azure_mcp_resourcehealth
  intent: "check health status of <resource-name>"
  command: "get"
  parameters:
    resourceId: "<resource-id>"
Using CLI
# Check specific resource health
az resource show --ids RESOURCE_ID

# Check recent activity
az monitor activity-log list -g RG --max-events 20

References

Files

troubleshooting/aks/references/inspektor-gadget.md

Inspektor Gadget (IG) Reference

Use Inspektor Gadget for low-level node/pod diagnostics when kubectl is insufficient.

Run Script

Invoke gadgets with the run-ig script (scripts/run-ig.sh / scripts/run-ig.ps1). It resolves the node from the pod, injects the pinned IG image/version, applies the default --timeout for the gadget type, adds the k8s filters, and handles the tcpdump variant. You still choose which gadget (see the Symptom-to-Gadget Map) and interpret the output.

./scripts/run-ig.sh --gadget trace_dns --pod <pod> --ns <ns>       # node auto-resolved
./scripts/run-ig.sh --gadget snapshot_process --node <node>        # node-wide
./scripts/run-ig.sh --gadget trace_dns --pod <pod> --ns <ns> --dry-run
.\scripts\run-ig.ps1 -Gadget trace_dns -Pod <pod> -Namespace <ns>

Options (bash flags below; PowerShell uses PascalCase equivalents: -Gadget, -Pod, -Namespace/-Ns, -Node, -Container, -Timeout, -Filter, -Pf, -IgVersion, -DryRun): --gadget (required); target --pod/--ns or --node; --container; --timeout <s> override; --filter <arg> (repeatable IG-flag passthrough, e.g. --filter --max-entries --filter 20); --pf "<expr>" (tcpdump only); --ig-version <tag>; --dry-run. Default timeout by gadget name: snapshot_*/top_* → 5s, trace_*/profile_*/tcpdump → 30s. Returns the gadget JSON (pcap-ng for tcpdump) plus a Ran gadget X on node Y summary. IG version is pinned to v0.51.0 in the scripts.

Approval required: IG uses kubectl debug --profile=sysadmin (a privileged debug pod). A request naming the gadget and target counts as approval; otherwise ask before running. Use --dry-run to preview.

Common Filters

The k8s scope filters and --timeout are set by the script. Pass any other IG flag below via its repeatable --filter, e.g. --filter --max-entries --filter 20.

FilterDescription
--max-entries <n>Max entries per batch for top/profile gadgets
--map-fetch-interval <dur>Map fetch interval for top (except top_process) and profile gadgets (default 1000ms)
--interval <dur>Reporting interval for top_process only (e.g. 5s)
--syscall-filters <list>Comma-separated syscalls for traceloop (e.g. open,connect,accept). Always specify to limit data volume

Tip: For top/profile, keep --map-fetch-interval ≤ half of --timeout to collect ≥1 batch. top_process uses --interval instead of --map-fetch-interval.

Gadget Catalog

Networking
GadgetTypeWhat It DoesWhen To Use
trace_dnstraceTrace DNS queries and responses with latencyDNS failures, NXDOMAIN, SERVFAIL, slow resolution, intermittent DNS
trace_tcptraceTrace TCP connect/accept/close eventsConnection refused, timeouts, unexpected drops, mapping pod connectivity
trace_tcpretranstraceTrace TCP retransmissionsNetwork congestion, lossy links, high latency between pods/services
trace_bindtraceTrace socket bind callsPort conflicts, address-already-in-use errors
trace_snitraceTrace TLS SNI (Server Name Indication) valuesHTTPS routing issues, ingress TLS debugging, mTLS problems
snapshot_socketsnapshotList open sockets (TCP/UDP/Unix)Port conflicts, listening ports, connection leaks, ECONNREFUSED
tcpdumpspecialCapture raw packets in pcap-ng formatDeep packet inspection, protocol-level debugging, reproducing network issues
tcpdump gadget

Run via --gadget tcpdump; the script sets -o pcap-ng and pipes to tcpdump -nvr - when available. Use --pf "<expr>" for tcpdump filters (e.g., port 80, host 10.0.0.1); --pf is only valid for the tcpdump gadget.

./scripts/run-ig.sh --gadget tcpdump --pod <pod> --ns <ns> --pf "port 80"
Process & Workload
GadgetTypeWhat It DoesWhen To Use
snapshot_processsnapshotList running processes in pod/nodePID pressure, unknown processes, verifying entrypoint, CrashLoopBackOff
trace_exectraceTrace process execution (execve calls)CrashLoopBackOff (what actually runs), unexpected child processes, security audit
trace_oomkilltraceTrace OOM kill events with victim detailsOOMKilled pods — see which process was killed, memory usage at kill time
trace_signaltraceTrace signals delivered to processesUnexpected SIGKILL/SIGTERM, liveness probe kills, graceful shutdown issues
top_processtopRank processes by CPU/memory usageIdentifying resource-hungry processes inside a pod or across a node
profile_cpuprofileCPU profiling via stack samplingHigh CPU usage investigation, finding hot code paths
tracelooptraceRecord syscalls as a flight recorderCatch-all for intermittent issues. Always use --syscall-filters (e.g., open,connect,accept) to limit data volume
File & Storage
GadgetTypeWhat It DoesWhen To Use
trace_opentraceTrace openat syscallMissing config/secret files (ENOENT), permission denied (EACCES), startup failures
trace_fsslowertraceTrace slow filesystem operationsSlow disk I/O, PVC performance issues, NFS/Azure Disk latency
top_filetopRank files by read/write activityIdentifying I/O-heavy files, noisy log writers, disk pressure diagnosis
Security & Audit
GadgetTypeWhat It DoesWhen To Use
trace_capabilitiestraceTrace Linux capability checksPermission denied from dropped capabilities, SecurityContext debugging

Symptom-to-Gadget Map

SymptomGadget(s)
DNS resolution failurestrace_dns
Connection refused / timeouttrace_tcp + snapshot_socket
Silent connection dropstrace_tcpretrans
High network latencytrace_tcpretrans
TLS / HTTPS routing issuestrace_sni
Port already in usetrace_bind + snapshot_socket
CrashLoopBackOff (unknown cause)trace_exec + trace_open
OOMKilled podstrace_oomkill + top_process
Pod killed unexpectedlytrace_signal
PID pressure on nodesnapshot_process + top_process
"Too many open files"top_file
Missing config / secret mounttrace_open
Slow disk / PVC performancetrace_fsslower + top_file
Permission denied (capabilities)trace_capabilities
High CPU (unknown cause)profile_cpu + top_process
Deep packet inspectiontcpdump
Catch-all / intermittent issuestraceloop (use --syscall-filters)

Gadget Type Reference

TypeBehaviorIG --timeout
snapshotPoint-in-time data, returns immediately--timeout 5
topAggregated view, returns quickly--timeout 5
traceStreams events in real-time--timeout 30
profileSamples over a duration--timeout 30
tcpdumpStreams pcap-ng data, pipe to tcpdump -nvr ---timeout 30

Guardrails

  • IG gadgets are read-only — they do not modify cluster or application state.

  • Invoke gadgets through run-ig (scripts/run-ig.sh / scripts/run-ig.ps1); it resolves the node and timeout. Follow the approval rule above.

  • The script picks the default --timeout by gadget type. Prefer snapshot/top for quick checks; trace/profile for behavior over time. Override with --timeout when needed.

  • For reproduction: launch a trace gadget first, then reproduce the problem. The debug pod persists after the gadget exits, so run kubectl logs <debug-pod> to retrieve the captured output afterward.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs a command-line tool

Security

What our scanner noticed· Low risk

  • Instructions that use the network
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/skills · .github/plugins/azure-skills/skills/azure-diagnostics · commit 0696600
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from .github/plugins/azure-skills/LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Also distributed in
microsoft/azure-skills

AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download azure-diagnostics.zip