自建监控还是买现成的？按规模与运维能力判断
从监控边界、指标规模、运维所有权、总成本与退出风险出发，比较自建与采购现成监控方案的适用条件，给出三类团队的选择路径和四周试点验收方法。
监控与可视化工具的选型，最常见的误判是把问题压缩成一句“开源自建省钱，商业采购省事”。真正决定结果的，不是功能清单长短，而是三件事：指标和告警有多复杂、谁承担这套系统的日常运维、数据能不能离开机房。
没有统一答案：有稳定平台团队、指标规模可控且数据需要留在内网，自建更合适；缺少专职负责人、希望快速拿到可用告警，优先买现成。 本文只讨论形态选择，不做厂商排名，也不引用具体报价。
一、监控、可观测性与研发效能看板不是一回事
监控回答“系统现在是否正常”，典型形态是指标、阈值和告警；
可观测性回答“为什么异常”，需要指标、日志和链路追踪能够相互关联；
研发效能看板回答“交付流程是否顺畅”，关注构建失败率、发布频率和需求交付周期。三者数据源和消费人都不同。
很多团队把它们打包成一个采购项目，结果买了应用性能监控，却发现告警没人分级；或者搭了一套指标系统，却做不出管理层要的交付报表。选型前先列需求清单：基础设施指标、应用性能、日志检索、链路追踪、告警值班、研发交付度量。逐项标注“必须有”或“可以后补”，这张清单决定你比较的是不是同一类方案。
另一条容易混淆的边界是 DevOps 平台。GitFox 是禅道 DevOps 解决方案的内置核心组件，定位为一体化 DevOps 底层引擎，承接代码托管、代码评审、流水线、制品库等交付环节；它与禅道的分工是，禅道管理需求、任务和缺陷，GitFox 负责从代码到发布的执行链路。它的效能度量看板关注构建、发布和交付效率等研发数据，不替代基础设施监控。底层已剥离海外开源内核依赖，适合有私有化部署和信创要求的团队。先确认你要的是交付度量还是系统监控，再判断是否需要在平台之外单买一套监控。
二、规模不看人数，看指标和告警的复杂度
团队人数只是代理指标。更可靠的规模维度有四个：
监控目标的数量和变化速度。几十台固定虚机和数百个随时扩缩的容器，采集配置、标签规范和服务发现的难度不在一个量级。
活跃时间序列数量。把用户 ID、请求路径直接做成标签，会让时间序列快速膨胀，内存和存储随之失控。
数据保留和查询范围。Prometheus 官方文档（2026 年 11 月查阅）明确说明，本地存储不集群、不复制，默认保留 15 天；要长期保存或跨集群查询，需要 remote write、Thanos 一类外部存储和查询层。
告警规则和值班强度。规则越多，越需要有人做分级、抑制和降噪，否则告警会被静音，监控形同虚设。
一个实用判断是：监控对象稳定、指标规模可控、15 天保留够用，自建的边界很清楚；如果指标基数随业务快速变化，还要长期留存和跨集群查询，复杂度已经超出“装一个 Prometheus”的范围。
三、运维能力看四件事，不只看有没有运维岗
自建的成本不只在部署。至少要回答四个问题：
所有权。谁负责升级、扩容、备份和故障恢复？没有明确负责人，系统很容易在半年后变成没人敢动的黑盒。
值班。凌晨告警响了谁处理？监控系统自己挂掉时，谁判断是业务故障还是监控故障？
升级与兼容。Prometheus、Grafana、各类 Exporter 的版本升级会带来配置和面板兼容问题，需要固定窗口和回滚方案。
存储与容量。按采集速率和保留时间估算磁盘；Prometheus 官方建议把保留容量控制在磁盘的 80%-85%，给压缩过程留出余量。
这四件事里有两件没有稳定负责人，买现成服务通常更稳；如果已有平台团队，监控只是其职责的一部分，自建才具备可持续性。
四、三类企业团队的典型选择
把规模和运维能力放在一起，可以看到三类典型路径：
团队特征 | 更适合的形态 | 关键理由 | 先验证什么 |
|---|---|---|---|
10-50 人，1-2 名运维或平台工程师，服务数量有限 | 现成服务或云监控 | 快速获得可用告警，不把有限人力压在监控系统本身 | 告警到达率、月度用量增长 |
50-300 人，有平台团队，容器和微服务占比较高 | 混合 | 核心指标自建可控，日志、链路和长期存储交给托管服务 | 跨数据源查询、数据导出 |
300 人以上，多集群多地域，金融、政企或军工场景 | 以自建为主，关键能力采购补足 | 数据不出域、合规审计和容灾要求更高 | 高可用切换、审计记录、容灾演练 |
规模只是起点，不是硬门槛。 同样 200 人，业务稳定程度、服务数量和数据约束不同，结论可能相反。
一个 40 人的 SaaS 团队，服务不到 20 个，运维只有一个人，却要跨三套系统查告警，这种状态不适合自建；反过来，一个 150 人的团队已有 Kubernetes 平台组，指标要保留一年并支持多集群查询，继续用单机 Prometheus 只会把问题推迟。
五、如何评估投入成本？
自建的直接软件成本低，但服务器、存储、带宽、人力、升级和故障处理要放进同一张表。采购现成方案也不只是订阅费，还要看采集量、留存时长、自定义指标、跨云出网和长期归档的计费方式。
更常被忽略的是退出成本：指标能否批量导出、告警规则能否迁移、历史数据能否带走、团队是否要重新学习查询语言。评估一款监控与可视化工具时，让对方明确数据导出格式和迁移协助的边界，比逐项比较功能更能降低后续风险。 不要用“先上线再说”跳过这一步。
六、企业如何落地？
无论倾向哪种，先用一个边界清楚的范围验证四周：
第 1 周，选 2-3 个核心服务，统一指标命名和标签规范，记录当前从故障发生到被发现的时间。
第 2 周，接入候选方案，只配置 10 条以内真正需要值班的告警，观察误报和漏报。
第 3 周，模拟一次依赖故障，走完从告警到定位的路径，记录需要跳转几个系统。
第 4 周，核算人力投入、数据增长和月度用量，形成继续或放弃的明确结论。
验收条件要写成可量化指标：关键告警 5 分钟内到达、误报在可接受范围、故障定位不需要登录三套以上系统、数据可以导出。达不到就换形态，而不是继续加人硬撑。
把决定收束成三个问题
监控系统本身故障时，团队能否在 30 分钟内恢复？不能，优先买现成。
指标规模和保留要求是否已超出单机 Prometheus 的边界？超出，考虑混合或托管。
数据是否必须留在内网，并需要合规审计？是，优先私有化自建或私有化托管。
三个问题没有标准答案，但答案会指向同一条原则：谁离故障最近、谁承担运维，谁就应该主导监控与可视化工具的选型。
