4. 遥测采集器部署与集成

在 Catalyst 网络可观测性体系中，设备侧只负责“产生并推送”遥测数据，真正把数据落到可查询、可告警、可长期保存的时序数据库，需要采集器这一中间层。本节讨论三类主流采集器——Telegraf、Cisco Pipeline 与 Cisco Telemetry Collector（CTC）——的部署方式、gNMI 订阅配置，以及如何把 Catalyst 的遥测数据接入 Prometheus 或 InfluxDB，并完成端到端数据管道验证。

采集器选型与定位

三类采集器并非互相替代，而是面向不同场景。Telegraf 是通用型指标采集代理，插件生态丰富，适合把 gNMI 数据同时写入 InfluxDB、Prometheus（通过 remote write 或 prometheus_client 输出）以及 Kafka；Cisco Pipeline 是 Cisco 官方推出的声明式遥测管道工具，用 YAML 描述“输入—处理—输出”，对 gNMI、MDT、SNMP 等输入支持好，适合快速搭建标准化管道；Cisco Telemetry Collector 更偏向大规模、多设备、多订阅的生产环境，支持订阅编排、TLS 双向认证与高吞吐分发。选型时可参考：小规模验证与多目标输出优先 Telegraf；需要声明式、可版本化管道优先 Pipeline；大规模生产与集中订阅管理优先 CTC。

无论选哪种，采集器都处于“南向 gNMI 客户端 + 北向时序写入端”的位置。南向要与 Catalyst 建立 gNMI 会话，完成能力协商、订阅建立与数据流接收；北向要把解析后的指标按目标库的写入协议发送。理解这条链路，是后续配置与排障的基础。

Telegraf 部署与 gNMI 订阅

Telegraf 以单二进制方式部署，配置文件默认位于 /etc/telegraf/telegraf.conf。接入 Catalyst gNMI 的关键是 inputs.gnmi 插件。下面是一段可直接参考的示例配置，采集接口计数器与接口状态，周期 10 秒，输出到 InfluxDB：

[[inputs.gnmi]]
  addresses = ["10.10.20.11:57400"]
  username = "telemetry"
  password = "C1sco!Demo"
  encoding = "json_ietf"
  redial = "10s"
  tls_enable = true
  tls_ca = "/etc/telegraf/ca.pem"
  tls_cert = "/etc/telegraf/client.pem"
  tls_key = "/etc/telegraf/client.key"

  [[inputs.gnmi.subscription]]
    name = "if_counters"
    origin = "openconfig-interfaces"
    path = "/interfaces/interface/state/counters"
    subscription_mode = "sample"
    sample_interval = "10s"

  [[inputs.gnmi.subscription]]
    name = "if_oper"
    origin = "openconfig-interfaces"
    path = "/interfaces/interface/state/oper-status"
    subscription_mode = "on_change"

[[outputs.influxdb_v2]]
  urls = ["http://10.10.20.50:8086"]
  token = "$INFLUX_TOKEN"
  organization = "netops"
  bucket = "catalyst_telemetry"

这里有两个关键点。第一，subscription_mode 决定数据节奏：sample 按固定周期推送，适合计数器这类需要连续趋势的指标；on_change 只在状态变化时推送，适合 oper-status、BGP 邻居状态等事件型数据。第二，encoding 建议用 json_ietf，字段名与 OpenConfig 模型一致，便于后续标签映射。若设备使用自签证书，需把设备 CA 放入 tls_ca，否则会因证书校验失败而无法建立会话。

若目标是 Prometheus，Telegraf 可通过 outputs.prometheus_client 暴露 /metrics 端点，由 Prometheus 主动抓取；也可用 outputs.http 配合 Prometheus remote write 适配器推送。前者部署简单，后者更适合采集器与 Prometheus 网络不通、只能单向推送的场景。

Cisco Pipeline 与 CTC 的声明式管道

Cisco Pipeline 用 YAML 描述管道，输入、处理、输出三段式结构清晰，适合把订阅配置纳入 Git 版本管理。一个最小示例：

pipeline:
  - name: catalyst-gnmi
    input:
      gnmi:
        target: "10.10.20.11:57400"
        subscriptions:
          - path: "/interfaces/interface/state/counters"
            mode: sample
            sample_interval: 10s
    output:
      influxdb:
        url: "http://10.10.20.50:8086"
        bucket: "catalyst_telemetry"

CTC 则更适合多设备场景：它把“设备清单、订阅模板、输出目标”分离管理，新增一台 Catalyst 只需在设备清单中追加条目，订阅模板自动套用。生产部署时建议为 CTC 配置独立的证书目录与并发上限，避免大量设备同时重连造成瞬时压力。

端到端验证方法

管道搭好后，验证要分层进行，而不是只看数据库里有没有数据。第一层验证 gNMI 会话：在采集器主机上用 gnmi_cli 或 gnoic 对设备执行 Capabilities 查询，确认能返回支持的模型列表；再手动发起一次 Subscribe，观察是否有 SubscribeResponse 持续到达。第二层验证采集器：查看 Telegraf 日志中 inputs.gnmi 的指标计数是否持续增长，若计数为 0 且日志出现 context deadline exceeded，通常是网络或 TLS 问题；若出现 parse error，则要检查 encoding 与订阅路径是否匹配。第三层验证时序库：在 InfluxDB 中执行 from(bucket:"catalyst_telemetry") |> range(start:-5m) |> filter(fn:(r)=>r._measurement=="openconfig-interfaces")，确认返回非空序列且时间戳间隔与 10 秒周期一致；在 Prometheus 中查询 rate(interface_counters_in_octets[1m])，确认计数器单调递增且速率合理。

常见集成问题与判断依据

实际部署中最常见的三类问题：一是订阅建立失败，日志提示 rpc error: code = Unauthenticated，应检查用户名密码与设备 AAA 配置；二是数据到达但标签缺失，导致无法按设备或接口聚合，需在采集器处理段补充 tags 映射，把 source、interface_name 提取为标签；三是写入被拒绝，InfluxDB 返回 401 或 Prometheus 返回 400，通常是 token、bucket 或 remote write 路径配置错误。把这三类问题的日志关键字与判断依据整理成检查表，可以在后续排障中快速定位。

完成上述配置与验证后，Catalyst 的接口计数器、oper-status 等遥测数据即可稳定落入时序库，为后续的仪表盘、告警规则与容量趋势分析提供数据基础。采集器作为管道中枢，其订阅模式、编码格式与标签策略会直接影响下游可用性，建议在部署阶段就把这些参数固化为可复用的配置模板。