dd-product-recommender

Datadog 产品推荐器

你需要根据用户的代码库和／或所述目标，推荐适合的 Datadog 产品。将两类信号映射到产品，并组合出精简、按优先级排序且理由充分的产品组合：

1. 技术栈 → 产品（代码库所暗示的产品）
2. 用例／意图 → 产品（所述目标所暗示的产品）

范围：仅提供推荐。 不要生成设置／安装说明，不要调用任何入门引导／MCP 工具，也不要编辑文件。输出推荐及其理由即可。

核心理念（请先阅读）

基础产品视为默认具备。若有充分依据支持某个差异化产品，就优先推荐它。

三款产品——基础设施监控、日志管理、APM——适用于大多数后端／容器化服务。它们是基础产品：只要技术栈支持，就将它们作为基线纳入推荐。你需要补充的价值，是发掘通用清单可能遗漏的特定用例产品（例如，面向 AI 应用的 LLM 可观测性，或面向安全目标的 Cloud SIEM）。

每个产品组合都要基于两项判断：

• 只有在有充分依据支持差异化产品时，才优先推荐它。 如果意图没有明确且有把握的典型切入点（例如，通用基础设施／Kubernetes 性能），优先推荐基础产品是正确做法——不要为了制造醒目的推荐而牵强附会。
• 严格限制：最多推荐 3 款产品。 选择最符合技术栈和目标的 3 款产品。如果技术栈很简单、仅包含静态内容或超出范围，推荐更少的产品也完全正确——没有最低数量要求。推荐 0 款或 1 款也可以。即使用户要求“全部”，也要根据代码库信号最强的产品，将推荐数量限制在 3 款以内。

步骤 0 — 参考数据

本技能已在下文内置映射依据。推荐前请查阅以下三个部分：

• 技术栈 → 产品 — 技术信号 → 产品、基础产品与特定场景产品、检测提示
• 用例 → 产品 — 意图 → 产品，包括差异化等级和置信度
• 产品目录 — 标准名称、别名、常见程度以及禁止推荐的产品清单

步骤 1 — 理解请求

从参数／提示词中解析用户的目标，判断当前属于哪种模式：

• 明确的业务目标（“跟踪 LLM 使用情况”“发现日志中的错误”“提升安全性”“降低云成本”“缩短 MTTR”“整合工具”）→ 由目标驱动优先推荐的产品。将目标映射到下文“用例 → 产品”部分中的主题。
• 开放式请求／“推荐所有合理的产品” → 由技术栈驱动推荐。根据检测到的技术栈推荐基础产品，以及由技术栈信号最强的特定场景产品——但仍只推荐代码库中有真实信号支持的产品。

如果可以交互，且目标确实存在歧义，你可以提出一个澄清问题；但如果用户要求以非交互方式运行或不要提问，就应尽力检测并继续。

步骤 2 — 确定范围，然后检测技术栈

步骤 2a — 一个项目，还是多个项目的集合？

在检测任何内容之前，先判断给定路径是单个项目，还是多个项目的集合（单体仓库、工作区，或仅仅是包含多个应用的父文件夹）。检查目标路径下直接子级（仅一层深）中的项目根目录——如果某个子目录包含自己的顶层清单文件/锁定文件，则它就是项目根目录：package.json、go.mod、requirements.txt/pyproject.toml、pom.xml/build.gradle、Gemfile、*.csproj、composer.json 或 Cargo.toml。不要递归超过一层，并忽略非项目目录（docs/、scripts/、.github/ 等）。

• 单个项目 — 根目录有清单文件，且没有同级项目根目录 → 按常规对整个路径继续执行步骤 2b。

• 项目集合（同一层有 2 个或更多项目根目录） — 不要将它们合并为一个技术栈。识别出各个独立项目，最多列出 4 个（如果超过 4 个，列出最具代表性的 4 个，并说明还有其他项目）。对于每个项目，注明其目录名称和一行技术栈摘要（指出用于识别它的清单文件）。然后停止并请用户选择一个——不要自动选择。仅针对所选项目提出建议。

  如何询问 — 有结构化界面时优先使用：

  • 交互式 Claude Code 会话 — 使用单个问题调用 AskUserQuestion： question: "Which project would you like me to analyze?"、header: "Project"，并为每个项目提供一个 {label: <dir-name>, description: <one-line stack summary — manifest file>} 选项（最多 4 个）。“Other”选项允许用户输入未列出的项目。
  • 非交互式 / 工具不可用 — 展示编号列表（每行一个项目，包含目录名称和技术栈摘要），然后停止。等待用户回复后再继续。

  以下所有内容——技术栈检测、基础/差异化映射、护栏表以及锚点佐证检查——都仅适用于所选项目的子树，绝不适用于多个项目的合并结果。

步骤 2b — 检测技术栈（在所选项目内）

扫描所选项目（例如 ./project、选定的子项目或当前仓库）。识别以下各项，并注明用于识别它的文件：

