告警系统的设计

现在告警系统可以说是系统的必备部分，只要有监控，就需要一个告警系统来帮忙主动推送消息，以此减少人不停的主动查看监控的作用。
在最初的告警系统中，基本主要就是设置阈值，达到阈值就发生告警。这个在机器数量少的时候是满足需求的。例如10个进程，就算都出问题也就是10条告警。在使用的过程中，随着进程数量的增多，告警种类的增多。会出现告警的洪荒，一直不停的收到告警。

重复性

为了准确的传达告警信息，告警的设计要只要问题不解决就需要一直告警，否则很容易出现告警信息不可达，人查看的时候忽略了。这种问题，需要让告警持续的发送，直到解除为止。

分级

这里为了减少告警信息，我们会设置告警的级别。

cpu >80 严重
80 > cpu > 50 一般

然后发送告警的时候加上告警级别，邮件的规则根据告警的级别进行分类，就可以很容易的去找出严重的优先处理，一般的紧急程度就低一些。

静默

虽然通过级别可以筛选出一些特别重要的信息，但是告警是一直持续发送的。例如cpu只要还在超过80，一定的时间间隔内，就会继续发送告警，严重级别的邮箱很快也多起来。而且是同一个告警的不同时间的信息。这个时候如果有其他严重级别的告警的时候，很容易被冲刷掉。导致了一定的延后性，需要指望这个告警信息也不停的发送，如果间隔时间不一样的话，很容易出现一些失误。
这里就需要有一个静默功能。
例如我收到了A进程的cpu使用率的告警，我现在开始去做处理，这时候并不能立马解决这个问题。可以通过静默的功能，把A进程的cpu告警取消发送。直到解决了问题以后再打开。中间过程如果再继续收到信的告警，就需要再次注意了，证明和手头正在解决的不是同一个问题。

抑制

我们想一个场景，现在有如下的告警设置

• 物理机宕机告警
• 进程探活告警
• api接口超时告警

当物理机宕机后，上面的所有进程肯定也都停止了，探测api的检测功能也检测不到api能正常返回了。于是触发了3条告警信息。但他们描述的根源的原因是同一个。如果一个机器上有20个进程，总共有300个api。那么就会一下子收到1+20+300=321条告警信息。这么多告警信息，人收到都是迷茫的，主动静默都是很大的工作量。得静默321条情况，这里也能直接选择把告警去掉，也怕别的程序也这个时候出了问题，导致告警的丢失。
这里就需要告警的抑制。上面表达是一个包含关系，api超时的原因是进程停止了，进程停止了原因是物理机停止了。这种场景其实报告物理机的宕机告警就可以。
也是就是物理机告警，进程告警，端口告警同时出现的时候，物理机的告警要抑制进程告警，抑制api告警。

路由设置

告警信息的通知是需要多样的，例如什么样的告警，什么样的级别通过什么样的形式发送（邮件，短信，电话）。这个是需要分层的。越紧急的事情就需要越紧急的方式，例如普通的告警就发送邮件就可以了。但是严重的告警，管理员可能晚上睡着了，邮件的消息通知可能不能被看到，这里可能就需要通过电话开通知。选择了更可靠的方式。