监控选型

监控的概念

监控的定义

通过技术手段发现服务异常，持续优化业务可用性与用户体验。这句话的关键词是 发现 持续优化 可用性与体验。

监控的方式

主动： 程序内部埋点，服务主动上报自身的运行情况，一般都是具化为业务的各个属性或者指标，这种方式准、快，灵活性好，指标丰富。但是在非标准框架下会有一定的代码改造成本。

被动： 无需埋点，从外部探测或获取服务的运行情况，例如ping探测、日志采集分析等等。

旁路： 与程序逻辑无关，对服务质量与口碑的监控，例如舆情分析。

监控的类型

类别	描述
硬件系统	温度、硬件故障、电源、风扇状态等
系统监控	nginx、Tomcat、PHP、Mysql、Redis等
日志监控	系统日志、服务日志、访问日志、错误日志
安全监控	WAF、 敏感文件监控
API监控	可用性、接口请求、响应时间
业务监控	例如电商网站，每分钟产生多少订单，注册多少用户，多少活跃用户，推广活动效果
流量分析	根据流量获取用户想关信息，例如用户的地理位置、某页面访问状况、页面停留时间等

监控的作用

1. 实时采集监控数据
2. 反馈监控状态
3. 预知故障和告警
4. 辅助定位问题
5. 辅助性能调优
6. 辅助容量规划
7. 辅助自动化运维

如何使用

1. 了解监控对象的工作原理
2. 确定监控对象的指标
3. 定义合理的报警阀值和报警等级
4. 建立完善的故障处理流程

运维监控选型

zabbix

国内使用ZABBIX非常广泛，移动互联网没有发展起来之前，这基本就是唯一的选择，对机器的监控非常全面，也非常灵活，各类监控插件，各类教程，在网上应有尽有。软件本身经过多年的发展，bug基本不会遇到了，相对比较稳定。

另外最重要的，ZABBIX既有监控能力，又有告警能力，是一套体系化的解决方案。

缺点有几个：

1. 产品易用性比较差，管理监控策略、服务器分组都不是太方便
2. 容量有限，ZABBIX的监控数据使用MySQL存储，MySQL没法良好的扩展，这导致ZABBIX监控的机器量有限，如果1分钟采集一次监控指标，大约可以监控2000台设备，如果10秒采集一次，大约可以监控400台设备
3. 对业务模块监控能力较差，监控指标描述的数据格式比较死板，与最新的监控领域的推荐做法相比，还是差了一个时代

总结： 如果只是对机器做监控，不需要做业务监控，设备量也不多，可以使用；如果设备量较大，而且对业务监控有需求，比如监控业务模块各个接口的QPS、延迟、成功率等等，ZABBIX就不太合适了。

CACTI

CACTI最常见的使用场景是监控网络设备，网工常用利器，核心原理就是通过SNMP协议去采集交换机数据，机器或者业务一般不用CACTI。

注意，CACTI没有报警能力，一般搭配NAGIOS使用。

Nagios

这也是一个很老牌的监控系统，看界面就知道了，一股浓浓的旧时代的感觉。在当下2020年，已经不推荐使用这样的系统了，这里也不做过多介绍。

InfluxDB/M3/OpenTSDB

随着移动互联网的发展，大家对网站稳定性的要求越来越高，而监控作为提升稳定性的重要抓手，对它的要求也不止是要监控机器、交换机了，还有非常多的模块、业务的监控诉求，这导致监控指标呈爆炸式增长。

监控系统的难点，实际是大容量高性能的时序数据的存储和查询，于是涌现了非常多的时序数据库，专门来解决这个问题，比如InfluxDB、OpenTSDB、M3DB等。所以，这些工具，不算是监控系统，只能算是监控系统的一个存储库。

如果我们具备自研能力，能够自己编写告警引擎，那就可以基于这些时序数据库构建自己的监控告警系统，但是这需要非常多的开发工作，也不是特别建议。

Open-Falcon

Open-Falcon是小米开源的一款监控系统，用来解决大容量监控场景，小米刚开始使用ZABBIX，但是ZABBIX容量有限，所以他们搭建了三套ZABBIX，这样一来，要做一些全局的统计、看图，就会非常麻烦了。

另外，小米是随着移动互联网发展起来的，公司有非常多的业务指标需要监控，ZABBIX难以胜任，于是，他们开发了一个内部的大一统监控系统，就是Falcon，后来开源了，名字就是Open-Falcon。

Open-Falcon被很多公司使用，除了小米，还有美团、滴滴、金山云、七牛、360、京东金融，等等，超过200家商业公司在用，现在来看，已经非常稳定了。既能解决机器监控的场景，也能解决业务监控的场景。

但是，Open-Falcon的易用性较差，页面是后台研发人员写的，比较糙，阉割掉了小米内部的服务树功能，真正落地的时候一般都是要二次开发，和自己公司的系统打通，但是Open-Falcon的存储组件、告警引擎的设计，都可圈可点，这也是为什么都是大公司使用，并且都做了二次开发。

Prometheus

在当下，2020年，聊监控肯定要聊Prometheus，Prometheus的作者，都是从Google跳槽出来的，基本就是Google内部的Borgmon的开源版本，和Kubernetes整合的很好，随着Kubernetes的火爆，Prometheus也建立了非常强大的影响力。

