图片来自 Pexels
目前我所经历的几家公司，监控系统都是自研的。实在业界有很多精良的开源产品可供选择，能知足绝大部分的监控需求，如果能从中选择一款知足企业当下的诉求，显然最省时省力。
这篇文章，我将对监控体系的根本知识、事理和架构做一次系统性整理，同时还会对几款最常用的开源监控产品做下先容，以便大家选型时参考。
内容包括如下三部分：
必知必会的监控根本知识主流监控系统先容监控系统的选型建议必知必会的监控根本知识
监控系统俗称“第三只眼”，险些是我们每天都会打交道的系统，下面四项根本知识我认为是必须要理解的。
监控系统的 7 大浸染
正所谓“无监控，不运维”，监控系统的地位不言而喻。不管你是监控系统的开拓者还是利用者，首先肯定要清楚：监控系统的目标是什么?它能发挥什么浸染?
监控系统有如下七大浸染：
实时采集监控数据：包括硬件、操作系统、中间件、运用程序等各个维度的数据。实时反馈监控状态：通过对采集的数据进行多维度统计和可视化展示，能实时表示监控工具的状态是正常还是非常。预知故障和告警：能够提前预知故障风险，并及时发出告警信息。赞助定位故障：供应故障发生时的各项指标数据，赞助故障剖析和定位。赞助性能调优：为性能调优供应数据支持，比如慢 SQL，接口相应韶光等。赞助容量方案：为做事器、中间件以及运用集群的容量方案供应数据支撑。赞助自动化运维：为自动扩容或者根据配置的 SLA 进行做事降级等智能运维供应数据支撑。利用监控系统的精确姿势
出任何线上事件，先不说其他地方有问题，监控部分一定是有问题的。听着很甩锅的一句话，仔细思考彷佛有一定道理。
我们在事件复盘时，常日会思考这三个和监控有关的问题：
有没有做监控?监控是否及时?监控信息是否有助于快速定位问题?可见光有一套好的监控系统还不足，还必须知道如何用好它。一个成熟的研发团队常日会定一个监控规范，用来统一监控系统的利用方法。
如何利用监控系统?总结如下四个方面：
理解监控工具的事情事理：要做到对监控工具有基本的理解，清楚它的事情事理。比如想对 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 与 K8s 的强力支持，开源社区非常火爆。
Prometheus 于 2016 年加入云原生基金会，是继 K8s 后托管的第二个项目，未来前景被相称看好。
它和 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 进行加法、连接和取分位值等操作。很好地支持云环境：能自动创造容器，同时 K8s 和 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 和 K8s 加持。Zabbix、Open-Falcon 和 Prometheus 都支持和 Grafana 做快速集成，想要都雅且强大的可视化体验，可以和 Grafana 进行组合。用得当的监控系统办理相应的问题即可，可以多套监控同时利用，这种在企业初期很常见。到中后期，随着机器数据增加和个性化需求增多(比如希望统一监控平台、打通公司的 CMDB 和组织架构关系)，每每须要二次开拓或者通过监控系统供应的 API 做集成，从这点来看，Open-Falcon 或者 Prometheus 更得当。如果非要自研，可以多研究下主流监控系统的架构方案，借鉴它们的上风。末了的话
本文对监控体系的根本知识、事理和主流架构做了详细梳理，希望有助于大家对监控系统的认识，以及在技能选型时做出更得当的选择。
由于篇幅问题，本文的内容并未涉及到全链路监控、日志监控、以及 Web 前端和客户真个监控，可见监控真的是一个弘大且繁芜的体系，如果想理解透彻，必须理论结合实践再做深入。
对付运维监控体系，如果你们也有自己的履历和体会，欢迎留言谈论。
作者：骆俊武
简介：前亚马逊工程师，现 58 转转技能总监，持续分享个人的发展经历，希望为你的职场发展带来些新思路。
编辑：陶家龙
出处：转载自微信公众号 IT 人的职场进阶
