APM体系概述

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了APM体系概述相关的知识,希望对你有一定的参考价值。

参考技术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

以上是关于APM体系概述的主要内容,如果未能解决你的问题,请参考以下文章

什么是Apache SkyWalking?

285.软件体系结构评估概述

Oracle体系概述

计算机网络—— 概述:计算机网络体系结构

应用性能管理(APM, Application Performance Management)

简要概述网络安全保障体系的总体框架