物联网边缘网关的可观测性：弱网、离线缓存与批量上报

边缘网关部署在工厂车间、机房和工地，网络不稳定、磁盘和内存有限，日志和指标不能像云上服务那样实时推送。方案的核心思路是：边缘先落盘缓冲，再批量、压缩、断点续传地往中心上报。

边缘侧：本地缓存 + 批量上报

网关上用 OpenTelemetry Collector，通过 file_storage 扩展把数据先写到本地磁盘，再异步发往中心：

extensions:
  file_storage:
    directory: /var/lib/otelcol
    timeout: 1s

exporters:
  otlphttp:
    endpoint: https://ob.jjhub.cn/otel
    sending_queue:
      storage: file_storage
      queue_size: 10000

断网时数据先落盘，恢复后按队列重传，避免丢数据。queue_size 要结合网关磁盘容量估算：一天的数据量乘以最长断网时长，确保磁盘不会写满。

弱网下的压缩与采样

边缘到中心的带宽通常只有几 Mbps 甚至更低。OTLP HTTP 开启 gzip 压缩能省下大半流量；指标在边缘先按 30 到 60 秒聚合一次再上报，日志只保留 error 级别和关键业务事件，普通 info 在边缘滚动删除。这样既控制带宽，也控制中心端的存储成本。

设备身份与多租户隔离

每台网关用独立的 service.name 和 resource attribute（site_id、gateway_id）标识，中心端按站点维度做看板和告警。告警规则把 site_id 作为分组键，一台网关离线只影响它自己，不会在告警群里刷屏。

receivers:
  otlp:
    protocols: { http: {} }
processors:
  resource:
    attributes:
      - key: site_id
        value: "factory-3"
        action: upsert

排障路径

网关告警上报中断时，先在中心看板确认最后上报时间，判断是网络还是设备问题；再登录网关看 file_storage 目录增长情况和 collector 的 queue 指标。最常见的根因是磁盘写满导致队列卡死，所以给 /var/lib/otelcol 单独分区并设置保留水位，比事后救火省心得多。