AI 资源库 · 已整理 28 项
查看与Datadog相关的 AI 资讯、工具、Skill、工作流和开源项目。
Datadog 宣布自己在 Forrester 的 AIOps 平台评测里被评为“领导者”。以前工程师要自己翻告警、查问题、找根因；现在 Datadog 的 Bits AI 会帮忙定位问题并给出修复建议，还能在设定的护栏内执行修复，工程师保留最终控制权。支撑它的 Scout 1.0 模型刚进入预览，Bits AI 已有超过 1 万名付费客户。对读者来说，这意味着运维排障可能从“人工逐条查”变成“AI 先查、人来把关”，但 Scout 1.0 尚未正式开放。
Datadog 推出了一个叫 Infrastructure Basic 的轻量监控档位。原来，对于不太重要的服务器（比如内部后台系统、开发测试机），团队要么用比实际需要更重的监控方案，要么另买一套工具，要么干脆不监控、留下盲区。现在这个档位只采集 CPU、内存、磁盘、网络、开机时长等基础系统指标，还能盯住指定进程是否在跑，并复用现有的告警通知工具。这样，次要服务器也能和重要系统放在同一个 Datadog 环境里统一查看，减少监控空档。目前该功能需要联系 Datadog 销售团队开通，新用户可先试用 14 天。
Datadog 宣布支持通过其 AWS、Azure 和 Google Cloud 集成中的专用子集成来监控 Oracle AI Database@AWS、@Azure 和 @Google Cloud。过去，数据库托管在 Oracle 云上而应用跑在其他云里，出问题时常出现监控盲区，难以判断是应用还是数据库的锅；迁移后性能验证和跨账单的成本归属也很麻烦。现在每套子集成提供 50 多项开箱即用的指标和仪表盘，还能配合数据库监控（DBM）、应用性能监控（APM）和云成本管理（CCM）排查慢查询、对比迁移前后性能，并把 OCI 与云厂商的账单归一化后按团队归因成本。原文未说明具体上线时间或收费方式，以上能力均以已发布的产品功能形式介绍。
很多团队现在直接用 AI 写代码，Anthropic 的工程师产出的代码量达到原来的八倍，有人每月提交数千个 PR。但麻烦在于：代码写得快了，测试仍然要靠人写，得决定测哪些流程、写脚本、流程一变还要改，瓶颈从写代码挪到了测试环节。Datadog 今年收购了 Propolis，把“由智能体写的测试”加进自家平台：智能体自己去探索应用、走用户流程，再根据自然语言的要求生成测试，并结合 Datadog 的日志和链路追踪来检查性能，避免硬编码测试容易失效的问题。对团队来说，这有望缩短开发周期；不过目前只是文章介绍的方案，具体能否用、怎么用还要看 11 月 4 日的线上活动。
Datadog 的产品经理 Kathy Lin 和技术作者 David Lentz 写了一篇文章，讲 Kubernetes 的旧设备插件模型怎么限制 GPU 使用效率。旧模型里，团队必须提前把 GPU 切好固定的分区，请求只能写数量、看不出显存大小和连接方式，结果经常是花钱买的 GPU 容量白白闲着，或者任务排队等资源。新的动态资源分配（DRA）让 Kubernetes 按每个任务的具体需求灵活挑选和分配 GPU，还能让多个任务共用同一块 GPU，把闲置容量利用起来。读者可以了解 DRA 相比旧模型好在哪，以及用 Datadog 怎么跟踪这些改进和省下的成本。文章目前是博文介绍，没有给出具体性能数字，也没有说明 DRA 功能是否已普遍可用。
Datadog 为它的 RUM（真实用户监控）产品加了一个叫“运维监控”的新功能。以前，团队能单独看到页面浏览、点击、报错这些零散事件，但很难直接回答“付款这一步到底成没成功、花了多久”。现在，你可以把“处理支付”这类由应用控制的关键步骤定义成一个“操作”，单独追踪它的成功率和耗时，还能用 SLO 设目标、用 Bits AI 查为什么变慢或报错，最后再把它放回整条用户旅程里看。这个功能随 RUM 免费提供，Bits Investigation for Operations 目前还在预览阶段。
Datadog 内部有数千个服务，以前对所有服务一视同仁地制定部署和可靠性标准，规模变大后成本太高，也不知道该把有限的可靠性投入放在哪里。他们用大语言模型读取几百篇最高严重级别的故障复盘文档，提取出哪些服务导致或被卷入事故，再结合 APM/RUM 错误链、生产流量和监控告警等信号，给每个服务打出高、低、未知的关键性等级和置信度。这样就能对真正关键的服务严格部署、收紧可靠性目标，对不关键的服务放宽标准，把精力集中在故障时最影响客户的地方。
Datadog 在自带云（BYOC）日志功能里加了跨集群查询。有些公司因为数据必须留在本地或某些地区，就把日志分散存放在自己控制的多个 Kubernetes 集群里。以前要查一次故障，得挨个集群重复搜索再手动对比。现在用一条查询就能同时搜索多个选定集群，Datadog 会把各集群的结果合并展示，日志本身仍留在原处。团队和 AI 智能体因此能更快判断问题是局部还是全球性的，智能体还能少发几次工具调用、省一些 token。该功能已在 BYOC 日志中可用，具体哪些集群可查文中未说明。
Datadog 的政府版服务最近拿到了 FedRAMP High 认证，这意味着处理最敏感政府数据的团队，现在也能用 Datadog 来做事件响应了。以前，政府系统的告警、日志、截图等敏感信息，可能不敢放在认证环境里，事件处理会缺东少西。现在，值班呼叫、协调沟通、自动化处理、复盘等一整套流程，都能在 US1-FED 这个认证环境里完成，还能跟现有监控工具配合。对政府用户来说，好处是事件数据不用再挪出安全区，响应过程更完整，也更容易通过审计。文章说它是目前唯一有此认证的事件响应平台，但具体怎么开通、价格多少，原文没说明。
Datadog 推出了可视化标注工具（Visual Labeler），让产品经理不用写代码就能给网页上的点击、点击等交互起名字。以前，自动采集到的操作名只描述页面元素本身，看不出用户真正想干什么，比如“开始结账”这种业务问题往往要工程师写代码或加自定义事件才能回答。现在你只需打开浏览器扩展，在自家网站上点选元素并命名，Datadog 就会把这个名字补用到留存期内已经记录的所有匹配交互上，历史趋势和漏斗当天就能用。标好的操作还能作为共享事件在漏斗分析、热力图和仪表盘中重复使用，减少不同分析师对同一行为各叫各名字的麻烦。
Datadog 原有远程漏洞扫描器在主机规模扩大后，扫描全部主机需超过18小时，而扫描器的 SSH 凭证只有12小时有效期，凭证过期后无法继续认证剩余主机，导致部分主机漏扫。他们改用已经部署在各主机上的 Datadog Agent 收集安装的软件包版本，传给 Datadog Cloud Security 来识别已知漏洞，并用六个月新旧系统并行比对覆盖范围和检测结果。迁移后扫描新鲜度保持在99%以上，即99%以上范围内主机在过去24小时内完成过扫描，并继续满足 SOC 2 Type II、ISO 27001、PCI DSS 和 FedRAMP High 的审计要求。
Datadog 推出 CI/CD Optimization，帮助平台和 DevOps 团队应对 AI 辅助开发带来的 CI 压力。AI 让代码产出变多，但流水线跑不完、测试结果不稳定、算力开销水涨船高，交付反而变慢。这个产品把流水线和测试数据与提交记录、日志、运行器及基础设施信息放在一起，帮团队找出瓶颈、自动重试不稳定的测试、只运行受改动影响的测试。对读者来说，这意味着查看合并请求的等待时间可能缩短，CI 账单也不会随代码量同步膨胀。文中提到 Betterment 把平均构建时间从近 40 分钟降到 10 分钟以内，The Browser Company 把 CI 流水线时间缩短了 50%。
Datadog 推出了可观测性流水线中的 Exabeam 预配置包（Observability Pipelines Exabeam Packs），帮助企业在把安全日志送进 Exabeam 这个安全分析平台之前，先在自己的基础设施里过滤掉没用的噪音。以前的问题是：防火墙、终端和网络网关产生大量重复的日常日志，全部传进 Exabeam 会让存储和处理费用暴涨，还会把真正有价值的身份、访问和终端行为信号淹没。这些包针对不同来源预设了丢弃、去重和抽样规则，比如过滤 Cisco ASA、Fortinet FortiGate、Palo Alto、CrowdStrike、SentinelOne、Windows 和 Zscaler 的日志，同时保留检测所需的原始字段，Exabeam 的解析器不受影响。目前发布的包括七个来源专属包，以及 Active Directory、Okta、Microsoft 365、Abnormal.ai 等可搭配 Exabeam 目标的通用包，用户可在流水线中直接添加，并用实时抓取验证过滤效果。
Datadog 发布官方介绍，讲如何把 Databricks 上的分析、数据工程和 AI/ML 工作负载接入 Datadog 统一监控。原来用户只能分别看 Databricks 自带指标和下游基础设施，成本和数据质量难以串起来。这次通过三条数据采集路径（集群上的 Agent 抓 Spark 指标与日志、轮询 Databricks API 拿任务运行状态、查系统表获取成本与血缘），把作业健康、花费、数据质量和日志汇总到一个界面。读者可以据此设置作业失败告警、查看 Spark 查询瓶颈、获得集群规格优化建议，并配合云厂商集成定位底层问题；相关功能已可用，但文中未说明具体版本或价格限制。
Datadog 把开源工具 Supply Chain Firewall 接入了自家的 Code Security 产品。原来这个工具只能在开发者电脑上拦截已知的恶意软件包，一旦每台机器各管各的配置，就容易失控，也没法知道哪些规则真正生效。现在可以在 Datadog 里集中设置允许和禁止名单，装到电脑和 CI 流水线里的防火墙都会自动同步，还能对已经装过的包回头复查，发现是恶意的就报警。此外新增了一个 GitHub action，让 CI 流程也能在安装前拦截。这些功能目前处于预览阶段，需要申请才能使用。
Datadog 的工程师发现，过去用来分析 Python 程序运行快慢的工具（火焰图）在看 asyncio 异步代码时，会搞不清“哪个任务等哪个任务”，导致看不出性能问题是哪条调用路径造成的。他们新做了一种“异步感知”的分析方式，像记录函数调用关系一样记录任务之间的父子依赖，再把相关任务叠起来展示，这样就能看出一个协程到底在等什么。同时他们还把分析器自身的额外开销降低了 60% 以上，并产出更精细的数据。对用 Python 写异步服务的人来说，以后定位异步任务的性能瓶颈会更清楚。文中没有说明这个新版分析器是否已对所有用户开放。
Datadog 推出 RUM 远程配置功能，让开发者可以直接在 Datadog 界面里修改浏览器、iOS 和 Android 端 RUM SDK 的采样率、隐私设置和数据采集范围，不用改代码重新发版。过去这些设置写在应用代码里，改动必须发新版本，移动端还得等应用商店审核和用户慢慢升级，遇到故障想多采数据时来不及。现在只需在初始化代码里加一个远程配置 ID，SDK 下次启动时就会拉取最新设置。新应用默认开启，老应用手动接入即可。
Datadog 推出了一项叫 Tap to Parse 的 AI 辅助功能，用来解决日志里有用信息被埋在一整句话里、难以筛选和统计的问题。以前想从日志里提取状态码、耗时这类字段，得自己写复杂的正则或 Grok 规则，遇到不归自己管的服务或第三方系统就更麻烦。现在只要点一下某条日志并选择 Tap to Parse，Datadog 就会分析样例、自动生成解析规则，并让你先预览再应用，提取出的字段就能用来筛选、分组和画图。它能在 Log Explorer 里查询时用、在 Log Pipelines 里对以后新进的日志用，也能在 Observability Pipelines 里让日志离开你的环境前先结构化。目前 Log Explorer 和 Log Pipelines 中已正式可用，Observability Pipelines 中需申请开通。
Datadog 的工程师把 Qwen3.5-9B 微调成一个专门做“变更归因”的小模型：告警响了以后，它能推断最近哪次部署、功能开关或配置改动最可能是元凶。原本用规则筛选又快又便宜，但遇到复杂故障就不准；用 GLM-5.3 这类前沿大模型做多轮智能体调查则准得多，可每次调用 API 约 0.06 美元，全量告警跑不起。他们用 GLM-5.3 生成的 348 起内部事故调查轨迹来训练小模型，结果小模型达到 GLM-5.3 召回率的 87%，自托管每次调查成本约 0.003 美元，约为原来的二十分之一，一张 40GB A100 每周能支撑约 10 万次调查。目前这还只覆盖客户每周数百万个监控项中的一小部分，团队称会继续优化以扩大适用范围。
WHOOP 是一家做健康手环的公司，每天要处理成千上万条漏洞告警，靠全员连续多天手工分类才能不漏掉问题，既费人力又容易被噪音淹没。这次他们用 Datadog 的 Bits AI 和 Workflow Automation 搭了一套自动化的漏洞响应流程：先结合运行时数据判断哪些漏洞真的在被利用，再把工单自动分配给对应微服务的负责人，让开发者能自己处理一部分。原文尚在预告 2026 年 10 月 7 日的线上分享，具体实现细节和效果数据没有给出；不过它的思路是自动化处理加人工最终确认，对同样被大量漏洞告警困扰的安全和运维团队有参考意义。