APM体系概述

Posted 2023-02-28

参考技术A

APM（ Application Performance Management ）

核心思想是什么？ 在服务各节点彼此调用的时候，记录并传递一个应用级别的标记，这个标记可以用来关联各个服务节点之间的关系。比如两个节点之间使用 HTTP 作为请求协议的话，那么这些标记就会被加入到 HTTP 头中。因此如何传递这些标记是与节点之间使用的通讯协议有关的，有些协议就很容易加入这样的内容，但有些协议就相对困难甚至不可能，因此这一点就直接决定了实现分布式追踪系统的难度。

所有现有的解决方案，都需要如下模块的支持：

❏ 数据采集 ：如何在 广度 和 效率 上进行数据采集 ——> Agent

❏ 数据加工 ：数据统一格式的整理、调用链集合 ——> Collector

❏ 数据存储 ：将计算出的指标和聚合链路信息实时保存起来 ——> Storeage

❏ 数据展示 ：高颜值、多功能显示 ——> UI

Skywalking & Pinpoint 生态下的四大组件

目前的实现方式 SkyWalking 这种直接使用 javaagent 技术 修改字节码 来自动埋点；也有类似于 cat 这种直接编码进行手动埋点的，虽然方式不同，但是解决的问题相同。

相比较普通监控和日志，调用链APM等就复杂的多了。除了有大量的数据产生源，也要有相应的业务组件来支持调用链聚合和展示。看似展示的结果很直接简答，但是过程却很复杂。器复杂性主要体现在调用链数据的收集上。

关于Tracing的数据结构，为了解决不同的分布式追踪系统 API 不兼容的问题，诞生了 OpenTracing （ opentracing.io/ ) 规范。本质上说是一套接口定义，主流的调用链服务端实现都兼容此规范， OpenTracing 大有一统天下的架势，它在其中融合Tracing、Log、Metrics的概念。

目前看标准化是大趋势（CNCF Jaeger，SpringCloud，Elastic APM），至于国内大公司的产品，也都在主动向其靠拢（阿里的鹰眼、听云、OpenApm）。

整体来说，整个APM体系就是将大三类数据（logs、metrics、trace）应用到四大模块中（收集、加工、存储、展示），并在四个难点（程序异构，组件多样，链路完整，时效采样）上不断优化

不同数据采取不同采样数据源，过于笨重。依赖过多无法维护

https://openapm.io/landscape

根据自己的技术栈，DIY APM框架

在框架中引进 kafaka:

利用HBase来存储实时数据

16年开始完全放弃HDFS，引入流式计算 ，改有HBASE列存储。

SkyWalking是分布式系统的应用程序性能监视工具，专为微服务、云原生架构和基于容器（Docker、K8S、Mesos）架构而设计

微服务治理之监控APM系统监控架构概述

APM 简介

APM 通常认为是 Application Performance Management 的简写，它主要有三个方面的内容，分别是

1. Logs(日志)、
2. Traces(链路追踪)
3. Metrics(报表统计)。

以后大家接触任何一个 APM 系统的时候，都可以从这三个方面去分析它到底是什么样的一个系统。Metrics可以用于服务告警，Tracing 和 Logging 用于调试发现问题。监控、追踪和日志是可观测性（observability）的基石

有些场景中，APM 特指上面三个中的 Metrics，我们这里不去讨论这个概念。这节我们先对这 3 个方面进行介绍，同时介绍一下这 3 个领域里面一些常用的工具。

1、Metrics

Prometheus：收集度量标准
告警管理器：根据指标查询向各种提供者发送警报
Grafana：把prometheus收集到的数据，变成可视化豪华仪表板

还有一个方案是使用美团开源监控系统CAT，提供了比较全面的实时监控告警服务。
优势：监控功能强大，基本上可以覆盖各种监控场景
劣势：接入成本较高、对业务代码侵入较大

1、Logs ，就是对个应用中打印的 log 进行收集和提供查询能力。

