自带监控够用吗

云控制台自带的监控，平时看看够用，出事追因时不够用。搞清它的长处和短板，才知道什么时候要补自建手段。 一、够用的部分 基础资源监控各家都差不多：CPU 使用率、内存占用、磁盘空间和 IO、公网带宽，粒度大多到分钟级，配合阈值告警，能覆盖日常运维的大部分场景。CPU 突然跑满、磁盘快满这类问题，平台告警能第一时间把你叫起来，这部分等于白送，要用足：给每台机器的磁盘设 85% 告警、带宽设 80% 告警，多数磁盘写满事故都能提前几天预警出来。告警方式也检查一遍，短信、邮件、站内信至少开两种，只靠站内信的告警基本等于没有告警。 二、不够用的部分 短板集中在三处。一是历史留存短，不少平台指标只保留几天到几十天，想对比上个月的基线曲线做不到，容量规划缺依据，故障复盘时也拿不出当时的曲线，责任界定没有凭据。二是视角停在系统层，看得见 CPU 高，看不见是哪个进程吃的；看得见带宽涨，看不见是哪个连接在跑。三是告警渠道受制于平台，短信邮件之外接不到你的值班系统，告警到人这一步可能断链。 三、补齐的办法 系统层信息自己采：用 crontab 挂个定时任务，*/5 * * * * (uptime; df -h) >> /var/log/brief.log 2>&1，几分钟一行，留存多久自己说了算。进程和连接的历史用 atop 或 sar 记录，出问题时回放当时的进程状态，比事后猜强得多。告警链路把平台告警转接到自己的值班群或电话系统，确保夜里真能叫到人。采集脚本本身也要盯住，定时任务挂了没人知道是常见事故，给日志文件设个大小异常检查即可兜底。 四、结论 自带监控是及格线以上的标配，解决知不知道出事了；自建采集和告警解决知道为什么、找得到人。两者是补充关系不是替代关系，基础监控靠平台，深度监控靠自己，这样配最经济。