北京
用Nagios监控一台服务器很简单，直到基础设施开始膨胀。Platform.sh（现Upsun）的工程师团队在过去几年里三次推倒重来，才摸清大规模监控的真正痛点。
第一次迁移：从单机脚本到分布式采集。早期用Nagios写死配置，每台新机器都要手动加监控项。VM数量过百后，配置管理成了噩梦。团队改用配置模板化，把"这台机器跑什么服务"的定义从监控系统中抽离，让自动扩缩容时的监控跟随业务自动生效。
第二次迁移：指标与日志分家后的统一难题。Prometheus负责指标，ELK堆栈管日志，Jaeger追链路——三套系统三个查询语法，故障排查时要在三个界面来回跳转。工程师的挫败感直接体现在平均恢复时间（MTTR）上。这次重建的核心是把"可观测性三支柱"塞进同一个查询层，用统一标签体系打通数据孤岛。
第三次迁移：成本与精度的博弈。数千VM产生的数据量让存储成本指数级上涨。团队发现80%的指标从未被查询过，却按同样的精度保留90天。解决方案是分层采样：核心服务秒级精度长期保留，边缘服务分钟级精度短期保留，查询时再按需降采样聚合。
三个反复出现的模式：一是配置即代码，所有监控规则进Git，变更可审计可回滚；二是标签标准化，服务名、环境、版本号强制统一，否则跨系统关联时字段对不上；三是渐进式切换，新老体系并行跑两周，指标差异报警后再切流量，避免"大爆炸"迁移的凌晨惊魂。
最反直觉的教训：监控系统的可靠性不能依赖被监控的基础设施。团队曾把监控数据库放在业务K8s集群里，集群故障时监控也跟着失联——相当于火灾时消防电话占线。第三次重建时，监控栈独立部署在隔离的故障域，甚至用了不同的云提供商。
从单台Nagios到统一可观测平台，没有银弹。每次迁移的驱动力都不是技术时髦，而是特定规模下的特定痛苦：配置爆炸、数据孤岛、成本失控。下一次重建会是什么触发？可能是AI生成的异常检测规则，也可能是边缘计算场景下的轻量级代理——但前提是真到了那个规模，真有那个痛点。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
