Datadog MCP 服务器

它解决什么问题

Node.js 服务一旦进入分布式链路，最棘手的不是"有没有报错"，而是报错发生在哪一段代码、经过了哪些下游依赖。传统做法是手动埋点：在每个 fetch、mysql.query、redis.get 前后写 instrument 代码，成本高且容易漏。漏掉一处，链路就在那个节点断裂，排查时只能靠日志和猜测拼凑时间线。

这个技能的目标，是把 Datadog 的自动插桩能力以 MCP 服务器的形式暴露出来，让链路追踪的接入变成一次依赖安装，而不是一轮侵入式改造。

它如何工作

核心依赖只有一个：dd-trace。它通过 Node.js 的模块加载机制，在运行时自动包装常见库的导出函数，无需修改业务代码：

• HTTP 出站调用：http、https、express、fastify 等请求会被自动打点；
• 数据库与缓存：mysql、pg、mongodb、redis 的查询语句纳入同一条 trace；
• 消息队列与异步任务：amqplib、kafkajs 的收发记录上下文传递；
• 错误传播：抛出的异常自动携带完整 trace_id，与 Datadog 后端的 service map 对应。

技能的执行路径很直接：确认运行环境具备 Node.js 与 npm，然后通过 npm install dd-trace 引入库。启动时由 dd-trace 的初始化逻辑挂载到应用生命周期，默认开启自动插桩后，所有进出流量都会生成 span，最终汇聚成可视化的调用链。

适用边界与注意点

• 仅覆盖 Node.js 运行时。Java、Python、Go 的插桩由各自的 dd-trace 库负责，这里不涉及。
• 自动插桩依赖模块加载机制，使用 webpack 将依赖打进 bundle、或在 native addon 中动态加载的库，可能无法被捕获。
• dd-trace 本身会带来少量运行时开销，高吞吐服务建议在压测中确认采样率与 span 体积。
• 采集到的 trace 需要配合 Datadog 账号与 API Key 才能在控制台查看，技能本身只负责数据的产生，不负责上报配置。
• 更多插桩细节以 Datadog 官方文档为准，不同 dd-trace 版本的默认启用列表有差异。