Skip to content

Commit

Permalink
更新可观测性内容
Browse files Browse the repository at this point in the history
  • Loading branch information
isno committed Jan 25, 2024
1 parent 4482227 commit 9bfef4b
Show file tree
Hide file tree
Showing 3 changed files with 9 additions and 30 deletions.
12 changes: 1 addition & 11 deletions Observability/history.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,9 +11,7 @@ The information that you will use to determine whether an application is healthy
遥测数据是指采样和汇总有关软件系统性能和行为的数据,这些数据(响应时间、错误率、资源消耗等)用于监控和了解系统的当前状态。
:::

遥测数据你不一定陌生,你或许看过中央电视台火箭发射的直播,发射指挥大厅内有条不紊的回响起一系列口令:“USB、雷达 跟踪正常,遥测信号正常”。遥测信号正常说明火箭运行的参数在理想的范围内。软件领域的可测性和系统遥测数据本质和火箭一样,主要就是通过收集系统内部各类的遥测数据来了解系统内部正在发生的事情,以此找到问题的根本原因并提⾼系统可用性,所以,本质上它就是一门数据收集和分析的科学。

总结来说,软件领域的可测性能够帮助大家在 DevOps 中遇到的故障定位难、容量评估、链路梳理、性能分析等问题,提供一种所谓洞见的能力。所以从实际效果看,分布式系统的可观测性可以认为是生物学的显微镜、天文学的望远镜,我想这也是很多开源项目 Logo 中带有各种镜子的原因。
遥测数据你不一定陌生,如果你在生活中观察仔细,观看电视台火箭发射的直播时,能注意到发射指挥大厅内回响起一系列这样的口令:“东风光学USB雷达跟踪正常,遥测信号正常”,软件领域的可测性和系统遥测数据本质和火箭一样,主要就是通过收集系统内部各类的遥测数据来了解系统内部正在发生的事情,帮助大家在 DevOps 中遇到的故障定位难、容量评估、链路梳理、性能分析等问题,提供一种所谓洞见的能力,本质上它就是一门数据收集和分析的科学。


