创业公司如何快速构建高效的监控系统？

12 月 7 日，在 2018 ArchSummit 全球架构师峰会·运维与监控专场，七牛云资深运维开发工程师贺强带来了主题为《如何快速构建高效的监控系统》的内容分享。

本文是对演讲内容的实录整理。

你们好，今天给你们带来的分享是如何在创业公司去搭建一套高效快速的运维系统。我演讲的主要内容有：谈到高效，咱们如何来定义所谓的高效的监控系统；如何作好一个监控系统的选型和设计；七牛云内部的监控系统介绍；最后会和你们一块儿来探讨监控的发展趋势以及将来展望。

如何定义「高效」的监控系统？

在我认为，高效的系统应该包含如下几个特性：高可靠、易扩展、自适应、开放性。

01 高可靠

全部的可以体现高可靠的几点信息，第一是整个系统没有单点的模块，无单点的风险，这是咱们平常作系统或者作运维、作系统设计的时候须要首先考虑的问题。第二是自己会提供一个丰富的自采集系统层面的监控项，包括系统内核、设备、应用的一些资源消耗等信息。第三是它所支持的监控种类比较丰富，由于咱们如今的应用的类型也比较多，像常见的对应用监控的需求，好比日志监控、端口监控、RPC 监控等等，这些可以很方便的进行添加和管理。第三点是比较基础的，高效、延时低，不管是数据采集、上报、计算处理、再到通知，以及到用户收到这个通知，整个效率是比较高的，这也是和高效可以对应起来的。最后是易于 debug，若是开发人员说监控没有报警或者误报警，如何 debug 这个信息，快速修复问题。这是我对高可靠的一些认识。

02 易扩展

它实际上是咱们系统的开发过程当中，对于运维侧以及部署和扩容方面的考虑，这个系统很容易扩容和部署，它的依赖比较小。其次，它可以达到快速部署的基础是它的数据存储是要集群化管理，而不是数据和单机绑定，它的服务逻辑层须要去可水平扩展，随着业务对监控的需求不断增长，监控的压力变大的时候，可以快速地进行服务层面的水平扩展。

03 自适应

我认为这点比较重要。咱们不少传统的监控系统都是比较机械一点，为何说机械？就是说它监控的添加、修改之类的，都是须要咱们人工手动的作一些不少冗余的操做，而不能随着服务器服务，咱们监控对象的生命周期的运转，好比说服务器上线、下线、运维、维修、新添加的服务或者服务下线，可以进行动态关联，监控也随着这些对象的生命周期进行变化。还有是人员流转，咱们常常会遇到公司内部的员工入职、转岗、离职等方面，还会随着他的岗位状态运转可以自动匹配，是否对它进行报警发送以及删除。

04 开放性

首先是要对外提供 SDK 或者 API ，除了咱们本身运维侧采集一些监控，提供一些既有的监控，还容许第三方开发和其余的人员对监控人员 push 一些数据，以及对这些数据的读取、处理。

这样几个特征，我认为是构成高效监控系统的必要因素。

如何作好监控系统的选型和设计？

谈这点须要基于公司的现状去谈这个选型和设计。由于在创业初期，最开始可能对运维和监控的关注度并不高，咱们在这块用于很粗粒度的方式去解决。拿七牛云来讲，从如今往前推一年的时间，用的监控有 32 套单机版的 Prometheus。

具体说说它的问题。首先单机 Prometheus，它是一个开源很强大的单机版监控，它的问题也是它的特色，有一套很牛逼的查询语法，支持强大的数据查询功能，可以知足各类方位、各类姿式对数据的需求，经过它的语句组合。这样也致使了一个问题，运维人员若是没有深刻研究这套语法的话，就很难掌握灵活的语句去配置你的报警，存在的问题是少数人可以掌握这个问题，学习成本比较高，而精通的人更少。

目前这个 Prometheus 没有比较好的分布式解决方案，因此出现了 32 套 Prometheus分业务去构建它的监控，并且可能一个业务里面还存在多套 Prometheus，由于受到单机性能的影响，随着监控指标数据量不断增长，出现了这个瓶颈，出现以后咱们还要再进行扩容。这样长时间下来，会出现多套集群套用，数据和配置分布杂乱，无统一入口。

