蚂蚁金服在云原生架构下的可观察性的探索和实践 | Meetup#3 回顾

2024-01-17 05:08

本文主要是介绍蚂蚁金服在云原生架构下的可观察性的探索和实践 | Meetup#3 回顾,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

作者:苟利(陈自欣),蚂蚁金服中间件产品专家, 负责蚂蚁金服分布式链路跟踪系统的产品化工作,在日志分析、监控领域有多年工作经验。

本文根据 8 月 11 日 SOFA Meetup#3 广州站 《蚂蚁金服在云原生架构下的可观察性的探索和实践》主题分享整理。

现场回顾视频以及 PPT 查看地址见文末链接。

640?wx_fmt=jpeg

| 前言

随着应用架构往云原生的方向发展,传统监控技术已经不能满足云原生时代运维的需求,因此,可观察性的理念被引入了 IT 领域。

下面我将会就可观察性在云原生的起源,可观察性发展动力,可观察性与监控的关系,可观察性的三大支柱,社区发展方向及产品现状,以及蚂蚁金服对相关问题的理解及实践进行探讨。

才疏学浅,欢迎拍砖。

| 为什么云原生时代需要可观察性

可观察性的由来

在云原生语境下的可观察性这个词,最早出现于2017年7月,Cindy Sridharan 在 Medium 写的一篇博客, "Monitoring and Observability"[1] 谈到了可观察性与云原生监控的关系。

而在2017年10月,来自 Pivotal 公司的 Matt Stine,在接受 InfoQ 采访的时候,对云原生的定义进行了调整,将 Cloud Native Architectures 定义为具有以下六个特质:

  • 模块化 (Modularity) (通过微服务)

  • 可观察性 (Observability)

  • 可部署性 (Deployability)

  • 可测试性 (Testability)

  • 可处理性 (Disposability)

  • 可替换性 (Replaceability)

可见,在2017年下半年,可观察性成为了一个 buzzword(时髦词),正式出现在了云计算领域。

可观察性的定义

虽然“可观察性”这个词在 IT 行业是一个新的术语,但它其实是在上世纪60年代,由匈牙利裔工程师鲁道夫·卡尔曼提出的概念[2]。

术语“可观察性”,源于控制论,是指系统可以由其外部输出推断其内部状态的程度。

这个外部输出,在云原生的语境下,即 Telemetry ,遥测,通常由服务(services)产生,划分为三个维度或者说支柱,Tracing(跟踪),Metrics(指标) , Logging(日志)。

为什么云原生需要可观察性

近年可以看到,云计算对基础架构改变甚为巨大,无论是互联网行业,还是传统行业,云化在提升资源利用率,提高业务敏捷性的价值已经成为了公式。而在应用层面,由于业务特性的原因,互联网公司大部分已经完成云化,应用架构也不同程度上,完成了从单体应用向微服务应用演进。在转型后,整体系统复杂性大大增加,倒逼相应的工具及方法论进行升级改造,去 hold 住这么复杂的局面。

640?wx_fmt=jpeg

上图为 Uber 展示的总体调用链图。

考虑到业务多样性及复杂度,在蚂蚁金服内部,相关调用关系只会更为复杂,用人类的智力,已经没有办法去理解如此复杂的调用关系。而上图只是展示了可观察性的链路调用,如果再加上指标及日志,不对工具及方法论进行革新,是难以实现对复杂微服务架构的管控的。

微服务只是云原生的模块化特性的体现,再考虑到近年被广泛应用容器,Kubernetes , 以及大家关注度极高的 Service Mesh , Istio,每一个新的技术的出现,在带来了更优雅的架构、更灵活的调度、更完善的治理的同时,也带来更多新的复杂性。

因此,可观察性对于云原生的应用架构,是必不可少的特性。

可观察性和传统监控的区别

不少同学就会说,这个可观察性与我们谈的最多的监控有什么区别。虽然有不少人认为,这词就是个buzzword,就是赶时髦的,没有太大的意义,但是我结合网上的讨论,个人认为可观察性与监控,含义上虽然接近,但是也有一些理念上的差别,使得讨论可观察性这个词,是有具有现实意义,并能真正产生相应的价值。

  • 监控更多关注的是基础设施,更多与运维工程师相关,更强调是从外部通过各种技术手段去看内部,打开黑盒系统。

  • 可观察性更多的是描述应用,在我们谈论具体某应用,或者是某些应用是否具备客观性的时候,通常与开发人员相关,因为在常见的可观察性的实践之中,开发人员需要在应用的开发过程中嵌入例如 statd 或者是 opentracing,或者是 opencensus 等所提供的库,对相关的 telemetry 进行输出,或者是俗话说的埋点。通过埋点,将服务内部的状态白盒化,使得其在运维阶段具备可观察性。某种程度上可以说,可观察性遵循了  DevOps 及 SRE 的理念,即研发运维一体化,从开发侧就考虑系统的可运维性。 

