架构微服务化后，如何优化监控系统？

微服务 监控 运维

架构微服务化之后，快速找出问题根源变得更具难度。普元架构师顾伟首先监控面对的新挑战，并指出了并没有改变的是监控数据来源。从三种应用场景、监控数据的呈现的两大角度，探讨了如何优化监控。最后，顾伟对三大来源监控数据收集的流行技术工具给出了参考意见。

微服务的监控难点及思考

单块应用架构下，故障的判断是一个非0即1的问题，如果宿主服务器指标一切正常，那么就是单块应用出问题。除了判定的简单之外，监控技术也已经很成熟：宿主服务器的监控技术有如Nagios、Zabbix等；应用的监控则主要有基于应用服务器的管理平台、基于应用日志两种模式。

随着微服务越来越多的被采用，由以前的单个服务器+单个服务，转变成现在的多个服务器+多个服务的模式。一旦出现异常，需要快速找出问题根源，这明显提高了对监控能力的要求，监控系统需要解决一些微服务带来的新问题：

• 日志分散在各处，该如何进行监控？
• 异常发生怎么判断是某个宿主服务器的问题？还是某个服务的问题？
• 无论异常源自是服务还是服务器问题，异常的影响链是什么？
• ……

当然，上述问题一直在围绕故障定位，因为微服务化架构使得故障定位变得更加困难，但监控并不是只为了故障定位。仔细想想，其实一般监控目标无非下面三种：

• 事故预警：比如基于阀值对比的实时的事件告警等
• 故障定位：比如静态点的异常日志收集等
• 优化决策：比如用户行为数据分析，发现瓶颈等。

无论微服务带来的哪些难点，又或是要实现上述的哪些目标，有一样东西是一直没有变的，那就是监控数据的三种来源：落地日志、若干自定义的程序埋点、硬件设备或系统信息。（当然也可以把日志作为埋点的一种实现方式）只是在微服务架构下，信息收集后需要的处理动作（关联、合并、过滤、去重等等）更多更复杂了。

三大应用场景下的监控优化

上面提到的三种监控系统的数据来源，这里结合实际的应用场景的优化进行一一分析。

1 . 落地日志——微服务的日志收集场景

假设我现在是平台的运维人员，我肯定不希望一个一个地登录到每台宿主服务器上去看各种日志，最好是把日志都收集到一起展现，然后做后续的分析挖掘，基本流程如下图所示：

• 管道除了传输之外，还会具备很多处理能力，最常用的是简单预处理和数据缓冲（比如很多架构里用到了kafka）

• 传输可以是多级，一般来说系统规模大到一定程度，海量数据往一个点的汇聚很容易出现问题，分级处理是个很好的方式

• 日志收集方式尽量统一，在很多系统设计中，对于业务日志、容器日志（如Docker）、宿主机日志等采用不同agent，这是一个不好的方式。因为agent也要管理，引入太多agent只会给系统增加不必要的麻烦 。

2 . 自定义的程序埋点———行为数据分析场景

很多创业公司都在关注这块，常用方式是基于数据埋点，一般埋点可分为前端（终端）和服务端两种，两者各有利弊。前端的好处在于可获取更丰富的界面操作信息，从而指导界面UI（如布局）的演进，而其最大的问题在于采集数据的传输对网络要求较高（一般采用批量方式）。而对于后端，在微服务架构下，基于埋点的被统计进程变得越来越多，比如服务健康检查这类，既要有点，又要有链。埋点的设计里有几点经验供大家参考：

• 在两种方式都可以做到的情况下，埋点首选后端采集。
• 前端采集尽量采用框架进行埋点，不要到处插入自定义代码（框架的做法其实不复杂，比如web端，用过类似Selenium这些框架自然就清楚原理了）。
• 埋点很难做到语言无关性，尤其后端埋点。微服务架构下，尽量结合各微服务语言特征来实现。

3. 硬件设备或系统信息——系统性能跟踪场景

与传统架构下相比，此类情况下的方案的原理并没有发生本质性变化，比如通过协议采集系统的CPU、内存、磁盘IO等，进而分主题入指标库。不过采用容器来承载微服务之后，数据采集发生了两点变化：需要采集的系统信息量变多，比如容器的性能信息；同时在创建性能相关的主题时，数据关联的复杂度也明显升高。

