AI 年度盘点与2025发展趋势展望,50+案例解析亮相AICon 了解详情
写点什么

51 信用卡在微服务架构下的监控平台架构实践

  • 2018-12-05
  • 本文字数:3381 字

    阅读完需:约 11 分钟

51信用卡在微服务架构下的监控平台架构实践

一、背景介绍

51 信用卡的技术架构是基于 Spring Cloud 所打造的微服务体系,随着业务的飞速发展,不断增多的微服务以及指标给监控平台带来了极大的挑战。监控团队在开源 vs 自研,灵活 vs 稳定等问题上需要不断做出权衡,以应对飞速发展的需求。本次将会分享我们在微服务下的白盒监控思考,以及如何将时下社区流行的 Spring Cloud,K8S,Prometheus 等开源技术在企业落地。


本文整理自杨帆在 QCon 2018 北京站上的演讲,原标题为《51 信用卡在微服务架构下的监控平台架构实践》


这次主要讲的是关于微服务的监控,微服务看起来很美话,但实践起来却有很多坑,希望这次的分享能给大家一些收获或者思考。

二、传统的监控分层

传统的监控一般会将监控分层,比如我们常用的分层方式是将监控分成基础设施、系统、应用、业务和用户端这几层,分完层后将每层的监控做到位。



而在传统的监控里,zabbix 是最常用的开源软件,zabbix 的优点主要是成熟可靠,社区非常强大,几乎你的需求,社区都有一套对应的解决方案,但 zabbix 的缺点也很明显,就是太难用,很多监控配置加起来成本很高,甚至很多运维用了很久的 zabbix,还没学会怎么配置 HTTP 监控,这在应用较少的时候,还不是很明显的问题,但是到了微服务时代,这个问题就暴露得非常明显了,而且 zabbix 以机器为维度的监控也无法适用微服务时代的理念。

三、以服务为维度的监控

微服务监控比起传统应用的监控,最明显的改变就是视角的改变,我们把监控从分层+机器的视角转换成以服务为中心的视角,在微服务的视角下,我们的监控可以分为指标监控、链路监控和日志监控,在开源社区,这些监控也都有对应的解决方案,比如指标监控有 prometheus、influxdb,链路监控有 zipkin、pinpoint,日志则有 elk。



在 51 信用卡发展起步的时候,我们也同样使用这些开源方案来解决我们的监控问题,但当我们业务快速发展的时候,我们开始不断碰到监控上的挑战,其中有部分是互联网金融特有的,另一部分是微服务所带给我们的。


微服务监控有什么特点?用一句话概括就是服务特别多,服务间的调用也变得非常复杂。我们其实是微服务的受害者,其实业内很多人做的架构只是服务化,并不够「微」,而我们做的比较彻底,我们线上很多服务都只有一个 API,但这样造成线上指标非常多,告警也非常多,读和写的压力都非常大。


互联网金融是一个跟钱息息相关的行业,所以互联网金融对监控也有自己的要求。首先是对故障的容忍程度很低,监控的有效性需要被反复确认,其次是对监控的覆盖度,黑盒监控在互联网金融里很难行得通,白盒监控变得越来越重要,开发们迫切需要对自己的应用有全面的了解。然后是对告警的及时以及快速诊断有更高的需求,告警以及诊断信息在 10 分钟内发出与 5 分钟内发出有很大的差别,举个例子,如果有个活动有个漏洞被黑产行业抓住,如果能早一分钟确定问题关闭后门,就能给公司挽回巨大的损失。

四、Prometheus 下的监控

51 信用卡在早期也同样使用 Prometheus,其实 Prometheus 是个很棒的产品,白盒监控的理念也很先进,自带告警以及 PromQL,稍微学习之后便能上手,作为 CNCF 的项目与 K8S 等开源产品结合得也很好。



在随着服务的增长,我们开始不断地踩坑,首先突出的问题就是 Prometheus 没有现成的分布式方案,性能遇到单机瓶颈之后只能手动给业务划分集群并且之间的数据不能共享,然后拉模式在兼容多数据源上也显得力不从心,比如我们有场景需要指定精确的时间,还有比如我们有些数据是从日志来的或是从 Kafka 来的,这些都没有现成的方案。


