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
根据自己的技术栈，DIY APM框架
Dapper
-
通过AGENT生成调用链日志。
-
通过logstash采集日志到kafka。
-
kafka负责提供数据给下游消费。
-
storm计算汇聚指标结果并落到es。
-
storm抽取trace数据并落到es，这是为了提供比较复杂的查询。比如通过时间维度查询调用链，可以很快查询出所有符合的traceID，根据这些traceID再去 Hbase 查数据就快了。
-
logstash将kafka原始数据拉取到hbase中。hbase的rowkey为traceID，根据traceID查询是很快的。
pinpoint
在框架中引进kafaka:
- 可以削峰填谷，防止大数据量的冲击
- 实现数据的多同步，扩展性也提高
PinPoint
利用HBase来存储实时数据
pinPoint
鹰眼
16年开始完全放弃HDFS，引入流式计算 ，改有HBASE列存储。
鹰眼
SkyWalking
在Apache“云原生”生态中的布局
[图片上传失败...(image-94bdfb-1587285620094)]
部署框架
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
功能展示
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=<ip>:<port> \ -Dspring.profiles.active=local,nosso \ -jar is-kcloud-1.0-SNAPSHOT.jar
-
-
提供SDK 手动埋点