咱们作的更可能是添加监控、修改阈值和条件，原生的 Prometheus 是经过配置文件的方式，Prometheus 启动的时候加载，而后会出现的配置文件大概有好几千行，一行表明一个监控，一行是一个很是复杂的查询语句，天天有好多监控的需求，须要重复的修改这些配置文件，无界面化管理，操做效率很是低。

最后一个问题，我认为比较重要的是监控和咱们的业务服务器，还有业务服务之间没有一个动态关联关系。由于都是静态的，有任何一方的改动均可能出现误报的状况，咱们调整了机器扩容或者下线机器，须要彻底手动修改配置和 Prometheus。

基于这样的状况，咱们指望改善这个现状，由于这样的规模只会让状况变的愈来愈糟，不符合高效运维的定义。

首先设立几个目标，第一个是如何把这 32 套 Prometheus 进行统一化、统一入口，做为一个运维的统一监控平台，来知足咱们全部业务对于平常监控和数据处理、查询、报警的需求，第一个目标是化简为繁。第二是可视化，包括监控配置可视化和数据展现可视化。第三是动态关联，保持监控对象的动态感知能力。

第四个也比较重要，咱们作一套新的监控，必需要考虑老的监控的东西须要往新的东西迁移，在迁移的时候，必需要考虑成本。若是作一套彻底和新的结构迁移出东西，成本会很是高，还有历史数据的迁移，咱们用了监控数据作一些东西，它的数据确定还会迁移到新的数据上来，让它继续发挥做用。它如何迁移、如何进行兼容，咱们首先定义了一个目标。

基于这个目标，咱们作一个方案选型，首先仍是考虑 Prometheus，由于咱们之前用的是 Prometheus，它也很强大，咱们不肯意放弃。

优势是组件少、部署很方便；PromQL 强大的数据查询语法。它有很是强大的查询数据的方法，好比说一般会对数据进行打标签，对这个数据的标签进行一些组合，而后查询到你须要的这些数据，在这些组合基础上，它还能够提供一些很方便的函数，好比说求和、求平均值、求方差、求最大最小、求分位数，咱们一般须要写一些代码或者写一些脚原本知足这些函数可以简单达到的效果。

第三，它是一个很是高可靠的时序数库，相似于一些优秀的数据库，很是符合咱们监控时序数据的存储和展现。第四，它具备很是丰富的开源社区 exporter。Prometheus 社区里面会有一些针对各类开源软件的数据收集的一些组件，都能找到对应的 exporter 组件，只要把它跑起来，不用做为一个 DBA 或者专业的运营人员，你也能够很方便的拿到数据库应该关注的指标，而后这些指标的数据表现形式是什么样的，并且配套的在平台上已经有不少开源的东西，甚至能够一键导入，能够很方便的生成数据库的大盘数据。

说完优势，咱们直面它的缺点。主要是数据集群多、配置管理低下、配置报警起来没有界面，很是痛苦。

咱们会调研下一个监控方案，就是 Falcon，这也是一套国内比较优秀的监控系统。它有如下几个优势：首先组件都是分布式的，没有单点模块，这符合咱们高可靠的要求，每一个稳定性都很高，由于它在设计的时候彻底考虑到了用户的使用策略，因此全部的操做都是基于页面完成，这点比较人性化，并且支持了很丰富的监控方式和方法。

可是基于基于咱们公司的原有监控，也有一些缺点。咱们考虑迁移的时候，原有的监控都须要废弃，须要作两种格式的兼容，成本很高，历史数据也不能很方便的一键导入，这也是须要直面的两个问题。

咱们怎么作呢？咱们的选择方案是 Prometheus 分布式化，再加上 Falcon 高可用，但愿可以打造一款既知足高可靠、兼容性好、配置比较简单的一套系统来解决咱们监控的痛点，作到取长补短。

七牛云内部监控系统介绍

首先说一下咱们监控系统在解决上面几个问题的时候，最终作出的一些比较有特点的地方。第一是联动服务树，不少公司里面都会拥有本身的监控平台，其中服务树是一个很核心的组件，联动服务树是刚才提到的一个动态关联的基石。第二个是分布式 Prometheus，能够进行数据存储和告警功能。还有一点是咱们的监控是具备自动故障处理的特征功能。还有一个是监控自动添加。除了咱们提供人工添加的途径外，还能够自动添加。

