蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理

本文涉及的产品
全局流量管理 GTM,标准版 1个月
可观测可视化 Grafana 版,10个用户账号 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 近期,对于 SOFALookout 开源版本主要是以完善适配为主,包括计算下推到 ES,和适配其他时序数据库。之后,我们也会开源关于 Trace 数据的处理模块。

,有趣实用的分布式架构频道。
本文根据 SOFAChannel#6 直播分享整理,主题《轻量级监控分析系统 SOFALookout 原理讲解和功能演示》。


回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群:23195297,不错过每场直播。

image.png

大家好,我是来自蚂蚁金服响风,SOFALookout 的开源负责人。本期 SOFAChannel 我给大家带来主题是《轻量级监控分析系统 SOFALookout 原理讲解和功能演示》的分享。本期的讲解内容如下将从以下四个部分展开:

  • 监控预警基本概念介绍
  • SOFALookout 的客户端使用(包括系统设计简介与实现)
  • SOFALookout 的服务端使用(包括系统设计简介与实现)
  • SOFALookout 发展规划

欢迎大家 Star 我,SOFALookout:

https://github.com/sofastack/sofa-lookout

1 监控预警基本概念介绍

1.1 什么是 SOFALookout

现在我们开始第一部分,先介绍一些基本概念。6 月初,SOFALookout 服务端开源,具体内容可以查看相关文章:蚂蚁金服轻量级监控分析系统 SOFALookout 服务端开源,SOFALookout 客户端在之前也已经开源。目前整个系统是真正地可以玩转起来的,这里先介绍一下 SOFALookout。

SOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。开源版本只提供对 Metrics 的处理部分:涵盖 Metrics 数据的产生,也就是 Metrics 的埋点、收集、加工、存储与查询等一系列服务。

1.2 Metrics 的前置知识

介绍一些 Metrics 的前置知识:

第一是时序数据,比较正式的解释是“基于稳定频率持续产生的一系列指标监测数据”。简单说横轴是时间,纵轴是数值的情况下,第一印象可以做成走势图的数据通常就是时序数据。比如 2009 年到 2018 年每年双十一天猫的成交额,就构成了时序数据。

第二是标签(Tag),它用于表明指标项监测针对的具体对象。还是以刚才的成交额为例子,其实我们要监测的指标是“成交额”,但是“成交额”并没有标明要监测的对象,即谁的成交额,哪个省的成交额,也就是缺少“定语”。标签的作用就相当于是“定语”。比如“天猫的 浙江省的 成交额”,在代码中通常会有键值对来描述,比如 type="天猫",province="浙江"。

第三是时序数据库,即专门为存查时序数据而设计的数据管理系统。主要有以下几个特点:

  • 写多读少
  • 数据多维度,无 schema,需要多维度查询或聚合
  • 通常无删除和更新操作, 或受限

以下是一些常见的开源时序数据库:

  • Graphite
  • InfluxDB
  • OpenTSDB
  • Prometheus

由于篇幅关系,就不一一介绍了。

1.3 传统 Metrics 和 Metrics 2.0 的对比

下面再来看一下传统 Metrics 和 Metrics 2.0 的对比。

1.3.1 传统 Metrics
传统 Metrics 是我对它的称呼,简单来说它只有 Name 和 Value,没有显式的 Tags 概念。比如 "temperature = 29",温度=29,当然这里都省略了时间戳。这个表达式并没有指出监测对象,传统 Metrics 的做法是,将监测对象的信息编码到 Name 里,因此可能就变成了 "temperature.hangzhou=29"。这里是有一些隐式的 Tags 信息的,只是被编码到 Name 里了。

这种做法会导致一个问题,来看一个例子:shanghai.host1.foo.exporter.bar 。 只看这个名字的话几乎很难知道这个 Metrics 统计的是什么。这是因为它并没有把字段对应的 Key 编码到名字里,所以在缺少一些上下文的情况下,我们很难读懂它的含义。

