可观测性

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

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

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

  1. 需要事先预测问题可能发生在哪里，以及问题发生的模式
  2. 关注的维度不一样，监控更加关注基础设施的资源情况，可观测平台瞄准的恰恰是应用软件本身
  3. 数据收集的全面性（不仅仅是指标数据）和关联性上

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

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

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

度量：Prometheus

链路追踪：Zipkin...

日志

20201125143743

日志中有用的信息

输出

输出的日志应该是什么样的：

收集&缓冲

为了缓解收集大量日志的压力 可以在收集器之前假设Kafka或者Redis作为缓冲层 面对突发流量

加工&聚合

存储&查询

ES是这方面唯一的选择

日志有如下性质：

  1. 写入后基本无需修改
  2. 分为冷热数据 更早的日志价值更低
  3. 日志可离线查询与实时查询

链路追踪

目标：排查故障 分析性能数据 监控服务间的行为

2020112514590

链路追踪的挑战：

  1. 异构技术
  2. 对性能敏感
  3. 对应用透明
  4. 自动扩缩容
  5. 持续的监控

数据收集

追踪规范化

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

OpenTelemetry

跨语言规范：

API与SDK需要通过插桩的方式来收集数据

  1. API：定义用于生成和关联追踪、指标和日志的数据类型和操作
  2. SDK：定义 API 特定语言实现的要求，同时还定义配置、数据处理和导出等概念
  3. 数据：定义遥测后端可以提供支持的 OpenTelemetry 协议 （OTLP），OTLP 的数据模型定义是基于 ProtoBuf 完成的

OpenTelemetry Collector：针对如何接收、处理和导出遥测数据提供了与供应商无关的实现

OpenTelemetry Collector 架构

部署模式：

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

聚合度量

指标收集

指标数据类型

指标采集方式

指标传输协议：

健康检查API模式：

屏幕截图 2021-01-29 094428

Prometheus

架构

存储查询

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

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

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

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

监控预警

可观测性驱动开发

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

文化

可观测性文化

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

可观测性成熟度框架