1. 概述

此处的监控系统是指，用来对计算机硬件、软件运行情况进行监控的系统。
监控系统要监控的指标或内容多种多样，根据不同的侧重点、不同的层次划分，监控系统又有多种实现。例如，Zabbix、Promethos、Open-falcon、Skywalking、CAT等等。
因此，很难简单的概括监控系统的定义。

2. 作用

监控系统可以为用户提供
• 实时的关键指标监控展示、和告警能力
• 记录数据，提供故障回溯和风险预测依据
• 优化系统的依据

3. 层次划分

从监控对象的设计角度看，监控系统可以分为以下层次。
• 基础监控：监控操作系统相关基础性能指标和信息，如CPU负载、磁盘存储、网络等情况，例如Zabbix、Prometheus等系统
• 资源监控：资源主要指为应用系统提供通用能力的软件系统，如数据库、MQ、缓存等 如Prometheus，Skywalking等
• 应用程序监控：监控应用程序的相关指标，如服务健康状态，接口性能，调用链路追踪等 如CAT、Pinpoint、Skywalking等
• 日志监控：日志贯穿所有层次，每个层次可能都需要依赖日志作为基础，是一个纵向的监控

此外，在这些层次，还可以划分业务层次，如对业务指标进行监控等，也可以直接涵盖在应用程序监控层次中。监控系统的监控对象，并不是完全按层次划分的。
监控系统可能专注于某一个层次的监控，也兼有其他层次的监控对象。但是并不赞同一个监控系统全面监控所有的指标，这会大大增加监控系统的复杂度，造成数据存储和处理的压力，且在业务上不能有的放矢。
按照上面的分层、Zabbix、Promethos更偏向基础监控和资源监控，后者通过exporter插件提供对资源的监控。而一些APM系统（应用性能管理），则偏向应用系统监控和资源监控，对基础监控的能力较弱。

4.监控作用域

除了按照上述的监控对象层次划分，还可以按照监控系统能力的作用域来划分。监控系统的最根本作用是实时的数据观察能力，而这种能力可以划分为3个领域：logging、tracing、metrics
• Logging：记录孤立的没有关联关系的独立事件，如普通的日志，每条日志之间没有直接的管理关系
• Metrics：可以聚合/统计的数据，例如调用请求次数、响应时间等
• Tracing：一段范围的数据，如一个请求经历了哪些服务、经历了哪些层次

如上图所示，越偏向下的作用域，记录的数据规模越大。
按照此方式，ELK是更侧重Logging的监控，虽然Kibana也提供了Metrics统计的能力，但是还是需要依赖应用自定义规则主动埋点，从而赋予Event业务意义，让其产生关联；
而CAT、Skywalking等分布式追踪系统，就更偏向Tracing，Metrics，展示记录Logging的能力相对较弱。

5. 监控系统的组成

目前，主流的监控系统主要由3个部分组成：数据采集、数据处理、数据展示，数据处理还可以拆分为存储、告警等。

5.1 数据采集

指通过多种方式采集客户端的相关指标，可以客户端主动采集，也可以被动采集或两者兼有。采集方式有两种：
• 客户端采集：在应用中部署的客户端，通过客户端采集相关数据执行传输。如Agent、Exporter
• 协议采集：操作系统、JVM提供了IPMI、SNMP、JMX标准协议来获取硬件、网络、JVM等指标

5.2 数据传输

将采集到的数据传输至服务端进行处理，传输方式有
• Socket长链接：客户端与服务端保持长链接，点对点传输，传输高效但链接的维护成本增加，尤其是在海量监控对象时。CAT中，服务端是不负责维持链路的，有客户端管理自身的链路。
• Http协议：
• Pull模式：Agent如果充当Server角色，服务端则通过commet模式读取数据
• Push模式：Agent充当Http客户端，调用服务端上报数据
• MQ传输：Agent将消息发送到MQ中，实现解耦，流量整形。但是强依赖MQ，可能引发故障。

5.3 数据处理

对数据进行分析聚合等操作，用于产生告警、进行存储，并利于展示分析

5.4 数据存储

由于监控数据的特点，时间是一个非常明显且独特的指标，且随着时间不断变化这种数据可以被归类为时序数据，其特点为：
• 写多读少，且时序数据写入后，通常不会再进行修改
• 数据流平稳，即数据量与采集节点数成正比，相对稳定，且随着时间不断增加
• 查询主要以时间为纬度，热数据通常在几小时内
所以，监控系统的数据存储通常使用TSDB（时序数据库），关系型数据库使用B+树实现，时序数据库使用LSM树实现。

5.5 数据展示

监控数据的展示方式有很多种，大部分监控系统自身提供了展示数据的控制台，也可以利用类似Kibana、Grafana这种独立应用处理数据进行展示