可观测性：从发现问题到解释原因¶
监控通常回答“已知指标是否超过阈值”，可观测性进一步要求仅凭系统输出，就能调查事先没有写好规则的问题。它不是安装 Grafana 就完成，而是让指标、日志、Trace、事件和发布记录围绕同一服务关联起来。
系统与应用产生遥测数据
→ Agent / Exporter / OpenTelemetry Collector
→ 指标、日志、Trace 后端
→ Dashboard / 查询 / 告警
→ 值班处置、根因分析、容量与改进
四类核心信号¶
| 信号 | 擅长回答 | 不擅长回答 |
|---|---|---|
| Metrics | 是否异常、趋势、比例、容量、SLO | 单个请求的完整细节 |
| Logs | 具体错误、上下文、业务事件 | 全局趋势，成本可能随请求量增长 |
| Traces | 请求经过哪些服务、哪里慢或失败 | 长期容量趋势，采样会遗漏请求 |
| Events/变更 | 何时发布、扩容、重启、改配置 | 单独不能说明用户影响 |
三类数据应能通过服务、环境、版本、实例、时间和 Trace ID 互相跳转。详细设计参见 信号架构与数据关联。
完整学习路径¶
| 顺序 | 章节 | 核心内容 |
|---|---|---|
| 1 | 我为什么选择 Victoria 体系 | VM、VL、采集器、Grafana 的选型理由和边界 |
| 2 | 信号架构与数据关联 | 采集、传输、存储、查询及统一属性 |
| 3 | Prometheus | 指标类型、采集、PromQL、规则和容量风险 |
| 4 | VictoriaMetrics | 长期指标存储、vmagent、单机/集群选型 |
| 5 | 日志体系 | 结构化日志、采集管道、Loki/Elasticsearch 与保留 |
| 6 | OpenTelemetry 与链路追踪 | Trace/Span、上下文传播、Collector 和采样 |
| 7 | Grafana | 数据源、Dashboard、变量、关联跳转和权限 |
| 8 | 告警、SLI 与 SLO | 从用户症状设计告警、路由、抑制和错误预算 |
| 9 | 平台运维与排障 | 遥测链路自身监控、容量、丢数和查询故障 |
从用户目标开始¶
在线服务常用 RED：请求率 Rate、错误 Errors、耗时 Duration；资源组件常用 USE：利用率 Utilization、饱和度 Saturation、错误 Errors。CPU、内存很重要，但不能代替用户可用性指标。
OpenTelemetry 把 Trace、Metrics、Logs 等定义为可关联的遥测信号，详细概念见官方 Signals 文档。