## 可观测性与传统监控
Expand Down Expand Up @@ -63,14 +61,6 @@ X 轴的右侧称为 Known Knows(已知且理解)和 Known Unknowns(已知

所以,在最新 CNCF 发布的可观测性白皮书中,将这些可观测的数据统一称为信号(Signals),主要的信号除了 Metrics、logs、traces 之外又额外增加了 Profiles 和 Dumps。

## 可观测性生态

在 CNCF Landscape 中,有个专门的可观测方案分类:Observability and Analysis,下面还有三个子分类:Montioring、Logging、Tracing,其中的产品加起来上百个,可见其纷繁庞大。关键的这并不是全部,不在 CNCF 范围内的商业产品更是不计其数。
<div align="center">
<img src="../assets/cncf-observability.png" width = "400" align=center />
</div>



[^1]: 参见 https://medium.com/lightstephq/observability-will-never-replace-monitoring-because-it-shouldnt-eeea92c4c5c9

Expand Down
27 changes: 8 additions & 19 deletions Observability/tracing.md
Original file line number Diff line number Diff line change
@@ -1,50 +1,39 @@
# 9.4 链路追踪

微服务架构中,每个完整的请求会跨越多个服务(数十个甚至数百个),并在期间产生多次网络、RPC、消息、数据库等调用。参阅 Uber 公开的技术文档信息,它们的架构大约有 2,200 个服务,这个级别的微服务相互依赖的链路关系引用 Uber 博客中的配图[^1],供你直观感受。而分布式链路追踪所要做的事情就是通过请求粒度的轨迹追踪与数据透传,实现服务之间的确定性关联。
参阅 Uber 公开的技术文档信息,它们的微服务架构中大约有 2,200 个服务,这些服务相互依赖的链路关系引用 Uber 博客中的配图[^1],供你直观感受。而分布式链路追踪所要做的事情就是通过请求粒度的轨迹追踪与数据透传,实现服务之间的确定性关联。

<div align="center">
<img src="../assets/uber-microservice.png" width = "350" align=center />
<p>Uber 使用 Jaeger 生成的追踪链路拓扑</p>
</div>


分布式链路追踪诞生的标志性事件就是 Google Dapper 论文的发表。2010年4月,Benjamin H. Sigelman 等人在 Google Technical Report 上发表了《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》[^2]

Dapper 首先明确了分布式链路追踪的两个目标:任意部署和持续监控,进而给出了三个具体的设计准则:

- 低开销:额外数据采集的资源开销不能影响核心的业务系统
- 应用级透明:对应用开发透明,无需开发人员的协助,降低接入门槛
- 可扩展性:在未来相当长的一段时间内,随着业务的告诉发展,任然可以有效运转

Dapper 论文详细阐述了分布式链路追踪的设计理念,还提出了成为后续链路追踪系统设计的共识的两个概念:“追踪”(Trace)和“跨度”(Span)。一条 Trace 代表一次入口请求在 IT 系统内的完整调用轨迹及其关联数据集合。其中,全局唯一的链路标识 TraceId,是最具代表的一个属性。通过 TraceId 我们才能将同一个请求分散在不同节点的链路数据准确的关联起来,实现请求粒度的“确定性关联”价值。光有 TraceId 还不够,请求在每一跳的接口方法上执行了什么动作、耗时多久、执行状态是成功还是失败?承载这些信息的记录就是跨度(Span)。

每一次 Trace 实际上都是由若干个有顺序、有层级关系的 Span 所组成一颗“追踪树”(Trace Tree),如下图所示。通过 TraceId 将一次请求的所有链路日志进行组装,就能还原出该次请求的链路轨迹。
分布式链路追踪诞生的标志性事件就是 Google Dapper 论文的发表。2010年4月,Benjamin H. Sigelman 等人在 Google Technical Report 上发表了《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》[^2]。Dapper 论文详细阐述了分布式链路追踪的设计理念,还提出了成为后续链路追踪系统设计的共识的两个概念:“追踪”(Trace)和“跨度”(Span)。一条 Trace 代表一次入口请求在 IT 系统内的完整调用轨迹及其关联数据集合。其中,全局唯一的链路标识 TraceId,是最具代表的一个属性。通过 TraceId 我们才能将同一个请求分散在不同节点的链路数据准确的关联起来,实现请求粒度的“确定性关联”价值。光有 TraceId 还不够,请求在每一跳的接口方法上执行了什么动作、耗时多久、执行状态是成功还是失败?承载这些信息的记录就是跨度(Span)。每一次 Trace 实际上都是由若干个有顺序、有层级关系的 Span 所组成一颗“追踪树”(Trace Tree),如下图所示。

<div align="center">
<img src="../assets/Dapper-trace-span.png" width = "350" align=center />
<p>Trace 和 Spans</p>
</div>

总结分布式链路追踪的原理就是在分布式应用的接口方法中设置一些观察点,在入口节点给每个请求分配一个全局唯一的标识 traceId,当请求流经这些观察点时就会记录一条对应的链路日志(Span),最后通过 TraceId 将一次请求的所有链路日志进行组装,就能还原出该次请求的链路轨迹。

在没有形成大一统标准的早期,Dapper 的思想和协议影响了大量的开源项目。受到 Dapper 的启发,Twitter 开发了自己的分布式追踪系统 Zipkin,Zipkin 是第一个被广泛采用的开源的分布式链路追踪系统,提供了数据收集、存储和查询的功能以及友好的 UI 界面来展示追踪信息。

<div align="center">
<img src="../assets/zipkin-architecture.png" width = "450" align=center />
<p>Zipkin 架构图</p>
</div>

2017年 Uber 在基于 Zipkin 思想和经验的基础上开源了 Jaeger,增加了自适应采样、提供了更加强大和灵活的查询能力等,后来 Jaeger 成为 CNCF 的托管项目,并在 2019年 成为 graduated 级别。即使在今天,Zipkin 和 Jaeger 仍然是最流行的分布式追踪工具之一。

Zipkin 和 Jaeger 或多或少都对业务代码有侵入性,国内的工程师应该熟悉一款基于字节码注入具有无侵入性特点的 Skywaling ,这是一款本土开源的的调用链分析以及应用监控分析工具,特点是支持多种插件,UI 功能较强,接入端无代码侵入(Java Agent 技术)。

最后,无论是 Zipkin 还是 Jaeger 又或者 Skywaling,如何选择还是要参考采集的方式(无侵入、侵入)以及数据收集的开销。
<div align="center">
<img src="../assets/skywalking-ui.jpeg" width = "550" align=center />
<p>Skywaling 链路分析</p>
</div>


随着分布式追踪技术的日益流行,有一个问题也日益突出,不同链路追踪系统和工具之间缺乏兼容性,如果使用了一个追踪系统,很难再切换到另一个。


CNCF 技术委员会发布了 OpenTracing 和 微软推出的 OpenCensus 两个竞品在 2019 年忽然宣布握手言和,共同发布了可观性的终极解决方案 OpenTelemetry。


[^1]: 参见 https://www.uber.com/en-IN/blog/microservice-architecture/
[^2]: 参见《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/

Expand Down
Binary file added assets/skywalking-ui.jpeg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit 9bfef4b

Please sign in to comment.