亿级高并发系统的监控与报警

什么是系统监控

对于功能简单，用户量较少的软件系统，大部分公司不需要额外的监控系统来保证公司业务的正常运行。而当公司发展到一定程度，系统越来越多元化，单一系统也越来越复杂，面对的用户数量越来越多。为了能实时保证系统的正常与稳定和对外业务的实时监控，大部分互联网公司都会根据自己的系统架构和业务级别来设计并开发一套监控系统，例如阿里巴巴的＂鹰眼＂系统。

个巡 - 个推系统监控

随着个推业务的不断扩展，用户量不断的增加，个推急需一套完整的监控系统来实时保证系统和业务的正常运转。系统层面上，个推必须保证上亿用户在同时接入时的系统稳定和正常，业务层面上，个推需要通过实时数据来反应每天的业务增长和下降，个巡就是在这时孕育而生了。

系统难点与设计

多元化的数据

基于推送业务，个推扩展出许多独立运行的系统，而且每个系统的监控数据也不一样。为了保证系统的稳定和可扩展性，我们将所有数据来源分成了两类：一类为基于JMX的可配置型数据，另一类为独立封装的接入型数据，基于两种数据的特性，JMX数据设计为去主动收集，独立封装数据设计为被动接收。

庞大的节点分布

面对大量的用户，个推需要布置许多节点在不同的地域以保证业务的实时性。面对大量的节点，并发型的数据收集和接收设计是唯一方案，并且基于不同的数据来源我们也需要封装不同类型的线程和线程池，但大量多线程并发的带来的另一难点就是，共享资源的设计与分配，原子操作的保证与回滚，以及数据收集的准确性。基于此难点，代码结构上采用Producer-Consumer模式，以及进程与线程的设计思路。

复杂的业务逻辑

监控系统的另一功能就是能实时反应出公司业务的发展趋势并及时报警，为了保证个推的每一项决策都能反应在用户量与业务量上，我们的监控系统收集了大量的系统接入以及不同种类请求的数据。基于这些数据，许多分析策略和报警策略需要写入程序，因此使得业务逻辑异常复杂，动态的加载不同策越，Strategy 设计模式成为不二选择．

实时性的需求

监控系统的一大特性就是能够及时对异常数据进行报警，以及对大量数据的秒级收集，分类，分析和展示。因此，内存数据库(couchbase)和数据搜索引擎(elasticsearch)成为保证系统实时性的关键性中间键。

系统层面上，集成了包括Database, couchbase, elasticsearch, flume, kafka等一系列外部工具。

代码层面上通过试用不同的设计模式来帮助整套系统能够更好的兼容不同的数据，保证系统的稳定运行和数据的准确抓取和展示。

个巡的特点

异常日志报警

当系统有异常日志时， 会实时同步到个巡的ES。个巡一旦监控到有异常日志时，就会马上发告警信息给相应人员。这样我们会实时收到系统异常的问题，为及时处理线上的问题提供了必要条件。

周期性的比较

对于某些监控点，每天都应该有一个固定的趋势，如下图所示。我们通过前7天的数据更新这个趋势，当线上数据不符合这个趋势的时候，就发告警信息。

自监控

个巡是用来监控线上系统的，而个巡也是线上系统的一部分，那么个巡怎么做到自己监控自己呢？我们使用自动修改阀值的方式做到自监控。当修改阀值后，个巡会发送告警邮件，然后10分钟后再把阀值改成原来的样子，然后我们会收到恢复正常的邮件，并且整个过程是自动。所以当我们收不到自告警的邮件时，个巡本身就有问题了。

开发总结

相信很多项目都会遇到以上所提到的四种问题。实时上很多系统在开发的紧张过程中也难以从全局去审视和总结一些问题或经验，在这里我们仅提供其中一个视角去分析一个庞大的系统：当数据来源多元化的时候，开发人员务必保证在所有数据进入系统业务逻辑前的统一性，也就是常见的数据封装，这样才能保证在多变的需求环境下系统核心模块的稳定性；庞大的数据节点所带来的主要问题则为数据流的稳定性，因此在数据流传入和接受之间加入一层(也就是此系统的Producer-Consumer)来保证数据流的稳定性和可控性变得异常重要。复杂的业务逻辑是软件开发中最常见的问题，很多经典书籍都专门讨论过。但实际开发中，也别是开发周期较紧迫的时候，很难有一套具体且通行的解决方案，在个巡的开发中，我们也只能根据需求和业务逻辑来制订Strategy代码框架，实时性常常会因为数据量的增大而受到印象，在个巡的开发中我们采用的原则是数据分开存储，然后在根据不同的数据应用采用不同的数据库。