第1章告警系统概述

第一章：告警系统概述

大家好，我是老张。在运维这行摸爬滚打了十几年，今天咱们来聊聊告警系统。

说实话，我刚入行那会儿，告警基本靠吼。服务器宕了？同事喊一嗓子。磁盘满了？邮件通知一下。那时候哪有现在这么讲究。但后来系统越来越复杂，机器越来越多，我才意识到——没有告警系统，运维就是睁眼瞎。

告警系统，说白了就是帮你盯着系统状态的「哨兵」。它负责收集各种指标数据，一旦发现异常，就第一时间通知你。

我习惯把它比作汽车仪表盘上的报警灯。机油压力低了，它会亮；发动机温度高了，它也会亮。没有这些灯，你开着开着车就趴窝了，还不知道问题出在哪。

告警系统的核心流程其实很简单：

嗯，流程看着简单，但实际落地的时候，坑多着呢。后面我会一个个讲。

你可能要问：搞这么复杂干嘛？我手动看看不就行了？

我举个例子。我之前在一家电商公司，双十一大促的时候，几千台服务器同时跑。你让我一台台看？看到明年也看不完。而且很多问题，比如内存泄漏，它是一点点涨上去的。你肉眼根本看不出来。

告警系统的价值，主要体现在这几点：

核心观点：告警系统不是用来「看」的，而是用来「防」的。它的终极目标，是让用户感觉不到故障的存在。

市面上主流的告警系统，我基本都用过。Prometheus、Zabbix、Nagios，各有各的脾气。我简单说说我的感受。

特性	Prometheus	Zabbix	Nagios
架构	拉模式（Pull）	推拉结合	推模式（Push）
数据存储	时序数据库（TSDB）	关系型数据库/时序库	文件/数据库
告警规则	PromQL 表达式	触发器表达式	插件脚本
扩展性	强，适合云原生	中等，适合传统架构	弱，配置繁琐
学习曲线	中等	较低	较高
社区活跃度	非常活跃	活跃	逐渐衰退

Prometheus 是我现在最常用的。它天生为云原生环境设计，Kubernetes 集群监控基本都选它。

它的核心优势是拉模式。什么意思呢？就是 Prometheus 主动去目标机器上拉数据。这样你不用担心目标机器挂了导致数据丢失。而且它自带时序数据库，查询速度飞快。

我记得有一次，我们有个微服务集群，几百个 Pod 跑来跑去。用 Zabbix 根本没法搞，Pod 一重启 IP 就变了。但 Prometheus 配合服务发现，自动就找到了新的 Pod。嗯，这个场景下，Prometheus 确实香。

小技巧：Prometheus 的告警规则用 PromQL 写，非常灵活。比如你想监控「过去5分钟CPU使用率超过80%」，一行表达式就搞定。

Zabbix 是老牌选手了。它最大的特点是开箱即用。装好之后，模板一导入，各种监控项就自动出来了。

我早期做传统 IDC 运维的时候，Zabbix 是标配。它支持 SNMP、IPMI、Agent 等多种采集方式，对网络设备、服务器硬件的监控非常友好。

但 Zabbix 有个问题——配置复杂。尤其是告警通知的配置，各种动作、条件、媒介，绕来绕去。我曾经在一个项目里，光配置告警就花了两天。后来我学乖了，直接用它的 API 批量导入。

注意：Zabbix 的数据库容易成为瓶颈。监控项一多，MySQL 就扛不住了。建议用 TimescaleDB 或者分区表来优化。

Nagios 嘛，怎么说呢，它是告警系统的「老前辈」。很多现在的设计理念，都是从它那来的。

但说实话，Nagios 已经有点跟不上时代了。它的配置全是文本文件，写起来非常痛苦。而且它没有内置的时序数据库，历史数据查询很慢。

我当年第一次用 Nagios，光配置一个磁盘监控，就写了十几行脚本。后来换成 Zabbix，点几下鼠标就搞定了。那感觉，就像从手动挡换成了自动挡。

不过 Nagios 的插件生态很丰富。你几乎能找到任何你想监控的东西的插件。如果你有耐心折腾，它依然能干活。

下面这张图，是我自己画的。它展示了告警系统的核心知识结构。你可以先有个整体印象，后面我们会一个一个拆开讲。

这张图把告警系统拆成了四个核心模块。数据采集是基础，规则引擎是大脑，通知分发是手脚，可视化是眼睛。缺一个都不行。

好了，第一章就聊这么多。告警系统这东西，光看理论没用。后面我会带着你一步步搭建、配置、调优。到时候你就知道，这些知识点到底怎么用了。