接下来具体介绍一下架构。

左侧绿色是咱们内部的运维平台，里面的两个小块 Portal 和服务树是两个和监控有密切交互的组件。右侧是整个监控系统，监控系统里面核心是分布式 Prometheus，底下是咱们的服务器集群，这是咱们机房的业务机器，上面有一个 agent。具体它们之间工做的流程：咱们的分布式 Prometheus 主要提供 API 层的一些策略管理、一些监控添加，还有一些数据的存储、告警触发。这边是把咱们的操做进行界面化，以及 API 层面存储的工做。服务树是管理咱们整个运维体系中这些对象的一个工具，它和分布式 Prometheus 之间会有一个同步的机制。Alarm 会负责告警处理、告警消息的处理，包括合并、分级、优先级调整等工做。还有咱们的告警自动处理模块、数据聚合模块，用来计算出咱们整个告警处理的效率和长尾统计分析的模块。还有 agent，它是系统数据收集模块。

接下来详细介绍如下几个主要的内容。

首先是服务树。左侧这一列能够看出它是树状结构的东西，它是一组基于惟一 id 和 pid 生成的树状结构组织，能够将运维的对象和树节点关联起来，包括平常的服务器、服务、初始化策略、监控策略、部署任务等等，能够称之为它的运维对象。它和某一个节点关联起来，就变成了某一个服务上面有哪些机器，以及它有哪些初始化策略、有哪些监控策略、有哪些部署任务，这些均可以和服务树关联起来。只要咱们维护好这个服务树，就能够管理好平常的监控、发布、初始化等一切需求，包括服务署下面的服务器扩容、缩容，也能够在这个服务树上来管理，它是这样一个组织关系。

Portal 这块有不少功能，首先说一下监控性的功能，它是一套带 UI 的配置功能，对于监控，配置的监控项是配置监控策略、配置自定义脚本、配置值班信息、查看告警信息和历史数据。

咱们配置的一些条件，多是咱们上报上来的东西，里面有一些 Tags，咱们设置它的一些值，匹配好以后，能够对这个数据进行求和、求平均、求最大、求最小，基于此会生成一条查询语句，这样构成了一个监控策略，其实是一条模板化的查询语句，而后在这边修改。还有告警级别、告警间隔、最大告警次数等信息。

还有自定义插件，由于如今监控的需求比较多，不少需求很难经过监控系统自己来实现，因此咱们提供了插件的功能，只须要任意用脚本去写，而后按照咱们的格式输出，就能把你的格式收集上来，配置对应的监控项就能够，它是绑定在某一个服务上面的脚本，针对这些服务作某些监控。

上图有一些告警数据的告警截图。咱们分不一样的颜色展现不一样的告警级别，多是一些微信的发送、以及对应的短信的分级通知机制。

最重要的一点是分布式 Prometheus，由于 Prometheus 目前没有开源的集群化解决方案，咱们是和第三方的公司进行合做开发的，用它们对原生分布式 Prometheus 进行改造，同时归入咱们服务树的一些核心的点，进行考虑合做开发一套适合公司使用的分布式 Prometheus。对于原生 Prometheus 的原生改动，主要就是把它对存储进行分离，而后把它的查询层和告警计算进行拆分，进行了多级的高可用素质，存储方面进行了存储分片、查询调动。其次是设计一些API，可以把 Prometheus的查询语句进行模板化，监控策略配置的时候，把它升级为一条条的存储语句存储起来，就是把原生 Prometheus 一万多条的配置文件进行系统化、界面化的过程。

由于模板语句比较复杂，因此咱们提供了一个自动生成模板语句的功能，凡是用户本身配置的自定义脚本，好比要生成监控的某一个东西，只要这个监控脚本提交了这个系统，系统会自动调用它，而后给它生成模板语句，不须要关心就能够看到模板语句，有他要求的 Tags，有一些对应的约束值。

下面介绍咱们的 alarm，基于 Open-Falcon 的 alarm，首先改形成分布式的，进行告警合并、告警优先级的策略，咱们一般会遇到某些机器异构的状况，咱们对一批机器加一个优先级告警，可能有一些机器满一两块都没有关系，咱们对它进行一些特殊的策略设置。好比说告警的监控加在这块和子节点上，咱们但愿看到 95% 的告警进行告警，告警发生过来的时候，会有一些优先级策略的判断，会对它进行默认的屏蔽，不会通知到用户。

