IT咖啡馆：边缘采集与网关的抉择

概述

在可观测性体系建设中，边缘采集层扮演着“第一入口”的角色。其核心目标是保证数据在靠近源头时就具备完整性、可靠性与可扩展性，避免因高负载或链路抖动造成数据丢失。方案选用 Vector 作为统一的边缘采集与汇聚出口，理由如下：

• 边缘汇聚：在主机上部署 Vector Agent，统一拉/收 node_exporter、process-exporter、DeepFlow Agent 输出（file/journald/JSON）
• 可靠性：具备内存/磁盘缓冲、背压控制、重试退避等机制，可确保在高负载下不丢包。
• 灵活性：在边缘即可做标签规范化、采样与初步降噪，降低中心化网关的负担。
• 统一出口：向区域 OTel Gateway（otelcol） 统一转发为 OTLP (gRPC/HTTP)，对接 OTel Gateway（otelcol），由网关再写入到 OpenObserve / Kafka 等。实现与 OpenObserve、Kafka、VictoriaMetrics 等后端的解耦。

这样，边缘节点只需运行一个轻量化 Vector 进程，即可完成采集、缓冲与转发；而复杂的处理、路由和多后端分发由 OTel Gateway 完成，职责边界清晰。

概览与示例链路

1) 采集器能力对比（优势/劣势）

• 统一性与可靠性是边缘最关键的两个维度。Vector 以单进程覆盖多源（Prom 拉取 + journald/file）、强背压/缓冲与多后端协议，更适合作为边缘汇聚/出口。
• OTel Collector 更适合做区域网关与协议/处理器编排中心（当然也可上边缘，但对资源与配置治理要求更高）。
• DeepFlow Agent 继续担任网络可观测探针，通过 file/journald/JSON 与 Vector 解耦上游与下游，避免直连 Collector 丢包。
• 各种 exporter 继续扮演单一指标探针，不承担转发与可靠性职能。

2) 高负载下的可靠性机制（Vector 侧）

设计目标：至少一次投递（at-least-once）偏好，优先保证不丢；在极限情况下阻塞而非静默丢弃；自监控可告警。

关键机制

1. 背压（Backpressure）：下游拥塞时停止上游读取，防止内存爆炸；配合批处理与限速。
2. 缓冲（Buffer）：每个 sink 可配置 内存/磁盘缓冲；建议磁盘 ≥ 10–50 GiB；when_full: block。
3. 重试与退避：指数退避（带上限），避免对拥塞下游形成“雪崩式重压”。
4. 降噪与采样：在边缘做日志采样/字段裁剪/聚合，减少热点时的流量。
5. 自监控指标：暴露 /metrics，重点看：buffer 使用率/磁盘占用、events dropped/overflows/retries、请求失败率/延迟。
6. 健康检查：启动时与运行时的 downstream healthcheck，快速故障显性化。

Vector 样例（YAML, 按目录拆分）

