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

什么是系统监控

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

 

个巡 - 个推系统监控

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

 

系统难点与设计

多元化的数据

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

庞大的节点分布

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

复杂的业务逻辑

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

实时性的需求

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

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

代码层面上经过试用不一样的设计模式来帮助整套系统可以更好的兼容不一样的数据，保证系统的稳定运行和数据的准确抓取和展现。

 

个巡的特色

异常日志报警

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

 

周期性的比较

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

 

自监控

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

开发总结

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