datadog-query-recipes

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Datadog Query Recipes

Datadog 查询方案集

Use this skill for Langfuse production telemetry research where the main work is finding the right Datadog data path. Keep findings evidence-based and include the exact Datadog links or query shapes that support the answer.
本技能适用于Langfuse生产遥测数据研究场景,核心工作是找到正确的Datadog数据路径。所有结论需基于实证,并附上支持结论的具体Datadog链接或查询语句结构。

Required Scope

必要范围

Unless the user explicitly narrows the scope, cover every production environment:
  • prod-us
  • prod-eu
  • prod-hipaa
  • prod-jp
Query both Datadog sites when needed. Default to the EU site for
prod-eu
and the US site for the other prod environments, but verify with a small count or facet query before concluding an environment has no data.
Before querying live Datadog, load the relevant Datadog MCP guidance for the data domain you need: traces, logs, metrics, and visualizations.
除非用户明确缩小范围,否则需覆盖所有生产环境:
  • prod-us
  • prod-eu
  • prod-hipaa
  • prod-jp
必要时需查询两个Datadog站点。默认
prod-eu
使用欧盟站点,其他生产环境使用美国站点,但在得出某环境无数据的结论前,需通过小型计数或分面查询进行验证。
在查询实时Datadog数据前,请加载对应数据领域(追踪、日志、指标、可视化)的相关Datadog MCP指南。

Workflow

工作流程

  1. Identify the entity and signal: tenant ID, org ID, project ID, route, queue, service, error class, or metric.
  2. Read only the relevant reference:
    • Prod environment/site routing:
      references/environments.md
    • Public API tenant or legacy endpoint usage:
      references/public-api-tenant-usage.md
    • Queue inventory, queue consumers, and queue metrics:
      references/queue-consumers.md
  3. Start with aggregate queries, grouped by environment, service, route, queue, project, org, status, or error facets as appropriate.
  4. Fetch raw spans, logs, or traces only after aggregation identifies the cluster or sample you need.
  5. For tenant-specific HTTP usage, prefer trace correlation over single-span queries when tenant tags and route tags live on different spans.
  6. Report the windows, environments, sites, query links, and any sampling or missing-data caveats.
  1. 确定实体与信号:租户ID、组织ID、项目ID、路由、队列、服务、错误类别或指标。
  2. 仅阅读相关参考文档:
    • 生产环境/站点路由:
      references/environments.md
    • 公开API租户或旧版端点使用情况:
      references/public-api-tenant-usage.md
    • 队列清单、队列消费者及队列指标:
      references/queue-consumers.md
  3. 从聚合查询开始,根据实际情况按环境、服务、路由、队列、项目、组织、状态或错误分面进行分组。
  4. 仅在聚合分析确定所需集群或样本后,再获取原始追踪跨度(spans)、日志或追踪数据。
  5. 针对租户特定的HTTP使用情况,当租户标签与路由标签位于不同追踪跨度时,优先使用追踪关联而非单跨度查询。
  6. 报告时间范围、环境、站点、查询链接,以及任何采样或数据缺失的注意事项。

When To Use Other Skills

何时使用其他技能

  • Use
    debug-issue-with-datadog
    when a Linear issue, GitHub issue, incident report, or monitor needs root-cause analysis and patch recommendations.
  • Use
    weekly-production-review
    when the user asks for a weekly engineering overview of production bugs, pages, and incidents.
  • Use
    incident-alert-tickets
    when the research is anchored to a named production alert or monitor: look up documented causes before measuring, and record new ones only after human approval.
  • Use
    linear-bug-triage
    only after a human approves sharing measured findings in Linear.
  • 当需要针对Linear工单、GitHub问题、事件报告或监控进行根因分析及补丁建议时,请使用
    debug-issue-with-datadog
    。
  • 当用户要求获取生产环境bug、告警及事件的每周工程概览时,请使用
    weekly-production-review
    。
  • 当研究基于特定生产告警或监控时,请使用
    incident-alert-tickets
    :在进行测量前先查阅已记录的原因,仅在获得人工批准后记录新原因。
  • 仅在获得人工批准允许将测量结果分享至Linear后,方可使用
    linear-bug-triage
    。

Output Expectations

输出要求

Summarize what was checked, including:
  • Datadog site and
    env
    values covered.
  • Time windows.
  • Core filters or metrics used.
  • Count, rate, latency, queue depth, trace sample, or "No measurements found".
  • Datadog links or trace IDs that let the human rerun the query.
总结已检查的内容,包括:
  • 覆盖的Datadog站点及
    env
    值。
  • 时间范围。
  • 使用的核心过滤器或指标。
  • 计数、速率、延迟、队列深度、追踪样本,或「未找到测量数据」。
  • 可让人工重新运行查询的Datadog链接或追踪ID。