推荐以 目录加载方式运行：vector --config-dir /etc/vector/ 目录结构： /etc/vector/ sources/*.yaml transforms/*.yaml sinks/*.yaml vector.yaml # 全局开关（data_dir/api等）

vector.yaml

data_dir: /var/lib/vector
api:
  enabled: true
  address: "0.0.0.0:8686"

sources/prom.yaml — 拉取 node_exporter / process-exporter

sources:
  node_exporter:
    type: prometheus_scrape
    endpoints: ["http://127.0.0.1:9100/metrics"]
    scrape_interval_secs: 15

  process_exporter:
    type: prometheus_scrape
    endpoints: ["http://127.0.0.1:9256/metrics"]
    scrape_interval_secs: 15

sources/logs.yaml — DeepFlow 与系统日志

sources:
  journald:
    type: journald
    current_journal_only: true

  deepflow_file:
    type: file
    include: ["/var/log/deepflow/*.json", "/var/log/deepflow/*.log"]
    read_from: beginning
    ignore_older_secs: 2592000  # 30d

transforms/normalize.yaml — 统一标签与抑噪（VRL）

transforms:
  add_tags:
    type: remap
    inputs: [node_exporter, process_exporter, journald, deepflow_file]
    source: |
      .labels.host = get_env("VECTOR_HOSTNAME") ?? .labels.host ?? .host
      .labels.cluster = .labels.cluster ?? "prod"
      .labels.region = .labels.region ?? "ap-northeast-1"
      # 示例：丢弃过长行或明显无效日志
      if exists(.message) && bytes!(.message) > 1_000_000 { drop() }

sinks/otlp.yaml — 统一输出到 OTel Gateway（关键：磁盘缓冲+阻塞）

sinks:
  to_otlp:
    type: opentelemetry         # Vector 的 OTLP sink
    inputs: [add_tags]
    protocol: grpc
    endpoint: "http://otel-gw.svc:4317"
    request:
      timeout_secs: 10
    batch:
      max_events: 10000
      timeout_secs: 2
    buffer:
      type: disk
      max_size: 50GiB
      when_full: block
    healthcheck:
      enabled: true

说明：

• 若 DeepFlow 只能输出自定义二进制/Proto 且无法转 JSON，可先原样转运（file → OTLP/logs 原样字段），结构化解析放到后端/ETL做。
• 对热点业务可在边缘做采样/裁剪，优先保障关键指标与关键信息字段。

3) 与 OTel Gateway（otelcol）的结合

职责分层

• 边缘（Vector）：吸收抖动、做初级加工、强可靠传递（磁盘缓冲+背压）。
• 网关（otelcol）：协议集中接入（OTLP gRPC/HTTP）、持久化队列（WAL）、路由/再采样/脱敏、多路扇出（OpenObserve、Kafka 等）。

otelcol 最小可用配置（YAML）

extensions:
  file_storage:
    directory: /var/lib/otelcol/wal
  zpages: {}

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 75
    spike_limit_percentage: 15
  batch:
    timeout: 5s
    send_batch_size: 10000

exporters:
  otlphttp/openobserve:
    endpoint: https://otel.svc.plus/api/default/
    headers:
      Authorization: "Basic <REDACTED>"
    # 关键：开启发送队列并接入 file_storage，形成 WAL 持久化
    sending_queue:
      enabled: true
      num_consumers: 8
      queue_size: 20000
      storage: file_storage
    retry_on_failure:
      enabled: true
      initial_interval: 1s
      max_interval: 10s
      max_elapsed_time: 0   # 无限重试

  # 可选：原始扇出到 Kafka，供离线 ETL/回放
  kafka/traces:
    brokers: ["kafka-1:9092","kafka-2:9092"]
    topic: traces_raw
    protocol_version: 2.0.0
    encoding: otlp_proto

service:
  extensions: [file_storage, zpages]
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp/openobserve]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp/openobserve]
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp/openobserve, kafka/traces]  # 可增/减

组合要点

• 双层缓冲：Vector（磁盘 buffer）＋ otelcol（sending_queue + file_storage），吸收网络/下游抖动。
• 职责清晰：边缘只做“可靠转运 + 轻加工，脱敏”，重处理（聚合、复杂路由等）放网关。
• 弹性扩展：网关横向扩容；Kafka/OO 作为独立扩展点。
• 安全：全链路 TLS/鉴权（Vector → OTel 使用 mTLS/Token；OTel → 后端同理）。

4) 结论（为何选 Vector 做边缘统一出口）

1. 统一与简化：用一个 agent 覆盖 Prom 拉取、file/journald 多源，一处配置完成标签规范、采样与多后端协议（OTLP/Loki/…）。
2. 强可靠性：原生背压 + 磁盘缓冲 + 重试/退避，极压场景优先阻塞、不默丢；自监控指标可快速告警与容量规划。
3. 边缘轻量：相较将 OTel Collector 完整搬到边缘，Vector 更省资源/更易管控，把复杂编排留在网关。
4. 与 DeepFlow 解耦：DeepFlow Agent 专注网络探针，产出（最好 JSON 行或 journald）→ Vector 可靠转运，避免直连 Collector 造成环形队列丢包。
5. 渐进式演进：先接入指标与关键日志，随后再引入追踪与业务事件；后端可按需切换/并行（OO、Kafka、VM、Tempo…），边缘侧无需变更采集形态。

统一输出的取舍

• 其他 exporter（node/process 等）继续保留——它们只做采集不做转发；统一出口由 Vector 承担。
• DeepFlow Agent 不适合承担“边缘汇聚/转发”，保留其 探针角色，输出对接 Vector，需要代码改造。
• OTel 采集器（otelcol） 在网关层最佳，集中编排处理器/路由与 WAL；若边缘节点资源宽裕、且你确有 OTel 处理器强依赖，也可在个别节点补充 agent 型 otelcol，但不作为全局默认。

5) 运维与落地建议（精简要点）

• Systemd 启动（Vector）：ExecStart=/usr/bin/vector --config-dir /etc/vector
• 容量规划：每节点磁盘缓冲≥ 20–50 GiB；监控 buffer 使用率≥70% 告警、≥90% 严重告警。
• 告警哨位（Vector/OTel）：投递失败率、重试激增、buffer 占用、队列长度、下游 5xx。
• 灰度与回滚：先单机观测 24–48h，再批量推；保留旧配置回滚；所有变更走 GitOps。
• 数据治理：在边缘只做“安全/体积相关”的轻加工（脱敏、裁剪、采样），语义重 ETL 放到网关/后端