• 实时采集监控数据：包括硬件、操作系统、中间件、应用程序等各个维度的数据；

• 实时反馈监控状态：通过对采集的数据进行多维度统计和可视化展示，能实时体现监控对象的状态是正常还是异常；

• 预知故障和告警：能够提前预知故障风险，并及时发出告警信息；

• 辅助定位故障：提供故障发生时的各项指标数据，辅助故障分析和定位；

• 辅助性能调优：为性能调优提供数据支持，比如慢SQL，接口响应时间等；

• 辅助容量规划：为服务器、中间件以及应用集群的容量规划提供数据支撑；

• 辅助自动化运维：为自动扩容或者根据配置的SLA进行服务降级等智能运维提供数据支撑。

• 了解监控对象的工作原理：要做到对监控对象有基本的了解，清楚它的工作原理。比如想对JVM进行监控，你必须清楚JVM的堆内存结构和垃圾回收机制；

• 确定监控对象的指标：清楚使用哪些指标来刻画监控对象的状态？比如想对某个接口进行监控，可以采用请求量、耗时、超时量、异常量等指标来衡量；

• 定义合理的报警阈值和等级：达到什么阈值需要告警？对应的故障等级是多少？不需要处理的告警不是好告警，可见定义合理的阈值有多重要，否则只会降低运维效率或者让监控系统失去它的作用；

• 建立完善的故障处理流程：收到故障告警后，一定要有相应的处理流程和oncall机制，让故障及时被跟进处理。

• CPU：单个CPU以及整体的使用情况；

• 内存：已用内存、可用内存；

• 磁盘：磁盘使用率、磁盘读写的吞吐量；

• 网络：出口流量、入口流量、TCP连接状态。

• Nginx：活跃连接数、等待连接数、丢弃连接数、请求量、耗时、5XX错误率；

• Tomcat：最大线程数、当前线程数、请求量、耗时、错误量、堆内存使用情况、GC次数和耗时；

• 缓存 ：成功连接数、阻塞连接数、已使用内存、内存碎片率、请求量、耗时、缓存命中率；

• 消息队列：连接数、队列数、生产速率、消费速率、消息堆积量。

• HTTP接口：URL存活、请求量、耗时、异常量；

• RPC接口：请求量、耗时、超时量、拒绝量；

• JVM ：GC次数、GC耗时、各个内存区域的大小、当前线程数、死锁线程数；

• 线程池：活跃线程数、任务队列大小、任务执行耗时、拒绝任务数；

• 连接池：总连接数、活跃连接数；

• 日志监控：访问日志、错误日志；

• 业务指标：视业务来定，比如PV、订单量等。

• 数据采集：采集的方式有很多种，包括日志埋点进行采集（通过Logstash、Filebeat等进行上报和解析），JMX标准接口输出监控指标，被监控对象提供REST API进行数据采集（如Hadoop、ES），系统命令行，统一的SDK进行侵入式的埋点和上报等；

• 数据传输：将采集的数据以TCP、UDP或者HTTP协议的形式上报给监控系统，有主动Push模式，也有被动Pull模式；

• 数据存储：有使用MySQL、Oracle等RDBMS存储的，也有使用时序数据库RRDTool、OpentTSDB、InfluxDB存储的，还有使用HBase存储的；

• 数据展示：数据指标的图形化展示；

• 监控告警：灵活的告警设置，以及支持邮件、短信、IM等多种通知通道。

下面是 Zabbix 的优势：

• 产品成熟：由于诞生时间长且使用广泛，拥有丰富的文档资料以及各种开源的数据采集插件，能覆盖绝大部分监控场景；

• 采集方式丰富：支持Agent、SNMP、JMX、SSH等多种采集方式，以及主动和被动的数据传输方式；

• 较强的扩展性：支持Proxy分布式监控，有agent自动发现功能，插件式架构支持用户自定义数据采集脚本；

• 配置管理方便：能通过Web界面进行监控和告警配置，操作方便，上手简单。

• 性能瓶颈：机器量或者业务量大了后，关系型数据库的写入一定是瓶颈，官方给出的单机上限是5000台，个人感觉达不到，尤其现在应用层的指标越来越多。虽然最新版已经开始支持时序数据库，不过成熟度还不高；

• 应用层监控支持有限：如果想对应用程序做侵入式的埋点和采集（比如监控线程池或者接口性能），zabbix没有提供对应的sdk，通过插件式的脚本也能曲线实现此功能，个人感觉zabbix就不是做这个事的；

• 数据模型不强大：不支持tag，因此没法按多维度进行聚合统计和告警配置，使用起来不灵活；

