1. 课程导入与可观测性工程定位
在传统网络运维中，我们习惯用 SNMP 轮询、Syslog 日志和 CLI 巡检来掌握设备状态。这套方法在设备数量有限、业务变化缓慢的年代足够用，但当网络规模扩展到数千台设备、业务对时延和丢包极度敏感时，它的短板就暴露无遗：轮询周期通常是分钟级，只能看到"采样瞬间"的粗粒度指标；日志是离散事件，难以还原连续变化；CLI 巡检更是人工、滞后、不可扩展。换句话说，传统监控回答的是"设备现在是否活着、端口是否 up"，而现代网络真正需要回答的是"业务流量的时延、丢包、抖动此刻如何变化，异常发生在哪一跳、哪个队列、哪条链路"。
这正是网络可观测性（Network Observability）要解决的问题。可观测性不是"监控的升级版"这么简单，它强调从系统对外输出的数据中，推断出系统内部状态的能力。监控是"我预先知道要问什么问题"，可观测性是"我可以问出我事先没想到的问题"。落到工程上，可观测性依赖三类数据：指标（Metrics）、日志（Logs）和追踪（Traces），再加上网络特有的流数据（Flows）。Juniper Telemetry 的核心价值，就是把 Junos 设备内部丰富的运行状态，以高频率、结构化、可订阅的方式持续推送给采集端，让上述数据从"事后查询"变成"实时流式"。
从"轮询"到"流式推送"：数据获取方式的根本转变
理解 Juniper Telemetry 的定位，关键要抓住数据获取方式的转变。传统 SNMP 是拉取（Pull）模型：采集器按固定周期向设备发请求，设备被动响应。Telemetry 是推送（Push）模型：设备按订阅配置，主动、周期性地把指定数据发往采集器。这一转变带来三个直接收益：
- 频率更高：SNMP 通常 60 秒一次，Telemetry 可做到 1 秒甚至亚秒级，能捕捉瞬态拥塞和微突发。
- 粒度更细：可订阅到接口队列、防火墙过滤器计数、BGP 邻居状态、传感器温度等具体对象，而非仅接口总量。
- 开销更可控：推送由设备侧调度，避免了大量轮询请求对设备控制平面的冲击，同时支持 gRPC、UDP 等高效传输。
下面这张图展示了传统监控与可观测性在数据链路上的本质差异，以及 Juniper Telemetry 在其中的位置。左侧是"拉取式"链路，右侧是"推送式"链路，中间是数据从设备到分析平台的完整流向。
Juniper Telemetry 在可观测性体系中的角色
Juniper 的 Telemetry 能力主要建立在 Junos Telemetry Interface（JTI）之上，它允许设备通过 gRPC（基于 HTTP/2 的远程过程调用）或 UDP 向采集器推送数据。其数据来源包括：OpenConfig 模型（厂商中立的标准化路径）、原生 Junos 传感器（如 /junos/system/linecard/interface/）以及 流表（Flow）数据。采集端常见组合是 Telegraf、Prometheus、InfluxDB 与 Grafana，或 Juniper 自家的 Paragon Insights（原 HealthBot）。
需要强调的是，Telemetry 本身只是"数据管道"，它不直接等于可观测性。可观测性工程还包含数据建模、存储、关联分析、告警和可视化。因此本课程的学习路径是：先理解数据从设备到平台的流动，再掌握订阅配置与采集器对接，最后落到"用数据定位真实网络问题"的闭环。
课程目标与学习路径
本课程围绕"能配、能采、能看、能定位"四个层次展开，共 30 章。整体路径可概括为：
- 概念与定位（第 1~4 章）：可观测性与监控的差异、JTI 架构、数据模型与传输协议。
- 订阅与采集（第 5~12 章）：gRPC/UDP 订阅配置、OpenConfig 与原生传感器路径、采集器部署与调优。
- 数据建模与可视化（第 13~20 章）：指标语义、标签设计、时序库选型、Grafana 看板与告警规则。
- 场景化定位（第 21~27 章）：拥塞与微突发、BGP 抖动、丢包定位、队列深度分析等真实排障场景。
- 工程化与规模化（第 28~30 章）：多设备订阅管理、性能开销控制、可观测性平台演进。
最后要建立的一个关键认知是：可观测性不是一次性项目，而是持续演进的工程能力。随着网络规模、业务类型和故障模式的变化，需要采集的对象、频率和关联维度都会变化。Juniper Telemetry 提供的可编程、可订阅的数据接口，正是让这种演进成为可能的基础设施。接下来的章节，我们将从 JTI 的架构与协议细节开始，逐步把这条数据链路打通。