APM体系概述

APM体系

APM（Application Performance Management ）

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

img

监控对象

• 数据维度 从数据类型划分，大体可分为：

  • 日志（logs）：自动埋点/手动埋点
  • 指标监控(metrics)：服务、端点、实例的各项指标
  • 调用链(tracing): 同一TraceId的调用序列

• 功能维度 从业务角度划分，可分为：

  • 基础监控 ：应用服务的基本性能，物理机/虚拟机的指标
  • 中间件监控：kafka Db Redis Zk 等依赖项的性能
  • 业务监控：根据业务需求定制监控内容

监控象限

功能模块

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

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

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

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

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

Skywalking & Pinpoint 生态下的四大组件

image-20200415155233587

使用人群

image-20200414203658711

现有的方法

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

• 收集组件的异构化。开发语言可能有java，也可能有golang
• 组件的多样化。从前端埋点开始，nginx、中间件、db等链路都需要包含
• 调用链的完整性，技术难点的攻关，如异步、进程间上下文传递等
• 时效采样。尤其在海量调用时，既要保证准确性，也要保证效率

调用链难题 & OpenTracing

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

如何统一囊括记录日志、指标和调用链三个维度的数据？这是关键挑战。

—— “Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”

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

img

img

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

系统架构实现方案

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

全开源方案

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

image

https://openapm.io/landscape

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

[Dapper] (https://bigbully.github.io/Dapper-translation/)

• 通过AGENT生成调用链日志。

• 通过logstash采集日志到kafka。

• kafka负责提供数据给下游消费。

• storm计算汇聚指标结果并落到es。

• storm抽取trace数据并落到es，这是为了提供比较复杂的查询。比如通过时间维度查询调用链，可以很快查询出所有符合的traceID，根据这些traceID再去 Hbase 查数据就快了。

• logstash将kafka原始数据拉取到hbase中。hbase的rowkey为traceID，根据traceID查询是很快的。

pinpoint

在框架中引进kafaka:

1. 可以削峰填谷，防止大数据量的冲击
2. 实现数据的多同步，扩展性也提高

PinPoint

利用HBase来存储实时数据

pinPoint

鹰眼

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

鹰眼

SkyWalking

在Apache“云原生”生态中的布局

image.png

部署框架

skywakling

方案对比

方案	skywalking	cat	pinpoint	zipkin
依赖	Java 8+ maven3.0+ nodejs zookeeper/k8s elasticsearch	Java 6 7 8、Maven 3+ MySQL 5.6 5.7、Linux 2.6+ hadoop可选	Java 6，7，8 maven3+ Hbase0.94+	Java 6，7，8 Maven3.2+ rabbitMQ
实现方式	java探针，字节码增强	代码埋点（拦截器，注解，过滤器等）	java探针，字节码增强	拦截请求，发送（HTTP，mq）数据至zipkin服务
存储	elasticsearch , H2	mysql , hdfs	HBase	in-memory ， mysql ， Cassandra ， Elasticsearch
jvm监控	支持	不支持	支持	不支持
trace查询	支持	支持	需要二次开发	支持
stars	13k	13.1k	10.2k	12.7k
侵入	低, 也可以手动埋点	高，需要埋点	低	高，需要开发
部署成本	较低，集群部署需要中间支持	中	较高	中
数据导出	需要开发，ES 支持分索引定时导出	不容易，hdfs 太重	HBase 实时同步较容易	较容易
定制化监控	基于端口可以支持，再细粒度需要二次开发	支持，手动埋点来实现

SkyWalking

• 官网
• 对应中文文档(目前6.X, 有些内容可以对照看)

功能展示

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

演示地址：

• 官方演示地址

集成方式

• agent 自动无侵入埋点

  • JVM参数中添加 -javaagent:/path/to/skywalking-package/agent/skywalking-agent.jar，并且确保这个参数在-jar参数之前。

  • 注意 需要和agent包一起使用

    java -javaagent:/Users/rongxin.srx/Downloads/apache-skywalking-apm-bin/agent/skywalking-agent.jar \
    -DSW_AGENT_NAME=sw-test-demo-app \
    -Dskywalking.collector.backend_service=: \
    -Dspring.profiles.active=local,nosso  \
    -jar is-kcloud-1.0-SNAPSHOT.jar 
    

• 提供SDK 手动埋点

服务端功能

• 性能大盘

• 服务依赖拓扑

• 请求调用追踪

• 性能采样分析

• 业务告警

• 指标对比

需要解决的问题

• 运维依赖复杂

  • SkyWalking 集群部署依赖 Zk 或者 部署在 k8s

  • 数据存储依赖集群 ES集群

• 大数据量下稳定性

  • 缺乏数据缓冲池，需要引入MQ

  • 依赖ES的稳定性 (ES可能出现性能抖动)

• 可扩展性，ES中的数据不易导出 ，进行多备份 （考虑使用多方监听MQ中的数据，进行备份）

• 二次开发：agent插件开发比较专业，服务端逻辑复杂，需要时间消化