以前，我写过几篇有关「线上问题排查」的文章，文中附带了一些监控图，有些读者对此很感兴趣，问我监控系统选型上有没有好的建议？前端
目前我所经历的几家公司，监控系统都是自研的。其实业界有不少优秀的开源产品可供选择，能知足绝大部分的监控需求，若是能从中选择一款知足企业当下的诉求，显然最省时省力。数据库
这篇文章，我将对监控体系的基础知识、原理和架构作一次系统性整理，同时还会对几款最经常使用的开源监控产品作下介绍，以便你们选型时参考。内容包括3部分。缓存
必知必会的监控基础知识安全
监控系统俗称「第三只眼」，几乎是咱们天天都会打交道的系统，下面 4 项基础知识我认为是必需要了解的。服务器
监控系统的7大做用网络
正所谓「无监控，不运维」，监控系统的地位不言而喻。无论你是监控系统的开发者仍是使用者，首先确定要清楚：监控系统的目标是什么？它能发挥什么做用？架构
实时采集监控数据：包括硬件、操做系统、中间件、应用程序等各个维度的数据。并发
实时反馈监控状态：经过对采集的数据进行多维度统计和可视化展现，能实时体现监控对象的状态是正常仍是异常。运维
预知故障和告警：可以提早预知故障风险，并及时发出告警信息。分布式
辅助定位故障：提供故障发生时的各项指标数据，辅助故障分析和定位。
辅助性能调优：为性能调优提供数据支持，好比慢SQL，接口响应时间等。
辅助容量规划：为服务器、中间件以及应用集群的容量规划提供数据支撑。
辅助自动化运维：为自动扩容或者根据配置的SLA进行服务降级等智能运维提供数据支撑。
使用监控系统的正确姿式
出任何线上事故，先不说其余地方有问题，监控部分必定是有问题的。
听着很甩锅的一句话，仔细思考好像有必定道理。咱们在事故复盘时，一般会思考这3个和监控有关的问题：有没有作监控？监控是否及时？监控信息是否有助于快速定位问题？
可见光有一套好的监控系统还不够，还必须知道「如何用好它」。一个成熟的研发团队一般会定一个监控规范，用来统一监控系统的使用方法。
了解监控对象的工做原理：要作到对监控对象有基本的了解，清楚它的工做原理。好比想对JVM进行监控，你必须清楚JVM的堆内存结构和垃圾回收机制。
肯定监控对象的指标：清楚使用哪些指标来刻画监控对象的状态？好比想对某个接口进行监控，能够采用请求量、耗时、超时量、异常量等指标来衡量。
定义合理的报警阈值和等级：达到什么阈值须要告警？对应的故障等级是多少？不须要处理的告警不是好告警，可见定义合理的阈值有多重要，不然只会下降运维效率或者让监控系统失去它的做用。
创建完善的故障处理流程：收到故障告警后，必定要有相应的处理流程和oncall机制，让故障及时被跟进处理。
监控的对象和指标都有哪些？
监控已然成为了整个产品生命周期很是重要的一环，运维关注硬件和基础监控，研发关注各种中间件和应用层的监控，产品关注核心业务指标的监控。可见，监控的对象已经愈来愈立体化。
这里，我对经常使用的监控对象以及监控指标作了分类整理，供你们参考。
硬件监控
包括：电源状态、CPU状态、机器温度、风扇状态、物理磁盘、raid状态、内存状态、网卡状态
服务器基础监控
CPU：单个CPU以及总体的使用状况
内存：已用内存、可用内存
磁盘：磁盘使用率、磁盘读写的吞吐量
网络：出口流量、入口流量、TCP链接状态
数据库监控
包括：数据库链接数、QPS、TPS、并行处理的会话数、缓存命中率、主从延时、锁状态、慢查询
中间件监控
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等多种通知通道。
主流监控系统介绍
下面再来认识下主流的开源监控系统，因为篇幅有限，我挑选了3款使用最普遍的监控系统：Zabbix、Open-Falcon、Prometheus，会对它们的架构进行介绍，同时总结下各自的优劣势。
Zabbix（老牌监控的优秀表明）
Zabbix 1998年诞生，核心组件采用C语言开发，Web端采用PHP开发。它属于老牌监控系统中的优秀表明，监控功能很全面，使用也很普遍，差很少有70%左右的互联网公司都曾使用过 Zabbix 做为监控解决方案。
先来了解下Zabbix的架构设计：
Zabbix架构图
Zabbix Server：核心组件，C语言编写，负责接收Agent、Proxy发送的监控数据，也支持JMX、SNMP等多种协议直接采集数据。同时，它还负责数据的汇总存储以及告警触发等。
Zabbix Proxy：可选组件，对于被监控机器较多的状况下，可以使用Proxy进行分布式监控，它能代理Server收集部分监控数据，以减轻Server的压力。
Zabbix Agentd：部署在被监控主机上，用于采集本机的数据并发送给Proxy或者Server，它的插件机制支持用户自定义数据采集脚本。Agent可在Server端手动配置，也能够经过自动发现机制被识别。数据收集方式同时支持主动Push和被动Pull 两种模式。
Database：用于存储配置信息以及采集到的数据，支持MySQL、Oracle等关系型数据库。同时，最新版本的Zabbix已经开始支持时序数据库，不过成熟度还不高。
Web Server：Zabbix的GUI组件，PHP编写，提供监控数据的展示和告警配置。
下面是Zabbix的优点：
产品成熟：因为诞生时间长且使用普遍，拥有丰富的文档资料以及各类开源的数据采集插件，能覆盖绝大部分监控场景。
采集方式丰富：支持Agent、SNMP、JMX、SSH等多种采集方式，以及主动和被动的数据传输方式。
较强的扩展性：支持Proxy分布式监控，有agent自动发现功能，插件式架构支持用户自定义数据采集脚本。
配置管理方便：能经过Web界面进行监控和告警配置，操做方便，上手简单。
下面是 Zabbix 的劣势：
性能瓶颈：机器量或者业务量大了后，关系型数据库的写入必定是瓶颈，官方给出的单机上限是5000台，我的感受达不到，尤为如今应用层的指标愈来愈多。虽然最新版已经开始支持时序数据库，不过成熟度还不高。
应用层监控支持有限：若是想对应用程序作侵入式的埋点和采集（好比监控线程池或者接口性能），Zabbix没有提供对应的SDK，经过插件式的脚本也能曲线实现此功能，我的感受Zabbix就不是作这个事的。
数据模型不强大：不支持tag，所以无法按多维度进行聚合统计和告警配置，使用起来不灵活。
方便二次开发难度大：Zabbix采用的是C语言，二次开发每每须要熟悉它的数据表结构，基于它提供的API更多只能作展现层的定制。
Open-Falcon（小米出品，国内流行）
Open-Falcon是小米2015年开源的企业级监控工具，采用Go和Python语言开发，这是一款灵活、高性能且易扩展的新一代监控方案，目前小米、美团、滴滴等超过200家公司在使用它。
小米初期也使用的Zabbix进行监控，可是机器量和业务量上来后，Zabbix就有些力不从心了。所以，后来自主研发了Open-Falcon，在架构设计上吸收了Zabbix的经验，同时很好地解决了Zabbix的诸多痛点。
先来了解下Open-Falcon的架构设计：
Open-Falcon架构图，来自网络
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中查询指标数据，汇总结果后统一返回给用户，屏蔽了存储集群的分片细节。
下面是Open-Falcon的优点：
自动采集能力：Falcon-agent 能自动采集服务器的200多个基础指标（好比CPU、内存等），无需在server上作任何配置，这一点能够秒杀Zabbix.
强大的存储能力：底层采用RRDTool，而且经过一致性hash进行数据分片，构建了一个分布式的时序数据存储系统，可扩展性强。
灵活的数据模型：借鉴OpenTSDB，数据模型中引入了tag，这样能支持多维度的聚合统计以及告警规则设置，大大提升了使用效率。
插件统一管理：Open-Falcon的插件机制实现了对用户自定义脚本的统一化管理，可经过HeartBeat Server分发给agent，减轻了使用者自主维护脚本的成本。
个性化监控支持：基于Proxy-gateway，很容易经过自主埋点实现应用层的监控（好比监控接口的访问量和耗时）和其余个性化监控需求，集成方便。
下面是Open-Falcon的劣势：
总体发展通常：社区活跃度不算高，同时版本更新慢，有些大厂是基于它的稳定版本直接作二次开发的，关于之后的前景其实有点担心。
UI不够友好：对于业务线的研发来讲，可能只想便捷地完成告警配置和业务监控，可是它把机器分组、策略模板、模板继承等概念所有暴露在UI上，感受在围绕这几个概念设计UI，理解有点费劲。
安装比较复杂：我的的亲身感觉，因为它是从小米内部衍生出来的，虽然去掉了对小米内部系统的依赖，可是组件仍是比较多，若是对整个架构不熟悉，安装很难一蹴而就。
Prometheus（号称下一代监控系统）
Prometheus（普罗米修斯）是由前Google员工2015年正式发布的开源监控系统，采用Go语言开发。它不只有一个很酷的名字，同时它有Google与Kubernetes的强力支持，开源社区异常火爆。
Prometheus 2016年加入云原生基金会，是继Kubernetes后托管的第二个项目，将来前景被至关看好。它和Open-Falcon最大不一样在于：数据采集是基于Pull模式的，而不是Push模式，而且架构很是简单。
先来了解下Prometheus的架构设计：
Prometheus架构图，来自网络
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的数据源，建立仪表盘以及查看指标。
下面是Prometheus的优点：
轻量管理：架构简单，不依赖外部存储，单个服务器节点可直接工做，二进制文件启动便可，属于轻量级的Server，便于迁移和维护。
较强的处理能力：监控数据直接存储在Prometheus Server本地的时序数据库中，单个实例能够处理数百万的metrics。
灵活的数据模型：同Open-Falcon，引入了tag，属于多维数据模型，聚合统计更方便。
强大的查询语句：PromQL容许在同一个查询语句中，对多个Metrics进行加法、链接和取分位值等操做。
很好地支持云环境：能自动发现容器，同时Kubernetes和etcd等项目都提供了对Prometheus的原生支持，是目前容器监控最流行的方案。
下面是Prometheus的劣势：
功能不够完善：Prometheus从一开始的架构设计就是要作到简单，不提供集群化方案，长期的持久化存储和用户管理，而这些是企业变大后所必须的特性，目前要作到这些只能在Prometheus之上进行扩展。
网络规划变复杂：因为Prometheus采用的是Pull模型拉取数据，意味着全部被监控的endpoint必须是可达的，须要合理规划网络的安全配置。
监控系统的选型建议
经过上面的介绍，你们对主流的监控系统应该有了必定的认识。面对选型问题，个人建议是：
先明确清楚你的监控需求：要监控的对象有哪些？机器数量和监控指标有多少？须要具有什么样的告警功能？
监控是一项长期建设的事情，一开始就想作一个 All In One 的监控解决方案，我以为没有必要。从成本角度考虑，在初期直接使用开源的监控方案便可，先解决有无问题。
从系统成熟度上看，Zabbix属于老牌的监控系统，资料多，功能全面且稳定，若是机器数量在几百台之内，不用太担忧性能问题，另外，采用数据库分区、SSD硬盘、Proxy架构、Push采集模式均可以提升监控性能。
Zabbix在服务器监控方面占绝对优点，能够知足90%以上的监控场景，可是应用层的监控彷佛并不擅长，好比要监控线程池的状态、某个内部接口的执行时间等，这种一般都要作侵入式埋点。相反，新一代的监控系统Open-Falcon和Prometheus在这一点作得很好。
从总体表现上来看，新一代监控系统也有明显的优点，好比：灵活的数据模型、更成熟的时序数据库、强大的告警功能，若是以前对Zabbix这种传统监控没有技术积累，建议使用Open-Falcon或者Prometheus。
Open-Falcon的核心优点在于数据分片功能，能支撑更多的机器和监控项；Prometheus则是容器监控方面的标配，有Google和Kubernetes加持。
Zabbix、Open-Falcon和Prometheus都支持和Grafana作快速集成，想要美观且强大的可视化体验，能够和Grafana进行组合。
用合适的监控系统解决相应的问题便可，能够多套监控同时使用，这种在企业初期很常见。
到中后期，随着机器数据增长和个性化需求增多（好比但愿统一监控平台、打通公司的CMDB和组织架构关系），每每须要二次开发或者经过监控系统提供的API作集成，从这点来看，Open-Falcon或者Prometheus更合适。
若是非要自研，能够多研究下主流监控系统的架构方案，借鉴它们的优点。
最后的话
本文对监控体系的基础知识、原理和主流架构作了详细梳理，但愿有助于你们对监控系统的认识，以及在技术选型时作出更合适的选择。
因为篇幅问题，本文的内容并未涉及到全链路监控、日志监控、以及Web前端和客户端的监控，可见监控真的是一个庞大且复杂的体系，若是想理解透彻，必须理论结合实践再作深刻。
对于运维监控体系，若是大家也有本身的经验和体会，欢迎留言讨论。
文章来源：IT人的职场进阶，点击查看原文。
Kubernetes管理员认证（CKA）培训
本次CKA培训课程，基于最新考纲，经过线下授课、考题解读、模拟演练等方式，帮助学员快速掌握Kubernetes的理论知识和专业技能，并针对考试作特别强化训练，让学员能从容面对CKA认证考试，使学员既能掌握Kubernetes相关知识，又能经过CKA认证考试，学员可屡次参加培训，直到经过认证。点击下方图片或者阅读原文连接查看详情。