可观测性

1. 可观测性的本质与理论基础

如果能够在不发布新代码（如增加一个用于调试的日志）的情况下理解任何奇怪或不确定性的状态，那么我们的系统就具备可观测性。

1.1 可观测性的科学基础

可观测性源自控制理论，其核心数学定义是：通过系统的输出（观测值）能够唯一确定系统内部状态的全部信息。在现代分布式系统中，可观测性已从纯粹的数学概念演变为工程实践，成为理解复杂系统行为的基石。

1.2 系统复杂性与可观测性

现代软件系统的复杂性呈现指数级增长：

结构化的事件（Structured Events）是可观测性的基础，通过高基数（指包含在一个集合中的唯一值的数量）、高维度（数据中键（key）的数量）的事件，将成为能够发现隐藏在复杂系统架构中的其他隐藏问题的关键组成部分。

1.3 可观测性与传统监控的区别

维度传统监控可观测性
问题发现方式预定义规则与阈值告警探索式发现未知问题
关注点基础设施资源状态应用软件行为与用户体验
数据广度主要为指标数据指标、日志、追踪、事件全覆盖
灵活性静态仪表板动态查询与关联分析

2. 三支柱模型深度解析

以下三种监控数据都只是结构化事件的一部分

监控的三种维度方式监控的三种维度方式各维度技术栈

2.1 日志：系统行为的时间戳记

日志记录离散事件，通过这些记录事后分析出程序的行为。现代日志系统不仅记录文本信息，还包括结构化数据、元数据和上下文信息。

日志分级策略：

结构化日志最佳实践：

2.2 追踪：分布式系统的路径可视化

单体的调用栈追踪或者服务调用之间的分布式追踪。追踪系统的核心是建立请求在分布式系统中的完整路径。

追踪数据模型：

分布式追踪挑战与解决方案：

  1. **异构技术**：通过标准化协议（如W3C Trace Context）实现跨语言、跨框架的追踪
  2. **性能敏感**：采用采样策略，在性能和可观测性之间找到平衡
  3. **对应用透明**：使用字节码插桩或eBPF等技术实现无侵入式追踪
  4. **自动扩缩容**：动态服务发现与追踪上下文传播
  5. **持续监控**：建立端到端的追踪数据处理流水线

数据收集模式对比：

2.2.1 追踪规范化演进

OpenTracing（链路追踪标准） -> OpenCensus（在前者的基础上，还包括度量） -> OpenTelemetry（统一标准）

OpenTelemetry关键特性：

2.3 度量：系统状态的量化表达

度量是指对系统中某一类信息的统计聚合。度量数据提供了系统行为的量化视图，支持趋势分析和容量规划。

指标数据类型详解：

指标采集方式：

指标传输协议：

3. OpenTelemetry生态系统深度解析

3.1 核心组件架构

OpenTelemetry定义了完整的可观测性数据收集、处理和导出体系：

API（Application Programming Interface）：定义用于生成和关联追踪、指标和日志的数据类型和操作。API是语言无关的规范，确保不同语言实现的兼容性。

SDK（Software Development Kit）：定义API特定语言实现的要求，同时还定义配置、数据处理和导出等概念。SDK提供具体的实现和扩展点。

数据模型（Data Model）：基于Protocol Buffers定义的通用数据模型，支持追踪、指标和日志三种信号。

3.2 OpenTelemetry Collector架构

OpenTelemetry Collector 架构

OpenTelemetry Collector提供与供应商无关的实现，用于接收、处理和导出遥测数据。

Receivers → Processors → Exporters

Receivers（接收器）：

Processors（处理器）：

Exporters（导出器）：

部署模式：

  1. **Agent模式**：作为守护进程或边车（sidecar）与应用部署在一起

    • 优势：低延迟、本地缓冲、减少网络调用
    • 适用场景：单机部署、容器化部署

  2. **Gateway模式**：作为独立中间件部署，汇聚多个Agent数据

    • 优势：集中管理、统一配置、高级处理能力
    • 适用场景：大规模部署、多租户环境

  3. **混部模式**：结合Agent和Gateway的优势

    • 优势：灵活性高、容错能力强
    • 适用场景：复杂网络环境、混合云部署