• Logs 的典型实现是 ELK (ElasticSearch、Logstash、Kibana)，三个项目都是由 Elastic 开源，其中最核心的就是 ES 的储存和查询的性能得到了大家的认可，经受了非常多公司的业务考验。Logstash 负责收集日志，然后解析并存储到 ES。通常有两种比较主流的日志采集方式，一种是通过一个客户端程序 FileBeat，收集每个应用打印到本地磁盘的日志，发送给 Logstash；另一种则是每个应用不需要将日志存储到磁盘，而是直接发送到 Kafka 集群中，由 Logstash 来消费。
  Kibana 是一个非常好用的工具，用于对 ES 的数据进行可视化，简单来说，它就是 ES 的客户端。

我们回过头来分析 Logs 系统，Logs 系统的数据来自于应用中打印的日志，它的特点是数据量可能很大，取决于应用开发者怎么打日志，Logs 系统需要存储全量数据，通常都要支持至少 1 周的储存。

每条日志包含 ip、thread、class、timestamp、traceId、message 等信息，它涉及到的技术点非常容易理解，就是日志的存储和查询。

使用也非常简单，排查问题时，通常先通过关键字搜到一条日志，然后通过它的 traceId 来搜索整个链路的日志。

题外话，Elastic 其实除了 Logs 以外，也提供了 Metrics 和 Traces 的解决方案，不过目前国内用户主要是使用它的 Logs 功能。

2、 Traces 系统，它用于记录整个调用链路。

前面介绍的 Logs 系统使用的是开发者打印的日志，所以它是最贴近业务的。而 Traces 系统就离业务更远一些了，它关注的是一个请求进来以后，经过了哪些应用、哪些方法，分别在各个节点耗费了多少时间，在哪个地方抛出的异常等，用来快速定位问题。

经过多年的发展，Traces 系统虽然在服务端的设计很多样，但是客户端的设计慢慢地趋于统一，所以有了 OpenTracing 项目，我们可以简单理解为它是一个规范，它定义了一套 API，把客户端的模型固化下来。
微服务架构普及，分布式追踪系统大量涌现，但API互不兼容，难以整合和切换，因此OpenTracing提出了统一的平台无关、厂商无关的API，不同的分布式追踪系统去实现。这种作用与“JDBC”类似。
OpenTracing是一个轻量级的标准化层，位于“应用程序/类库”和“日志/追踪程序”之间。
应用程序/类库层示例：开发者在开发应用代码想要加入追踪数据、ORM类库想要加入ORM和SQL的关系、HTTP负载均衡器使用OpenTracing标准来设置请求、跨进程的任务（gRPC等）使用OpenTracing的标准格式注入追踪数据。所有这些，都只需要对接OpenTracing API，而无需关心后面的追踪、监控、日志等如何采集和实现。
当前比较主流的 Traces 系统中**，Jaeger、SkyWalking** 是使用这个规范的，而 Zipkin、Pinpoint 没有使用该规范。

SkyWalking 在国内应该比较多公司使用，是一个比较优秀的由国人发起的开源项目，已进入 Apache 基金会。
另一个比较好的开源 Traces 系统是由韩国人开源的 Pinpoint，它的打点数据非常丰富。国内用skywalking比较好，有成熟的社区，可以加群和创始人沟通。
Skywalking目前想要做成跟踪、监控、日志一体的解决方案（Tracing, Metrics and Logging all-in-one solution）。
数据收集：Tracing依赖探针（Agent），Metrics依赖Prometheus或者新版的Open Telemetry，日志通过ES或者Fluentd。
数据传输：通过kafka、Grpc、HTTP传输到Skywalking Reveiver
数据解析和分析：OAP系统进行数据解析和分析。
数据存储：后端接口支持多种存储实现，例如ES。
UI模块：通过GraphQL进行查询，然后通过VUE搭建的前端进行展示。
告警：可以对接多种告警，最新版已经支持钉钉。

参考：
1、https://developer.aliyun.com/article/971591?spm=a2c6h.14164896.0.0.5b90c520Bz1nGI
2、https://developer.aliyun.com/article/1053064
3、https://blog.51cto.com/mingongge/3313415