3. Junos性能监控工具链实战

当网络出现丢包、时延抖动、接口拥塞或控制平面CPU飙升时，真正决定排障效率的并不是“有没有监控”，而是“用哪一层工具、在多细的粒度上、以多快的节奏拿到数据”。Junos提供了一条从秒级到毫秒级、从人工拉取到自动推送的完整监控工具链。理解这条链上各工具的采样方式、数据模型和适用场景，才能在性能瓶颈出现时快速定位到具体接口、队列、协议进程或硬件资源。

一、工具链的分层逻辑：拉取式与推送式

Junos监控工具可以按“数据获取方式”分为两大类。拉取式（polling）由管理端主动发起，包括CLI show命令和SNMP轮询；推送式（streaming）由设备主动发出，包括Telemetry、Streaming Telemetry和JTI。拉取式的优势是无需预先配置采集器、随查随用，缺点是采样间隔受限于轮询周期，通常为30秒到5分钟，无法捕捉瞬态突发。推送式则可以把采样间隔压到1秒甚至100毫秒，适合观察微突发（microburst）和队列深度瞬时变化。

从数据模型看，CLI输出是面向人的文本，SNMP是面向MIB的标量或表结构，而Telemetry/JTI基于YANG模型，输出结构化数据（通常为JSON或GPB），可直接被采集器解析入库。这意味着排障时若需要快速确认“现在是什么状态”，CLI最直接；若需要长期趋势和阈值告警，SNMP最成熟；若需要高精度、细粒度的性能画像，必须依赖Streaming Telemetry或JTI。

二、show commands：最快的第一现场取证

性能问题发生时，第一反应通常是登录设备执行show命令。但“执行show”不等于“有效取证”，关键在于选对命令并理解输出中的关键字段。以下是一组针对性能瓶颈的常用命令及其判读要点。

show interfaces xe-0/0/0 extensive | match "errors|drops|CRC|queue"
show interfaces xe-0/0/0 statistics
show chassis fpc 0 pic 0
show chassis routing-engine
show system processes extensive | match "PID|CPU|Memory"
show class-of-service interface xe-0/0/0
show interfaces queue xe-0/0/0
show pfe statistics traffic
show log messages | last 50
show log interactive-commands | last 30

其中，show interfaces extensive用于确认物理层和MAC层错误，重点看CRC、帧对齐错误、FIFO溢出；show interfaces queue用于确认队列丢弃和队列深度，是判断拥塞点的核心命令；show chassis routing-engine用于确认RE CPU和内存是否成为瓶颈；show system processes extensive用于定位具体进程的CPU占用；show pfe statistics traffic用于确认转发引擎的丢包统计。这些命令的输出应结合时间戳一起记录，否则无法判断是持续问题还是瞬态问题。

三、SNMP：成熟稳定的趋势采集

SNMP适合做长期趋势采集和阈值告警。在Junos上需要先配置community或v3用户，并限制访问权限。典型配置如下：

set snmp community public authorization read-only
set snmp community public clients 10.10.10.0/24
set snmp trap-group perf-trap targets 10.10.10.50
set snmp trap-group perf-trap categories link
set snmp trap-group perf-trap categories chassis

采集端通常使用ifHCInOctets、ifHCOutOctets计算接口带宽利用率，使用ifInErrors、ifOutDiscards判断错误和丢弃趋势，使用jnxOperatingCPU和jnxOperatingBuffer监控RE和PFE资源。需要注意的是，SNMP轮询间隔通常为1到5分钟，对于微突发和毫秒级队列变化无能为力。因此SNMP的定位是“发现异常趋势”，而不是“捕捉瞬态事件”。

四、Telemetry与Streaming Telemetry：高精度性能画像

Streaming Telemetry通过订阅方式，让设备按指定周期主动推送数据。Junos支持基于UDP的Telemetry和基于gRPC的JTI（Junos Telemetry Interface）。前者配置简单，适合快速验证；后者支持更丰富的数据模型和更可靠的传输。

一个典型的gRPC订阅配置如下：

set services analytics export-profile grpc-profile
set services analytics export-profile grpc-profile reporting-rate 1000
set services analytics export-profile grpc-profile format gpb
set services analytics export-profile grpc-profile transport grpc
set services analytics export-profile grpc-profile address 10.10.10.60
set services analytics export-profile grpc-profile port 50051
set services analytics sensor interface-statistics
set services analytics sensor interface-statistics server-name grpc-profile
set services analytics sensor interface-statistics export-name grpc-profile
set services analytics sensor interface-statistics resource /junos/system/linecard/interface/
set services analytics sensor interface-statistics resource /junos/system/linecard/interface/traffic/

上述配置中，reporting-rate 1000表示每1000毫秒推送一次，即1秒粒度；若需要观察微突发，可调整为100毫秒。采集器收到gPB格式数据后解析为JSON，写入时序数据库。与SNMP相比，Streaming Telemetry的优势在于：采样间隔可低至100毫秒、数据模型更细（可到队列级和PFE级）、推送方式减少设备轮询开销。

五、日志分析：把离散事件串成时间线

性能瓶颈往往不是单一事件，而是多个事件在时间上的叠加。Junos日志中与性能相关的典型条目包括：接口up/down、链路抖动、协议邻居震荡、RE CPU超过阈值、PFE丢包告警、配置变更等。排障时应把show log messages、show log interactive-commands和Telemetry时间线对齐，观察“配置变更—资源变化—业务异常”之间的因果关系。

例如，某次性能异常的时间线可能是：10:02:15 配置变更新增一条策略；10:02:18 RE CPU从35%升至82%；10:02:20 协议邻居震荡；10:02:25 接口队列丢弃开始上升。通过日志与Telemetry对齐，可以快速判断根因是策略变更导致控制平面过载，而非物理链路问题。

六、工具选择速查

实际排障中，工具链的使用顺序通常是：先用show命令快速确认当前状态，再用SNMP或Telemetry确认趋势和粒度，最后用日志把事件串成时间线。三者不是替代关系，而是互补关系。只有把“即时取证、趋势采集、高精度推送、事件关联”组合起来，才能在大型网络中稳定地定位性能瓶颈。