Update nexus wiki content

This commit is contained in:
2026-05-03 05:42:06 +08:00
parent 90f3811b83
commit 111bc65b7b
707 changed files with 32306 additions and 7289 deletions

View File

@@ -1,72 +1,85 @@
---
title: "Observability"
type: concept
tags: [Observability, SRE, Cloud-Native, Telemetry, Monitoring, Reliability]
sources:
- public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113
- ctp-topic-67-cloud-native-observability-using-opentelemetry
- public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2
last_updated: 2026-04-29
tags: [DevOps, Monitoring, Reliability]
sources: [engineering-devops-automator]
last_updated: 2026-05-01
---
## Observability(可观测性)
# Observability
可观测性Observability是指系统通过其外部输出理解其内部状态的能力。在软件工程中可观测性通过遥测数据Telemetry——指标Metrics、日志Logs、追踪Traces——持续理解系统健康状态是 [[SRE]] 和 [[Recovery-Assurance]] 的核心技术基础。
## 定义
可观测性Observability是通过收集系统外部输出来推断其内部状态的能力核心目标是回答"为什么系统出现了问题",而不仅仅是"系统是否正常"。
## Three Pillars
## 可观测性三支柱
可观测性三大支柱Three Pillars of Observability
### 1. 指标Metrics
- **定义**:数值型测量,反映系统健康状况
- **特点**:聚合性强、支持告警、存储成本相对低
- **工具**[[Prometheus]]、CloudWatch、DataDog
- **示例**CPU 使用率、请求延迟、错误率、QPS
| 支柱 | 说明 | 示例 |
|------|------|------|
| **Metrics指标** | 聚合的数值数据,反映系统状态趋势 | CPU 使用率、请求延迟、错误率 |
| **Logs日志** | 离散的事件记录,按时间顺序记录系统活动 | 访问日志、错误日志、审计日志 |
| **Traces追踪** | 跨服务和组件的请求传播路径 | 分布式链路追踪、调用链可视化 |
### 2. 日志Logs
- **定义**:系统产生的离散事件记录
- **特点**:详细信息、时序排列、关联分析
- **工具**ELK StackLoki、CloudWatch Logs
- **示例**:访问日志、错误日志、审计日志
## Observability vs. Monitoring
### 3. 追踪Traces
- **定义**:请求在分布式系统中的完整调用路径
- **特点**:端到端关联、延迟分析、瓶颈定位
- **工具**Jaeger、Zipkin、AWS X-Ray
- **示例**:微服务调用链、数据库查询耗时
传统监控Monitoring与可观测性Observability的核心区别
## SRE 可观测性实践
| 维度 | 传统监控Monitoring | 可观测性Observability |
|------|---------------------|-------------------------|
| **目标** | 回答预设问题 | 回答任意未知问题 |
| **假设** | 故障模式已知 | 故障模式未知High Cardinality |
| **数据** | 聚合指标,低基数 | 原始事件,高基数 |
| **根因定位** | 依赖仪表板预设视图 | 通过遥测数据探索定位 |
| **适用场景** | 稳定系统 | 云原生、分布式系统 |
### RED 方法(面向服务)
- **Rate**:请求率(每秒请求数)
- **Errors**:错误率(失败请求百分比)
- **Duration**:延迟(响应时间分布)
> "You can't monitor your way to understanding a distributed system. You need observability." — Charity Majors
### USE 方法(面向资源)
- **Utilization**:利用率
- **Saturation**:饱和度
- **Errors**:错误
## Observability Engineering
## 在 DevOps Automator 中的应用
DevOps Automator 的可观测性体系:
1. **指标收集**Prometheus scrape metrics
2. **可视化**Grafana Dashboard
3. **告警**Prometheus Alert Rules → AlertManager
4. **日志聚合**:可选 Loki/ELK
5. **分布式追踪**:可选 Jaeger
可观测性工程Observability Engineering是将可观测性作为架构设计原则在软件开发生命周期中内嵌遥测数据收集
### 关键监控指标
- 部署频率Deployment Frequency
- 变更失败率Change Failure Rate
- MTTRMean Time To Recovery
- 可用性Availability
- **Left-Shift**:在开发阶段就定义 SLI/SLO持续验证
- **Telemetry as Code**:将遥测配置纳入 IaC实现版本化管理
- **Continuous Validation**用主动探测Synthetic Monitoring验证恢复路径
## 相关概念
- [[Prometheus]]:指标采集和告警核心组件
- [[Grafana]]:指标可视化平台
- [[Zero-Downtime Deployment]]:可观测性支撑零停机部署的监控需求
## Connection to SRE and Recovery Assurance
## 相关工具
| 类型 | 工具 |
|------|------|
| 指标 | Prometheus, CloudWatch, DataDog, New Relic |
| 日志 | ELK Stack, Loki, CloudWatch Logs |
| 追踪 | Jaeger, Zipkin, AWS X-Ray, OpenTelemetry |
| 可视化 | Grafana, Datadog Dashboards |
在 [[SRE]] 实践中,可观测性是实现可靠性目标的必要条件:
## SRE 四个黄金信号
Google SRE 提出的关键指标:
1. **Latency**:延迟
2. **Traffic**:流量
3. **Errors**:错误
4. **Saturation**:饱和度
- **SLI/SLO/SLA 的测量基础**:可观测性提供量化可靠性的原始数据
- **Error Budget 的支撑**:通过指标追踪 Error Budget 消耗速度
- **On-Call 响应的依据**:日志和追踪是 MTTRMean Time To Recovery的核心数据源
- **[[Recovery-Assurance]] 的前提**:无法观测的系统无法保证恢复能力
## OpenTelemetry
[[OpenTelemetry]]OTel是 CNCF 的开源可观测性框架,提供厂商中立的指标、日志、追踪统一采集标准。
## Related Concepts
- [[SRE]] — 可观测性是 SRE 四大黄金信号的基础
- [[Recovery-Assurance]] — 可观测性是 Recovery Assurance 的技术前提
- [[OpenTelemetry]] — 可观测性工程的具体实现框架
- [[RTO]] / [[RPO]] — 可观测性支撑 RTO/RPO 的持续监控
## Sources
- [[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]]
- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]
- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]
## Aliases
- 可观测性
- Observability
- Monitoring
- 监控
- 可观测系统工程