一款会照顾自己的软件长什么样

值班最怕的不是业务挂了，而是平台自己出了问题、你还不知道。日志量突然少了、数据悄悄丢了一大片——查半天才发现，不是业务的事，是采集链路自己堵住了。更要命的是，传统监控软件永远在盯着「别人」，自己却像个黑盒：CPU 高了、内存满了、队列堵了，它一个字都不会主动说。

先说一句 DataBuff 是什么：一款开源的 AI 原生 APM，AI 直接长在 OpenTelemetry 数据上，问数、排查都是 AI 专家调工具查真实数据，项目在 GitHub（github.com/databufflabs/databuff）。它的做法很不一样：把自己也当成一个被监控的业务系统，装好就能看到自己健不健康、为什么异常、该调哪个参数，甚至说一句话，它就能给自己做一轮巡检。这篇就用一个真实案例讲清楚。

1 会看自己：平台的自监控页

DataBuff 的「部署状态」页，把三个核心组件全部上了指标：ingest（收数据）、web（查数据）、Doris（存数据）。一打开总览，四张卡先说结论：入站每秒多少、写出有没有失败、Doris 磁盘还剩多少、查询有没有报错。

往下翻更细：ingest 收的 trace / metric / log 每一路信号，都单独记着「收到多少、多大、多慢、丢没丢」；Doris 的磁盘、CPU 也拆开给看。

2 懂自己：每个指标都自带「说明书」

指标多不是重点，每个指标自带解释和优化参数才是。点任何一张图的标题，会弹出一个指标说明抽屉：这指标怎么算的、该不该担心、出了异常该调哪个环境变量、默认值是多少，一次讲清。

比如「写出丢弃」这个指标，抽屉会告诉你它只在两种情况下产生：队列满被整批丢，或者写入连续失败被丢弃；会提醒你「任何持续 drop 都意味着数据丢失，先对照队列水位、写入失败和 Doris 存活」；最后直接列出可调参数。

3 会体检：一句话，让 AI 把平台从头到尾查一遍

不想一页页翻？直接跟 AI 平台说一句「对 DataBuff 平台进行巡检，并出一份 html 巡检报告」。产品答疑专家会自己读指标清单、查平台自身的自监控指标、把异常挑出来，最后产出一份能直接转发的 HTML 报告。

我们实测跑了一次：几分钟里，它自动查了接入、写出、Pipeline、查询域、Doris、进程资源几组指标，结论和人工排查基本一致——有一项查询域失败还在持续，它照实标了出来。

4 会诊断：日志在丢，它自己找出原因

这个丢数不是编的，是我们 demo 环境里真实发生、又真实修好的。部署状态页的「写出丢弃」红了——只有 log 信号在持续丢，每分钟丢几千到一万五千条：

这种时候，不用人自己一页页去翻。在 AI 平台说一声，让专家去查。它先排除掉两个「不是问题」：业务侧正常，不是应用的事；Doris 存储也活着、写入也快，不是存储的事。真正的原因落在 ingest。日志是攒成一批批往写出队列里塞的，这个环境的队列只有 16 批，正常是 32。瞬时涌进来的数据装不下，多出来的就整批丢掉。日志里每分钟都在打 Doris ready queue full (16/16)，实锤。

它把「为什么丢、丢在哪、该调哪个参数、改成多少」整理成一份带证据的结论，修复建议直接给到：

5 会修复：改参数、重启，都是它自己来

排查给的建议，就是这组 INGEST_DORIS_* 参数——核心是队列太小，调大就行：

改参数、重启也不用自己动手。产品答疑专家按建议 SSH 上去，改配置、重启 ingest，改完再复查确认：

重启生效后，丢弃归零——修复前每分钟还丢几千条，重启后连续几分钟都是 0，曲线恢复正常：

人做的事，就是先让它排查、再让它修。

落地 你也可以这样用

• 装好后先看 部署配置 → 部署状态，总览四张卡先扫一眼健康度
• 想确认有没有丢数据：ingest 页「写出丢弃」，点标题看说明
• 把「数据在丢怎么调」存进值班手册：在 AI 平台触发排查拿修复建议，让产品答疑专家 SSH 上去改 INGEST_DORIS_*、重启 ingest
• 定期让答疑专家来一次平台巡检，把报告转发给团队

结语 软件该有的自我修养

以前软件交付完就完事，出问题靠人盯、人查、人重启。DataBuff 干的事不复杂：把运维活儿内建到软件自己身上，跟你盯业务用同一套办法。

这次的丢数，从发现到上机修复，没让人翻过一次手册、猜过一次方向。