Prometheus的优点很明显，和Kubernetes有良好的整合，这是最大的优势，毕业于CNCF，一提到云原生，就会提到Prometheus。

Prometheus的查询引擎也非常厉害，支持PromQL，非常灵活，可以对数据做各种实时计算。

但是，Prometheus也有一些自己的问题，最大的问题是单点，虽然查询引擎有PromQL很灵活，但是单点问题削弱了这种灵活性的价值，告警策略是基于配置文件的不太方便，学习成本较高，告警事件的处理缺少了一些生产级的灵活性。不过近年来出现了Thanos，号称是大规模Prometheus解决方案，大家可以调研尝试一下。

Nightingale

Nightingale，中文是夜莺，是近来滴滴开源的一款监控系统，核心研发人员就是Open-Falcon的研发人员，可以看做是Open-Falcon的升级版本。

Nightingale融入了滴滴内部的监控实践，据说监控指标达到7亿，这个数据量是非常吓人的。他们有一个商业版本的运维平台，Nightingale就是从那个商业版本的运维平台里摘出来的。

夜莺有服务树，弥补了Open-Falcon长期以来被诟病的点，易用性大为提升，看官方介绍，相比Open-Falcon也有很多性能提升架构优化。看图告警策略配置都有页面，这点比Prometheus要好一点，策略非常灵活，支持告警升级、告警收敛、告警时段、与条件告警等等，看起来确实是生产级的灵活性。

另外他们融入了日志监控，可以从日志里抽取业务指标，比如接口的QPS、延迟、成功率等，这点比较适合国内环境，因为国内IT界，大都不愿意用SDK埋点的方式采集监控指标，读取日志，相对更接地气一些。

看这个架势，Open-Falcon估计是不会维护了，毕竟Open-Falcon的主力研发都去搞Nightingale了，大家选型的时候要注意。

链路监控选型

在微服务横行的年代，没有链路级监控简直就是灾难。技术在不断的发展过程中，总是会有新的工具被推出来，它们存在的价值就是解决问题。链路监控工具存在的价值就是尽快找到微服务中哪一个环节是最慢的。

简介

Zipkin是Twitter开源的调用链分析工具，目前基于springcloud sleuth得到了广泛的使用，特点是轻量，使用部署简单。

Pinpoint是韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能强大，接入端无代码侵入。

SkyWalking是本土开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能较强，接入端无代码侵入。目前已加入Apache孵化器。

CAT是大众点评开源的基于编码和配置的调用链分析，应用监控分析，日志采集，监控报警等一系列的监控平台工具。

原理

类别	实现方式
Zipkin	拦截请求，发送（HTTP，mq）数据至zipkin服务
Pinpoint	java探针，字节码增强
SkyWalking	java探针，字节码增强
CAT	代码埋点（拦截器，注解，过滤器等）

接入

类别	Zipkin	Pinpoint	SkyWalking	CAT
接入方式	基于linkerd或者sleuth方式，引入配置即可	javaagent字节码	javaagent字节码	代码侵入
agent到collector的协议	http,MQ	thrift	gRPC	http/tcp
OpenTracing	√	×	√	×

分析

类别	Zipkin	Pinpoint	SkyWalking	CAT
颗粒度	接口级	方法级	方法级	代码级
全局调用统计	×	√	√	√
traceid查询	√	×	√	×
报警	×	√	√	√
JVM监控	×	×	√	√

页面UI展示

类别	Zipkin	Pinpoint	SkyWalking	CAT
健壮度	**	*****	****	*****

数据存储

类别	Zipkin	Pinpoint	SkyWalking	CAT
数据存储	ES，mysql,Cassandra,内存	Hbase	ES，H2	mysql,hdfs

PinPoint和skyWalking支持的插件对比

类别	Pinpoint	SkyWalking
web容器	Tomcat6/7/8,Resin,Jetty,JBoss,Websphere	Tomcat7/8/9,Resin,Jetty
JDBC	Oracle,mysql	Oracle,mysql,Sharding-JDBC
消息中间件	ActiveMQ, RabbitMQ	RocketMQ 4.x,Kafka
日志	log4j, Logback	log4j,log4j2, Logback
HTTP库	Apache HTTP Client, GoogleHttpClient, OkHttpClient	Apache HTTP Client, OkHttpClient,Feign
Spring体系	spring,springboot	spring,springboot,eureka,hystrix
RPC框架	Dubbo,Thrift	Dubbo,Motan,gRPC,ServiceComb
NOSQL	Memcached, Redis, CASSANDRA	Memcached, Redis

性能分析

摘自： https://juejin.im/post/5a7a9e0af265da4e914b46f1

模拟了三种并发用户：500，750，1000。使用jmeter测试，每个线程发送30个请求，设置思考时间为10ms。使用的采样率为1，即100%，这边与生产可能有差别。pinpoint默认的采样率为20，即50%，通过设置agent的配置文件改为100%。zipkin默认也是1。组合起来，一共有12种。下面看下汇总表：

从上表可以看出，在三种链路监控组件中，skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显，在500并发用户时，测试服务的吞吐量从1385降低到774，影响很大。然后再看下CPU和memory的影响，在内部服务器进行的压测，对CPU和memory的影响都差不多在10%之内。

参考文档：

SkyWalking：性能监控工具之链路级监控及常用计数器解析
运维监控系统 - 选型篇
调用链选型之Zipkin，Pinpoint，SkyWalking，CAT