监控告警体系你会怎么建？
五个经典回答示范
我的监控体系分三层：资源层——CPU、内存、磁盘、网络（ Prometheus 加 node_exporter 标准方案）；服务层——进程存活、端口、接口成功率与延迟、JVM/连接池等中间件指标；业务层——订单量、支付成功率等核心业务指标（异常往往业务层最先感知）。告警设计：分级（警告/严重/紧急）、收敛（聚合去重防风暴）、值班与升级机制。
我讲一次告警治理：接手时每天 300 条告警，全是狼来了没人看。治理三步：清洗——下线无意义告警（常年满载的测试机）、合并（同机房同维度聚合成一条）；分级——按影响面定级别，P0 打电话其他进群；闭环——每条严重告警必须有处理记录，周报统计告警有效率。两个月后日均 20 条，响应率从 30% 到 100%。监控的价值不在采集在告警质量——没人信的告警系统等于没有。
资深视角：监控体系的服务对象是决策——故障时缩短定位时间，平时发现劣化趋势。三个设计原则：可观测三支柱齐备——metrics 看趋势、logging 看细节、tracing 看链路，只有 metrics 的监控定位不了复杂问题；SLO 驱动——围绕用户可感知的可用性目标设计指标与错误预算，告警基于 SLO 燃烧率而非单机阈值；自愈与演练——常见故障自动处置（磁盘清理、进程拉起）加故障演练验证监控盲区。监控是成本中心也是保险，衡量它的价值用 MTTR 与事故逃逸率。
追问『Prometheus 和 Zabbix 怎么选』：动态云环境与容器选 Prometheus 生态（服务发现与拉模型），传统静态机房 Zabbix 上手快；『业务监控怎么做』：埋点落库加实时聚合（Flink 或定时任务）出核心指标大盘，异动告警用同环比与波动区间；『误报太多怎么办』：阈值改动态基线（基于历史分位数）、告警加持续性条件（连续 N 次才报）。
『监控装个 Zabbix 加 CPU 内存模板就完事了，告警全发邮件爱看不看，出问题再看日志找原因，监控就是个摆设，重在人工经验。』——点评：无服务与业务层的监控发现不了用户视角的故障——机器全绿用户全挂是常态；『人工经验』在凌晨三点的故障前不堪一击。
- 打开 模拟练习，选择「运维/DBA」方向，限时 3 分钟作答本题。
- 对照上方答题框架，逐点检查：哪些要素没覆盖、哪里表达啰嗦。
- 用自己项目的真实经历替换框架中的占位内容，重讲一遍并录音回听。
这类题在真实面试中常被追问细节，
建议进入限时模式练一遍。