跳转至

信号架构与数据关联

可观测平台由“产生、采集、处理、存储、查询、告警”六个环节组成。任何环节都可能丢数、积压或产生高成本，因此平台本身也必须被监控。

参考架构

Linux / 网络设备 / 数据库 / Java / Python / Kubernetes
   ├─ metrics endpoint / exporter
   ├─ stdout / file / syslog
   └─ OpenTelemetry SDK / Agent
              ↓
Prometheus / vmagent / Fluent Bit / Vector / OTel Collector
              ↓
VictoriaMetrics     Loki/Elasticsearch     Trace Backend
              └────────── Grafana ──────────────┘
                         ↓
                  Alertmanager / 通知

采集层与存储层分离后，可在不修改应用的情况下更换后端或同时导出，但中间层也会带来队列、重试、内存和网络容量问题。

统一资源属性

建议在所有信号中保持一致：

service.name       服务稳定名称
service.version    镜像/应用版本
deployment.environment.name
k8s.cluster.name / namespace / pod
host.name / cloud.region
trace_id / span_id（日志关联）

不要把用户 ID、订单号、完整 URL、异常文本作为 Metrics label。指标系统为每个唯一标签组合维护时序，高基数会快速增加内存、磁盘和查询开销。这些字段更适合日志或 Trace。

采集方式

方式 优点 注意事项
Pull Prometheus 主动抓取，目标状态清晰 网络路径、服务发现、抓取周期
Push/Remote Write Agent 集中缓冲和转发，适合边缘/多集群 队列积压、重试和去重
文件/Stdout Tail 兼容已有日志 轮转、文件指纹、多行堆栈
OTLP 统一传输 Metrics/Logs/Traces Collector 容量、队列和后端兼容

保留与成本

每日新增量 ≈ 活跃时序/日志速率/Span 速率
             × 每条大小 × 保留时间 × 副本与索引开销

生产前要估算基数、采样率、峰值、压缩、复制、保留和查询并发。Debug 日志和全量 Trace 不能无期限保留。保留策略按合规、排障周期和成本分层，而不是所有数据一个期限。

信号关联

  1. Dashboard 显示发布注解和告警时间点。
  2. 从指标按服务、版本、实例下钻。
  3. Exemplars 或链接跳到同时间 Trace。
  4. Trace 的 trace_id 跳到相关日志。
  5. 日志包含实例和版本，再回到基础设施指标。

如果三个系统的服务名、时区或标签不一致，工具再多也无法形成完整证据链。