본문으로 건너뛰기
cccskills
무료GitHub에 공개

datadog-automation

Automate Datadog tasks via Rube MCP (Composio): query metrics, search logs, manage monitors/dashboards, create events and downtimes. Always search tools first for current schemas.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

연동 도구Datadog
설치 방법 보기

포함된 파일(1)

  • SKILL.md9.2 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Datadog Automation via Rube MCP

Automate Datadog monitoring and observability operations through Composio's Datadog toolkit via Rube MCP.

Toolkit docs: composio.dev/toolkits/datadog

Prerequisites

  • Rube MCP must be connected (RUBE_SEARCH_TOOLS available)
  • Active Datadog connection via RUBE_MANAGE_CONNECTIONS with toolkit datadog
  • Always call RUBE_SEARCH_TOOLS first to get current tool schemas

Setup

Get Rube MCP: Add https://rube.app/mcp as an MCP server in your client configuration. No API keys needed — just add the endpoint and it works.

  1. Verify Rube MCP is available by confirming RUBE_SEARCH_TOOLS responds
  2. Call RUBE_MANAGE_CONNECTIONS with toolkit datadog
  3. If connection is not ACTIVE, follow the returned auth link to complete Datadog authentication
  4. Confirm connection status shows ACTIVE before running any workflows

Core Workflows

1. Query and Explore Metrics

When to use: User wants to query metric data or list available metrics

Tool sequence:

  1. DATADOG_LIST_METRICS - List available metric names [Optional]
  2. DATADOG_QUERY_METRICS - Query metric time series data [Required]

Key parameters:

  • query: Datadog metric query string (e.g., avg:system.cpu.user{host:web01})
  • from: Start timestamp (Unix epoch seconds)
  • to: End timestamp (Unix epoch seconds)
  • q: Search string for listing metrics

Pitfalls:

  • Query syntax follows Datadog's metric query format: aggregation:metric_name{tag_filters}
  • from and to are Unix epoch timestamps in seconds, not milliseconds
  • Valid aggregations: avg, sum, min, max, count
  • Tag filters use curly braces: {host:web01,env:prod}
  • Time range should not exceed Datadog's retention limits for the metric type

2. Search and Analyze Logs

When to use: User wants to search log entries or list log indexes

Tool sequence:

  1. DATADOG_LIST_LOG_INDEXES - List available log indexes [Optional]
  2. DATADOG_SEARCH_LOGS - Search logs with query and filters [Required]

Key parameters:

  • query: Log search query using Datadog log query syntax
  • from: Start time (ISO 8601 or Unix timestamp)
  • to: End time (ISO 8601 or Unix timestamp)
  • sort: Sort order ('asc' or 'desc')
  • limit: Number of log entries to return

Pitfalls:

  • Log queries use Datadog's log search syntax: service:web status:error
  • Search is limited to retained logs within the configured retention period
  • Large result sets require pagination; check for cursor/page tokens
  • Log indexes control routing and retention; filter by index if known

3. Manage Monitors

When to use: User wants to create, update, mute, or inspect monitors

Tool sequence:

  1. DATADOG_LIST_MONITORS - List all monitors with filters [Required]
  2. DATADOG_GET_MONITOR - Get specific monitor details [Optional]
  3. DATADOG_CREATE_MONITOR - Create a new monitor [Optional]
  4. DATADOG_UPDATE_MONITOR - Update monitor configuration [Optional]
  5. DATADOG_MUTE_MONITOR - Silence a monitor temporarily [Optional]
  6. DATADOG_UNMUTE_MONITOR - Re-enable a muted monitor [Optional]

Key parameters:

  • monitor_id: Numeric monitor ID
  • name: Monitor display name
  • type: Monitor type ('metric alert', 'service check', 'log alert', 'query alert', etc.)
  • query: Monitor query defining the alert condition
  • message: Notification message with @mentions
  • tags: Array of tag strings
  • thresholds: Alert threshold values (critical, warning, ok)

