告警通知机制。总的来说，我们使用独自开发集成化统一告警平台遵循多渠道通知、细化通知内容及告警压缩的原则。集成化统一告警平台（我们的MessageIn平台 http://linkyoyo.com/messageIn/）

针对每个机器或者每个服务，来配置一个或者多个告警接收人，对于告警级别高的告警，配置告警接收电话及值班情况既可支持告警电话通知，对于急迫性没那么高的问题，默认会发生微信及邮件告警，在此系统中只需配置告警接收人的信息即可，大大节省了配置告警规则的时间。

当告警被触发时，我们会尽可能将所有的问题纳入在告警中，包括了报警的状态，具体触发报警的内容，报警的服务器及IP地址，告警持续的时间，当前状态的具体值，联系人和电话。

当有大量告警时候优先级的问题，优先级别高的通知，记录级别低的告警，不做告警处理。

支持多平台调用，灵活的通知方式 。

一般报警后我们故障如何处理，首先，我们可以通过告警升级机制先自动处理，比如nginx服务down了，可以设置告警升级自动启动nginx。但是如果一般业务出现了严重故障，我们通常根据故障的级别，故障的业务，来自动触发电话来通知不同的运维人员进行处理。

当然不同业务形态、不同架构、不同服务可能采用的方式都不同。

报警在发生后第一时间内有人处理并在规定的时间内处理完毕。如果未在规定的时间内处理完毕，监控中心会进行报警升级，通报该系统的管理人员，从而确保该报警可以得到更高的重视度和支持力度。

系统会对告警进行统计分析，将最近的告警进行分类，及产生报表。

对所以告警采用应对预案及处理机制，并定期进行真实测试。

期待更好的未来，我们的Raptor（监控管理）和MessageIn（消息告知平台）都已经整装待发了。

敬请期待。