之前，我写过几篇有关「线上问题排查」的文章，文中附带了一些监控图，有些读者对此很感兴趣，问我监控系统选型上有没有好的建议？
目前我所经历的几家公司，监控系统都是自研的。其实业界有很多优秀的开源产品可供选择，能满足绝大部分的监控需求，如果能从中选择一款满足企业当下的诉求，显然最省时省力。
这篇文章，我将对监控体系的基础知识、原理和架构做一次系统性整理，同时还会对几款最常用的开源监控产品做下介绍，以便大家选型时参考。内容包括3部分：
必知必会的监控基础知识
主流监控系统介绍
监控系统的选型建议
01 必知必会的监控基础知识监控系统俗称「第三只眼」，几乎是我们每天都会打交道的系统，下面 4 项基础知识我认为是必须要了解的。
1. 监控系统的7大作用正所谓「无监控，不运维」，监控系统的地位不言而喻。不管你是监控系统的开发者还是使用者，首先肯定要清楚：监控系统的目标是什么？它能发挥什么作用？
实时采集监控数据：包括 硬件、操作系统、中间件、应用程序等各个维度的数据。
实时反馈监控状态：通过对采集的数据进行多维度统计和可视化展示，能实时体现监控对象的状态是正常还是异常。
预知故障和告警： 能够提前预知故障风险，并及时发出告警信息。
辅助定位故障：提供故障发生时的各项指标数据，辅助故障分析和定位。
辅助性能调优：为性能调优提供数据支持，比如慢SQL，接口响应时间等。
辅助容量规划：为服务器、中间件以及应用集群的容量规划提供数据支撑。
辅助自动化运维：为自动扩容或者根据配置的SLA进行服务降级等智能运维提供数据支撑。
2. 使用监控系统的正确姿势出任何线上事故，先不说其他地方有问题，监控部分一定是有问题的。
听着很甩锅的一句话，仔细思考好像有一定道理。我们在事故复盘时，通常会思考这3个和监控有关的问题：有没有做监控？监控是否及时？监控信息是否有助于快速定位问题？
可见光有一套好的监控系统还不够，还必须知道 「如何用好它」。一个成熟的研发团队通常会定一个监控规范，用来统一监控系统的使用方法。
了解监控对象的工作原理：要做到对监控对象有基本的了解，清楚它的工作原理。比如想对JVM进行监控，你必须清楚JVM的堆内存结构和垃圾回收机制。
确定监控对象的指标 ：清楚使用哪些指标来刻画监控对象的状态？比如想对某个接口进行监控，可以采用请求量、耗时、超时量、异常量等指标来衡量。
定义合理的报警阈值和等级：达到什么阈值需要告警？对应的故障等级是多少？不需要处理的告警不是好告警，可见定义合理的阈值有多重要，否则只会降低运维效率或者让监控系统失去它的作用。
建立完善的故障处理流程：收到故障告警后，一定要有相应的处理流程和oncall机制，让故障及时被跟进处理。
3. 监控的对象和指标都有哪些？监控已然成为了整个产品生命周期非常重要的一环，运维关注硬件和基础监控，研发关注各类中间件和应用层的监控，产品关注核心业务指标的监控。 可见，监控的对象已经越来越立体化。
这里，我对常用的监控对象以及监控指标做了分类整理，供大家参考。
3.1 硬件监控
包括：电源状态、CPU状态、机器温度、风扇状态、物理磁盘、raid状态、内存状态、网卡状态
3.2 服务器基础监控
CPU：单个CPU以及整体的使用情况
内存：已用内存、可用内存
磁盘：磁盘使用率、磁盘读写的吞吐量
网络：出口流量、入口流量、TCP连接状态
3.3 数据库监控
包括：数据库连接数、QPS、TPS、并行处理的会话数、缓存命中率、主从延时、锁状态、慢查询
3.4 中间件监控
Nginx：活跃连接数、等待连接数、丢弃连接数、请求量、耗时、5XX错误率
Tomcat：最大线程数、当前线程数、请求量、耗时、错误量、堆内存使用情况、GC次数和耗时
缓存 ：成功连接数、阻塞连接数、已使用内存、内存碎片率、请求量、耗时、缓存命中率
消息队列：连接数、队列数、生产速率、消费速率、消息堆积量
3.5 应用监控
HTTP接口：URL存活、请求量、耗时、异常量
RPC接口：请求量、耗时、超时量、拒绝量
JVM ：GC次数、GC耗时、各个内存区域的大小、当前线程数、死锁线程数
线程池：活跃线程数、任务队列大小、任务执行耗时、拒绝任务数
连接池：总连接数、活跃连接数
日志监控：访问日志、错误日志
业务指标：视业务来定，比如PV、订单量等
4. 监控系统的基本流程无论是开源的监控系统还是自研的监控系统，监控的整个流程大同小异，一般都包括以下模块：
