Datadog Metrics Skill
Query metrics and explore dashboards in Datadog.
Tools
| Tool | Description |
|---|---|
query_metrics | Execute metric queries with aggregations |
list_metrics | List available metrics matching a pattern |
get_metric_metadata | Get metadata for a specific metric |
list_dashboards | List all available dashboards |
get_dashboard | Get dashboard definition and widgets |
Example Queries
Query CPU utilization for network devices → query_metrics(query="avg:system.cpu.user{role:network_device} by {host}", time_range="1h") Get interface traffic metrics → query_metrics(query="sum:network.bytes_rcvd{*} by {interface}", time_range="4h") List all network-related metrics → list_metrics(pattern="network.*") Get a specific dashboard → get_dashboard(dashboard_id="abc-def-123")
Workflows
Network Performance Monitoring
- Query interface utilization:
query_metrics(query="avg:network.bytes_sent{*} by {host,interface}") - Check error rates:
query_metrics(query="sum:network.errors{*} by {host}") - Monitor latency percentiles:
query_metrics(query="p99:network.latency{*}") - Compare against SLA thresholds
Infrastructure Health Assessment
- List all infrastructure metrics:
list_metrics(pattern="system.*") - Query CPU/memory across fleet:
query_metrics(query="avg:system.cpu.user{*} by {availability_zone}") - Identify outliers and degradation
- Check dashboard for historical trends
Capacity Planning
- Query peak utilization:
query_metrics(query="max:system.disk.used{*} by {host}", time_range="30d") - Calculate growth rate
- Forecast exhaustion dates
- Generate capacity report
Prerequisites
DD_API_KEYDatadog API keyDD_APP_KEYDatadog application keyDD_SITEDatadog site (optional, defaults to datadoghq.com)
Server
This skill uses the datadog-mcp server via remote MCP transport.
Failure Behavior
- On a tool error (timeout, unreachable host, malformed response), report the failure and its error message directly to the user rather than fabricating or guessing at results.
- For a confirmed read-only call, check connectivity and retry once if appropriate. For any call that changes state or sends a message, a timeout does not prove the action failed: inspect current state or delivery status before retrying, preserve the required approval/change gates, and do not repeat an action whose outcome is unknown.