另外,字段的顺序也是很重要的,不能写错,这是因为编码到 Name 里的只有 Tag 的 Value,Key 不在里面,于是又有了另外一种编码方式:zone.shanghai.host.host1.app.foo.counters.exporter.bar 这种方式将 Tag 的 Key 也编码在 Name 里。但带来的问题也很明显:Name 越来越长。

我们再看下一个例子:login.success.h5,它想表达来自 H5 平台登录成功的次数。假设我们还有其他平台,比如安卓、IOS,我们想求所有平台的总登录成功次数,那么就需要做一个聚合操作。通常时序数据库会提供型号来匹配所有值。

其实上面这些都是旧版本 Graphite 的例子, 不过它在 2017 年底的版本支持了 Tags 概念,所以已经不能拿新版来当反面教材了。

这是 Dropwizard 客户端的一个简单 Demo,它是一个很流行的 Metrics 埋点客户端,但是只能支持传统 Metrics 的概念。

MetricRegistry
 registry = 
new
 
MetricRegistry
();

Counter
 h5Counter = registry.counter(
"login.success.h5"
);

h5Counter.inc();

1.3.2 Metrics 2.0
我们再来看 Metrics 2.0,其实 Metrics 2.0 也就只是多了 Tags 的概念,这里同样省略了 Timestamp。

这是 OpenTSDB 风格的数据描述。

{  
"metric"
: 
"login.counter"
,

   
"tags"
: {

   
"result"
: 
"success"
,

   
"platform"
: 
"h5"

   },

   
"timestamp"
: 
1560597254000
,

   
"value"
: 
100

}

这是 Prometheus 的描述方式。

temperature{city=
"hangzhou"
}=
29

这是对应的 lookout-client 的埋点代码。

Registry
 registry = …;

Id
 loginCounter = registry.createId(
"login.counter"
);

Id
 id = loginCounter.withTags

   
"result"
, 
"success"
,

   
"platform"
, 
"ios"

);

registry.counter(reqId).increment();

可以看到它们都显式支持了 Metrics 2.0 的概念。

这里我们花了点时间强调传统 Metrics 与 Metrics 2.0版本的区别,主要是想强调合理使用 Name 和 Tags,避免将 Tags 都编码在 Name 里的传统做法。现在基本上流行的开源时序数据库都通过自己的方式支持了Metrics 2.0 的概念。

2 SOFALookout 的客户端使用

介绍完前置知识之后,我们开始第二部分:SOFALookout 的客户端使用。

lookout-client 是 JVM 平台上的 Metrics 埋点客户端。下图是 lookout-client 的包结构:

image.png

API 包包含接口模型和空实现。API 包列出了一些重要的类,前 4 个是常见的 Metrics 数据模型。Registry 用于直接管理 Metrics,是 Metrics 的容器。Observer 负责观察 Registry,比如定期将 Registry 的整个快照数据导出到控制台或者是存储层,仅依赖 API 包就可以编程。此时用的是空实现,需要引入实现包,这样才能真正导出数据。最后,扩展包里则包含收集常见指标的实现, 比如 CPU 内存信息。

接下来我将演示 SOFALookout 客户端的使用。我会使用开源的 lookout-client,介绍 SOFALookout 里几个基本概念和它们的使用,在整个过程中还会讨论 Tags 的合理使用。

SOFALookout 客户端的相关演示操作可以在文末获取 Demo 地址以及演示视频查看地址。

3 SOFALookout 的服务端使用

第三部分是 SOFALookout 的服务端使用。整个服务端有 2 个应用:Gateway(多协议的数据收集与处理设计与实实现)和 Server(PromQL 与多种存储层的设计与实现)。各个客户端将数据上报到 Gateway,Gateway 进行处理,然后落库。Server 则负责对外提供查询服务。

3.1 Gateway - 多协议的数据收集与处理设计与实现

