微服务下的监控体系

1

前言

分布式和微服务架构的落地和发展，随着业务快速发展，服务器越来越多，中间件、应用、微服务、数据库等也越来越多样化，监控是微服务控制系统的关键部分，你的软件越复杂，那么你就越难了解其性能及问题排障。

业务量达到百亿、千亿规模后，几百、数千台虚拟机、中间件容器，需要监控的网络、硬件、软件、应用和各种数据库。

微服务的特点决定了功能模块的部署是分布式的，大部分功能模块都是单独部署运行的，彼此通过总线交互，都是无状态的服务。这种架构下，从前到后的业务流程会经过多台虚拟机和很多微服务进行处理、调用和传递，业务处理过程中会遇到很多棘手的问题：

如何基于同一套技术方案和架构来实时监控如此庞大的微服务体系？

如何主动并提前发现生产问题和生产隐患？

分散在各个服务器上的日志怎么处理？

如果业务流出现了错误和异常，如何定位是哪个点出的问题？

如何快速定位问题？

如何跟踪业务流的处理顺序和结果？

2

微服务的挑战

(1)、监控源的多样化

较多的业务域，存在的大量的子系统、模块、数据库(mysql、redis、mongodb、neo4j)和中间件。

(2)、海量数据

海量的业务数据，结构化数据和非结构化数据(影像文件、电子合同、报文、身份证等)。

(3)、数千个服务提供方

大量的微服务，部署在不同的虚拟机上，服务的注册、提供服务、挂起、版本更新、停止服务。

(4)、调用路径和环节长

完成一个业务动作可能会调用数个甚至超过10以上的服务，经过网状的服务调用路径，经过不同的主机、甚至不同的机房。生产出现问题可以跟环境、网络或存储都有关系。

(5)、基础组件众多

基于微服务架构的应用使用较多的基础和开源组件。

(6)、部署模式多样化

不同的应用、微服务、开源组件对部署环境的要求是不一致的。

3

服务维度监控

3.1 传统监控

传统IT模式都是按分层来监控，比如从基础设施（如网络、主机、虚拟机上的CPU、内存、磁盘等）、系统（操作系统、中间件、数据库）、应用（子系统、模块、功能的申请量、交易量、成功率、失败率）、前端（用户申请页面、动作等）。

3.2 微服务监控

微服务的监控主要以服务以中心来监控，业务发展比较顺利的情况下，金融业务突破百亿级规模是比较快速的。那么支撑这些业务量下服务的数量达到数千级别是比较正常的。在云化环境或虚拟化环境，一千多个服务被部署到不同的主机上，每个相同的服务最少部署了二个主机上，这时不同的服务之间的调用变得非常复杂。

如果基于微服务的监控体系没有成熟之前，微服务的弊端就会凸现。此时我们会深受其害，当一个业务流程出现问题后，我们无法知道那个环节出现的问题，只能靠慢慢看日志和后台数据，判断问题变的非常冗长。对服务提前预警以及快速诊断成为我们最迫切需要解决的问题。

4

技术架构

4.1 监控源

微服务架构下，网络的监控指标、主机指标、存储指标、中间件指标、虚拟机指标、应用和模块指标、微服务指标、服务间调用指标，都需要纳到我们的监控源里去。

4.2 采集和埋点

(1)、埋点

对业务流程节点和重点环节作日志埋点，对业务量、业务指标、波动值都可以作为微服务中的埋点打印出来。

(2)、日志监控

系统日志监控上，可以时间、服务为维度去匹配ERROR 或是 Exception 日志。把所有发现的异常都抓出来。

(3)、采集器

关于主机和网络的监控，主要靠采集器来定时打印日志，然后依靠日志分析来作抓取和后续分析。

4.3 Logstash

Logstash是一个开源的数据收集引擎，它具有备实时数据传输能力。它可以统一过滤来自不同源的数据，并按照我们的规范输出到ES里。

Logstash通过管道进行运作，管道有两个必需的元素，输入和输出，还有一个可选的元素，过滤器。

输入插件从数据源获取数据，过滤器插件根据用户指定的数据格式修改数据，输出插件则将数据写入到目的地。

4.4 Elasticsearch

Elasticsearch的特点：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。

ES在整个架构里承担了后台分布式存储以及全文检索的功能。ES在数据架构的主要概念（与关系数据库Mysql对比）：

4.5 监控分析和预警

ELK架构里的Kibana和Elasticsearch可以无缝衔接，监控分析可以基于Kibana来作分析，不过有很多局限性。

另一个方案从ES里定时抽取数据，作分析和监控实时展示。

监控阀值：

监控阀值的设立需要有分级机制，以分通知、预警、告警三级为例：通知应用运维人员关注，比如“系统登录数2000，登录成功率95%，最近7天登录数基线500，登录成功率96%”。

预警代表监控事件需要运维人员处理，但重要性略低，比如“CPU使用率71%”。

告警则必须马上处理的事件，比如“交易成功率为10%，平时为90%”这类监控事件己反映出交易。

预警升级：当一个预警超过一定时间限制后，未处理或一直未解决，需要上升处理。

5

小结

金融产品同质化的时代，服务不可用或问题不能快速诊断解决的时候，客户不会在线等待，他们会用脚投票。

互联网时代百万黑产团队会随时关注和扫描我们的问题或漏洞，这个时候，解决速度和金钱在赛跑。

作为IT民工的我们知道，代码是人写出来的，只要是人作的事，就不可能不出问题。实时监控和预警有些时间成为我们最后一道关口和守护。

END