3.3 语义约定（Semantic Conventions）

OpenTelemetry定义了标准的属性和标签约定，确保不同系统收集的可观测性数据具有统一的含义和结构：

4. 现代可观测性技术栈

4.1 数据收集层

应用层插桩：

基础设施层收集：

网络层观测：

4.2 数据存储与查询

时序数据库优化策略：

如果使用传统的关系型数据库存储度量数据，那每天监控数据的产生量将会非常的大。大部分度量数据都可以使用专门的时序数据库来进行存储。

由于度量数据多写少读、几乎不删改、数据只顺序追加这些特点，时序数据库就可以使用某些策略来进行优化：

  1. **日志结构的合并树（LSM-Tree）**：先写内存再批量刷盘，优化写入性能
  2. **数据采样策略**：对历史数据进行降采样，如几周前的数据只保留小时级聚合，几年前的数据只保留日级聚合
  3. **数据生命周期管理**：类似环形缓冲区，输入无限但存储有限，根据数据重要性设置不同的保留策略

主流时序数据库对比：

分布式追踪存储：

4.3 数据分析与可视化

告警系统：

日志分析平台：

5. 可观测性驱动开发（ODB）

在整个开发过程中考虑应用程序的可靠性和软件质量，利用工具或是插桩来观测系统的状态和行为。

5.1 开发阶段的可观测性

设计阶段：

编码阶段：

测试阶段：

5.2 部署与运维阶段

部署阶段：

监控阶段：

故障响应阶段：

6. 可观测性文化与组织能力建设

6.1 文化变革理念

拥抱失败：

允许犯错：

拒绝个人英雄主义：

早排查：

6.2 组织能力建设

SRE（Site Reliability Engineering）实践：

DevOps文化融合：

知识管理与传承：

7. 可观测性成熟度框架

7.1 成熟度阶段定义

阶段1：被动感知（Reactive Awareness）

阶段2：快速响应（Rapid Response）

阶段3：主动预防（Proactive Prevention）

阶段4：持续优化（Continuous Optimization）

阶段5：认知增强（Cognitive Enhancement）

7.2 成熟度衡量指标体系

技术维度指标：

业务维度指标：

组织维度指标：

8. 最佳实践与实施路径

8.1 实施策略

渐进式部署：

  1. 从核心业务系统开始试点
  2. 逐步扩展到整个系统架构
  3. 建立标准化的部署和配置模板

标准化建设：

治理机制：

8.2 挑战与解决方案

性能挑战：

数据量挑战：

复杂性挑战：

9. 未来发展趋势

9.1 技术演进方向

AI与可观测性融合：

边缘计算可观测性：

零信任架构下的可观测性：

9.2 行业标准化

日志收集：与具体技术栈无关 ELK EFK

度量：Prometheus

链路追踪：Zipkin...

健康检查API模式：

屏幕截图 2021-01-29 094428

Prometheus

架构

部署模式：

  1. Agent模式 通过边车直接跟应用部署在一起
  2. Gatewaay模式，一个独立的中间件，

存储查询

如果使用传统的关系型数据库存储度量数据 那每天监控数据的产生量将会非常的大

大部分度量数据都可以使用专门的时序数据库来进行存储

由于度量数据多写少读、几乎不删改、数据只顺序追加这些特点，时序数据库就可以使用某些策略来进行优化：

  1. 日志结构的合并树
  2. 对数据进行采样进行节省空间 比如几周前的数据就只保留一天 几年前的就保留一周
  3. 轮替数据存储 类似于环形缓冲区 输入可以无限 存储有限

监控预警

可观测性驱动开发

在整个开发过程中考虑应用程序的可靠性和软件质量，利用工具或是插桩来观测系统的状态和行为

文化

可观测性文化

  1. 用真实数据确定工作优先级并做出决策
  2. 根据对业务来说真正重要的事情发出告警，找出真正的问题或是影响，而不仅仅根据基础架构的情况作出判断
  3. 不断消除告警
  4. 持续地对文档进行改进对于建立可观测性文化来说至关重要

可观测性成熟度框架

关联文档