这里给出一些经验供大家参考：

• 指标库的选型一般会采用一些内存计算框架，对于主题的设计和优化要充分考虑内存容量。
• 无论容器、虚机、物理机，性能数据采集都面临着窗口的问题，一般是两个窗口（多长时间采集一次和采集的数据是多长时间的数据平均值），需结合业务设置合理值。
• 还有一点，包括在上述的两个场景中也需要注意：尽量将采集器本身对宿主机的性能影响降到最低。

“面向对象”的监控优化

前面是在技术或业务架构层面上谈监控，除此之外，微服务架构下做监控设计时，还有一项重要因素：人（PS：我不是要说康威定律）。监控系统的使用者最希望的是：“给我看到我最想要的信息”，“我”很重要，我可以是很多角色。即使是同一个微服务，不同的角色对于想看到的信息都可能是不一样的。如果结合角色去考虑，往往会发现微服务架构的监控系统设计中，有很大的优化空间。举个例子：

我们曾经在一个项目中采集性能信息，后端的指标库用了InfluxDB，存储虚拟机的各性能数据，每次采集信息作为某时间点的一条完整记录（默认是1分钟采集一次），中间架了缓冲（kafka），然后由处理器订阅，并对一批数据向InfluxDB做批量插入，示意图如下：

一开始我们认为这是可行的方案，使用基于类sql语句和内置函数完全可以得到想要的信息了：比如每天的性能曲线，可以将一天的数据通过mean计算出24个点；而每个月的时间曲线，可以将一个月的数据计算出30个点。按照预设，数据被持续地积累着，预定的积累时期为半年，可是直到一段时间之后，发现系统撑不住了。这该怎么办呢？然后我们开始重新审视监控方案，发现了两个问题：不同的角色需要什么信息？他们又是怎样消费数据的呢？

经过反思总结，监控数据信息的使用者一般分为两类：

• 决策者：最关注的是这周或这个月比前段周期负载增加或降低了多少，给他的只需提供是数字对比结果，数据明细根本不重要。此外，从比较时间而言，决策者最多希望能够对比到半年前即可。
• 运维人员：运维人员其实对数据实时性要求很高，他们根本不在乎几个月前的数据，只要能看到最近时间的数据有没有问题即可

从这个角度来考虑，会发现其实优化方式很多，详细数据虽然需要存档，但完全可不放在时序库中；针对决策者，数据按每周或每月汇总再存入线性指标库即可（InfluxDB continuous queries）；而针对运维人员，数据驻留内存周期可大幅缩短。

总的来说，在微服务架构下，监控确实变得越来越复杂；但无论怎么复杂，我们都需要时刻结合业务需要和角色识别，来进行监控方案的设计与优化。

关于技术栈的选择意见

【在此处，可以放原文开篇的内容（利用智能监控的手段，将明确的报警信息送给相关的人。信息不可模棱两可）】

最后给大家分享下我们目前平台中使用的一些技术栈：

• 日志收集的需求：我们是基于容器技术的，使用的CoreOS系统；最终我们采用了Journald+Fluentd+ElasticSearch的技术（业务日志亦是如此）。对于简单的场景，根据我们在一些小项目中的实践经验，ELK、Flume等其实就足够了。对于实时分析系统部分，大家可选择Akka、Esper、或者Storm作为实现框架，Akka通过actor模型实现信息流转，Esper我们是用来做CEP产品的，Storm就不用多说了。【请分析下】

• 埋点的需求：大家可参考Metrics项目，或者Netflix的Suro项目。两者都是Java实现，前者简单，后者则考虑更周全。

• 性能指标的需求：InfluxDB可作为后端存储，考虑到InfluxDB的版本之间的兼容性做得一般，建议大家尽可能使用最新版本。OpenTSDB也是一种常见的选择，不过毕竟是基于HBase的，比较重，大家有兴趣可以尝试。

作者简介

顾伟，现任普元软件产品部主任架构师，先后参与华为，中信银行，工商银行，中航信，阿里云，兴业银行等客户定制项目。擅长OSGI，Eclipse插件，web前端，云计算，CI/CD等领域技术，对新技术有着浓厚的兴趣。