• 方便二次开发难度大：Zabbix采用的是C语言，二次开发往往需要熟悉它的数据表结构，基于它提供的API更多只能做展示层的定制。

• Falcon-agent：数据采集器和收集器，Go开发，部署在被监控的机器上，支持3种数据采集方式。首先它能自动采集单机200多个基础监控指标，无需做任何配置；同时支持用户自定义的plugin获取监控数据；此外，用户可通过http接口，自主push数据到本机的proxy-gateway，由gateway转发到server；

• Transfer：数据分发组件，接收客户端发送的数据，分别发送给数据存储组件Graph和告警判定组件Judge，Graph和Judge均采用一致性hash做数据分片，以提高横向扩展能力。同时Transfer还支持将数据分发到OpenTSDB，用于历史归档；

• Graph：数据存储组件，底层使用RRDTool（时序数据库）做单个指标的存储，并通过缓存、分批写入磁盘等方式进行了优化。据说一个graph实例能够处理8W+每秒的写入速率；

• Judge和Alarm：告警组件，Judge对Transfer组件上报的数据进行实时计算，判断是否要产生告警事件，Alarm组件对告警事件进行收敛处理后，将告警消息推送给各个消息通道；

• API：面向终端用户，收到查询请求后会去Graph中查询指标数据，汇总结果后统一返回给用户，屏蔽了存储集群的分片细节。

• 自动采集能力：Falcon-agent 能自动采集服务器的200多个基础指标（比如CPU、内存等），无需在server上做任何配置，这一点可以秒杀Zabbix；

• 强大的存储能力：底层采用RRDTool，并且通过一致性hash进行数据分片，构建了一个分布式的时序数据存储系统，可扩展性强；

• 灵活的数据模型：借鉴OpenTSDB，数据模型中引入了tag，这样能支持多维度的聚合统计以及告警规则设置，大大提高了使用效率；

• 插件统一管理：Open-Falcon的插件机制实现了对用户自定义脚本的统一化管理，可通过HeartBeat Server分发给agent，减轻了使用者自主维护脚本的成本；

• 个性化监控支持：基于Proxy-gateway，很容易通过自主埋点实现应用层的监控（比如监控接口的访问量和耗时）和其他个性化监控需求，集成方便。

• Prometheus Server：核心组件，用于收集、存储监控数据。它同时支持静态配置和通过Service Discovery动态发现来管理监控目标，并从监控目标中获取数据。此外，Prometheus Server 也是一个时序数据库，它将监控数据保存在本地磁盘中，并对外提供自定义的 PromQL 语言实现对数据的查询和分析；

• Exporter：用来采集数据，作用类似于agent，区别在于Prometheus是基于Pull方式拉取采集数据的，因此，Exporter通过HTTP服务的形式将监控数据按照标准格式暴露给Prometheus Server，社区中已经有大量现成的Exporter可以直接使用，用户也可以使用各种语言的client library自定义实现；

• Push gateway：主要用于瞬时任务的场景，防止Prometheus Server来pull数据之前此类Short-lived jobs就已经执行完毕了，因此job可以采用push的方式将监控数据主动汇报给Push gateway缓存起来进行中转；

• Alert Manager：当告警产生时，Prometheus Server将告警信息推送给Alert Manager，由它发送告警信息给接收方；

• Web UI：Prometheus内置了一个简单的web控制台，可以查询配置信息和指标等，而实际应用中我们通常会将Prometheus作为Grafana的数据源，创建仪表盘以及查看指标。

• 轻量管理：架构简单，不依赖外部存储，单个服务器节点可直接工作，二进制文件启动即可，属于轻量级的Server，便于迁移和维护；

• 较强的处理能力：监控数据直接存储在Prometheus Server本地的时序数据库中，单个实例可以处理数百万的metrics；

• 灵活的数据模型：同Open-Falcon，引入了tag，属于多维数据模型，聚合统计更方便；

• 强大的查询语句：PromQL允许在同一个查询语句中，对多个metrics进行加法、连接和取分位值等操作；

• 很好地支持云环境：能自动发现容器，同时k8s和etcd等项目都提供了对Prometheus的原生支持，是目前容器监控最流行的方案。

通过上面的介绍，大家对主流的监控系统应该有了一定的认识。面对选型问题，我的建议是：

本文对监控体系的基础知识、原理和主流架构做了详细梳理，希望有助于大家对监控系统的认识，以及在技术选型时做出更合适的选择。

由于篇幅问题，本文的内容并未涉及到全链路监控、日志监控、以及Web前端和客户端的监控，可见监控真的是一个庞大且复杂的体系，如果想理解透彻，必须理论结合实践再做深入。

对于运维监控体系，如果你们也有自己的经验和体会，欢迎留言讨论。