蚂蚁金服轻量级监控分析系统解析 | 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

目录
相关文章
|
24天前
|
机器学习/深度学习 存储 人工智能
让模型评估模型:构建双代理RAG评估系统的步骤解析
在当前大语言模型(LLM)应用开发中,评估模型输出的准确性成为关键问题。本文介绍了一个基于双代理的RAG(检索增强生成)评估系统,使用生成代理和反馈代理对输出进行评估。文中详细描述了系统的构建过程,并展示了基于四种提示工程技术(ReAct、思维链、自一致性和角色提示)的不同结果。实验结果显示,ReAct和思维链技术表现相似,自一致性技术则呈现相反结果,角色提示技术最为不稳定。研究强调了多角度评估的重要性,并提供了系统实现的详细代码。
46 10
让模型评估模型:构建双代理RAG评估系统的步骤解析
|
3天前
|
域名解析 缓存 网络协议
【网络】DNS,域名解析系统
【网络】DNS,域名解析系统
18 1
|
15天前
|
移动开发 Android开发 数据安全/隐私保护
移动应用与系统的技术演进:从开发到操作系统的全景解析随着智能手机和平板电脑的普及,移动应用(App)已成为人们日常生活中不可或缺的一部分。无论是社交、娱乐、购物还是办公,移动应用都扮演着重要的角色。而支撑这些应用运行的,正是功能强大且复杂的移动操作系统。本文将深入探讨移动应用的开发过程及其背后的操作系统机制,揭示这一领域的技术演进。
本文旨在提供关于移动应用与系统技术的全面概述,涵盖移动应用的开发生命周期、主要移动操作系统的特点以及它们之间的竞争关系。我们将探讨如何高效地开发移动应用,并分析iOS和Android两大主流操作系统的技术优势与局限。同时,本文还将讨论跨平台解决方案的兴起及其对移动开发领域的影响。通过这篇技术性文章,读者将获得对移动应用开发及操作系统深层理解的钥匙。
|
7天前
|
域名解析 运维 网络协议
推荐一款专业级的动态域名解析系统 - bind webadmin
`bind webadmin`是一款基于Bind9打造的高效DNS管理系统,简化了DNS配置与管理流程,适用于动态IP环境下的远程访问需求。此系统不仅便于维护,还支持API接口,方便自动化操作与第三方应用集成,特别适合远程办公、智能家居及各类物联网应用场景。其自托管特性保障了数据的安全与可控性,同时提供了详尽的中文安装教程,易于部署。项目地址:[bindwebadmin](https://github.com/guofusheng007/bindwebadmin.git)。建议使用阿里云主机以获得最佳性能。
|
26天前
|
存储 缓存 自然语言处理
深度解析ElasticSearch:构建高效搜索与分析的基石
【9月更文挑战第8天】在数据爆炸的时代,如何快速、准确地从海量数据中检索出有价值的信息成为了企业面临的重要挑战。ElasticSearch,作为一款基于Lucene的开源分布式搜索和分析引擎,凭借其强大的实时搜索、分析和扩展能力,成为了众多企业的首选。本文将深入解析ElasticSearch的核心原理、架构设计及优化实践,帮助读者全面理解这一强大的工具。
114 7
|
4天前
|
监控 数据可视化 搜索推荐
医院绩效核算系统源码开发,平衡计分卡在绩效管理中的应用解析
医院绩效核算系统是专为医疗机构设计的系统,通过科学方法评估科室和员工绩效,与HIS系统集成,确保数据准确实时。核心功能包括战略导向配置、现代技术架构、自动数据集成、灵活绩效核算机制及模块化管理,支持RBRVS、DRGs等多种考核方法,确保全面科学评估。采用平衡计分卡等工具,实现多维度绩效管理,促进组织持续改进与发展。
|
1月前
|
域名解析 缓存 网络协议
域名系统DNS_基础知识
域名系统(DNS)使我们能够通过易记的域名访问互联网资源,而非直接使用IP地址。DNS采用层次树状结构,由多个分量组成,如顶级域名(如.com或.cn)位于最右侧。域名长度限制为255个字符,各级域名由相应管理机构监管,顶级域名由ICANN管理。DNS分为国家顶级域名、通用顶级域名和反向域等。域名解析涉及根域名、顶级域名及权限域名服务器,通过递归和迭代查询完成。为提高效率,DNS使用分布式服务器和高速缓存技术。
|
18天前
|
测试技术 UED 开发者
软件测试的艺术:从代码审查到用户反馈的全景探索在软件开发的宇宙中,测试是那颗确保星系正常运转的暗物质。它或许不总是站在聚光灯下,但无疑是支撑整个系统稳定性与可靠性的基石。《软件测试的艺术:从代码审查到用户反馈的全景探索》一文,旨在揭开软件测试这一神秘面纱,通过深入浅出的方式,引领读者穿梭于测试的各个环节,从细微处着眼,至宏观视角俯瞰,全方位解析如何打造无懈可击的软件产品。
本文以“软件测试的艺术”为核心,创新性地将技术深度与通俗易懂的语言风格相结合,绘制了一幅从代码审查到用户反馈全过程的测试蓝图。不同于常规摘要的枯燥概述,这里更像是一段旅程的预告片,承诺带领读者经历一场从微观世界到宏观视野的探索之旅,揭示每一个测试环节背后的哲学与实践智慧,让即便是非专业人士也能领略到软件测试的魅力所在,并从中获取实用的启示。
|
2月前
|
机器学习/深度学习 自然语言处理 负载均衡
揭秘混合专家(MoE)模型的神秘面纱:算法、系统和应用三大视角全面解析,带你领略深度学习领域的前沿技术!
【8月更文挑战第19天】在深度学习领域,混合专家(Mixture of Experts, MoE)模型通过整合多个小型专家网络的输出以实现高性能。从算法视角,MoE利用门控网络分配输入至专家网络,并通过组合机制集成输出。系统视角下,MoE需考虑并行化、通信开销及负载均衡等优化策略。在应用层面,MoE已成功应用于Google的BERT模型、Facebook的推荐系统及Microsoft的语音识别系统等多个场景。这是一种强有力的工具,能够解决复杂问题并提升效率。
63 2
|
2月前
|
测试技术 uml 开发者
使用UML进行系统建模:深入解析与实践指南
【8月更文挑战第19天】UML作为一种强大的建模语言,为系统建模提供了全面的支持。通过合理使用UML,可以显著提高软件开发的效率和质量,促进团队成员之间的有效沟通。然而,UML并非万能,它需要根据项目的具体情况进行灵活应用和调整。希望本文能为你在使用UML进行系统建模时提供一些有益的参考和指导。

推荐镜像

更多