微服务下的监控体系

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

  • 发表于:
  • 原文链接:https://kuaibao.qq.com/s/20180719G08LA700?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券