这里值得补充说明的是,目前市面上,有商用或者开源 APM 方案,通过入侵 JVM 或者其他技术手段,对应用进行自动埋点的,输出 trace 及 metrics 信息。这同样也是一种可观察性的实现方式,这样做的最大的好处是,不需要对现有的应用进行改造,但是相应的 agent 对应用进行实时的监控,必然会或多或少的增加资源的占用,例如每实例额外 30+MB 内存,5~10% 的 CPU 占用,在大规模的运行环境之中,会有不少的成本增加。

可观察性的三大支柱及社区进展

可观察性的三大支柱

640?wx_fmt=jpeg

可观察性的三大支柱及其之间的关系,Peter Bourgon 在2017年2月撰写了一篇简明扼要的文章, 叫 "Metrics, tracing, and logging" [3], 有兴趣的可以去看一下,以下仅为简单的提及。

指标数据(Metrics Data)

描述具体某个对象某个时间点的值。在 Prometheus 中,指标有四种类型,分别 Counter(计数器)、Gauge(瞬时值)、Histogram(直方图)和 Summary (概要), 通过这四种类型,可以实现指标的高效传输和存储。

日志数据 ( Logging Data)

描述某个对象的是离散的事情,例如有个应用出错,抛出了 NullPointerExcepction,或者是完成了一笔转账,个人认为 Logging Data 大约等同于 Event Data,所以告警信息在我认为,也是一种 Logging Data。但是也有技术团队认为,告警应该算是可观察性的其中一个支柱。 

跟踪数据(Tracing Data)

Tracing Data 这词貌似现在还没有一个权威的翻译范式,有人翻译成跟踪数据,有人翻译成调用数据,我尽量用 Tracing 这个词。Tracing 的特点就是在单次请求的范围内处理信息,任何的数据、元数据信息都被绑定到系统中的单个事务上。一个 Trace 有一个唯一的 Trace ID ,并由多个 Span 组成。

社区方案进展

640?wx_fmt=jpeg

由于可观察性在云原生中,是一个非常重要的特性,因此,在开源世界中,先后出现了两个定位都比较类似的项目,分别是源自 Google 的 OpenCensus (定位上报 Tracing + metris)和由 CNCF 孵化的 OpenTracing(定位上报 Tracing)。两者都定位于提供厂商中立的技术规范,及实现该规范各种编程语言遥测库,使得用户在使用了相关的库以后,可以将相关的遥测数据, 发往不同厂商的后端,如 Zipkin , SignalFX,Datdog 等,从而促进云原生的可观察的良性发展。

由于两个项目的定位高度雷同, 因此在2019年3月,两个项目社区的主要领导者,决定将两个项目进行融合,产生一个同时向下兼容 OpenCensus 及 OpenTracing 的项目,叫 Open Telemetry,将多个标准降低为一个。

OpenTelemetry 旨在将可观察性的三大支柱,组合成一组系统组件和特定于语言的遥测库。项目在最初并不会支持日志,但最终会将其合并。这个事情比较好理解,因为日志数据量太大,也缺乏相应的初始规范,社区选择在时机成熟时再进行引入是一个很合理的策略。

简单来说,以后在应用开发里头,只要使用了 Open Telemetry的类库进行埋点,则应用就可以通过一个协议,统一上传指标,跟踪日志到不同厂商的后端,进行后继的分析。

| 社区产品现状及局限

与协议层,日趋一统情况不一样,在产品层面,由于产品的侧重点不同,呈现出了百花齐放的局面。

640?wx_fmt=jpeg

640?wx_fmt=jpeg

但是,从某种角度来看,目前社区的产品方案有以下的局限:

1、缺乏大一统的产品,同时对三个支柱进行支撑,并进行有机的关联

这个无需多言,只要使用过上述的产品,就会发现没有办法找到一个完整开源产品,能够对以上三种遥测进行同时处理。就更没有办法进行统一的关联了。

2、缺乏大一统的产品模型,统一展示微服务 + Mesh + Serverless

在不远的将来,传统微服务、Mesh 、Serverless 应用混合交互构成业务系统,将会是一个普遍的情况,但是目前开源的产品,并不具备对以上三种计算模型进行统一的,可识别的管理。

| 蚂蚁金服对云原生的可观察性的理解及实践

蚂蚁金服在多年的分布式系统运维过程中,对可观察性有着自己深入的理解,结合用户的特点,将其进行产品化及解决方案,并提供给金融用户。

640?wx_fmt=jpeg

链路跟踪是可观察性的核心,用于故障定位

640?wx_fmt=jpeg

在微服务及分布式架构中,链路跟踪是用户的核心使用诉求,这里大家都应该比较熟悉了,我也不多做展开。

