1. 系统关键指标缺失

监控建设从来都是一个持续的过程，没有一劳永逸的解决方案。在持续不断的监控运维中，我们不断去丰富和完善相关监控，常见的系统和应用层面的监控指标如下所示。

从上图中我们可以看到，监控的具体使用用户对监控指标的采集是非常宽泛的，不管是市面哪款监控系统，其提供的默认监控指标，可能是无法满足实际的场景需求。随着监控系统的持续运营和业务不断发展，采集更多监控指标的需求会越来越迫切，因此，我们希望监控系统能够提供自由扩充和灵活定制的能力。

2. 功能扩展困难重重

在持续的监控系统建设过程中，我们根据实际需求不断地完善采集指标。因此，监控平台是不是原生支持多种采集方式，可能会限制我们能力的发挥，比如监控网络、存储等硬件设备，我们就必须使用SNMP协议来获取监控指标数据，这应该是平台自带的一个基本能力。如果还要我们自己去从零实现，就相当于写了一个小型的监控软件。因此，这个监控系统应该提供扩展能力，要么是代码开源，要么是接口开放，我们可以根据实际需求去扩展模块和组件，从而达到我们业务不断发展的需求。

监控指标的不断扩充，指标数据需要存储的数据量也会越来越大，此时，对监控系统的QPS，就有非常高的要求。监控系统能否支持高并发的请求，直接就决定了这个监控系统能否使用。试想，如果一个监控系统三天两头出问题，那么用户可能就会流失，甚至是放弃这个监控系统的使用，转而去寻求更好的解决方案。

监控用户的使用过程中，对监控平台的期望SLA可能是100%，而实际能达到的SLA可能是99.9%(每年停机约9小时)。随着业务和技术的不断发展，监控用户对监控系统的要求也越来越高，SLA能不能再继续提高呢？

实际上，SLA的提高1个9，对系统的挑战都是非常大的，比如我们的架构是否支持，架构设计是否合理，架构有没有冗余，能不能支持水平横向扩容，存不存在单点故障，服务器资源是否足够，系统的并发是否是一条直线，等等众多的因素，直接决定了我们提供的监控系统SLA能否再继续提高。理想情况是，架构有冗余，当链路出现故障时，能够自动切换，能够有备机顶替；当容量出现不足时，能够加服务器就扩容，而能够自动负载均衡。

所以，我们在设计监控系统的时候，一定要学习互联网架构中的高并发，高可用，分布式架构设计方案。此后，无论是增加功能模块，或者是系统的整体升级，有了架构上的保障，可以做到按需进行升级扩展，而不用担心系统可用性问题，升级变更扩展对用户都是无感知的。

3. 系统可靠性毫无保障

当监控的主机规模达到5000设备，1万设备的时候，一般监控系统会出现瓶颈，系统的QPS持续增长，能否支撑7*24小时、365天稳定运行，是一个非常大的挑战，可以说，监控系统从来都是一个高并发系统，同时，也是一个大数据库系统，比如日增5T，10T，50T的数据，并且要求详细历史数据，保存周期需要7天，30天，甚至是1年，而趋势数据(将历史数据进行归档，如按小时的max,min,avg存储)则要求保留1年，2年或者是更久，那么监控系统的数据可能达到PB数据级别，其数据处理之道，和海量的大数据处理系统，有异曲同工之妙，采集->清洗->分析->入库->使用。

数据上报延迟，大致的原因有三个，一是采集器出现的问题，无法按照既定的周期采集到数据，或因原始数据不存在，或因采集器达到本身性能上限问题；二是监控系统的清洗，处理分析环节出现堵塞，表现为采集上报正常，数据未入库；三是数据处理后，不得正常入库，即为监控的数据库存在问题，表现为数据写入慢，查询慢，超过数据库的上限。这3种情况，不论是哪种情况，对用户来说，都是不可用的。

不误报，不漏报，不延迟，这是对监控系统的基本要求。误报就是数据处理出现问题，让用户降低对监控的信任感，如果长期存在误报情况，那么用户就会失去对监控的信任，逐步抛弃此监控系统。漏报就是本该发出的告警而没有发送出来，这种情况就更严重了，严重影响了用户的正常使用，严重降低了用户的预期，宛如晚点的飞机，不能准时达到目的地。延迟就是告警现在产生，明天才收到，这个情况说明监控系统已处于不可用状态。在本该故障的时候，告警收不到，在故障结束时，告警发出来，用户会完全不信任这个监控系统。如果监控系统连告警这个基本事情都做不好，那么算不上一个合格的监控系统，用户会将这个监控系统当做一个噪音对待。

当我们把数据上报，告警问题都解决后，系统能够正常工作，又会面临新的问题。用户反馈，能不能将告警做得更智能一点呢？试想一下，告警模块正常工作，用户每天收到1000条告警，甚至收到10000条告警，用户也会疯掉，这简直就是告警“轰炸机”，过多的告警，成为了噪音，干扰正常判断。因此，告警能否收敛的问题，成为了头等大事。

告警收敛，是指将多条策略相同、目标范围不同的告警进行合并发送，按照一定的规则进行收敛的一种告警发送方式。比如，我们一个云区域的网络故障，会造成该区域下所有设备不可达，那么ping不可达告警，则会逐条发送，如果该区域下1000条机器，是发送1条告警好呢？还是1000条好呢？相信绝大多数正常人会只想接收1条重要告警即可。告警收敛，将告警极大提高告警的精确性，真正让我们做到运筹帷幄之中而不慌乱，不至于让我们天天神经紧张，天天处于狼来了的局面，因为过多的告警，有温水煮青蛙效应，让我们会逐步失去对告警的敏感度，逐渐会因为过多的告警而完全不关注告警。

有了告警收敛，是不是就可以高枕无忧了呢？不，我们还需要故障关联 ，故障自动分析，为什么需要这个功能呢？试想，一个机架掉电，引起了15台设备全部宕机，从而引发了一系列故障，如API超时，HTTP拨测失败，DB连接数增长，那么能否找到root-cause呢？能否提供一条重要告警帮我们自动分析故障的根因呢？此时，故障关联和故障自动分析，显得格外重要。所以，监控系统，必须具备故障关联分析的能力，为我们的运维决策提供更准确的信息。

此外，监控系统能否对当前环境的性能进行分析，对系统容量分析，也将是一个重要能力，如对趋势预测，什么时候我们应该对业务进行扩容服务器，什么时候应该进行缩容服务器，当前的性能是否足够，是否还有优化的空间。而监控系统，因为有数据存在，是完全可以提供这一系列数据作为重要依据的。

4. 技术落后于业务发展

随着业务不断发展，组织架构会根据业务形态进行调整，不同人员，需要对应不同的权限，需要划分更多角色，如超级管理员，分级管理员，普通管理员，普通用户，甚至于针对菜单按钮级别更细粒度权限管控需求。如果监控系统一开始没有考虑到这些需求，则很难应对业务的增长需求。随着业务的发展，公司为了降低成本，可以将一些常规事项外包出去，此时，对权限的分级控制显得格外重要。在这个时候，监控系统不再是一个孤立的系统，必须和统一用户登录认证系统集成，实现配置，查询分离，才能够满足组织的业务发展。

随着业务不断发展，业务对监控系统提出了更高要求，比如要求“微秒级监控数据采样”，要求“秒级告警”，要求监控系统提供100%可靠信息，根据监控系统提供的系统容量指标数据，对业务应用的目标服务器、容器进行扩容或者缩容。监控系统作为一个底层依赖系统，此时将发挥更大价值。