我们来仔细看一下 Gateway 的设计与实现,下图表明了数据的流动方向:

image.png

Gateway 负责收集数据,适配了多种协议。通常只要是支持 Metrics2.0 概念的协议都可以进行适配。这部分是由 Importer 负责的,目前主要是客户端主动上报数据为主。如果是像普罗米修斯的拉模式的话,则需要和服务发现系统或部署平台打通,这个目前暂时没有支持。

Gateway 还会负责数据的基本清洗,比如过滤掉一些已知的坏数据。这里使用的是管道过滤器模式, 所以我们可以很容易加入一个新的切面逻辑.

经过各种过滤器之后, 数据到达了 exporter 适配器,它负责将数据写入多种存储。

3.2 Server - PromQL 与多种存储层的设计与实现

下面是 Server 的设计与实现,下图表明了数据的流动方向:

image.png

Server 提供了与普罗米修斯一致的 HTTP API,它负责分析收到的 PromQL 语句,然后执行,在取数据的地方适配底层存储。

由于 Server 是计算与存储分离的架构,因此需要注意将一些聚合计算下推到存储层,而不是将原始数据取到内存里再进行计算,否则会很慢。

这里我提一下为什么我们选择适配普罗米修斯的 API,而不是其他时序数据库的 API:其中一个重要原因是它的查询能力明显比其他时序数据库的查询能力强大,也比较简洁,特别是在跨多个 Metrics 查询时。

举一个例子,假设我们有一个 Metrics 记录了成功数,有另一个 Metrics 记录了总数,想求成功率。显然就是两个Metrics 除一下就行了,比如下方的代码,就是表达了这个意思:

sum(success{zone=
"..."
}) 
by
(service{zone=
"..."
}) / sum(total{zone=
"..."
}) 
by
(service)

InfluxDB 的话,其实也可以做到,但前提是它需要将成功数和总数放在同一个 measurement 下,因此并不能对任意两个指标做四则运算。

OpenTSDB 的聚合查询能力则明显比较弱了,但好在它能支持同时查多个查询,实在无法处理的情况下可以取回来然后自己做计算。但是这个步骤前端的 grafana 并不能帮我们做掉。

当然 PromQL 的强大,这只是其中一方面,并不代表它就全面优与其他的 QL。

3.3 SOFALookout 服务端演示

下面,我来演示一下 SOFALookout 服务端的部署流程,以及演示整套系统从数据收集到展示的玩法。

为了演示流畅, 使用 Docker 来部署软件,我已经事先将要用到镜像拉到本地了。

预先拉取镜像:

docker image pull grafana/grafana && \

docker image pull elasticsearch:
5.6
 && \

docker image pull docker.io/xzchaoo/lookout-allinone:
1.6
.
0
-SNAPSHOT

再启动存储层, 这里用的是 ES:

docker run -d --name es -p 
9200
:
9200
 -p 
9300
:
9300
 -e 
"discovery.type=single-node"
 elasticsearch:
5.6

执行 docker logs-f es 查看 ES 启动情况。

启动 SOFALookout,因为演示机是 Mac, Docker 的 host 网络模式无法正常工作,而 SOFALookout 默认连接到 localhost 的 ES,这会导致错误,因此需要覆盖参数。

我们需要创建一个配置文件, 比如 foo.properties,有如下内容:

gateway.metrics.exporter.es.host=es

metrics-server.spring.data.jest.uri=http:
//es:9200

然后启动 SOFALookout 容器, 将该配置文件挂到指定路径, 并且使用 Docker 的 link 参数来引用 ES 容器的地址:


docker run -it \

--name allinone \

--link es:es \

-e TZ=
'Asia/Shanghai'
 \

-p 
7200
:
7200
 \

-p 
9090
:
9090
 \

-v $PWD/foo.properties:/home/admin/deploy/foo.properties \