微服务的指标增长其实比想像得要快很多,因为微服务架构下,我们总是迫切想要把应用的每个细节都搞清楚,比如主机指标、虚拟机指标、容器指标、应用性能指标、应用间调用指标、日志指标以及自定义的业务指标等等,甚至在这些指标下,我们还会给指标打上更多的标签,比如是哪个进程,哪个机房,我们大致算过一笔账,一个服务即使开发什么都不做,他通过基础框架就自带了 5000 个指标。


我们内部也讨论过为什么指标会这么多,能不能把一些指标去掉,但很快我们就否决了去指标的想法,我们觉得业界的趋势是白盒监控会变得越来越重要,APM 的概念会变得越来越重要,devops 会和白盒监控不断发生化学反应,变成一种潮流。


而在 51 信用卡,我们是怎么解决的呢,其实很简单,用三个字概况就是「平台化」,平台化的好处很多,最直观的好处就是提供了一个统一的平台去处理监控问题,并给开发带来了统一的使用体验。

五、基于 Prometheus 的架构改进

我们首先要解决的问题是如何构建对上层统一的存储,一开始我们基于 Prometheus 的生态做了一些架构改进,将底层换成分布式的列式存储 Cassandra,并开发了推送服务和拉取服务来兼容原先的数据模型,在上层,我们开发了兼容 PromQL 的界面提供给开发使用。



但很快,我们就碰到了新的问题。


首先是 labels 的匹配效率问题,当指标名相同的时候,由于 label 是自由组合的,在匹配部分 label 的时候,我们需要先将 labels 的元数据全部读出来,然后进行过滤,这样的效率会显得很低,我们的做法是在 label 元数据上面加上倒排索引,因为我们是分布式方案,倒排索引本身也需要分布式,所以我们直接使用 ES 来帮我们构建元数据。



第二个问题是预聚合,比如我们只想看 API 的整体访问量,但做这个查询的时候,我们会在底层读到 4 份数据,然后再聚合再显示出来,这样无疑也是一种浪费。我们的做法是引入预聚合机制,在纵向,我们需要舍弃维度,在横向,我们需要聚合时间轴。对于分布式而言,预聚合会显得比较麻烦,因为我们需要考虑的东西比较多,比如需要在内存里完成,需要合理将数据分批分配到不同机器,需要有一个窗口机制保证数据的及时有效又高性能。业内常用的做法是引入一个 Storm 这样的流式计算或者 Spark Streaming 这样的微批计算,然后将计算完的结果推入缓存或者内存供告警来使用。



第三个问题是 Metric 的长度,因为在列式存储的底层,我们直接借鉴 Kairosdb 的存储格式,兼容 UTF8 的 Metric 而直接讲 Metric 转换成二进制存储在数据库里,如果指标很少,这个问题不大,但如果指标非常多,这会造成底层存储的存储浪费,而且影响索引的效率,这个问题的解决办法也很简单,直接引入一个 Bitmap 机制就可以解决。


第四个问题是维度重复,比如我们有三个指标,这三个指标的维度都一样,但这三个指标完全不同,代表不同的值,但存储在数据库的时候,它会占用三个 series 的空间,查找的时候也不够高效,因为往往三个指标会同时查询同时展示。这个解决办法是将数据库里原本的 value 定义成多类型支持,不只是双精度浮点或是整型,增加 Map 的支持类型,并在数据库的上层做兼容。


当初我们在解决这些问题的时候,我们发现社区已经有一个比较好的解决方案了,就是 Druid,不是阿里那个数据库连接池 Druid,而是 druid.io。它比较好地满足了 Bitmap、预聚合、复合类型、倒排索引、冷热数据这些需求。


我们将拉服务和收服务做了进一步的改进,可以自动将数据做转换,兼容原先数据模型的同时,将数据也投递一份到 Druid 里。



至此我们基本完成了一个能够满足需求的存储架构改进。



最后限于时间关系,和大家分享两个非常有用又容易实践的告警智能诊断:


第一个是和日志监控的联动,当一个告警发生的时候,我们以时间、服务为维度去匹配 ERROR 或是 Exception 日志,并以 simhash 之类的相似算法排序日志,就会非常快速地找到问题的直接原因,不一定是 Root Cause,但告警的时候如果附上这个日志,对开发排查问题的效率会有很大的帮助。


