微服务可观测性
[toc]
1. 什么是可观测性
可观测性是通过检查其输出来衡量系统内部状态的能⼒。如果仅使⽤来⾃输出的信息（即传感器数据）可以估计当前状态，则系统被认为是“可观测的”。 a 软件工程的可观测性：
控制理论的可观测性定义同样适用于软件工程领域，但是软件工程领域可观测性提出了更多的要求，在软件工程领域，要求：
- 理解应用的内部工作
- 理解应用可能会进入的任何可能的状态
- 无需借助额外的工具达成上述两点
简单来说，软件工程领域的可观测性指衡量和理解和解释应用可能进入的任何可能的状态。
从微服务及云原生技术至今，对系统的可观测性要求越来越高。通过提升可观测性，可以帮助开发和运维迅速定位到系统错误及性能问题。
2. 可观测性三大支柱
2.1 metrics（指标）
指标（Metrics）通过数据的聚合，对一个程序在特定时间内的行为进行衡量。指标数据是可累加的，它们具有原子性，每个都是一个逻辑计量单元。指标数据可以观察系统的状态和趋势，但对于问题定位缺乏细节展示。
- 四个黄金指标
- 延迟
- 流量
- 错误
- 饱和度
- RED方法
- (请求)速率：服务每秒接收的请求数。
- (请求)错误：每秒失败的请求数。
- (请求)耗时：每个请求的耗时。
- USE方法
- 使用率
- 饱和度（这里主要是针对资源的饱和度(注意，不同于4大黄金信号)）。
- 错误
2.1.1 Prometheus
Prometheus是一个开源的完整监控解决方案，其对传统监控系统的测试和告警模型进行了彻底的颠覆，形成了基于中央化的规则计算、统一分析和告警的新模型
- 数据类型
- Counter：只增不减
- Gauge：可增可减
- Histogram、Summary：用于统计分析
2.2 tracing
追踪（Tracing）面向的是请求，可以分析出请求中的异常点，通常需要通过采样等方式减少数据量。追踪的最大特点是它在单次请求的范围内处理信息，任何数据、元数据信息都被绑定到系统中的单个事务上。
2.2.1 tracing 相关概念
- Trace：一个完整请求链路，包含了一个或者多个Span，这些Span最终构成一棵树（SpanTree），体现了单个请求如何扇出被处理。
- Span：一个独立的工作单元（通常是一个后端服务）
- SpanContext：Trace的全局上下文信息，包含了与tracing和span有关的标识符
- annotations：键值对，用于对Span进行额外的解释
一个完成的Tracing可以用下图来描述
更普遍的一种可视化方式如下：
2.3 logging
日志（Logging）展现的是应用程序运行产生的事件或记录，可以详细解释其运行状态，通常，在可观测中，日志也被定义为结构化的事件。。日志描述了一些离散的、不连续的事件，对于应用程序的可见性是很好的信息来源，也为应用程序的分析提供了精确的数据源。但是日志数据存在一定的局限性，它依赖于开发者暴露出来的内容，而且其存储和查询需要消耗大量的资源。
2.4 一些其他的数据
- profile
- coredump
2.4 监控数据分析
告警
告警通常包括
- 告警规则
- 分组
- 抑制
等
Prometheus alert-manager
Grafana 告警规则
一个普遍的工作流
一些值得关注的项目和方向
OpenTelemetry
OpenTelemetry 是 CNCF 的一个可观测性项目，是一个与供应商无关的开源可观测性框架，用于检测、生成、收集和导出遥测数据，比如(跟踪、指标、日志)。
eBPF
eBPF 是一项革命性技术，它能在内核中运行沙箱程序（sandbox programs）， 而无需修改内核源码或者加载内核模块。将 Linux 内核变成可编程之后，就能基于现有的（而非增加新的）抽象层来打造更加智能、 功能更加丰富的基础设施软件，而不会增加系统的复杂度，也不会牺牲执行效率和安全性。