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

时间 2019-11-29

标签蚂蚁轻量级监控分析系统解析 sofachannel#6 sofachannel 直播整理繁體版

原文原文链接

<SOFA:Channel/>，有趣实用的分布式架构频道。
本文根据 SOFAChannel#6 直播分享整理，主题：轻量级监控分析系统 SOFALookout 原理讲解和功能演示。
回顾视频以及 PPT 查看地址见文末。
欢迎加入直播互动钉钉群： 23195297，不错过每场直播。

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

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

欢迎你们 Star 我，SOFALookout：github.com/sofastack/s…node

1 监控预警基本概念介绍

1.1 什么是 SOFALookout

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

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

1.2 Metrics 的前置知识

介绍一些 Metrics 的前置知识：github

第一是时序数据，比较正式的解释是“基于稳定频率持续产生的一系列指标监测数据”。简单说横轴是时间，纵轴是数值的状况下，第一印象能够作成走势图的数据一般就是时序数据。好比 2009 年到 2018 年每一年双十一天猫的成交额，就构成了时序数据。spring

第二是标签（Tag），它用于代表指标项监测针对的具体对象。仍是以刚才的成交额为例子，其实咱们要监测的指标是“成交额”，可是“成交额”并无标明要监测的对象，即谁的成交额，哪一个省的成交额，也就是缺乏“定语”。标签的做用就至关因而“定语”。好比“天猫的浙江省的成交额”，在代码中一般会有键值对来描述，好比 type="天猫"，province="浙江"。docker

第三是时序数据库，即专门为存查时序数据而设计的数据管理系统。主要有如下几个特色：数据库

写多读少
数据多维度，无 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 的包结构：

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 的设计与实现，下图代表了数据的流动方向：

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

Gateway 还会负责数据的基本清洗，好比过滤掉一些已知的坏数据。这里使用的是管道过滤器模式, 因此咱们能够很容易加入一个新的切面逻辑.

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

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

下面是 Server 的设计与实现，下图代表了数据的流动方向：

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 的发展规划：

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

以上内容由 SOFAChannel#6 直播分享整理，若是你们有疑问能够在钉钉群（搜索群号便可加入：23195297）或者 Github 上与咱们讨论交流，咱们将进行解答。也欢迎你们一块儿参与共建呀~

SOFALookout：github.com/sofastack/s…

文中提到的相关连接

蚂蚁金服轻量级监控分析系统 SOFALookout 服务端开源
SOFALookout Demo 下载地址： github.com/sofastack/s…

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

tech.antfin.com/community/l…

往期直播精彩回顾

给研发工程师的代码质量利器 | SOFAChannel#5 直播整理：tech.antfin.com/community/l…
分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理：tech.antfin.com/community/l…
SOFAChannel#3 SOFARPC 性能优化实践（下）：tech.antfin.com/community/l…
SOFAChannel#2 SOFARPC 性能优化实践（上）：tech.antfin.com/community/l…
SOFAChannel#1 从蚂蚁金服微服务实践谈起：tech.antfin.com/community/l…

公众号：金融级分布式架构（Antfin_SOFA）