Tracing + metirce + Log 有机关联是实现可观察性的关键

链路与日志关联

640?wx_fmt=jpeg

链路与日志关联[4]是一个很重要的场景。在很多时候,某一个调用失败,失败的原因,并不能体现在 Trace 之上,也许是发生在业务侧,例如余额不足,导致整个调用的失败。因此,很多时候,我们需要将链路和日志关联,帮助我们更好的判断到底是什么原因,导致链路调用失败,或者是进行进行其他分析。

为此,我们提供了一个 SDK,用户可以根据我们官网上的配置,对 log4j 及其他 logger进行配置后,将 TraceId 及 RPCId 从 Tracer 中进行获取,那么在打印的日志的时候,TraceId , RPCId 也会如图上所示,在日志中打印出来。最后,然后通过 Trace view,就能在查看链路的同时查看关联的日志。

具体的配置方式或者原理,感兴趣的同学,可以查看蚂蚁金服金融科技官网。

https://tech.antfin.com/

拓扑与指标关联

640?wx_fmt=jpeg

640?wx_fmt=jpeg

除了链路与日志关联,我们 SOFA 还提供了应用指标的上传功能 在应用上传 Trace 的同时,我们将指标与调用拓扑进行了关联,用户可以点击应用拓扑中的应用,下转查看响应的拓扑指标。

按照固定采样率进行采样不能满足实践使用需求

640?wx_fmt=jpeg

有 Tracing 相关产品使用经验的同学都知道,在业务量大的时候,相关的 Tracing 产生的数据量会较多,导致存储成本以及处理成本的大幅度增加。在实际的生产中,我们往往会对 Tracing 进行采样,通常会采用 1/100 甚至是1/1000 的方式进行采样。

具体的采样方式,通常采用 Head-based 采样,即对 TraceId 进行以 100 或者 1000 来采模,采模后如果是 1 ,则 agent 对该 TraceId 进行进行采集。是否对链路进行采集的决定,发生在链路的第一跳,即 TraceId 产生时,所以叫 Head-based 采样。

这种采样方法好处是实现非常简单,但问题是 100 个链路数据中,可能有 3-5 个是运维人员关心的,通常是调用出错的链路,又或者是调用缓慢的链路,通过这种简单粗暴的采样,能采集到相应链路的机会就会很少。大部分情况下,用户只能期望异常多次发生,并在某次被采样命中,然后进行分析。

目前,开源软件中,采用的都是这种方案。

我们在蚂蚁金服内部,使用的是 Tail-based 的采样方案,简单来说,我们会把所有的 Span 数据,都会放到内存里,但这个时候,并不能决定具体那一条链路是采集还是不采集,但是当整条链路闭合后,我们就会对整条的 Trace 根据规则进行判断,如果有调用失败,或者整个调用中有部分 Span 是处于缓慢状态的,系统会将会标记此链路为异常链路,即命中采样,永久保存。这样就能保证运维人员能够无视采样率,具备对异常链路进行查看能力。由于对某一条链路数据是否采集的决定,其实是处于链路的尾部(非严格意义)才作出的,所以叫 Tail-based 采样。

当然以上 Tail-based 的采样的描述是极其简单及理想化的,在海量数据量的情况下,以上的方法基本上没有办法使用,很容易就把内存给撑爆了。在实际设计中,我们还考虑了很多的因素,进行了更多的细节处理,使得 Tail-based 采样的资源消耗也在一个可以接受的范围内。

目前这个功能在内部已经落地,对外还在产品化之中。

(想要了解上述更多技术细节,可以查看参考资料[5]&[6])

统一化 微服务 + Mesh + Serverless

640?wx_fmt=jpeg

未来,可以预期混合使用经典微服务、服务网格的企业必然越来越多。因此,如何设计一个通用的模型, 对以上三部分进行统一管控, 这也是蚂蚁金服目前正在实践探索的地方,期望外来有机会向大家分享。

| 未来展望

综上所述,随着云原生的发展, 我们相信拥有完整的可观察性三大支柱处理能力,并能在产品层面上对三大支柱进行灵活关联、下转、查看的监控产品,适用于混合的云原生场景的监控的产品,都将会越来越多,帮助企业内部落地云原生架构。

| 视频回顾

本次分享的视频回顾以及PPT 查看地址:

https://tech.antfin.com/community/activities/779/review

| 参考资料

[1] "Monitoring in the time of Cloud Native":

https://conferences.oreilly.com/velocity/vl-ny-2017/public/schedule/detail/61529

[2] Observability: 

https://en.wikipedia.org/wiki/Observability

[3] “Metrics, tracing, and logging”:

https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html

[4] 设置应用日志关联:

https://tech.antfin.com/docs/2/72179

[5] https://news.ycombinator.com/item?id=15326272

