可观测性技术栈选型是什么
可观测性技术栈由指标、日志、追踪三类数据及其采集、存储、查询链路组成。选型顺序应当是先统一采集标准与字段规范，再决定数据存哪里；OpenTelemetry 提供与厂商无关的采集与导出规范，应用只按 OTLP 上报，更换后端时不必重写埋点。落地上真正影响成本的是保留策略与采样率，而不是后端产品的品牌。
基本信息
| 指标 | 低基数聚合数据，用于告警、容量趋势与 SLO 计算 |
|---|---|
| 日志 | 事件明细，用于定位问题；必须设级别、采样与保留策略 |
| 追踪 | 请求链路与依赖耗时；关注采样率与上下文传播 |
| 标准 | OpenTelemetry 统一采集与导出，减少供应商绑定 |
| 成本项 | 存储容量、查询扫描量、标签基数与采样率共同决定账单 |
典型使用场景
- 故障定位：从指标告警下钻到追踪，再落到具体日志明细
- 容量规划：按历史指标趋势推算资源水位与扩容时间点
- SLO 统计：用成功率与延迟分位支撑错误预算与发布节奏
- 依赖分析：按调用方与下游维度切片，找出放大故障的链路
- 成本治理：按服务统计数据量与查询量，砍掉无人访问的指标与日志
- 审计追溯：关键操作日志单独保留，满足合规要求的留存期
采集端配置骨架（OpenTelemetry Collector）
采集端配置骨架（OpenTelemetry Collector）
receivers:
otlp: # 应用统一通过 OTLP 上报指标、日志与追踪
protocols: {grpc: {}, http: {}}
processors:
memory_limiter: {} # 限制采集端内存，避免自身被压垮
batch: {} # 批量导出，降低出口请求数
probabilistic_sampler:
sampling_percentage: 10 # 追踪采样率，按流量与预算调整
exporters:
otlp: {} # 出口走标准协议，换后端不改应用埋点
service:
pipelines:
traces: {receivers: [otlp], processors: [memory_limiter, probabilistic_sampler, batch], exporters: [otlp]}三类数据的取舍
| 数据 | 优势 | 成本与风险 |
|---|---|---|
| 指标 | 聚合开销小，适合长期保留与告警 | 高基数标签会迅速推高存储与查询延迟 |
| 日志 | 信息最全，排查细节靠它 | 无采样无保留策略时成本增长最快 |
| 追踪 | 跨服务链路清晰，依赖耗时可见 | 全量采集成本高，采样后台账对不上 |
| 元数据 | 服务名、版本、环境等维度统一后才能联查 | 命名口径不一致会使三套数据无法关联 |
先定采什么、留多久，再决定存哪里：把全量日志与全量追踪默认保留三十天，账单通常会在第一个完整月后失控。
字段规范要写成约束：服务名、环境、版本、消费者等标签的取值来源统一，采集端做校验与丢弃，避免同一含义出现多种写法。