Pitfalls:

  • Monitor type must match the query type; mismatches cause creation failures
  • message supports @mentions for notifications (e.g., @slack-channel, @pagerduty)
  • Thresholds vary by monitor type; metric monitors need critical at minimum
  • Muting a monitor suppresses notifications but the monitor still evaluates
  • Monitor IDs are numeric integers

4. Manage Dashboards

When to use: User wants to list, view, update, or delete dashboards

Tool sequence:

  1. DATADOG_LIST_DASHBOARDS - List all dashboards [Required]
  2. DATADOG_GET_DASHBOARD - Get full dashboard definition [Optional]
  3. DATADOG_UPDATE_DASHBOARD - Update dashboard layout or widgets [Optional]
  4. DATADOG_DELETE_DASHBOARD - Remove a dashboard (irreversible) [Optional]

Key parameters:

  • dashboard_id: Dashboard identifier string
  • title: Dashboard title
  • layout_type: 'ordered' (grid) or 'free' (freeform positioning)
  • widgets: Array of widget definition objects
  • description: Dashboard description

Pitfalls:

  • Dashboard IDs are alphanumeric strings (e.g., 'abc-def-ghi'), not numeric
  • layout_type cannot be changed after creation; must recreate the dashboard
  • Widget definitions are complex nested objects; get existing dashboard first to understand structure
  • DELETE is permanent; there is no undo

5. Create Events and Manage Downtimes

When to use: User wants to post events or schedule maintenance downtimes

Tool sequence:

  1. DATADOG_LIST_EVENTS - List existing events [Optional]
  2. DATADOG_CREATE_EVENT - Post a new event [Required]
  3. DATADOG_CREATE_DOWNTIME - Schedule a maintenance downtime [Optional]

Key parameters for events:

  • title: Event title
  • text: Event body text (supports markdown)
  • alert_type: Event severity ('error', 'warning', 'info', 'success')
  • tags: Array of tag strings

Key parameters for downtimes:

  • scope: Tag scope for the downtime (e.g., host:web01)
  • start: Start time (Unix epoch)
  • end: End time (Unix epoch; omit for indefinite)
  • message: Downtime description
  • monitor_id: Specific monitor to downtime (optional, omit for scope-based)

Pitfalls:

  • Event text supports Datadog's markdown format including @mentions
  • Downtimes scope uses tag syntax: host:web01, env:staging
  • Omitting end creates an indefinite downtime; always set an end time for maintenance
  • Downtime monitor_id narrows to a single monitor; scope applies to all matching monitors

6. Manage Hosts and Traces

When to use: User wants to list infrastructure hosts or inspect distributed traces

Tool sequence:

  1. DATADOG_LIST_HOSTS - List all reporting hosts [Required]
  2. DATADOG_GET_TRACE_BY_ID - Get a specific distributed trace [Optional]

Key parameters:

  • filter: Host search filter string
  • sort_field: Sort hosts by field (e.g., 'name', 'apps', 'cpu')
  • sort_dir: Sort direction ('asc' or 'desc')
  • trace_id: Distributed trace ID for trace lookup

Pitfalls:

  • Host list includes all hosts reporting to Datadog within the retention window
  • Trace IDs are long numeric strings; ensure exact match
  • Hosts that stop reporting are retained for a configured period before removal

Common Patterns

Monitor Query Syntax

Metric alerts:

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

Log alerts:

logs("service:web status:error").index("main").rollup("count").last("5m") > 10

Tag Filtering

  • Tags use key:value format: host:web01, env:prod, service:api
  • Multiple tags: {host:web01,env:prod} (AND logic)
  • Wildcard: host:web*

Pagination

  • Use page and page_size or offset-based pagination depending on endpoint
  • Check response for total count to determine if more pages exist
  • Continue until all results are retrieved

Known Pitfalls

Timestamps:

  • Most endpoints use Unix epoch seconds (not milliseconds)
  • Some endpoints accept ISO 8601; check tool schema
  • Time ranges should be reasonable (not years of data)