-e JAVA_OPTS=
"-Duser.timezone=Asia/Shanghai -Dlookoutall.config-file=/home/admin/deploy/foo.properties"
 \

docker.io/xzchaoo/lookout-allinone:
1.6
.
0
-SNAPSHOT

最后启动 grafana,同样使用了 link 参数:

docker run --name grafana -d -p 
3000
:
3000
 --link allinone:allinone grafana/grafana

SOFALookout 启动之后可以访问其 9090 端口,我们打开 http://localhost:9090,有一个简单的控制台, 我们搜索一个 Metrics:jvm.classes.loaded{app="*"},这是 lookout-client 扩展包自动采集的数据。执行之前写的 lookut-client demo 程序,此时应该有几个点的数据了,需要等一段时间数据点才会更多,这段时间内我们可以先到 grafana 上探索一下。

4 SOFALookout 发展规划

最后是 SOFALookout 的发展规划:

image.png

近期,对于 SOFALookout 开源版本主要是以完善适配为主,包括计算下推到 ES,和适配其他时序数据库。之后,我们也会开源关于 Trace 数据的处理模块。

以上内容由 SOFAChannel#6 直播分享整理,如果大家有疑问可以在钉钉群(搜索群号即可加入:23195297)或者 Github 上与我们讨论交流,我们将进行解答。也欢迎大家一起参与共建呀~

SOFALookout:https://github.com/sofastack/sofa-lookout

文中提到的相关链接
蚂蚁金服轻量级监控分析系统 SOFALookout 服务端开源

SOFALookout Demo 下载地址:

https://github.com/sofastack/sofa-lookout/tree/master/samples/metrics/client

本期视频回顾以及 PPT 查看地址

https://tech.antfin.com/community/live/687/data/846

往期直播精彩回顾
给研发工程师的代码质量利器 | SOFAChannel#5 直播整理:

https://tech.antfin.com/community/live/552

分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理:

https://tech.antfin.com/community/live/462

SOFARPC 性能优化实践(下)| SOFAChannel#3 直播整理:

https://tech.antfin.com/community/live/245

SOFARPC 性能优化实践(上)| SOFAChannel#2 直播整理:

https://tech.antfin.com/community/live/244

从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理:

https://tech.antfin.com/community/live/148