第二个是和链路监控的联动,当一个告警发生的时候,我们同样以时间、服务查询链路监控,并从日志监控里排名靠前的日志提取 trace id 后进行过滤,能很快发现故障的关联原因,这同样不一定是 Root Cause(很有可能是),但同样对开发排查问题很有帮助。

六、未来

最后展望一下未来,我们会继续在 3 个方向发力。


  • 第一个是更好的底层存储,Cassandra 毕竟是一个通用的列式数据库,对时序数据来说,有很多不好优化的地方,我们期望能够自研一个时序数据库来满足我们的业务需求。

  • 第二个是智能化的监控和告警,运用合适的算法并加上机器学习或是深度学习,探索出无阈值的告警体系,并自动分析出告警之间的关联关系,给出根因。

  • 第三个是 APM 和监控的更紧密结合,将链路监控、日志监控和指标监控直接合并,更深度地诊断系统,系统没有无法探查的秘密。


2018-12-05 14:423239

评论 1 条评论

发布
暂无评论
发现更多内容

大括号之谜:C++的列表初始化语法解析

华为云开发者联盟

c++ 函数 语法 元素 std::array

拖延症这个毛病「Day 16」

道伟

28天写作

工作日志3-2-3

技术骨干

知识+AI融合创新探索,华为云论文被AI顶级学术期刊IEEE TPAMI接受

华为云开发者联盟

AI 模型 华为云 卷积神经网络 IEEE TPAMI论文

列表推导式与字典推导式,滚雪球学 Python

梦想橡皮擦

28天写作 3月日更

面试现场:小伙伴的美团一面分享和分析[含答案]

小傅哥

Java 面试 小傅哥

上线 Python 应用仅需一条命令的开源框架:Zappa(详细教程)

HelloGitHub

Python Serverless 无服务器云函数

《精通比特币》学习笔记(第四章)

棉花糖

区块链 读书笔记 3月日更

女神节·走近又美又飒的程序媛

华为云开发者联盟

华为 程序媛 IT 工程师 汉服

Python基础之:函数

程序那些事

Python 数据分析 Python3 程序那些事

10 个解放双手超实用在线工具,有些代码真的不用手写

程序员小富

Java

与前端训练营的日子 -- Week18

SamGo

学习

数据分析师

Nydia

【笔记】第六周 - 第 2 课

Geek_娴子

正则表达式.03 - 分组

insight

正则表达式 3月日更

小喜量化交易系统开发|小喜APP软件开发

系统开发

5分钟介绍AI人工智能,机器学习和深度学习,John 易筋 ARTS 打卡 Week 40

John(易筋)

ARTS 打卡计划 arts

BI掌柜量化交易系统开发|BI掌柜炒币机器人软件APP开发

系统开发

MT马特量化交易系统开发|MT马特量化交易软件APP开发

系统开发

阿里P8大牛亲自讲解!难道Android真的凉了?3面直接拿到offer

欢喜学安卓

android 程序员 面试 移动开发

云边协同

lenka

云计算 产品经理 3月日更

「架构师训练营 4 期」 第九周 - 001&2

凯迪

架构师训练营 4 期

(28DW-S8-Day16) 在线教育体验课

mtfelix

28天写作

实现一个全链路监控平台很难吗?Pinpoint、SkyWalking、Zipkin,哪个实现比较好?

xcbeyond

架构 技术方案 链路监控 3月日更

IDEA 常用插件与配置

TroyLiu

Java vim ide idea插件 IntelliJ IDEA

Python 语言基础之 变量和常量

HoneyMoose

二维码高端路线养成计

happlyfox

学习 技能 28天写作 3月日更

阿里P8大佬亲自讲解!万字Android技术类校招面试题汇总,已拿offer

欢喜学安卓

android 程序员 面试 移动开发

世界上最好的排序算法是什么?

Nick

数据结构 算法 快速排序

Dubbo SPI 使用源码分析

Yangjing

dubbo spi ProxyFactory 服务暴露 ExtensionFactory

快速排序算法实现及优化

Silently9527

Java 排序算法 快速排序

51信用卡在微服务架构下的监控平台架构实践_架构_杨帆_InfoQ精选文章