这个告警接入公司统一的信息通告平台，它支持咱们几种用户的通知方式，重要的告警直接打电话，不重要的分别有短信、微信这些方式去通知。

还有一个是 task，它是一个同步的模块。主要涉及到服务树上面关联的信息，经过异步的方式通知给服务器那边。就是咱们服务上有哪些机器、端口是什么、进程名是什么、机器是否发生了变更、它的值班人员是什么，都会异步去通知给 Prometheus 那边，Prometheus 那边知道我这个服务上面加了哪些监控，而后从用户配置的监控策略去查询到这些数据以后去匹配这些阈值，接到告警以后，推送给值班人员，是这样一个过程，这是 task 模块起到数据同步的过程。

Auto-recovery 是咱们作的监控自愈的模块。咱们要针对某一个监控设定必定的处理机制，若是它知足某些条件，咱们就对它进行自动处理。自动处理的东西是人工处理好，主要的工做流程是：在告警那边收到消息，但这个告警消息是分告警策略的，这个信息属于哪条策略，而后这个策略会对应一些规则，匹配到这些规则再去看，规定了这些告警在什么状况下知足我定义的条件，多长时间执行了多少次，而后进行 action。由于在每台机器上都会有服务器，咱们有执行器，而后执行到对应的服务器，执行完以后，会把对应的结果推到微信群，历史记录和日志之类的能够去查看，这是监控自愈的状况。

这是监控自动聚合统计的内容，告警发生了认领的过程，体现了故障处理的效率；还有一个是从认领到故障恢复，故障处理用了多长时间，它来体现咱们的值班效率；还有一些告警，可能它发生的频次会比较多，咱们去经过一些大数据计算的方法，而后提炼出在零散的告警里面体现不出来的一些问题，最后经过这个中心去把它发掘出来，并进行一个个的处理和追踪。

而后再说一下咱们的 agent。咱们这个 agent 的特色是除了收集常见的几百项监控指标以外，凡是绑定了端口的服务，这个服务进程所占用的系统资源、进程级别的，都会收集到。还有一些协议级别的，好比说我这个机器上有经过一些网络请求调动另一个协议，这个开关比较耗资源，在某些部门才会用，打开以后它就会生成一些 Tags，而后在绘图的过程当中能够看到两个服务之间消耗状况的一些指标。

还有插件执行器，我要在这个机器上执行某脚本，只要是可执行文件就行，符合咱们监控系统的格式要求。

而后是 push-gateway，本地有一个 API，业务方但愿把服务运行过程当中的一些指标实时上报监控进行报警绘图，只要我有了 agent，就能够往 API 上面 push 数据，程序上面直接调用，就能够把数据推送到监控系统中来，进行对应的告警。

最后是探活，咱们 agent 的存活保证了全部数据的可用性，可能咱们 agent 已经挂掉了，若是没有收到告警就以为一切都正常，能够探活每一个 agent 的数据上报，若是有一段时间内没有收到 agent 的探活上报，说明全部的告警已经失效了，这是做为内部监控的数据。

以上就是咱们内部监控的总体介绍。总结一下，目前这套系统首先已经代替了 32 套单机的 Prometheus 监控，全部的操做都在界面上进行完成，全部的监控都是具备必定的自动处理机制。在咱们发布的时候，也会去自动添加这个服务相关的服务器基础建构和服务的进程端口、重要接口的一些监控。

监控的展望

第一个是说咱们也比较想作好，由于如今的系统微服务比较多，相互调用的链比较复杂且比较长，如今在单机的告警状况下，客户报一个故障上来以后，咱们很难快速的定位究竟是哪一个环节、甚至哪一个函数出现了问题，而是须要人肉筛选在整个链路中到底哪一个环节出了问题。这是咱们下一步跟踪的方向。

第二个是基于大数据的智能化监控。如今你们都提 AIOps，我以为 AI 要落地的话，首先要把基础的数据收集基本功作好，在这个基础上，积累一些现有的历史数据，分析一些趋势，作一些自动化的调度和自动化的处理，实现无人值守的目标。

以上是个人所有演讲内容，谢谢你们！