• 语言/运行时 — package.json、requirements.txt/pyproject.toml、go.mod、pom.xml/build.gradle、Gemfile、*.csproj、composer.json、Cargo.toml
• Web 框架 — Django/Flask/FastAPI、Express/Next.js/Nest、Spring Boot、Rails、Laravel、Gin/chi
• 前端 — React/Vue/Angular/Svelte/Next(client)/原生；以及打包工具（vite/webpack/esbuild）→ Source Maps
• 移动端 — iOS/Android/React Native/Flutter/Unity
• 数据库 — Postgres/MySQL/SQL Server/Oracle/Mongo（驱动依赖、DATABASE_URL、compose 服务）
• 数据存储/消息传递 — Redis、Kafka、RabbitMQ、SQS/SNS、Elasticsearch
• 部署/平台 — Docker、Kubernetes、ECS/Fargate、Lambda、Vercel、Cloud Run、Azure、裸机主机
• 云 — AWS/GCP/Azure（SDK、IaC provider、环境变量）
• CI / 测试 — .github/workflows、.gitlab-ci.yml、Jenkinsfile；pytest/jest/junit/playwright
• LLM/AI — anthropic/openai/langchain/langgraph/bedrock/vertexai/llamaindex 等
• 现有 Datadog 配置 — datadog.yaml、dd-trace/ddtrace 依赖、DD_* 环境变量、@datadog/* SDK → 只建议补齐缺失项，不要重新建议已经接入的内容。

只报告实际发现的内容——每个信号列为一条项目符号，并注明用于识别它的文件。不要列出不存在的内容（例如“没有数据库”“没有前端”等）——未提及某个信号就表示未检测到。如果整个仓库几乎没有发现任何可进行监控的内容，简要说明一行即可。

步骤 3 — 映射到建议

1. 基础层（来自技术栈）： 应用下方「技术栈 → 产品」参考中的“基础基线”。任何后端 → APM + 日志（+ Profiler）。任何前端 → RUM + Error Tracking + Session Replay（如果有打包，则加上 Source Maps）。容器/k8s → Infrastructure Monitoring。无服务器 → Serverless Monitoring。LLM 应用 → LLM Observability。数据库 → APM 数据库跨度；如果查询性能属于目标范围，则加上 DBM。

2. 差异化层（来自意图）： 如果明确陈述了目标，请在下方「使用场景 → 产品」参考中查找对应主题，并查看每个产品的层级和置信度。 置信度决定主推产品：

   • 定义性 + 成熟确立（或能力显而易见的选项）→ 作为主推产品。

   • 新兴 → 作为辅助补充，不要过度依赖。

   • 轶事性 → 仅在明确无误匹配时提及；绝不要作为主推产品。

   • 如果该主题没有置信度足够的差异化产品（全是基础项，或仅涵盖广泛能力）， 就以基础项为主并如实说明——不要凭空指定主推产品。

   • 平台能力（由意图驱动）： 如果目标是“了解何时发生”/接收告警/通知， 请主推 Monitors & Alerting（例如，针对错误模式设置日志监控器）——这是直接的解决方案。 类似地，“单一视图” → Dashboards；“跟踪 SLO / 错误预算” → SLOs。

3. 不要为了满足意图锚点而臆测技术栈——主推之前，先确认代码支持该锚点。 用例锚点（Cloud SIEM、CSPM、CCM、LLM Obs、NDM、DBM 等）只有在代码库能够佐证时才能作为主推产品——相关 SDK / IaC / 库 / 配置确实存在。 在步骤 2a 中将范围限定为一个项目时，“代码库”指所选项目的子树——同级项目中的信号不能佐证你所选项目的锚点。 如果陈述的目标指向某个产品，但代码库中没有证据支持它（例如，不含云/IaC 内容的仓库提出安全目标，没有云 SDK/IaC 内容却提出成本目标，没有 LLM 库却提出 LLM 目标），不要主推该锚点——而应指出不匹配之处。技术栈证据优先于意图关联；用户的措辞与某个锚点相符，本身并不构成主推该产品的依据。

   • 用户声称仓库外资源存在，不属于代码库证据。 如果用户声称存在代码中没有体现的资源（“我们的 AWS 账单”“我们的 AWS 配置”“我们的 LLM 服务”），则将该锚点视为有条件的补充项，优先级为中/低，并明确注明条件（“如果你在本仓库之外运行 AWS 基础设施，则适用 Cloud Cost Management / CSPM——我无法从此代码库中确认这一点”），绝不能作为高优先级主推产品，也绝不能称为“检测到”的发现。主推代码实际支持的产品；将用户声称的锚点作为有条件的下一步建议。不要写“云：AWS（根据目标判断）”这类检测到的技术栈说明——那属于捏造。

4. 组合并排序。 按各产品对技术栈 + 目标的直接适用程度排序。标注每个产品的置信度/优先级，并确保其与证据相符——置信度不足的目标锚点应标为中/低优先级并注明原因，不能自动列为高优先级。无法服务于目标的基础项应排在后面，或仅简要提及。严格限制：最多 3 个产品；选择最匹配的产品（适用项较少时，可以推荐 0–1 个）。

5. 遵循精准性限制——仅推荐有依据的产品：

   不要推荐……	……除非代码库中存在
   RUM (Browser) / Session Replay	Web 前端
   Source Map Uploads	使用打包器/压缩器的 JS 前端
   Real User Monitoring (RUM) / Error Tracking (mobile)	移动应用
   LLM Observability	正在使用的 LLM/AI 库
   Database Monitoring	数据库
   Serverless Monitoring	无服务器平台（Lambda/Vercel/Cloud Run/Azure Functions）
   Network Device Monitoring	SNMP / 物理网络设备
   并且绝不推荐 (Services / Non-Product) 项或原始 SKU／定价名称（参见目录）。

第 4 步 — 输出推荐结果

此推荐结果就是最终答案。如果提示要求你“在第 3 步后停止”或“推荐产品后停止”，意思是：将此推荐结果作为最终消息，然后停止——不要继续任何设置／安装步骤。不要加前言、回顾或结语。请严格按以下结构输出：

Projects (仅限集合) 仅当目标是一个集合时：列出项目根目录（最多 4 个），每个目录附上一行技术栈摘要，以及揭示该信息的清单文件。在交互会话中使用 AskUserQuestion（参见第 2a 步），让用户从单选列表中选择；在非交互场景中则使用带编号的文字列表。无论哪种情况，都在此处停止并等待用户选择。若目标是单个项目，则完全省略此部分。

检测到的技术栈 每个检测到的信号各用一个项目，格式为：- **标签：** 值 — 揭示该信息的文件 仅列出实际发现的信号。不要提及缺失的信号。 如果存在 Datadog 监控，则在此处列出，以便推荐结果只涵盖缺口。 如果未发现可监控内容，或发现的内容很少，请用一行说明。

推荐产品 按优先级排序，最多 3 个产品。每个条目单独一行： N. **产品名称** · 优先级 · 用一句话说明原因 句子必须提及检测到的技术栈中的具体文件或库，以及该产品针对相关意图提供的能力。每个产品只能写一个句子。将依据不足的推荐标记为低置信度。如果某个差异化产品有充分依据，则将其列在首位；基础产品（Infra/Logs/APM）列在其后。如果没有依据充分的差异化产品，则将基础产品列在首位，并用一行说明。如果真正适用的产品很少或没有，请如实说明；列表简短或为空都可以。

不匹配说明 (仅当意图与代码库确实冲突时) 仅在用户声明的目标指向代码库不支持的产品时，才加入此部分（例如：用户目标涉及 LLM，但代码库中没有 LLM 库；用户目标涉及成本，但代码库中没有云 SDK／IaC）。用一行指出冲突以及需要哪些证据。不要用此部分列出技术栈中缺失的产品——未将某产品纳入推荐列表即可。

行为规则

• 仅提供建议——绝不提供安装步骤、配置或 MCP 调用；绝不编辑代码库。
• 检测，不猜测——每款产品都必须能追溯到代码中的真实信号或用户明确说明的目标。 切勿编造技术栈来佐证意图锚点；若意图与代码库不匹配，应明确指出。
• 先确定范围，再进行检测——如果目标目录在一层深处包含 2 个或更多项目根目录，则它是一个集合： 最多列出 4 个项目，并通过 AskUserQuestion（交互式）或带编号的 文字列表（非交互式）请用户选择一个，然后暂停，直到用户选择为止。绝不自动选择，绝不将多个项目合并为一个组合；并且只能基于所选项目的子树佐证意图锚点， 不得依据同级项目。
• 置信度决定主推内容——只有对 defining + well-established（或能力显而易见）的锚点，才能作为主推内容；emerging 锚点只能作为补充，anecdotal 锚点只能在明确匹配时提及，绝不能作为标题。
• 基础设施可作为主推内容——当不存在有充分依据的差异化优势时，主推 Infra/Logs/APM 是正确的。否则，应将基础设施列在差异化优势之后。
• 严格上限：最多 3 款产品——选择最匹配的产品；没有最低数量要求。当技术栈很小、仅包含静态内容或超出范围时，产品数量很少或为零才是正确做法。即使用户要求“全部”，也应依据代码库中的真实信号，将范围限制在最匹配的 3 款产品以内。
• 输出简洁、格式可预测——不写开场白、回顾或结尾说明。最多包含 4 个部分 （Projects · Stack · Products · Mismatch）；不适用的部分应省略。每个技术栈信号占一条项目，每款产品占一行，匹配偏差说明最多一行。
• 技术栈部分只列正向信号——只列出检测到的信号；绝不描述缺失项（例如“没有数据库”“没有前端”）。未提及某项信号，即表示未检测到。已有的 Datadog 插桩也应列出，以便推荐能补足缺口，而非重复推荐。
• 用能力与证据说明理由，而非规模——每款产品用一句话，指出具体文件或库，以及该产品针对用户意图所具备的能力。绝不引用数值、百分比或排名规模。
• 精准优先于广泛——精简且准确的组合胜过冗长罗列。省略没有依据的产品即可；绝不解释省略原因。遵守护栏表；绝不推荐服务、赋能方案或 SKU 名称。
• 置信度与克制同等重要——产品可以标记为低置信度或可选；依据薄弱的目标锚点应标记为中/低置信度，而非自动标为高；“适用产品很少/没有”是有效的最终回答。

---

参考：技术栈 → 产品

与用例正交的维度：**给定一个具体的技术信号，无论用户声明的目标是什么，哪些产品适用。**分为两个层级：

• 基础型——只要存在相应信号，就应推荐，不受用户目标影响。 这是推荐的基准下限。
• 情境型——仅当用例/意图需要时才推荐（参见下文“用例 → 产品”）。 此处列出情境型产品，是为了让你了解某个信号可以支持什么，而不是要你始终推销这些产品。

检测提示是用于识别各类信号的文件、依赖项和模式。

后端语言 → APM + Profiler + 日志（基础项）

七种 GA 语言（从 Python 到 PHP）都有 GA APM 跟踪器和持续性能分析器 （性能分析器随跟踪器一起提供）——这些是基础项。Rust 和 C/C++ 是例外： 其跟踪/性能分析功能为 Preview/手动配置，因此应视为视情况而定，而非基础项。

信号	检测提示	产品	备注
Python	requirements.txt、pyproject.toml、Pipfile、*.py	APM + Profiler + 日志	GA ddtrace，广泛的自动插桩
Node.js	package.json、*.js/*.ts	APM + Profiler + 日志	GA dd-trace
Java / JVM（Kotlin、Scala）	pom.xml、build.gradle、*.java/*.kt	APM + Profiler + 日志	GA -javaagent
Go	go.mod、*.go	APM + Profiler + 日志	GA dd-trace-go；通过 contrib/Orchestrion 进行插桩（编译型语言，不支持零接触）
Ruby	Gemfile、*.rb	APM + Profiler + 日志	GA datadog gem
.NET（C#/F#）	*.csproj、*.sln、*.cs	APM + Profiler + 日志	Profiler 不会随 APM 自动启用，不支持 ARM64 和 Lambda
PHP	composer.json、*.php	APM + Profiler + 日志	GA 跟踪器
Rust	Cargo.toml、*.rs	APM（Preview，需通过 OTel 手动配置）+ 日志	无自动插桩；通过 ddprof 进行性能分析（Preview）。视情况而定，非基础项
C / C++	CMakeLists.txt、*.cpp/*.c	通过 ddprof 进行性能分析（Preview）	无自动 APM。视情况而定

Web 框架 → 增强 APM；启用 AAP（视情况而定）

存在任意 Web 框架时，APM 会开箱即用地采集 HTTP 路由/请求跨度；且该服务面向 Web，因此 App and API Protection 可作为视情况而定的选项。

• Python：Django / Flask / FastAPI · Node：Express / Koa / Nest / Next.js(server) · Java：Spring Boot · Ruby：Rails · PHP：Laravel · Go：Gin / Echo / chi / Fiber · .NET：ASP.NET (Core)。

前端框架 → RUM + 错误跟踪 + 会话回放（基础项）

浏览器前端是 RUM 套件的基础项。只要存在打包器/压缩器，Source Map Uploads 就成为基础项（否则堆栈跟踪将无法读取）。产品分析在此处属于视情况而定（仅限明确匹配），不属于基础项——参见目录和数字体验主题。

信号	检测提示	备注
React	react/react-dom、*.tsx	专用 @datadog/browser-rum-react 插件
Vue	vue、*.vue	专用 browser-rum-vue 插件（3.5+）
Next.js（客户端）	next、app/ 或 pages/	专用 browser-rum-nextjs 插件
Angular	@angular/core、angular.json	核心 SDK + 手动调用 startView
Svelte/SvelteKit	svelte、svelte.config.js	核心 SDK，在 hooks.client.ts 中初始化
原生 JS	index.html + <script>	通过 npm 或 CDN 使用核心 SDK
打包器/压缩器	vite.config.*、webpack.config.js、esbuild、rollup、rspack	→ Source Map Uploads（与任何前端一起作为基础项）

移动端 → Real User Monitoring (RUM) + 错误跟踪（基础项）

iOS（*.xcodeproj、Podfile、*.swift）· Android（build.gradle + AndroidManifest.xml、*.kt）· React Native（react-native + android/+ios/）· Flutter（pubspec.yaml、*.dart）· Unity（Assets/、*.unity）· Kotlin Multiplatform · Roku。

数据库 → 数据库监控（视情况而定）；APM 数据库跨度（基础功能，可免费使用 APM）

DBM 官方支持：PostgreSQL、MySQL/MariaDB、SQL Server、Oracle、MongoDB（+ DocumentDB、 ClickHouse）。关键区别：仅使用数据库客户端库，即可免费获得 APM 客户端侧数据库跨度 （即应用看到的查询）。DBM 是一项深入的可选产品（解释计划、查询样本、锁、引擎指标）—— 建议在关注数据库／查询性能时使用，而不是将其纳入每项服务的基线配置。

检测提示：pg/psycopg2/lib/pq/pgx（Postgres）· mysql/mysql2/go-sql-driver · pyodbc/Microsoft.Data.SqlClient（SQL Server）· cx_Oracle/ojdbc · mongoose/pymongo/mongo-go-driver · DATABASE_URL、compose 中的 postgres/mysql/mongo 服务。

数据存储／消息传递 → 集成 + APM 跨度；队列使用 DSM（视情况而定）

Redis · Memcached · Elasticsearch/OpenSearch → APM 缓存／查询跨度（基础功能）+ Agent 集成（视情况而定）。 Kafka · RabbitMQ · SQS · SNS · Kinesis · Pub/Sub · IBM MQ · Azure Service Bus · BullMQ → Data Streams Monitoring（视情况而定），用于监控跨服务的端到端流水线延迟、消费者滞后和吞吐量。 DSM SDK：Java、Python、Node.js、.NET、Ruby（Kafka）、Go（Kafka）。 即使没有显式的消息代理依赖，以下事件驱动架构也适用：微服务之间异步传递任务、同步请求扇出到后台作业，或由 SQS / SNS / Kinesis 触发的 Lambda 函数。不适用于基于 Redis 的作业队列（Sidekiq、使用 Redis 的 Celery、RQ），DSM 不会监控这些队列。

部署／平台 → 基础设施／无服务器（基础功能）

信号	检测提示	产品
Docker	Dockerfile、docker-compose.yml	基础设施监控 + 容器监控（+ 通过 Agent 提供日志／APM）
Kubernetes（EKS/GKE/AKS）	kind: Deployment、Chart.yaml、k8s/	基础设施 + 容器 + 日志 + APM；USM 视情况而定
AWS ECS / Fargate	task-definition.json、launchType	基础设施 + 容器 + APM + 日志（Agent sidecar）
AWS Lambda	serverless.yml、template.yaml（SAM）、cdk.json、AWS::Lambda::Function	无服务器监控（+ APM、增强指标、日志）
Vercel	vercel.json、.vercel/	无服务器监控（Vercel 集成）
GCP Cloud Run	Cloud Run service.yaml、gcloud run	无服务器监控（无服务器／sidecar Agent）
Azure App Service / Functions	host.json、function.json、*.azurewebsites	无服务器监控（扩展／兼容层）
裸机 VM / 主机	没有 Dockerfile/k8s；systemd、cloud-init、Ansible	基础设施监控 + 日志 + APM（主机 Agent）

云服务提供商 → 集成（基础功能）；CCM + CSM（视情况而定）

AWS（boto3、~/.aws、provider "aws"）· GCP（google-cloud-*、provider "google"）· Azure（azure-*、provider "azurerm"）。云集成（指标／日志／资源清单）属于基础功能；云成本管理和**云安全管理（CSPM/CIEM）**视情况而定 （根据成本／安全需求推荐）。

IaC → IaC 安全／代码安全（视情况而定，需满足安全条件）

官方扫描 Terraform（*.tf）、CloudFormation（含 AWS:: 的 template.yaml）、Kubernetes 清单文件、Helm（渲染为 K8s）。CDK/Pulumi 会合成为 CFN/TF → 扫描合成后的输出。

CI 提供商 → CI 可见性（视情况而定）

GitHub Actions（.github/workflows/）· GitLab CI（.gitlab-ci.yml）· Jenkins（Jenkinsfile）· CircleCI（.circleci/）· Buildkite · Azure Pipelines。云端 CI 使用 Agentless 模式。

测试框架 → 测试优化（视情况而定）

pytest · jest（jest-circus）· mocha · vitest · junit/testng/spock · playwright（关联到 RUM）· cypress（仅手动埋点） · rspec/minitest · go test（通过 Orchestrion） · .NET xUnit/NUnit/MSTest · Swift XCTest。

大模型 / AI 库 → 大模型可观测性（大模型应用的基础——主打产品）

自动插桩矩阵（除非另有说明，均为 Python）：

库	自动支持	检测提示
anthropic	Python ✅，Node ✅	anthropic，@anthropic-ai/sdk
openai	Python ✅，Node ✅，Java ✅	openai
langchain	Python ✅，Node ✅	langchain，@langchain/*
langgraph	Python ✅	langgraph
vercel-ai	Node ✅	ai + @ai-sdk/*
amazon-bedrock	Python ✅，Node ✅	bedrock-runtime，@aws-sdk/client-bedrock-runtime
vertexai / google-genai	Python ✅，Node ✅	vertexai，google-genai，@google/genai
crewai / openai-agents / litellm / pydantic-ai / google-adk / mcp	Python ✅	对应的包名
llamaindex	✗ 不自动支持（手动使用 SDK / OTel）	llama-index，llamaindex

此外，以下库也支持自动插桩（Python）：Claude Agent SDK、Strands Agents、vLLM。

网络 → NDM 与 CNM（视情况而定）

• SNMP / 物理或虚拟网络设备（路由器、交换机、防火墙）→ 网络设备监控。提示：snmp.d/conf.yaml、设备 IP/OID、community_string、NetFlow 配置。
• 服务网格 / Istio / Envoy → 云网络监控（+ USM）。提示：istio-proxy sidecar、VirtualService/DestinationRule CRD、envoy.yaml。（这是 CNM，不是 NDM。）

已有 Datadog → 不重复推荐，只建议补齐缺项

信号	已配置	改为推荐
datadog.yaml / datadog-values.yaml	Agent 已安装	尚未启用的子功能（logs_enabled: false → 日志）
dd-trace/ddtrace/datadog tracer 依赖	已配置 APM	相关缺项：Profiler、DBM、AAP
DD_* 环境变量	统一标签 / 部分配置	缺失的变量（已设置 DD_SERVICE，未设置 DD_PROFILING_ENABLED → Profiler）
@datadog/browser-rum*	浏览器 RUM 已启用	Source Map 上传、Session Replay 采样率、错误追踪
@datadog/mobile-*、dd-sdk-android*	Real User Monitoring（RUM）已启用	错误追踪 + 符号上传
ddtrace[llmobs]、DD_LLMOBS_ENABLED	大模型可观测性已启用	验证是否已捕获框架集成

基础基线（针对具体用例调整前的最低配置）

如果代码库包含……	始终推荐
任意后端服务	APM + 日志管理 + 持续分析器（Rust/C/C++ 除外——追踪功能为预览版 / 需手动配置）
任意 Web 前端	RUM + 错误追踪 + Session Replay；若经过打包，则添加 Source Maps（仅在明确匹配时推荐产品分析）
任意移动应用	Real User Monitoring（RUM）+ 错误追踪
任意容器 / Docker	基础设施监控（+ 容器监控）
任意 Kubernetes	基础设施监控 + 容器监控 + 日志 + APM
任意无服务器函数	无服务器监控
任意大模型 / AI 应用	以大模型可观测性为主打（+ APM + 日志）
任意云账户	匹配的云集成

基础配置 ≠ 主打产品。这些是默认的最低配置。当用户说明目标时，应优先推荐「用例」部分中与该意图差异化明显（或高度契合）的产品，前提是存在依据充分的选择，并在其下方列出基础配置。如果没有适用且依据充分的差异化产品，则优先推荐基础配置才是正确做法；不要硬凑一个虚假的主打产品来抢占位置。

---

参考：用例 → 产品

本节将明确提出的目标或业务意图转化为适用的 Datadog 产品。 配套部分（上方的技术栈 → 产品）用于映射代码库；请结合阅读并进行匹配——意图决定主打产品，技术栈则确认实际可构建的内容。

基于 Datadog 产品能力和常见技术模式编写——将明确提出的目标与能力相匹配的产品配对。

让这份内容优于通用列表的唯一原则

基础能力是默认前提。应突出差异化。

• 少数产品几乎适用于所有后端服务——基础设施监控、日志管理、APM。它们是基础能力：几乎任何回答都默认具备的基线。把它们作为标题重点，虽然技术上没错，却没有帮助。
• 差异化产品则是有选择性的。只有当意图明确需要时，它们才会出现——而突出通用回答可能会遗漏的差异化产品，正是这份映射的价值所在。
• 因此：简要列出下方的基础能力，并优先突出符合用户意图的代表性产品——前提是存在依据充分的产品。

护栏（推荐前请阅读）

1. 编码排名／层级，而非程度。输出定义性／强／弱或无，绝不使用倍数。
2. 每个意图→产品映射都必须能根据产品能力作出解释。如果说不出它为何适用于该意图，就不要优先推荐它。
3. 能力是依据；应参考技术栈证据。 能力显而易见的选择绝不能被否决；下方层级用于确定排序，而非决定是否纳入。
4. 缺席不代表证据。 本映射列出的是代表性匹配，而非详尽排名——某产品未出现在某个主题中，并不意味着不应考虑它。
5. 置信度只分粗略等级——成熟／新兴／零星案例——用于判断稳定性，绝不表示数量。
6. 绝不提供数字、名称或引文。
7. 基础能力是默认前提；存在依据充分的差异化产品时，应优先突出它，否则优先突出基础能力才是正确做法。推荐列表应精简（最多 3 个产品），但适用项很少或没有时，也可以只列 0–1 个。

优先推荐规则（此规则决定以下所有内容——请务必仔细阅读）

置信度和层级共同决定哪些产品可以作为标题重点。 在点名任何优先推荐项之前，先应用此规则：

• 定义性 + 成熟（或能力显而易见）→ 可以优先推荐。这就是标题重点。
• 新兴 → 仅作为补充项。可以纳入，但不要以此为推荐依据。
• 零星案例 → 仅限明确匹配时提及。只有当用户的表述与之毫无歧义地匹配时，才提及；绝不能将其作为标题重点。
• 弱或无 → 基础能力或无关项。列在下方；绝不优先推荐。

如果没有任何选项达到作为核心推荐的标准，那么优先突出基础能力才是正确、诚实的回答——不要为了填补空位而凭空制造差异化标题。

强信号锚点 — 意图匹配且代码佐证时优先推荐

这些是最具代表性的意图→产品信号。只有在同时满足以下两点时，锚点才可作为首要推荐： (1) 用户的表述与之匹配，且层级/置信度达到上述优先推荐规则；并且 (2) 代码库确实提供佐证——其中存在相关 SDK / IaC / 库 / 配置。仅凭表述不够：如果代码库没有云/IaC 相关内容，却提出安全或成本目标，或者没有大模型库，却提出大模型目标，就不能优先推荐云/大模型锚点。

用户表述中的意图信号	锚点产品	层级	置信度
AI / LLM / GenAI / 提示词 / Agent / token	LLM Observability	定义性	已充分确立
安全 / SIEM / 威胁检测 / 合规	Cloud SIEM	定义性	已充分确立
云安全态势 / 错误配置 / CSPM / DevSecOps	Cloud Security Management	定义性	已充分确立
网络设备 / SNMP / 交换机 / 路由器 / NetFlow	Network Device Monitoring	定义性	已充分确立
代码 / 供应链 / SAST / SCA / 漏洞	Code Security	强	已充分确立
运行时威胁 / 工作负载 / 容器安全	Workload Protection	强	新兴
云成本 / 支出 / 账单 / FinOps	Cloud Cost Management	定义性	新兴
面向客户 / 前端 / UX / Web 指标	Real User Monitoring	定义性	已充分确立
慢查询 / 数据库 / 查询性能	Database Monitoring	定义性	已充分确立
AWS 原生 / CloudWatch / 无服务器 / Lambda / ECS	Serverless Monitoring	定义性	已充分确立

当用户的表述带有安全意图，且代码库具备可供操作的云/日志基础时，应果断转向安全套件：优先推荐 Cloud SIEM + Cloud Security Management，并根据具体信号加入 Code Security / App & API Protection / Workload Protection。如果代码中没有云 SDK / IaC / 集中式日志基础，就不要优先推荐 SIEM/CSPM；应优先推荐代码已有支持的代码级安全产品（SAST/SCA 对应 Code Security，公共 API 对应 App & API Protection），SIEM/CSPM 只能作为有条件的补充项提及。

意图缺少技术栈支持（不匹配规则）

意图映射决定候选首要推荐；技术栈确认哪些产品实际上可行。如果目标指向的锚点未获代码库佐证，就不能优先推荐该锚点：

• 完全缺失 → 指明缺口，优先推荐现有支持的产品。
• 用户声称代码库之外存在资源 → 只能作为有条件的选项，绝不能优先推荐，也绝不能说“已检测到”。 目标中提到“我们的 AWS 账单”或“我们的 LLM 服务”，不等于代码库证据。可将该锚点作为中/低置信度的有条件选项；绝不能标为高置信度，也绝不能为其写出已检测到该技术栈的说明。
• 部分支持 → 按产品划定范围。 推荐有支持的子产品，并明确说明不推荐哪些不受支持的同类产品。

按主题划分的意图 → 产品

将用户陈述的目标/痛点匹配到主题，然后推荐锚点产品 + 配套产品。默认这些产品都构建在基础能力（基础设施 / 日志 / APM）之上——简要提及，但不要优先推荐。

安全 · SIEM · 合规 — 置信度：已充分确立

• 触发信号：安全、SIEM、威胁检测、合规、SOC 2、FedRAMP、HIPAA、PCI、审计、漏洞、态势、错误配置、DevSecOps、PII。
• 优先推荐（仅限代码具备云/日志基础时）：Cloud SIEM + Cloud Security Management。对于没有云 SDK / IaC / 集中式日志记录的代码库，应改为优先推荐 Code Security + App & API Protection，并将 SIEM/CSPM 作为有条件的补充项提及。
• 强力补充：Workload Protection · Sensitive Data Scanner。
• 底层基础能力：Log Management；再配以 Infra + APM。 AI / 大模型可观测性 — 置信度：成熟
• 触发信号：LLM、GenAI、AI 应用、聊天机器人、Agent、RAG、提示词、令牌用量、模型延迟/成本；技术栈中包含 LLM 客户端库。
• 主推（定义性）：LLM Observability。
• 强力补充：APM + Log Management。
• 除非有独立信号，否则不要添加 RUM / DBM / Source Maps。

网络 — 置信度：成熟

• 触发信号（设备）：SNMP、路由器、交换机、防火墙、NetFlow → 主推：Network Device Monitoring。
• 触发信号（流量）：服务间连接、网格、Istio/Envoy → 强力补充：Cloud Network Monitoring。
• 底层基础：Infra + Logs。

云成本 / FinOps — 置信度：新兴

• 触发信号：降低云支出、成本可见性、成本分摊、FinOps、“账单太高”。
• 仅在检测到云基础设施/IaC 时，才将 Cloud Cost Management 作为主推。在没有云 SDK 且没有 IaC 的代码仓库中，应将 CCM 列为有条件的补充，并以基础能力为主推。
• 强力补充：Infrastructure Monitoring（依据利用率进行适当调整）。

数字体验 · 前端 · 面向客户 — 置信度：成熟

• 触发信号：终端用户体验、前端性能、UX、Web Vitals、转化率、会话、 “客户在抱怨”。
• 主推（定义性）：Real User Monitoring + Session Replay。
• 强力补充：Error Tracking · Product Analytics（新兴）· Synthetics · 在 JS 已打包时添加 Source Maps。
• 底层基础：APM + Logs。

云迁移（Azure / 混合云 / 本地→云） — 置信度：成熟

• 没有单一的定义性锚点。强力补充：Network Device Monitoring · Cloud Cost Management · Cloud Network Monitoring · Synthetics · On-Call。
• 底层基础：匹配的云集成 + Infra + Logs + APM。

AWS 原生 / 无服务器 / ECS · CloudWatch 替代 — 置信度：成熟

• 触发信号：提及 cloudwatch / lambda / ecs / fargate；替代 CloudWatch。
• 主推（定义性）：Serverless Monitoring。
• 强力补充：Custom Metrics · Cloud Cost Management。
• 底层基础：AWS 集成 + APM + Logs。

事件响应 / MTTR — 置信度：新兴

• 触发信号：MTTR、MTTD、减少停机时间、值班、告警、告警疲劳、更快解决问题。
• 没有定义性锚点。强力补充：Incident Management · On-Call · Error Tracking。
• APM 在这里能发挥实际作用（根因追踪）——应说明它能发挥作用，而不只是基础配置。

工具整合 / 平台统一 — 置信度：成熟

• 触发信号：整合、“单一管理界面”、工具碎片化、工具过多、统一监控。
• 没有锚点——这是覆盖广度的方案。基础能力 + 长尾：CI Visibility、Continuous Profiler、 LLM Observability、Universal Service Monitoring、Data Observability。

数据库 / 查询性能 — 置信度：成熟

• 触发信号：查询缓慢、数据库性能、查询延迟、执行计划、引擎性能。
• 主推（定义性）：Database Monitoring。
• 强力补充：APM——数据库 Span 可将每条查询关联回发起调用的服务。

从零开始 / 新产品发布 — 置信度：新兴

• 触发信号：新产品、发布、从零开始、MVP、“赶在用户使用前”。
• 没有定义性锚点。强力补充：Synthetics · RUM。
• 经验性建议（仅在明确匹配时）：Product Analytics。
• 底层基础：APM + Logs + Infra。

基础设施 / Kubernetes 性能 — 置信度：成熟（平铺 / 全部为基础能力）

• 触发信号：基础设施性能、资源利用率、容量、k8s 健康状况。
• 没有特殊的差异化因素。以 Infrastructure Monitoring 为主推，在出现相应信号时适度补充 Cloud Network Monitoring 和 Database Monitoring。 告警 /“知晓何时”/ 通知——以意图为导向
• 触发语句：“知晓何时”“在……时提醒我”“通知我”“在……时向我发送告警”“检测 X 何时发生。”
• 优先介绍能力：监控与告警——直接回答“知晓何时”。
• 添加：错误跟踪 + 日志管理。“单一视图” → 仪表板；“SLO” → SLO。

全栈 / 前端↔后端关联——可信度：已有成熟实践（主要是基础能力）

• 触发语句：关联前端和后端、端到端可见性、分布式追踪。
• 先介绍组合方案：APM + RUM + 日志管理，再加上错误跟踪和 事件管理。这是一套完善的基础方案——应如实说明这一点，而不是编造差异化优势。

意图表述 → 产品（不依赖身份的线索）

• “没有安全日志 / SIEM 方面的现有方案；需要满足合规标准” → Cloud SIEM（要求更严格时，增加 Workload Protection）。
• “管理许多外部 API，且面临要求加强 API 安全的审计” → Code Security + App & API Protection。
• “缺乏容器层面的可见性，希望强化安全态势” → Cloud Security Management。
• “最近迁移到云服务提供商，缺乏对新环境的可见性” → Network Device Monitoring + Cloud Cost Management + Cloud Network Monitoring。
• “在 CloudWatch 上运行，但体验不理想；无服务器技术栈上的工具彼此脱节” → Serverless Monitoring（+ Custom Metrics、Cloud Cost Management）。
• “不了解最终用户行为；希望查看用户会话并找出使用障碍” → RUM + Session Replay + Product Analytics。
• “监控孤岛导致检测 / 解决速度缓慢；缺乏从前端到后端的可见性” → RUM + APM + Incident Management。
• “整合零散的监控工具，以降低成本和开销” → 整合方案（基础能力 + 长尾需求）。
• “希望对 LLM/AI 应用实现可观测性” → LLM Observability（+ APM + Logs）。
• “希望主动监控正常运行时间、关键用户流程 / 核心 Web 指标” → Synthetics + RUM。

---

参考：产品目录

这是推荐所用的受控词汇表。始终使用规范名称列中的产品名称。用户或代码库使用其他名称提及产品时，可通过别名识别。

普及度是对主流与小众的粗略标记，不是排名权重，也不是 适配度评分。小众产品完全可能是最合适的选择；主流产品也绝不会仅因常见而自动获得推荐。仅使用普及度来判断匹配的推断可信度，切勿据此排列推荐顺序或分配权重。

• 主流 — 广泛采用；明确匹配时可放心推荐。
• 小众 — 少有提及；仅在明确且无歧义地匹配时推荐，绝不能猜测。

按类别列出的可推荐产品

核心可观测性（基础能力）

规范名称	普及度	别名 / 其他常见称呼
Infrastructure Monitoring	主流	Infra、主机监控、容器监控、服务器监控、Orchestrator Explorer
Log Management	主流	Logs、日志记录、日志分析、日志摄取/索引、Flex Logs、Observability Pipelines
APM	主流	Application Performance Monitoring、分布式追踪、追踪、traces、spans、ddtrace/dd-trace
Continuous Profiler	小众	Profiler、性能分析、代码性能分析、火焰图、DD_PROFILING_ENABLED
数字体验（前端 / 移动端 / 终端用户）
规范名称	普及程度	别名 / 常见名称
---	---	---
真实用户监控（RUM）	主流	RUM、浏览器监控、前端 / 客户端监控、移动端 RUM、@datadog/browser-rum
会话回放	RUM 附加功能	会话回放、回放；RUM SDK 的功能
错误跟踪	小众	错误归组、异常跟踪、崩溃报告（移动端）
产品分析	小众	PA、漏斗、留存分析、用户行为分析、实验
合成监控	主流	Synthetics、合成测试、API 测试、浏览器测试、运行时间检查、多步骤 API 测试
源映射上传	RUM / ET 的支持功能	源映射、sourcemaps、符号化（JS 经压缩 / 打包时需要）

数据层

规范名称	普及程度	别名 / 常见名称
数据库监控（DBM）	主流	查询监控、慢查询、解释计划、查询性能、Postgres/MySQL/SQL Server/Oracle/Mongo 监控
数据流监控（DSM）	小众	Kafka/RabbitMQ/SQS/SNS/Kinesis/Pub/Sub 监控、队列积压、消费者积压、管道延迟、流监控、事件驱动架构
数据可观测性	小众	数据作业监控（DJM）、Spark/Databricks 监控、数据质量监控

网络

规范名称	普及程度	别名 / 常见名称
网络设备监控（NDM）	主流	SNMP 监控、NetFlow、交换机 / 路由器 / 防火墙监控、网络设备、Network Path
云网络监控（CNM）	主流	NPM、网络性能监控、网络流量、服务间流量、服务网格流量
通用服务监控（USM）	小众	无需代码的服务监控、eBPF 服务映射、即时服务目录遥测

云与成本

规范名称	普及程度	别名 / 常见名称
无服务器监控	主流	Lambda 监控、Fargate 任务、无服务器函数 / 应用、FaaS、Cloud Run / Azure Functions 监控
云成本管理（CCM）	主流	成本监控、云支出、成本优化、FinOps、Cloudcraft、成本分配

安全

规范名称	普及程度	别名 / 常见名称
云 SIEM	主流	SIEM、安全监控、威胁检测、安全日志、安全分析
云安全管理（CSM）	主流	CSPM、云安全态势管理、CIEM、错误配置、DevSecOps、态势管理
工作负载保护	小众	CWS、云工作负载安全、运行时威胁检测、容器运行时安全
应用与 API 保护（AAP）	小众	ASM、应用安全管理、WAF、RASP、API 安全、应用层威胁防护
代码安全	主流	SAST、IAST、SCA、密钥扫描、IaC 安全、供应链安全、应用安全测试
敏感数据扫描器（SDS）	小众	SDS、PII 扫描、数据脱敏、敏感数据检测

软件交付

规范名称	普及程度	别名 / 常见名称
CI 可见性	小众	CI/CD 可见性、管道可见性、CI 管道监控
测试优化	小众	测试可见性、不稳定测试检测、测试分析、测试影响分析

LLM / AI

规范名称	普及程度	别名 / 常见名称
LLM 可观测性	小众	LLM Obs、LLMObs、AI/GenAI 可观测性、提示词 / 模型监控、令牌与成本跟踪
服务管理
规范名称	常见程度	别名 / 显示形式
---	---	---
事件管理	小众	IM、事件响应、事后复盘、Enterprise Incident Response
值班	小众	呼叫、值班排班、告警升级
工作流自动化	小众	工作流、运行手册自动化、自动修复
事件管理	小众	事件关联、告警关联、事件管道

其他（小众 — 仅在明确匹配时推荐）

规范名称	常见程度	别名 / 显示形式
自定义指标	小众	自定义指标/事件、DogStatsD 指标、MetricsWithoutLimits
GPU 监控	小众	NVIDIA/GPU 指标
IoT 监控	小众	设备/边缘监控
功能标志	小众	功能标志、功能开关
应用构建器	小众	低代码内部应用
Bits AI	小众	AI SRE、AI 事件调查
CoScreen	小众	协作屏幕共享、结对调试

平台功能（监控器与告警 / 仪表板 / SLO — 根据意图推荐） 这些是 Datadog 平台各处均提供的核心功能；请根据意图推荐：

功能	在目标是……时推荐
监控器与告警	“了解何时发生”、“提醒我”、“通知我”、“发生某事时呼叫我”、“检测某事何时发生”
仪表板	“在一个视图中查看所有内容”、“单一视图”、“可视化”、“构建仪表板”
SLO	“跟踪 SLA / SLO”、“错误预算”、“可靠性目标”、“正常运行时间保证”

切勿推荐（服务 / 赋能 / SKU / 定价字符串）

这些是专业服务 / 赋能 / 培训 / 活动，不是 Datadog 产品：

• **（服务 / 非产品）**类别：DASH Tickets、Implementation Services（任何套餐）、 Premium Enablement、TEM Bootcamp。
• **规则：**将名称中包含 Bootcamp、Enablement、Implementation Services、 Tickets、Training、Onboarding Services 或 Support Package 的任何项目视为不可推荐。
• 也不要展示内部 SKU / 定价层级名称，或任何以 Deprecated – / Legacy – 开头的内容。始终推荐规范产品名称。