[6] https://github.com/jaegertracing/jaeger/issues/425

[7] 蚂蚁金服金融科技:https://tech.antfin.com/

本文归档在 sofastack.tech。

640?wx_fmt=png

这篇关于蚂蚁金服在云原生架构下的可观察性的探索和实践 | Meetup#3 回顾的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/614946

相关文章

mybatis的整体架构

mybatis的整体架构分为三层: 1.基础支持层 该层包括:数据源模块、事务管理模块、缓存模块、Binding模块、反射模块、类型转换模块、日志模块、资源加载模块、解析器模块 2.核心处理层 该层包括:配置解析、参数映射、SQL解析、SQL执行、结果集映射、插件 3.接口层 该层包括:SqlSession 基础支持层 该层保护mybatis的基础模块,它们为核心处理层提供了良好的支撑。

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

百度/小米/滴滴/京东,中台架构比较

小米中台建设实践 01 小米的三大中台建设:业务+数据+技术 业务中台--从业务说起 在中台建设中,需要规范化的服务接口、一致整合化的数据、容器化的技术组件以及弹性的基础设施。并结合业务情况,判定是否真的需要中台。 小米参考了业界优秀的案例包括移动中台、数据中台、业务中台、技术中台等,再结合其业务发展历程及业务现状,整理了中台架构的核心方法论,一是企业如何共享服务,二是如何为业务提供便利。

深入探索协同过滤:从原理到推荐模块案例

文章目录 前言一、协同过滤1. 基于用户的协同过滤(UserCF)2. 基于物品的协同过滤(ItemCF)3. 相似度计算方法 二、相似度计算方法1. 欧氏距离2. 皮尔逊相关系数3. 杰卡德相似系数4. 余弦相似度 三、推荐模块案例1.基于文章的协同过滤推荐功能2.基于用户的协同过滤推荐功能 前言     在信息过载的时代,推荐系统成为连接用户与内容的桥梁。本文聚焦于

90、k8s之secret+configMap

一、secret配置管理 配置管理: 加密配置:保存密码,token,其他敏感信息的k8s资源 应用配置:我们需要定制化的给应用进行配置,我们需要把定制好的配置文件同步到pod当中容器 1.1、加密配置: secret: [root@master01 ~]# kubectl get secrets ##查看加密配置[root@master01 ~]# kubectl get se

系统架构师考试学习笔记第三篇——架构设计高级知识(20)通信系统架构设计理论与实践

本章知识考点:         第20课时主要学习通信系统架构设计的理论和工作中的实践。根据新版考试大纲,本课时知识点会涉及案例分析题(25分),而在历年考试中,案例题对该部分内容的考查并不多,虽在综合知识选择题目中经常考查,但分值也不高。本课时内容侧重于对知识点的记忆和理解,按照以往的出题规律,通信系统架构设计基础知识点多来源于教材内的基础网络设备、网络架构和教材外最新时事热点技术。本课时知识

K8S(Kubernetes)开源的容器编排平台安装步骤详解

K8S(Kubernetes)是一个开源的容器编排平台,用于自动化部署、扩展和管理容器化应用程序。以下是K8S容器编排平台的安装步骤、使用方式及特点的概述: 安装步骤: 安装Docker:K8S需要基于Docker来运行容器化应用程序。首先要在所有节点上安装Docker引擎。 安装Kubernetes Master:在集群中选择一台主机作为Master节点,安装K8S的控制平面组件,如AP

AI(文生语音)-TTS 技术线路探索学习:从拼接式参数化方法到Tacotron端到端输出

AI(文生语音)-TTS 技术线路探索学习:从拼接式参数化方法到Tacotron端到端输出 在数字化时代,文本到语音(Text-to-Speech, TTS)技术已成为人机交互的关键桥梁,无论是为视障人士提供辅助阅读,还是为智能助手注入声音的灵魂,TTS 技术都扮演着至关重要的角色。从最初的拼接式方法到参数化技术,再到现今的深度学习解决方案,TTS 技术经历了一段长足的进步。这篇文章将带您穿越时

系统架构设计师: 信息安全技术

简简单单 Online zuozuo: 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo :本心、输入输出、结果 简简单单 Online zuozuo : 文章目录 系统架构设计师: 信息安全技术前言信息安全的基本要素:信息安全的范围:安全措施的目标:访问控制技术要素:访问控制包括:等保

【Kubernetes】K8s 的安全框架和用户认证

K8s 的安全框架和用户认证 1.Kubernetes 的安全框架1.1 认证:Authentication1.2 鉴权:Authorization1.3 准入控制:Admission Control 2.Kubernetes 的用户认证2.1 Kubernetes 的用户认证方式2.2 配置 Kubernetes 集群使用密码认证 Kubernetes 作为一个分布式的虚拟