目录
相关文章
|
2月前
|
机器学习/深度学习 数据采集 存储
时间序列预测新突破:深入解析循环神经网络(RNN)在金融数据分析中的应用
【10月更文挑战第7天】时间序列预测是数据科学领域的一个重要课题,特别是在金融行业中。准确的时间序列预测能够帮助投资者做出更明智的决策,比如股票价格预测、汇率变动预测等。近年来,随着深度学习技术的发展,尤其是循环神经网络(Recurrent Neural Networks, RNNs)及其变体如长短期记忆网络(LSTM)和门控循环单元(GRU),在处理时间序列数据方面展现出了巨大的潜力。本文将探讨RNN的基本概念,并通过具体的代码示例展示如何使用这些模型来进行金融数据分析。
319 2
|
22天前
|
数据采集 自然语言处理 搜索推荐
基于qwen2.5的长文本解析、数据预测与趋势分析、代码生成能力赋能esg报告分析
Qwen2.5是一款强大的生成式预训练语言模型,擅长自然语言理解和生成,支持长文本解析、数据预测、代码生成等复杂任务。Qwen-Long作为其变体,专为长上下文场景优化,适用于大型文档处理、知识图谱构建等。Qwen2.5在ESG报告解析、多Agent协作、数学模型生成等方面表现出色,提供灵活且高效的解决方案。
115 49
|
7天前
|
安全 前端开发 Android开发
探索移动应用与系统:从开发到操作系统的深度解析
在数字化时代的浪潮中,移动应用和操作系统成为了我们日常生活的重要组成部分。本文将深入探讨移动应用的开发流程、关键技术和最佳实践,同时分析移动操作系统的核心功能、架构和安全性。通过实际案例和代码示例,我们将揭示如何构建高效、安全且用户友好的移动应用,并理解不同操作系统之间的差异及其对应用开发的影响。无论你是开发者还是对移动技术感兴趣的读者,这篇文章都将为你提供宝贵的见解和知识。
|
13天前
|
测试技术 开发者 Python
使用Python解析和分析源代码
本文介绍了如何使用Python的`ast`模块解析和分析Python源代码,包括安装准备、解析源代码、分析抽象语法树(AST)等步骤,展示了通过自定义`NodeVisitor`类遍历AST并提取信息的方法,为代码质量提升和自动化工具开发提供基础。
26 8
|
11天前
|
调度 开发者
核心概念解析:进程与线程的对比分析
在操作系统和计算机编程领域,进程和线程是两个基本而核心的概念。它们是程序执行和资源管理的基础,但它们之间存在显著的差异。本文将深入探讨进程与线程的区别,并分析它们在现代软件开发中的应用和重要性。
26 4
|
12天前
|
负载均衡 网络协议 算法
Docker容器环境中服务发现与负载均衡的技术与方法,涵盖环境变量、DNS、集中式服务发现系统等方式
本文探讨了Docker容器环境中服务发现与负载均衡的技术与方法,涵盖环境变量、DNS、集中式服务发现系统等方式,以及软件负载均衡器、云服务负载均衡、容器编排工具等实现手段,强调两者结合的重要性及面临挑战的应对措施。
33 3
|
14天前
|
机器学习/深度学习 人工智能 数据处理
【AI系统】NV Switch 深度解析
英伟达的NVSwitch技术是高性能计算领域的重大突破,旨在解决多GPU系统中数据传输的瓶颈问题。通过提供比PCIe高10倍的带宽,NVLink实现了GPU间的直接数据交换,减少了延迟,提高了吞吐量。NVSwitch则进一步推动了这一技术的发展,支持更多NVLink接口,实现无阻塞的全互联GPU系统,极大提升了数据交换效率和系统灵活性,为构建强大的计算集群奠定了基础。
41 3
|
25天前
|
网络协议 网络安全 网络虚拟化
本文介绍了十个重要的网络技术术语,包括IP地址、子网掩码、域名系统(DNS)、防火墙、虚拟专用网络(VPN)、路由器、交换机、超文本传输协议(HTTP)、传输控制协议/网际协议(TCP/IP)和云计算
本文介绍了十个重要的网络技术术语,包括IP地址、子网掩码、域名系统(DNS)、防火墙、虚拟专用网络(VPN)、路由器、交换机、超文本传输协议(HTTP)、传输控制协议/网际协议(TCP/IP)和云计算。通过这些术语的详细解释,帮助读者更好地理解和应用网络技术,应对数字化时代的挑战和机遇。
69 3
|
14天前
|
前端开发 Android开发 UED
移动应用与系统:从开发到优化的全面解析####
本文深入探讨了移动应用开发的全过程,从最初的构思到最终的发布,并详细阐述了移动操作系统对应用性能和用户体验的影响。通过分析当前主流移动操作系统的特性及差异,本文旨在为开发者提供一套全面的开发与优化指南,确保应用在不同平台上均能实现最佳表现。 ####
18 0
|
21天前
|
存储 自然语言处理 数据可视化
3倍提升效率:医疗病理信息抽取与关系图谱展示系统解析
该项目旨在通过NLP技术将医疗病理报告中的非结构化文本转化为结构化数据,实现信息的高效抽取、存储及可视化展示。利用Python、JavaScript等技术栈,结合Echarts等工具,构建病理信息的关系图谱,支持多条件检索与图表互动,提高医生及研究人员的工作效率。预期成果包括数据结构化、关系图谱可视化、快速检索及数据统计分析等功能。项目预计2-4周完成。

推荐镜像

更多