Skill

Automate Datadog Operations with Rube MCP

Automates Datadog metrics, logs, monitors, dashboards, events, downtimes, hosts, and traces through Composio's toolkit via Rube MCP.

Works with datadogrube

78
Spark score
out of 100
Updated 5 months ago
Version 1.0.0
Models
universal

Add to Favorites

Why it matters

Streamline your Datadog monitoring and observability by automating key tasks. This asset leverages Rube MCP to query metrics, search logs, manage monitors, and handle events, reducing manual effort and improving response times.

Outcomes

What it gets done

01

Query and explore Datadog metrics using various aggregations and filters.

02

Search and analyze log entries across different indexes with flexible queries.

03

Create, update, mute, and inspect Datadog monitors for alerts.

04

Post events and schedule downtimes for maintenance or incidents.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-datadog-automation | bash

Overview

Datadog Automation via Rube MCP

A skill automating Datadog metrics, logs, monitors, dashboards, events, and downtimes via Composio's Rube MCP toolkit. Use for Datadog metric queries, log search, monitor/dashboard management, or event/downtime operations through Rube MCP with an active Datadog connection.

What it does

This skill automates Datadog monitoring and observability operations through Composio's Datadog toolkit via Rube MCP (https://rube.app/mcp, no API keys needed). Prerequisites: Rube MCP connected with RUBE_SEARCH_TOOLS available, an active Datadog connection via RUBE_MANAGE_CONNECTIONS with toolkit datadog (completed via the returned auth link if not yet ACTIVE), and always calling RUBE_SEARCH_TOOLS first for current tool schemas.

Its core workflows: querying and exploring metrics (DATADOG_LIST_METRICS and DATADOG_QUERY_METRICS using Datadog's aggregation:metric_name{tag_filters} query syntax with Unix-epoch-second from/to timestamps and valid aggregations avg/sum/min/max/count); searching and analyzing logs (DATADOG_LIST_LOG_INDEXES and DATADOG_SEARCH_LOGS using Datadog's log query syntax like service:web status:error, paginated via cursor/page tokens); managing monitors (DATADOG_LIST_MONITORS, DATADOG_GET_MONITOR, DATADOG_CREATE_MONITOR, DATADOG_UPDATE_MONITOR, DATADOG_MUTE_MONITOR/DATADOG_UNMUTE_MONITOR) - noting monitor type must match the query type, message supports @mentions like @slack-channel/@pagerduty, and muting suppresses notifications while the monitor keeps evaluating; managing dashboards (DATADOG_LIST_DASHBOARDS, DATADOG_GET_DASHBOARD, DATADOG_UPDATE_DASHBOARD, DATADOG_DELETE_DASHBOARD) - noting dashboard IDs are alphanumeric strings, layout_type cannot be changed after creation, and deletion is permanent; creating events and managing downtimes (DATADOG_CREATE_EVENT with markdown text and alert_type severity, DATADOG_CREATE_DOWNTIME scoped by tags like host:web01) - noting omitting end creates an indefinite downtime, so an end time should always be set for planned maintenance; and managing hosts and traces (DATADOG_LIST_HOSTS, DATADOG_GET_TRACE_BY_ID).

Common patterns cover monitor query syntax for metric alerts (threshold expressions like avg(last_5m):avg:system.cpu.user{env:prod} > 90) and log alerts (rollup-based count expressions), tag filtering (key:value format, AND logic via {host:web01,env:prod}, wildcard support like host:web*), and pagination (page/page_size or offset-based depending on endpoint, continuing until all results are retrieved). Known pitfalls: most endpoints use Unix epoch seconds not milliseconds (some accept ISO 8601 - check the tool schema), query syntax varies by type (metric vs log vs monitor), and Datadog enforces per-endpoint rate limits requiring backoff on HTTP 429 and batching where possible.

avg(last_5m):avg:system.cpu.user{env:prod} > 90

When to use - and when NOT to

Use this skill when querying/exploring metrics, searching logs, managing monitors, managing dashboards, creating events or downtimes, or inspecting hosts/traces in Datadog through Rube MCP.

Inputs and outputs

Inputs: a Datadog observability operation request (metric query, log search, monitor/dashboard management, event/downtime creation, or host/trace lookup) with the relevant query syntax and parameters.

Outputs: metric time series data, log search results, created/updated/muted monitors, dashboard definitions, posted events or scheduled downtimes, and host/trace data - resolved using correct query syntax, timestamp formats, and pagination.

Integrations

Rube MCP (https://rube.app/mcp), Composio's Datadog toolkit (DATADOG_QUERY_METRICS, DATADOG_SEARCH_LOGS, DATADOG_CREATE_MONITOR, DATADOG_UPDATE_DASHBOARD, DATADOG_CREATE_DOWNTIME, DATADOG_GET_TRACE_BY_ID), Datadog OAuth.

Who it's for

Teams automating Datadog observability workflows - metrics, logs, monitors, dashboards, events/downtimes, and infrastructure/trace inspection - via Rube MCP.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.