1.4.4 监控系统的选型分析及误区探讨
衡量一款监控系统是否符合需求，需要从多个维度进行考察。本节我们就从功能、性能、数据存储、服务发现、运维管理、开发语言、社区力度及生态发展、误区探讨这8个角度进行监控系统的选型分析。
1.功能
首先就是功能维度，它直接决定了能否实现开箱即用，从而缩短项目周期、降低成本等。如果一款监控系统达不到想要的功能，那么就需要进行二次开发，这样会增加项目的技术难度、复杂度以及延长项目周期等。
表1-3从主要维度对主流监控系统做了评估。
表1-3 主流监控系统对比
比如在功能上，相对于Open-Falcon，为什么会出现滴滴内部的基于Open-Falcon的DD-Falcon？是因为在功能上DD-Falcon相比于Open-Falcon，主要进行了如下改进。
·监控数据按服务单元分类。
·增加垃圾数据清洗。
·分级索引。
·精简RRA。
·巡检大盘支持同环比。
·重组看图首页。
·报警数据获取由推模式变为拉模式。
·去除告警模板。
·重新定义nodata。
2.性能
功能维度是监控系统选型中的一个重要参考维度，但不是唯一的维度。有时候性能比功能还要重要，况且性能和功能很多时候是相悖的，鱼和熊掌不可兼得。
小米初期是使用Zabbix来做监控的。Zabbix大名鼎鼎，成熟稳健，很多公司都在使用。小米也不例外，初期做运维开发的人员比较少，机器量、业务量也少，Zabbix可以很好地满足需求。但是随着业务的发展，MySQL出现了性能瓶颈。由于Zabbix是使用MySQL来存放监控历史数据的，假设一台机器有100个监控项，2000台机器就有20万个监控项。监控系统的数据采集没有高峰低谷，是持续性的、周期性的，一般是1分钟采集一次。机器量越来越大，数据量就越来越大，MySQL的写入逐渐成为瓶颈。小米尝试使用了业界的一些Proxy的方案，也尝试把采集周期调长，比如3分钟采集一次或者5分钟采集一次，但是都治标不治本。Zabbix有些数据采集是通过拉的方式，也就是服务器端主动探测的方式，当目标机器量大了之后，拉任务也经常出现积压。这些问题直接导致维护Zabbix的技术人员焦头烂额。因此，Falcon横空出世，Falcon经过了数家公司2亿多指标的海量数据验证，在稳定性、易用性方面都没有问题。
Prometheus也支持大规模的集群部署，在2019年结束的阿里“双十一”活动中，阿里云中间件官方在《不一样的双11技术：阿里巴巴经济体云原生实践》电子书中宣布Prometheus在全球大促中经受住了洗礼。连阿里内部的鹰眼系统也发布了全托管版的Prometheus服务，解决了开源版本部署资源占用过大、监控节点数过多时的写入性能问题，对于大范围、多维度查询时查询速度过慢的问题也做了优化。优化后的Prometheus托管集群在阿里内部全面支持Service Mesh监控以及几个重量级的阿里云客户，许多优化点也反哺了社区。托管版的Prometheus兼容开源版本，在阿里云的容器服务上可以做到一键迁移到托管版。
如图1-15所示，面对海量的监控数据和性能压力，阿里使用了联邦（Federation）的架构将监控压力分担到多个层次的Prometheus并实现全局聚合。在联邦集群中，每个数据中心部署单独的Prometheus，用于采集当前数据中心监控数据，并由一个中心的Prometheus负责聚合多个数据中心的监控数据。
针对每个集群的OS指标（如节点资源CPU、内存、磁盘等水位以及网络吞吐）、元集群以及用户集群K8S master指标（如kube-apiserver、kube-controller-manager、kube-scheduler等）、K8S组件（如kubernetes-state-metrics、cadvisor）、etcd指标（如etcd写磁盘时间、DB size、Peer之间吞吐量）等，架构被分层为监控体系、告警体系和展示体系3部分。监控体系按照从元集群监控向中心监控汇聚的角度，呈现为树形结构，其可以细分为3层：
·边缘Prometheus：为了有效监控元集群K8S和用户集群K8S的指标，避免网络配置的复杂性，将Prometheus下沉到每个元集群内。
·级联Prometheus：级联Prometheus的作用在于汇聚多个区域的监控数据。级联Prometheus存在于每个大区域，例如中国区，欧洲美洲区、亚洲区。每个大区域内包含若干个具体的区域，例如北京、上海、东京等。随着每个大区域内集群规模的增长，大区域可以拆分成多个新的大区域，并始终维持每个大区域内有一个级联Prometheus，通过这种策略可以实现灵活的架构扩展和演进。
·中心Prometheus：中心Prometheus用于连接所有的级联Prometheus，实现最终的数据聚合、全局视图和告警。为提高可靠性，中心Prometheus使用双活架构，也就是在不同可用区布置两个Prometheus中心节点，都连接相同的下一级Prometheus。
通过这样的架构部署模式，阿里的Prometheus从容应对了2019年“双十一”巨大流量带来的性能挑战。因此，性能是根据当前业务量做技术评估的一个重要因素。
3.数据存储
Zabbix采用关系数据库保存，这极大限制了Zabbix采集的性能。Nagios和Open-Falcon都采用RDD数据存储，Open-Falcon还加入了一致性Hash算法分片数据，并且可以对接到OpenTSDB，而Prometheus自研了一套高性能的时序数据库，在V3版本可以达到每秒千万级别的数据存储，通过对接第三方时序数据库扩展历史数据的存储。
图1-15 基于Prometheus联邦的全球多级别监控架构[1]
4.服务发现
在当下这个微服务与容器化的时代，很多企业的监控系统中，所有组件及配置均实现了容器化并由Kubernetes编排。如果需要在任意Kubernetes集群里都实现一键部署，且需要变更系统时仅需修改相关编排文件，那么Prometheus就是不二的选择了。Prometheus的动态发现机制，不仅支持swarm原生集群，还支持Kubernetes容器集群的监控，它是目前容器监控最好的解决方案。
5.运维管理
监控在运维中的核心地位不可动摇。
记得有一个老运维人员说过这么一句话：“监控如果真的做完美了，我们运维也就可以高枕无忧了，每天可以就看看监控数据，然后各种‘挑刺儿’就行了。”一言以蔽之，监控系统需要以人为本，让人使用、管理起来方便。
比如小米在研发Open-Falcon之前就面临着如下运维管理问题。
·管理成本高昂。为了让Zabbix压力小一点，整个公司搭建了多套Zabbix，比如多看自己用一套、电商自己用一套、米聊自己用一套，如果要做一些公司级别的统计，需要去多个数据源拉取数据。每套Zabbix都得有运维人员跟进，人力成本上升。
·Zabbix有易用性问题。比如Zabbix的模板是不支持继承的，机器分组也是扁平化的，监控策略不容易复用。Zabbix要采集哪些数据，是需要在服务器端做手工配置的，而这是一个本该省去的操作。
微服务监控有四大难点，分别是：
·配置难。监控对象动态可变，无法进行预先配置。
·融合难。监控范围非常繁杂，各类监控难以互相融合。
·排查难。微服务实例间的调用关系非常复杂，故障排查会很困难。
·建模难。微服务架构仍在快速发展，难以抽象出稳定的通用监控模型。
很多负责监控相关工作的读者在实际工作中会遇到告警的对接、告警的收敛、告警的可用性等问题，这些都是运维管理中需要考虑的问题。而Prometheus在这些方面都有解决方案。
2018年，爱可生数据库平台监控系统在数据库沙龙专场做过一次案例分享，这个案例对运维过程中的告警对接、收敛、可用性做了形象化的展示。
我们是一家乙方公司，通常服务于各种甲方，不同甲方有不同的需求。比如甲方如果有自己的监控系统，就会希望我们的监控系统能与它的监控系统进行对接。在与甲方接触过程中，我们曾遇到过这样的客户。有一天客户跟我们说他最新买的苹果手机被他换掉了，因为他的手机经常会死机，死机的原因就是他收到了太多的告警，最后他专门买了一个安卓手机用来接收告警。所以我们的第二个告警需求是，将告警进行收敛。假如长时间没有收到告警消息，你们是会认为自己的系统运行得很完美，还是会担心告警系统挂掉了？如果是告警系统挂掉了，不能及时把告警发出来，那么最后这个锅到底由谁来背？大家都不希望背锅，所以第三个告警问题是解决告警的可用性问题。
当然，运维管理还需要考虑到Web功能、画图展示、默认监控等。
以Nagios和Zabbix为例。一般来说，Nagios更容易上手，但Zabbix界面更美观。Zabbix的画图功能用得更舒服，且Zabbix会有很多默认监控，这给运维管理带来非常省心、舒适的感觉，Zabbix后续的批量监控实施也更为简单。对于Nagios，如果写好自动化脚本，处理相关工作也很简单，问题在于写自动化脚本很费神。
Prometheus虽然本身的画图展示功能非常一般，但是它借用了开源的产品Grafana，结合Grafana后，Prometheus的画图功能实现了质的突破。
6.开发语言
从开发语言来看，为了应对高并发和快速迭代的需求，监控系统的开发语言已经从C语言、C++语言、Java语言转移到了Go语言阵营，以Open-Falcon和Prometheus为代表。
Go语言凭借简单的语法和优雅的并发，在目前云原生场景下使用得越来越广泛。而且，目前在国内市场上，C语言主要用于单片机等底层开发领域，从中间件开发岗位需求和目前大量Java人员转型来看，Go语言在监控领域的活力还是非常高的。
从全世界来看，我国是Go语言爱好者最多的国家。在我国，Go语言开发者主要集中在北京、深圳、上海3个城市。在北京，由于做云计算的公司很多，不论是面向市场的公有云还是自建自用的私有云，开放平台技术、容器技术、集群管理技术、微服务和Serverless技术等都是Go语言擅长的方向。Go语言的应用主要集中在如下方向。
·服务器编程。以前使用C或者C++做的那些事情，现在用Go来做很合适，例如处理日志、数据打包、虚拟机处理、文件系统等。
·脚本编程。完全可以把Go当作Python来用，日常的各种自动化任务、小工具等都非常适合使用Go编写。
·网络编程。这一块目前应用最广，包括Web应用、API应用、下载应用。
·云平台。目前国外很多云平台都采用Go开发，CloudFoundy的部分组件、前VMware的技术总监自己出来做的Apcera云平台以及大名鼎鼎的Docker都是用Go开发的。
如表1-4所示，Go语言的项目中绝大多数可以在GitHub上搜到，在那里可以了解每个项目的实际功能、架构和使用场景，由于本书的主题和篇幅问题，这里不再展开。
表1-4 Go语言生态
7.社区力度及生态发展
对于目前流行的编程语言，如Java、Python，如果在使用过程中遇到了一些异常，基本上可以借助搜索引擎来解决，因为一个产品用的人越多，暴露的坑也就越多，对应的解决方案也就越多。这种方法对于监控系统同样适用，这可以让你“站在巨人的肩膀上”解决遇到的问题。
Zabbix、Nagios、Ganglia的确都是老牌的监控系统，它们分别在1997、1998、2001年左右出现，都具有系统稳定、成熟度较高等特点。Open-Falcon和Prometheus都是最近几年才出现的，虽然功能还在不断迭代和更新，但是它们借鉴了很多老牌监控系统的经验。尤其是Prometheus，作为CNCF第二个毕业的作品，其Google搜索量和GitHub活跃度非常高。Prometheus也是直接对接K8S环境的，非常适合云上使用。
8.误区探讨
伴随着企业的发展，企业内部的监控往往会经历无监控、半自动脚本监控、自动化监控、集群式监控、全方位立体监控等阶段。未来的监控，会朝着链路化、全息化、立体化、低成本、自愈性、无人值守等方向发展。
在进行监控系统选型之前可以先问自己一个问题：是否真的需要一个监控？
在搞清楚这个问题之后，还可以继续问自己一个问题：是否需要自己维护一套监控？很多初创型公司为了节省成本会选择直接购买与监控有关的云服务，自己只需要关注如何使用即可，其余的都可以外包出去。也有些公司采用内监控和外监控结合的形式，内监控是企业自己搭建自用监控系统，外监控是用外来的商业监控产品对产品的最外层接口和用户行为进行宏观监控。
很多人面对监控系统时会有一种自研的冲动，自研会有交接问题、KPI问题。如果之前自研的人不对监控系统进行维护了，会有什么问题？这些自研系统的交接会不会给新人挖坑般的噩梦体验？是否真的有自研的必要？如果不是KPI的压迫可以考虑如下问题：目前市面上的监控系统是否真的都无法满足目前业务需求？团队的核心竞争力真的就是监控系统吗？是否有足够的能力、人力、财力、精力来支持自研？
监控选型时切忌一味地追求性能或者功能，性能可以优化，功能可以二次开发。如果要在功能和性能方面做一个抉择的话，那么首选性能，因为总体上来说，性能优化的空间没有功能扩展的空间大。然而对于长期发展而言，生态又比性能以及功能都重要。
监控系统选型还有一个标准，就是尽量贴合团队的自身技术体系栈，比如我们团队是中间件方向、云原生方向，那么Java和Go语言就是团队自身的技术体系栈。在这个语言的基础上，团队可以合作、奋斗，拿出更多、更好、更棒的成果。
企业处在不同的成长时期也可以选择不一样的监控系统，CMDB+Zabbix在一定的量级以内还是非常靠谱和稳定的，一台机器就可以完成很多的监控业务。如果业务和技术并没有达到那个量级且中长期达不到那个量级，投入大量人力和物力实现的“巨无霸”，真的非常有意义和价值吗？很多经验丰富的技术人员用过的监控系统应该不下10种，每种监控工具都有自己的优缺点，并不是越新的技术就越好，不能盲目跟风，没有最好的，只有最合适的。Nagios虽然历史悠久，但是在实际运维中依然有它独立存在的意义，在一些基本的监控项目中甚至比高大上的Prometheus更加方便。比如针对最基本的监控ping和telnet port，Prometheus有一个up函数，但是其只有两个状态up和down，而Nagios对这种状态比较少的监控更为简单直接。盲目追新并不是监控选型的态度，专业的监控架构是综合实际使用情况去做设计、做规划的，可以根据实际情况结合使用多种监控。
十万的用户对应十万的架构方案，百万的用户对应百万的架构方案，千万的用户对应千万的架构方案，亿级的用户对应亿级的架构方案。这就好比我们团队中的一个成员在开会时提出的：“现在我维护的网关系统界面不太好看，我想请前端人员帮我美化一下。”我直接回复：“现在应该没有人接入你的网关吧？当前第一要务是接入，美化的事情并没有接入重要，当前也没有必要浪费前端资源。”什么阶段就应该做什么阶段的事情。
最后要说的就是不要迷信权威，不能人云亦云。不是别人说好就是好，一定要自己亲身试验过才有发言权，实践出真知，大家可以参见我在个人微信公众号“工匠人生”上发布的Prometheus作者的文章《PromCon上VictoriaMetrics和Prometheus的权威性能和正确性评估》[2]的译文。
[1] 级联Prometheus存在于几个大区，这些大区并非严格按地理区域划分，而是按使用量和中心节点位置来划分，如在亚洲区之外，又设立了同级的中国区，就是因为中国使用量大，且有中心节点（中心节点在这里即级联Prometheus）。
[2] 文章地址：https://mp.weixin.qq.com/s/NoQqY_ttTR7XU-QABDYLXg。