日志与遥测的边界
概述
一句话区分：日志回答“发生了什么”，遥测回答“系统现在或最近状态如何”。
严格讲，在可观测性、OpenTelemetry、Grafana Alloy 这类体系里，日志也可以算作 telemetry 的一种 signal；但工程设计中仍应把原始日志和结构化健康遥测分开治理，因为它们的数据量、隐私风险、查询方式和保留策略都不同。
内容
对比维度
| 项 | 日志 Logs | 遥测 Telemetry |
|---|---|---|
| 典型形态 | 文本或 JSON 事件流 | 指标、Reported State、链路追踪、性能剖析、健康摘要 |
| 粒度 | 细，按事件逐条记录 | 聚合或结构化，常见形态是时间序列 |
| 目的 | 排查问题、复盘现场、还原上下文 | 监控、告警、趋势分析、容量和健康判断 |
| 示例 | 摄像头打开失败、堆栈信息、上传失败的 HTTP 响应体 | CPU、内存、磁盘剩余、录制状态、帧率、上传失败计数 |
| 数据量 | 大，容易爆量 | 应小、稳定、可控 |
| 隐私风险 | 高，可能包含路径、token、客户信息或原始错误文本 | 相对较低，但必须控制 Label Cardinality |
| 查询方式 | grep、Loki log query | Prometheus、Grafana dashboard、alert rules |
| 保留策略 | 常短期保留，按需调试 | 适合长期趋势化和容量分析 |
工程信号分层
- Raw logs：原始日志，保留诊断现场。它适合记录错误文本、路径、堆栈、外部系统响应体等细节，但不适合作为长期监控主数据。
- Metrics / health telemetry：结构化健康数据，适合长期保存、看板和告警。它应该使用固定字段、固定标签集合和稳定采样周期。
- Traces：一次请求或流程经过哪些组件、每段耗时多少，适合定位跨服务延迟和依赖关系。
- Profiles：CPU 或内存热点，适合回答“资源消耗在哪里”。
这几类信号可以互相引用，但不应互相替代。日志可以派生出失败计数，失败计数可以进入指标系统；反过来，指标告警可以引导人去查对应时间窗口的日志。
设备场景边界
在设备或边缘系统里，边界可以这样划：
- 日志：设备应用、图形界面和系统服务的原始行进入日志系统，用于查问题。
- 遥测：CPU、内存、磁盘、录制状态、摄像头帧率、上传队列、错误计数、版本和配置摘要进入 metrics 或 health 系统，用于看板和告警。
- 业务身份或设备平台：适合接收 bounded 健康摘要 和 Reported State，不适合承载 raw logs 的数据面。
如果平台的主要职责是身份、设备台账、租户关系和当前状态同步，它更像控制面。Raw logs 数据量大、敏感且查询模型不同，应进入独立日志数据面；平台只保留必要的健康摘要、版本摘要和错误计数。
关键要点
- 日志偏诊断现场，遥测偏状态、趋势和告警。
- OpenTelemetry 视角下 logs、metrics、traces、profiles 都是 telemetry signals；工程落地时仍要分数据面、保留策略和权限边界。
- 长期监控优先使用结构化指标和健康摘要，原始错误文本、路径、对象 key、请求体等细节留在日志系统。
- 指标标签必须控制 Label Cardinality，不要把动态路径、设备节点、录制 ID、对象 key 或自由文本错误塞进 label。