Update nexus wiki content
This commit is contained in:
@@ -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 Stack(Loki)、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)
|
||||
- MTTR(Mean 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 响应的依据**:日志和追踪是 MTTR(Mean 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
|
||||
- 监控
|
||||
- 可观测系统工程
|
||||
|
||||
Reference in New Issue
Block a user