Query Syntax:

  • Metric queries: aggregation:metric{tags}
  • Log queries: field:value pairs
  • Monitor queries vary by type; check Datadog documentation

Rate Limits:

  • Datadog API has per-endpoint rate limits
  • Implement backoff on 429 responses
  • Batch operations where possible

Quick Reference

TaskTool SlugKey Params
Query metricsDATADOG_QUERY_METRICSquery, from, to
List metricsDATADOG_LIST_METRICSq
Search logsDATADOG_SEARCH_LOGSquery, from, to, limit
List log indexesDATADOG_LIST_LOG_INDEXES(none)
List monitorsDATADOG_LIST_MONITORStags
Get monitorDATADOG_GET_MONITORmonitor_id
Create monitorDATADOG_CREATE_MONITORname, type, query, message
Update monitorDATADOG_UPDATE_MONITORmonitor_id
Mute monitorDATADOG_MUTE_MONITORmonitor_id
Unmute monitorDATADOG_UNMUTE_MONITORmonitor_id
List dashboardsDATADOG_LIST_DASHBOARDS(none)
Get dashboardDATADOG_GET_DASHBOARDdashboard_id
Update dashboardDATADOG_UPDATE_DASHBOARDdashboard_id, title, widgets
Delete dashboardDATADOG_DELETE_DASHBOARDdashboard_id
List eventsDATADOG_LIST_EVENTSstart, end
Create eventDATADOG_CREATE_EVENTtitle, text, alert_type
Create downtimeDATADOG_CREATE_DOWNTIMEscope, start, end
List hostsDATADOG_LIST_HOSTSfilter, sort_field
Get traceDATADOG_GET_TRACE_BY_IDtrace_id

Powered by Composio

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Automate ActiveCampaign tasks via Rube MCP (Composio): manage contacts, tags, list subscriptions, automation enrollment, and tasks. Always search tools first for current schemas.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

davepoon/buildwithclaude3.7천2026년 10월 19일 업데이트

Pull the ads a competitor is running right now on Meta (Facebook/Instagram) and Google, then extract the hooks, offers, CTAs and landing pages worth modelling. Use when writing ad copy, planning creative tests, choosing a landing page angle, or when the user asks "what is X advertising", "what ads does X run", "find competitor ad hooks". Reads live Ad Library and Ads Transparency data through the Tracetify MCP; falls back to a manual Ad Library walkthrough when the connector is absent.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

davepoon/buildwithclaude3.7천2026년 10월 19일 업데이트

Analytics your AI agent can actually use. Track, analyze, run A/B experiments, and optimize across all your projects via CLI. Includes a growth playbook so your agent knows HOW to grow, not just what to track.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

davepoon/buildwithclaude3.7천2026년 10월 19일 업데이트

Teaches when to recall from long-term memory before acting and when to save durable decisions, corrections and failures afterwards. Use when a memory tool or MCP memory server is connected but the agent is not using it consistently, when the user complains that the assistant forgets preferences, conventions or past decisions between sessions, or when setting up persistent memory for a project. Works with any memory backend: a folder of Markdown files, a local MCP server, or a managed service.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

davepoon/buildwithclaude3.7천2026년 10월 19일 업데이트

Audit local AI coding-agent sessions with agenttrace for cost, tokens, tool failures, latency, anomalies, health, diffs, and CI gates.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

davepoon/buildwithclaude3.7천2026년 10월 19일 업데이트

Checks which private files (.env, keys, secrets) Claude Code and its subagents reached in this project, whether a value came into an agent's context, and which key to change, by running the open source agentwhy CLI over the session records Claude Code already keeps on disk. Use when the user asks whether the agent or a subagent read their .env or other secrets, which private files a session touched, whether a key leaked into the conversation, or which key to rotate. Runs locally and never prints a secret value.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

davepoon/buildwithclaude3.7천2026년 10월 19일 업데이트

davepoon의 스킬 모두 보기

이 스킬의 문제 신고