6. 可观测性#

某服务提供商的核心路由器一个风扇模块在夜间悄无声息地发生了故障。没有任何告警。线卡上的热管理子系统检测到温度升高，开始对转发 ASIC 进行降频以保护硬件。一条生产中转链路的吞吐量下降了 40%。监控系统什么都没发现：它轮询的温度传感器位于机箱主控板上，而不是单块线卡上。SNMP 轮询每五分钟运行一次，报告设备状态正常。接口计数器显示吞吐量下降，但没有为这种模式配置任何阈值，因为该链路的利用率历来远低于容量上限。

三小时后，一次客户 SLA 违规触发了一张工单。值班工程师 SSH 进入路由器，在本地告警日志中发现了风扇故障，对风扇模块进行了重新上电。风扇控制器重启，几分钟内热降频解除，流量恢复。SLA 违规已记录在案，客户已通知，事件已关闭。

根本原因始终未能确认。等到有人开始调查时，路由器已经正常运行了数小时。线卡的温度数据不存在，降频事件没有记录，也无法在任何监控系统中将吞吐量下降与风扇故障关联起来。事件报告总结为：“疑似硬件问题，通过硬件重置解决。“六个月后，这件事在另一台路由器上再次发生。

失败之处不在于缺少阈值。团队拥有数以千计的阈值。失败在于覆盖不完整：监控系统从那些一直被轮询的来源采集数据，而不是从每一个可能影响设备行为的来源采集。所有三种机箱型号的线卡温度数据都可以通过 gNMI 获取。没有人配置采集路径，因为没有人为风扇故障编写过操作手册。

传统网络监控关注的是已经出故障的东西：接口是否正常？CPU 是否超过 90%？服务是否有响应？这些都有用，但都是被动的：你在等待故障发生。

可观测性不同。它关注的是为什么会出故障，或者即将出故障。不只是"那台设备宕机了”，而是"为什么宕机，它的宕机影响了什么，业务影响是什么。“在网络自动化中，可观测性成为反馈回路：你观测到某件事，系统检测到它，决定如何响应，采取行动，并验证修复是否生效。这种循环就是"闭环自动化”。

本章涵盖你所需要的一切，以了解网络中正在发生什么：收集哪些数据、如何收集、如何存储、如何告警，以及如何以真正帮助人们做出决策的方式展示出来。

我们在这里介绍两个构建块：Collector 和 Observability，因为它们紧密相连。

无论你使用传统的一体化平台（SolarWinds、LibreNMS）、云服务（Datadog、New Relic），还是用开源组件自建（Prometheus、Grafana 等），底层架构都是相同的。理解这些模式有助于你根据自己的规模和团队选择合适的方案。

本节深受 Packt 出版的《Modern Network Observability》一书的影响，该书由我与 David Flores 和 Josh Vanderaa 共同撰写。如果你想动手实践，学习使用 TPG（Telegraf-Prometheus-Grafana）栈和其他工具的具体实现，强烈推荐阅读。

6.1. 基础概念#

在深入细节之前，我们先建立网络自动化策略中网络可观测性的基础，定义其目标、支撑支柱和范围。

6.1.1. 背景#

你可能已经在监控自己的网络了。你使用 Simple Network Management Protocol (SNMP)，查看 System Logging Protocol (Syslog)，有显示链路利用率的仪表板。这是监控：它告诉你事情是否正常运转。

但自动化需要更多。当你的网络发生变化（因为自动化改变了它），你需要立即知道是否出了什么问题。当你收到告警时，你需要上下文：哪些客户受到影响？哪些服务发生了故障？影响范围有多大？传统监控给你告警，而自动化需要的是情报。

关键区别如下：

• 监控：接口是否正常？CPU 是否过高？简单的是/否问题。
• 可观测性：接口为什么宕了？影响了什么？我们如何自动修复？历史上发生了什么导致了这个问题？

可观测性为自动化提供输入。你的系统观测网络，检测问题，决定做什么，采取行动，并验证修复是否有效。这个反复循环的过程就叫"闭环自动化”。

传统监控工具（像 SolarWinds 这样的大型单体产品）试图在一个产品中做所有事情。你可以让它工作，但往往为你不需要的功能付费，同时受限于你确实需要的功能。替代方案是将可观测性拆分成组件来构建：选择适合你设备的采集器、适合你数据规模的存储、适合你自动化工作流的告警。这更难组装，但灵活性更强。

本章讲解两种方法以及无论选择哪种都适用的模式。

关于平台运行方式，最初要做一个选择：

• 单体式（SolarWinds、LibreNMS）：一个产品做所有事情。安装、配置、运行。如果你的网络比较简单且没有 DevOps 经验，这是个好选择。如果你想要灵活性或你的网络比较特殊，这就是个坏选择：你被它的模型所约束。

• 云 SaaS（Datadog、New Relic、Kentik）：他们为你运行一切。部署快、无基础设施烦恼、开箱即用的漂亮仪表板。但你按量付月费，数据存在他们的服务器上（在某些合规场景下有影响），当你触及他们的限制时就卡住了。我见过团队每月在可观测性 SaaS 上花 5 万美元，还在纳闷为什么 CFO 不高兴。

• 自建（Prometheus + Grafana，或 Telegraf-Prometheus-Grafana (TPG) 栈）：完全灵活，无厂商锁定，规模化后经济性更好。但你现在要运行数据库、消息队列和采集器基础设施。如果你没有能操作这些的人，你会花更多时间修可观测性而不是修网络。

真正的问题是：你有没有团队来运行它？ 如果有，就自建。如果没有，就购买。不要对自己所处的类别自欺欺人。

在此之后，还有两个问题：

• 它在哪里运行？ 在你的本地（你控制一切，但你来运行），在云端（他们来运行，但你的数据离开了你的网络），还是混合（部分在本地，部分在云端）？
• 成本模型是什么？ 按设备收费？按摄入指标收费？固定订阅？当你每分钟采集数百万个数据点时，这些决策会迅速累积。

6.1.2. 目标#

你的可观测性系统需要做七件事：

1. 自动观测一切。 新设备接入？它应该在无需人工手动注册的情况下开始上报数据。新服务上线？它已经在被监控中。这需要与真实数据源集成，以便可观测性知道存在哪些设备。

2. 在异构环境中处理高质量数据。 你的网络可能有 Cisco、Arista、Juniper、云提供商、Linux 服务器、容器。每种都有不同的数据暴露方式。而且忘掉 5 分钟间隔吧：当自动化在进行变更时，你需要近实时数据。

3. 跨层关联数据。 某台服务器很慢。是网络拥塞，还是数据库问题？你需要来自网络设备、服务器、应用程序的数据，所有数据都用同一种语言，这样你才能在它们之间画出关联线。

4. 规模化而不崩溃。 网络在增长。当你每秒采集一百万个指标时，传统架构会崩溃。你需要从第一天起就为规模化设计的系统。

5. 让人们智能地分析数据。 给分析师提供查询数据的能力，不只是预构建的仪表板，而是强大的查询能力，让他们能回答自己的问题。他们需要实时数据和历史数据（趋势、异常检测）。

6. 主动检测问题并自动修复。 大多数时候，你的自动化应该在不等待人工的情况下响应问题。只有当自动化无法搞清楚时，才应该有人被呼叫到。而那个告警必须解释清楚什么地方出了问题，而不只是展示原始数字。

7. 给人们展示他们需要看到的内容。 如果仪表板展示太多或者展示错了内容，它毫无价值。给网络运维团队他们的视图，给业务人员他们的视图，给工程师他们的视图。每个人得到的都是帮助他们完成工作的内容。

6.1.3. 支柱#

每个目标都需要具体的构建块来实现。以下是你需要的：

1. 知道要观测什么。 你的真实数据源拥有所有设备、服务、凭证。可观测性应该自动拉取这些数据，以便采集器知道要监控什么。当你在 SoT 中添加设备时，监控自动上线。

2. 高效采集数据。 你需要多种采集方法：为旧设备使用 Simple Network Management Protocol (SNMP)，为现代设备使用 gRPC Network Management Interface (gNMI) 流式传输，用 System Logging Protocol (Syslog) 收集事件，用流量（NetFlow、IP Flow Information Export (IPFIX)）分析流量，可能还需要深度故障排查的抓包。不同工具、不同速度、不同数据丰富度。好消息是：你不必只选一种。

3. 规范化所有数据。 你的 Arista 指标与 Cisco 指标不同，后者又与云提供商指标不同。你的日志是非结构化文本，流量是二进制的。你需要一个层次将所有这些翻译成通用语言，并添加上下文（哪台设备、哪个客户、哪个服务）。

4. 在规模下可靠地移动数据。 传统监控管道是顺序的：采集器 → 处理器 → 存储。在规模下，这是瓶颈。你需要消息总线和流式平台，将每个阶段解耦，使它们可以独立扩展。

5. 智能存储。 时间序列数据（指标）需要为此优化的数据库。日志需要不同的处理。你需要在毫秒内查询数百万个数据点。不是所有数据库都在这方面一样出色。

6. 将数据转化为行动。 原始指标不会触发自动化。你需要规则：“如果 CPU > 90%，检查是否是预期中的维护，如果不是，执行这些步骤。“这些规则输入到你的自动化编排器或告警系统。

7. 直观展示数据。 如果没有人看，数据就没有价值。你需要仪表板，但要是智能的：针对不同人的不同视图，能够下钻，能够展示趋势和比较。

最后，在详述实现这些支柱的七项功能之前，让我们先明确可观测性的范围。

6.1.4. 范围#

为了扩展上面介绍的目标，还有一些其他方面也属于可观测性的职责：

• 适应不同用户视角（技术、运营、业务）的不同层次观测
• 与 CI/CD 管道集成，为自动化测试和验证提供反馈
• 对自动化系统本身的可观测性（对 Collector、处理器和告警系统的元监控）

然而另一方面，有些功能属于架构中其他组件的职责：

• 定义网络意图：网络应该是什么样子（意图/SoT 的职责）
• 执行网络变更：实际实施修复（Executor 的职责）
• 编排复杂工作流：协调跨多个系统的多步骤修复（Orchestrator 的职责）

这种清晰的边界确保 Observability 专注于检测和洞察，而其他构建块负责意图定义、执行和编排。

向现代可观测性过渡需要认真规划。不要把它看成像用一个监控工具替换另一个那么简单；你必须转变你的思维方式。能力越强，责任越大，你需要做更多的选择和调整。

在这个介绍了可观测性模块核心概念的初步概述之后，让我们进入各项功能的详细内容。

6.2. 功能#

七个目标和支柱通过七项核心功能来实现。每项功能对应一个目标及其支撑支柱，从业务需求到技术实现形成了一条直接链路：

1. 清单：从 SoT 获取意图，并为所有下游组件提供元数据、设备列表和采集目标。
2. Collector（采集器）：使用多种协议和采集方法从网络中检索观测数据，包括基于拉取（轮询）和基于推送（流式）两种方式。
3. 处理器：将异构数据规范化为通用模式，并使用上下文元数据（标签、关系、业务上下文）对其进行丰富，同时执行其他数据操作。
4. 分发：使用分布式、异步模式将数据生产者与消费者解耦。可靠地将数据和事件从 Collector 通过处理器传输到持久化和告警系统。
5. 持久化：将规范化数据存储在为高效摄入、保留和规模化查询而优化的数据库中。
6. 告警：使用灵活的规则和阈值分析持久化数据，以检测感兴趣的条件，生成触发外部系统（自动化或人工通知）的事件。
7. 可视化：将观测数据和触发事件渲染为仪表板、报告和其他视觉界面，针对不同用户受众和使用场景进行定制。

graph LR

    %% --- Subgraphs ---
    subgraph Goals
        direction TB
        A1[Observe all the network with minimal human effort]
        A2[Support heterogeneous network environments with enough data and accuracy]
        A3[Observe data from different IT layers with context]
        A4[Handle massive-scale network scenarios]
        A5[Offer access to observability data for sophisticated analysis in near real-time]
        A6[Be proactive to detect network issues and reduce time to recover]
        A7[Create tailored user-oriented visualizations]
    end

    subgraph Pillars
        direction TB
        B1[Close integration with SoT to understand what needs to be monitored]
        B2[Ability to collect data via different protocols supporting very frequent/on-demand updates]
        B3[Normalization of heterogeneous data with contextual metadata for richer analysis]
        B4[Scalable data distribution systems to support scale-out architectures]
        B5[Persistence layer supporting time-series data and powerful query languages]
        B6[Flexible rule definitions and routing scenarios with external system integration]
        B7[Custom visualizations and integration of multiple data stores]
    end

    subgraph Functionalities
        direction TB
        C1[Inventory]
        C2[Collector]
        C3[Processor]
        C4[Distribution]
        C5[Persistence]
        C6[Alerting]
        C7[Visualization]
    end


    %% --- Row connections ---
    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3
    A4 --> B4 --> C4
    A5 --> B5 --> C5
    A6 --> B6 --> C6
    A7 --> B7 --> C7

    %% --- Row gradient classes ---
    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;
    classDef row4 fill:#b3d8ff,stroke:#4a90e2,stroke-width:1px;
    classDef row5 fill:#99ccff,stroke:#4a90e2,stroke-width:1px;
    classDef row6 fill:#80bfff,stroke:#4a90e2,stroke-width:1px;
    classDef row7 fill:#66b2ff,stroke:#4a90e2,stroke-width:1px;

    %% --- Apply classes per row ---
    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;
    class A4,B4,C4 row4;
    class A5,B5,C5 row5;
    class A6,B6,C6 row6;
    class A7,B7,C7 row7;

这些组件可以看作一个数据管道或 ETL（提取、转换和加载），如下图所示：

flowchart TB
    A[Network] --> B[Collector]

    subgraph Observability
       direction LR
       B --> C[Distribution] -->  D[Persistence]
       B -.-> P[Processing]
       C -.-> P
       D -.-> P
       D --> E[Alerting]
       E -.-> P
       D --> G[Visualization]
       X[Inventory] -.-> B
       X -.-> G
       X -.-> P
    end

    E -.-> F[Orchestration]
    G -.-> H[Presentation]
    Y[SoT] -.-> X

图 1：可观测性管道。

6.2.1. 清单#

清单组件回答一个简单的问题：我应该监控什么？

你已经在某个地方有了这些数据：就在你的真实数据源中。你有设备名称、IP 地址、设备类型、是否活跃、凭证。不要通过手工重复录入来制造副本。自动拉取。

你需要从 SoT 中获取的内容：

• 每台设备或服务的唯一名称或 ID（以便你知道它就是你认为的那台设备）
• 如何访问它：IP 地址、主机名和凭证（如果你需要主动从它那里拉取数据）
• 它是什么：类型和厂商（以便你知道哪些 Collector 适用）
• 它是否活跃：计划中、活跃中还是正在退役中（以便你不会对预期的停机时间发出告警）

除了基本信息，你可能还关心：

• 操作系统或设备细节：某些设备使用不同的协议，某些旧设备需要特殊处理
• 上下文：谁拥有它、它在哪里、哪些客户依赖它（用于过滤告警和仪表板）

为什么要自动化而不是手工建一个列表？因为人们会忘记更新列表。设备被添加了，没人告诉监控系统，然后你就失去了可见性。但如果可观测性从你的 SoT 中读取，当你在那里添加设备时，它就会自动开始被监控。

推送还是拉取？

• 拉取：可观测性定期检查 SoT 的更新。简单，但如果某件事在间隔期内发生变化，你会错过它。
• 推送：当 SoT 发生变化时，它会自动通知可观测性（Webhook、消息总线）。更快更可靠。

如果你的 SoT 中有良好的数据并且有真实的集成（不是手工复制粘贴），清单就会变得自动化，你永远不会遗漏观测新设备。

6.2.2. 采集器#

你的数据必须从某处来。Collector 是你的网络和 Observability 平台之间的桥梁。它们负责从你的设备拉取（或接收）数据并将其输入管道。没有有效的 Collector，下游一切都是垃圾。

从数据流所有权的角度来看，有两种基本方法：

• 被动或推送：你的设备将数据发送给采集器。想想收到来自路由器日志消息的 Syslog 服务器，或监听流量记录的 IPFIX 采集器。设备决定发送什么以及何时发送。
• 主动或轮询：Collector 向设备请求数据。它连接到每台设备，使用 Simple Network Management Protocol (SNMP)、gRPC Network Management Interface (gNMI)、Representational State Transfer (REST) Application Programming Interface (API) 拉取信息，或订阅流式数据。Collector 处于主导地位：它决定请求什么以及何时请求。

你也可以按部署方式对采集器进行分类：

• 无代理：无需在设备上安装软件。一个中央采集器服务器（通常在其他地方运行）单独连接到每台设备。起步简单，但随着规模扩展可能成为瓶颈。
• 基于代理：在每台设备或服务上安装一个小型代理。代理将数据推送到中央位置，或直接从本地源拉取。更分布式、更容易扩展，但需要管理更多活动组件。

无论采集方法如何，都有必要重点介绍在网络自动化环境中可能感兴趣的不同数据类型。我将其分为四大类：

• 管理平面：设备的状态，或读取配置、日志或网络统计数据。该组的协议有 Simple Network Management Protocol (SNMP)、System Logging Protocol (Syslog)、gRPC Network Management Interface (gNMI)、NETCONF 和 RESTCONF。
• 控制平面：这是决定网络包转发的分布式协议所在之处，例如第 2 层或第 3 层转发表。控制平面协议的几个例子是 OSPF、IS-IS 和 BGP。这些平面可以通过 Ping 或 Traceroute 等技术，或 BMP 等遥测协议进行观测。
• 转发平面：此平面是数据包移动的地方（例如网络接口），在数据量和速度方面要求最高。自然地，在观测它时，不影响平面的主要目标（即转发数据包）也至关重要。该组有 TcpDump、IPFIX、sFlow、Netflow、Cisco SLA、PSAMP 和 eBPF 等工具。
• 外部数据：该类别包括所有非网络设备专用的数据。例如，来自外部资产管理系统的线路提供商信息和给定接口的联系人，或物联网（IoT）传感器，都可以归入这个宽泛的领域。

flowchart TB
    subgraph Network Device/Service
        direction TB
        A[Management Plane]
        B[Control Plane]
        C[Forwarding Plane]
        A --> B
        B --> C
    end

    D[External data]

图 2：采集器的范围。

停止对 Command Line Interface (CLI) 输出进行屏幕抓取。我知道你在这么做。我们都这么做过。但现在已经是 2026 年了，每个主要厂商都支持适当的遥测了。

CLI 抓取很脆弱（厂商会改变输出格式）、很慢（屏幕抓取和解析文本成本高昂）、不可靠（随机的命令超时），而且扩展性很差。如果你的设备太旧，只有 CLI，那么要么更换它，要么接受你的可观测性能力有限。不要围绕最低公分母构建你的整个监控栈。

归根结底，关于你正在采集的内容，有两个核心问题：

• 采集什么：指标？日志？流量记录？每种都有不同的数据模型。SNMP 有 MIB，现代设备支持 gNMI，应用程序使用 OpenTelemetry。梦想是有一个通用标准让你能跨所有内容关联数据，但这还不存在。所以你可能需要构建自己的翻译层，将这些不同格式转换成一致的内容（这就是下一步处理层做的事）。
• 如何获取它：使用哪种协议？SNMP 老旧但稳定，gNMI 现代且持续推送数据，IPFIX 捕获实际流量。取决于你想观测什么。

下表总结了你可能采集的内容和可用工具：

表 1：要采集的数据和协议。

若要更深入地了解不同选项，请参阅《Modern Network Observability》一书。

网络数据采集适用于数据中心、ISP 骨干网、云网络服务、Linux 内核接口或原始数据包，取决于你的环境。

关键是：在决定采集什么之前，先从你要解决的问题出发。这个决定驱动其他一切。你是在检测接口饱和？监控 BGP 收敛？追踪 DDoS 流量？你的问题决定你需要什么数据以及你需要多频繁地获取它。

为了提高采集数据的频率（在某些情况下很有意义）或整合采集方法，以下是近年来采用率增加的几种模式：

流式遥测

设备使用 YANG 模型持续推送数据。你设置订阅，数据实时流入。两种形式：

• 拨入式（Dial-In）：采集器请求设备开始流式传输（采集器主动发起）。
• 拨出式（Dial-Out）：设备预先配置为向你流式传输（设备主动发起）。

延迟比轮询低得多，而且设备对流量保持控制。

flowchart TB
    A[Collector]
    B[Device]
    A -.->|Dial-In| B
    B -->|Streaming| A
    B -.->|Dial-Out| A

图 3：流式遥测。

Hypertext Transfer Protocol (HTTP) 暴露的指标

Hypertext Transfer Protocol (HTTP) 抓取（基于拉取的指标）简单且扩展性好。Simple Network Management Protocol (SNMP) 也是这样做的，但越来越多的网络操作系统正在以 Prometheus 格式通过 Hypertext Transfer Protocol (HTTP) 直接暴露指标。Collector 更容易消费，不需要特殊的 Simple Network Management Protocol (SNMP) Management Information Base (MIB) 解析。SONiC、Cumulus、Arista EOS 等都以这种方式暴露指标。

表 2：HTTP 暴露的指标。

抓取方法提供低延迟和近实时指标、丰富的标签，以及基于拉取的采集（中央控制速率/超时），与云规模可观测性很好地连接。

OpenTelemetry

OpenTelemetry 是一个用于采集、处理和导出遥测数据的厂商中立标准和工具包。将其视为一种通用遥测语言和管道，统一跨网络、系统和应用程序的指标、日志和追踪。

它不替代 SNMP、NetFlow、gNMI 或 BMP 等网络协议。相反，它标准化了采集后遥测数据的表示和传输方式。

在传统网络监控中，数据模型多样，使用厂商特定的架构和命名，使得跨层（网络 ↔ 系统 ↔ 应用程序）关联变得困难。与之对应，OpenTelemetry 提供：

• 指标、日志和追踪的通用数据模型
• 标准传输协议（OpenTelemetry Protocol (OTLP)），通过 gRPC Remote Procedure Call (gRPC) 或 Hypertext Transfer Protocol (HTTP)
• 多种信号类型的单一处理管道

Grafana Alloy 或 Telegraf 是实现 OpenTelemetry Protocol (OTLP) 的 Collector 示例。它从不同的导出器采集数据，并导出到不同的后端，如指标（兼容 Prometheus 的 Time Series Database (TSDB)）、日志（Loki、Elasticsearch、ClickHouse）和追踪（Tempo、Jaeger）。

这引出了关于现代可插拔采集器通用结构的最后一点考量，包含输入、处理器和输出三个阶段。例如，在 Telegraf 中，OTLP 是一个输出插件的选项。

OpenTelemetry 作为架构选择

采用 OpenTelemetry 不仅是一个工具决策，更是一个关于如何统一你的可观测性管道的架构决策。这个选择在两种方法之间：

协议原生：每种信号类型通过其原生协议端到端传输（gNMI 到 Prometheus、Syslog 到 Elasticsearch、NetFlow 到 ClickHouse）。每条管道针对其信号进行了优化。代价是多个独立管道，没有共享数据模型，使跨信号类型的关联成本高昂。

OTel 原生：信号尽早转换为 OpenTelemetry Protocol (OTLP)，通过单一管道流向统一后端。跨指标、日志和追踪的关联是自然的，因为它们共享一个数据模型。代价是网络设备 OTel 支持仍在成熟中：大多数厂商不原生发出 OTLP，需要一个适配器层（gNMI 到 OTel、SNMP 到 OTel），增加了运营复杂性。

今天网络自动化环境的实用建议：在厂商支持强劲的应用程序相邻信号（自动化平台遥测、服务健康、结构化应用程序日志）中采用 OTel，并继续对传统网络遥测（SNMP 轮询、gNMI 流式）使用协议原生管道，直到设备侧 OTel 支持成熟。将管道设计为可以同时容纳两种方法，而不是强制进行需要为每台网络设备添加适配器的过早标准化。

趋势是明确的：OpenTelemetry 最终将成为所有可观测性数据的标准。首先将其用于自动化平台本身（第 5 章的元监控）是一个低风险的第一步，在将其扩展到网络设备之前可以建立起熟悉感。

采集器架构

简单来说，每个采集器都可以分解为三个部分（有时这些是可插拔的，有时是更硬编码的）。

flowchart LR
    A[INPUT] --> B[PROCESSOR] --> C[OUTPUT]

图 4：采集器的架构。

• 输入：定义需要观测的内容和参数。
• 处理器：虽然是可选的，但一旦数据进入数据管道，它对于确保数据结构一致性非常方便。处理可能变得非常复杂，可能影响规模下的性能，因此不是所有处理都必须在这个层面完成。
• 输出：展示采集器如何将数据移入管道。它可以直接发送到其他模块（如处理或持久化），或使用分发组件来扩展。

有许多采集器（每种有不同的功能），如 Telegraf、Grafana Alloy、gNMIc、PMACCT、goflow 等，但它们使用类似的架构。所以在选择时（有时你可能需要几种），可以从以下角度考量：

1. 设备能力：你的设备支持哪些协议？
2. 数据量：高容量需要流式传输；低容量可以使用轮询。
3. 延迟要求：近实时还是传统间隔。
4. 团队技能和与后端的生态系统契合度。

Suzieq、Kentik 等所有"完整"网络可观测性解决方案也为所涵盖的可观测性数据实现了内置采集器。

数据采集之后，其中一个已经介绍过的步骤是处理器，它在管道的不同阶段对数据进行处理。

6.2.3. 处理器#

来自采集器的原始数据很混乱。不同设备以不同方式导出指标，日志是非结构化文本，值可能使用不同的单位。处理器层对此进行清理，使其变得有用。

目标：一旦数据被接收，它必须遵循共享标准，以便汇聚来自多个来源的信号、关联它们，并用额外上下文丰富它们。没有这个处理步骤，可观测性管道会迅速变得碎片化、难以查询且运营成本高昂。根据规模、复杂性和运营需求，有多种机会对其进行处理。

以下是适用于可观测性管道的常见处理操作。

6.2.3.1. 规范化/转换#

数据以不同格式到来。Arista 以一种方式发送指标，Cisco 是另一种，Syslog 是文本，NetFlow 是二进制。规范化将所有这些翻译成通用格式，这样你的后端就不必理解 50 种不同的方言。

结构化

设备以对它们有意义的方式发出数据。你的工作是将其翻译成适合分析的格式：

• 基于日志：

  Mar 18 14:22:11 leaf01 IFACE-5-STATE: swp1 oper-state changed from UP to DOWN

  转换为

  {
  "timestamp": "2025-03-18T14:22:11Z",
  "level": "INFO",
  "device": "leaf01",
  "component": "interface",
  "event": "oper_state_change",
  "interface": "swp1",
  "previous_state": "UP",
  "current_state": "DOWN"
  }

• 基于指标：<指标名>{<标签>} <值>

  interface_admin_state{hostname="leaf01", ifname="swp1"} 1
  interface_oper_state{hostname="leaf01", ifname="swp1"} 0
  interface_speed_bps{hostname="leaf01", ifname="swp1"} 100000000000
  interface_in_errors_total{hostname="leaf01", ifname="swp1"} 0
  interface_out_errors_total{hostname="leaf01", ifname="swp1"} 12

• 基于表格：某些工具（如 Suzieq）将数据组织为表格式的、时间索引的状态视图：

  | hostname | ifname | adminState | operState | speed | inErrors | outErrors | timestamp |
  |----------|--------|------------|-----------|-------|----------|-----------|-----------|
  | leaf01   | swp1   | up         | up        | 100G  | 0        | 0         | t1        |
  | leaf01   | swp1   | up         | down      | 100G  | 0        | 12        | t2        |

重命名和对齐

不同的遥测来源使用不同的名称、路径和标签惯例来描述相同的概念。例如：

Openconfig: /interfaces/interface/state/oper-status value: UP tags: source=192.0.2.1 and interface_name=eth1
SNMP: ifOperStatus{ifName="GigabitEthernet0/1", device="router01"} 1
Native Prometheus: interface_oper_state{interface="swp1", host="leaf01"} 1

规范化将它们对齐到一致的模型，包括对象名称、标签重命名以及值（使用相同的单位转换）：

intf_oper_state{name="eth1", device="192.0.2.1"} 1
intf_oper_state{name="GigabitEthernet0/1", device="router01"} 1
intf_oper_state{name="swp1", device="leaf01"} 1

6.2.3.2. 丰富#

丰富是在实际观测到的内容之外为可观测性数据添加额外内容。添加到数据中的这些额外维度允许更复杂的数据消费。例如，你可能能够理解指标属于在网络中扮演特定角色的设备，并据此采取行动。

丰富有两种主要方法：

• 扩展数据 向观测数据添加额外的元数据或标签来补充它。这些数据可以是静态的（例如 org=my-company）来标记你的所有数据，基于采集上下文的动态数据（例如 collector_id=1234），或基于观测数据本身的动态数据（例如，给定 hostname=rtr-1，通过与 SoT 关联创建一个 location=BCN-01 标签）。

  intf_oper_state{
      name="swp1", 
      device="leaf01",
      role="leaf",
      location="BCN0001"
  } 1

• 创建新数据 遵循 Prometheus 生态系统的"信息指标"模式，我们可以生成不代表实际状态而代表预期状态的指标。这些指标在后续可观测性管道阶段中非常有用，可以为分析添加更多维度，你将在告警部分发现这一点。

  device_info{
      name="leaf1",
      role="leaf",
      vendor="arista",
      model="7050SX3",
      platform="eos",
      os_version="4.29.2F",
      location="BCN0001",
      rack="AB1",
      rack_unit="U32",
      environment="prod"
  } 1

  信息指标是一种有趣的数据类型，其相关数据不在值中（例如上面指标中的 1），而在标签中。这个技巧允许重用不支持某些值类型（如字符串）的 Time Series Database (TSDB)。

两种方法都添加了标签和上下文。这对于告警和分析来说非常有用。但需要考虑一些成本：

• 基数：每个新标签都会使你的时间序列成倍增加。设备 × 接口 × 指标已经是高基数。不加考虑地添加标签，存储会爆炸，查询会变慢。要深思熟虑。
• 更新频率：设备机架和管理 IP 不会每秒都变化。不要像轮询易变指标那样轮询丰富数据。事件驱动的更新效果更好，减少对你真实数据源的查询。
• 弹性：如果你的真实数据源离线，丰富就会停止。缓存它，这样即使降级你也能继续运营。你的自动化依赖这些数据，所以要让它坚如磐石。

6.2.3.3. 转换/衍生/聚合#

从原始指标衍生新指标。例如：将叶子交换机和脊柱交换机的所有接口输入流量合并为单个"结构带宽使用"指标用于趋势分析。你在组合现有数据来回答更大的问题或提供仪表板数据。Prometheus 将此称为"记录规则”。

- record: fabric:interface:in_bps
expr: 
    (
    sum by (fabric, role, hostname, name) (
        rate(interface_in_octets_total{role=~"leaf|spine"}[5m])
    ) * 8
    )
    * on (hostname, name) group_left (fabric, role)
    sot_interface_info{role=~"leaf|spine"}

在 Prometheus 生态系统中，这被称为记录规则。

另一个用于减少数据量的处理功能是聚合，通过减少根据数据最终用途调整的维度。例如，按设备汇总接口信息，或按站点汇总设备信息。例如，从计数器指标创建速率计算，或直方图分桶，对许多分析都很有用。

6.2.3.4. 过滤#

尽早丢弃垃圾。不是每条日志行都值得存储。不是每个接口指标都重要（也许你不关心环回接口）。你越早过滤，在存储和处理上的浪费就越少。允许列表（只保留这些）比拒绝列表（丢弃那些）更安全。

6.2.3.5. 采样/限流#

即使过滤之后，数据量可能仍然太高。对其进行限流。概率采样（“保留这些请求的 10%"），专注于 Top-K 指标（“只存储最繁忙的 100 个接口”），或按来源限速（“每台设备最多 1000 个指标”）。随着数据在数据库中老化，对其进行汇总（5 秒粒度变成 5 分钟平均值）以节省空间。

最后，所有这些处理器可能在可观测性管道的不同阶段运行，取决于使用情况：

• 采集器：最适合轻量级的早期规范化和过滤
• 专用处理器：在规模下进行动态丰富和复杂转换时是必要的
• 持久化层：适合记录规则和长期汇总（规范化应始终在此之前完成）
• 告警层：从存储数据中派生事件并应用业务逻辑

实际上，有效的可观测性管道会根据工具、规模和运营约束，在各层之间分配处理。

6.2.4. 分发#

简单的线性管道（采集器 → 处理器 → 数据库）无法扩展。如果数据库变慢，采集器就会备份。如果你需要升级处理器，就必须停止采集。一切都是紧密耦合的、脆弱的。

这就是消息代理的用武之地。

像 Apache Kafka 或 NATS 这样的消息代理坐在中间。生产者（采集器、设备）发布到主题。消费者（处理器、数据库、告警）按自己的节奏拉取。完全解耦。

好处：

• 扩展：每个组件独立扩展。
• 弹性：如果某个消费者很慢，数据会排队而不是被丢弃。
• 灵活性：相同的数据无需在来源端复制就可以输入多个后端。升级或重启一个组件而不影响其他组件。

更多关于扩展和可靠性模式的内容，请参见第 11 章。

6.2.5. 持久化#

数据处理完后，它需要存储在某个地方。数据库层存储你所有的可观测性数据。它需要处理巨大的数据量、支持快速查询，并将成本保持在合理水平。

优秀的可观测性数据库有共同的特点：

• 时间感知：数据本质上是带时间戳的。数据库针对范围查询和时间窗口计算进行了优化。
• 高写入吞吐量：持续的指标摄入。数据库在不变慢的情况下处理这些。
• 多维度：指标携带标签（设备、接口、位置）。高效地查询和聚合它们。
• 灵活查询：需要表达性强的语言（PromQL、LogQL）来在没有预定义架构的情况下探索数据。
• 生命周期管理：存储增长很快。支持保留、降采样、删除以控制成本。
• 架构灵活性：新指标不断出现。数据库在没有昂贵迁移的情况下处理演变。

哪些数据库类型有效？

没有一个数据库能完美地处理所有可观测性工作负载，任何告诉你相反的人都是在向你推销什么。以下是实际有效的内容：

1. 时间序列数据库（Time Series Database (TSDB)）：这是你的起点。Prometheus 赢得了指标领域的竞争。其数据模型（带标签的指标）成为事实上的标准，PromQL 是人人都知道的查询语言。如果你的活跃序列在 1 亿以下，就使用 Prometheus。超过这个数，考虑 VictoriaMetrics（与 Prometheus 兼容，扩展性更好，内存占用更少）。InfluxDB 还行，但他们的许可证一直在变。除非你已经锁定在他们的生态系统中，否则避免厂商特定的解决方案。

2. 列式数据库：ClickHouse 在这里称王。它在日志聚合和流量分析方面快得惊人。如果你需要为报告或历史分析查询数十亿行，这就是你的工具。InfluxDB v3 正在尝试竞争，但 ClickHouse 已有多年的硬化。Parquet 文件适用于不需要实时写入的分析工作负载（就像 Suzieq 那样）。

3. 文本搜索数据库：如果必须的话用 Elasticsearch，但说实话，Loki（来自 Grafana）等现代替代品更简单、运营成本更低。Splunk 很棒，如果有人帮你付费的话。说个秘密：大多数团队过度投资于日志搜索，而对会让搜索变得不必要的结构化日志投资不足。

我的建议：从 Prometheus（或类似的）处理指标，从 Loki（或类似的）处理日志开始。当你需要认真的历史分析时，添加 ClickHouse（或类似的）。这个栈会让你扩展到很大规模，然后再需要更复杂的东西。

这种分类不是绝对的；大多数工具都有一个主要分类，但也实现了其他一些特性（尤其是时间序列）。

设计存储时的两个重要概念：基数（一个标签可以取多少个唯一值）和维度（一个指标有多少个标签）。高基数标签乘以许多维度 = 存储数据爆炸和查询缓慢。这是可观测性中最大的挑战之一。详见第 11 章中的深度扩展考量。

完成所有数据管理之后，还有两个最后步骤：

• 为其他自动化创建事件或让人工介入：告警
• 可视化数据以提供决策信息：可视化

6.2.6. 告警#

告警将数据转化为行动。你的目标：将告警输入自动化系统。当自动化无法修复时通知人工。

告警经过以下阶段：

• 检测：在数据中发现问题。
• 处理：丰富上下文。是关键问题？轻微问题？误报？关联相关告警以减少噪音。
• 路由：发送到编排器（运行工作流）、团队（Slack）或事件管理（PagerDuty）。
• 升级：如果自动化失败，人工接手。

flowchart LR
    A[Detection] --> B[Processor] --> C[Routing] --> D[Escalation]

图 5：告警阶段。

困难的部分不是设置告警。而是防止告警疲劳。我见过 NOC 有 10,000 条活跃告警，没有人再看其中的任何一条。到那时，你拥有的不是监控，而是昂贵的噪音。

以下是实际解决方法：

1. 将 95% 的告警路由到自动化而不是人工。 如果人工看到一条告警，那应该是因为自动化尝试了但失败了。接口抖动？自动化检查是否在维护中，重启光模块，向厂商开工单。只有当自动化无法解决时，人工才被呼叫。

2. 消除静态阈值。 “CPU > 80%” 告警毫无用处。80% 对于那台设备可能是正常的。使用动态基线：当某件事偏离其历史模式时告警，而不是偏离某个任意数字时。

3. 对相关告警进行分组。 当一台核心交换机宕机时，你会收到来自下游设备的 500 条告警。显示一条：“核心交换机宕机，影响 500 台设备。“而不是 500 条单独的告警。

4. 每条告警都需要一个操作手册。 如果你无法写下当有人收到告警时应该做什么，就删除这条告警。认真的。如果行动是"调查”，那不是行动，那是浪费时间。

5. 衡量告警质量。 跟踪误报率。任何误报率 > 10% 的告警都要被修复或删除。跟踪确认时间。如果告警几小时都没人确认，它就不重要到需要存在。

目标不是"全面监控”。目标是"只呼叫人工处理人工需要修复的事情”。

6.2.6.1. AI 和 AIOps 在可观测性中的角色#

让我们切穿炒作：大多数"AI 驱动的可观测性"只是带着营销预算的异常检测。尽管如此，如果你正确部署，这里确实有真实价值。

真正有效的内容：

• 异常检测：ML 确实比静态阈值更擅长学习每台设备的"正常”。85% 的 CPU 对设备 A 可能没问题，对设备 B 可能是灾难。ML 会自动弄清楚这一点。这现在是基本配置，不是魔法。

• 告警关联：当 50 件事同时出故障时，ML 可以将它们分组并建议"核心交换机可能是根本原因"。节省数小时的故障排查。但你仍然需要人工验证，因为 ML 有 20% 的时间会出错。

• 容量预测：ML 擅长"根据趋势，这条链路将在 6 周内饱和。“比人工盯着图表看更好。仍然需要人工判断是否需要关注。

被过度宣传的内容：

• 自动根本原因分析：每个厂商都承诺这一点，但没有人能可靠地交付。你会得到建议，有时是好的，但"AI 诊断并修复了问题"95% 是营销，5% 是精心挑选的例子。

• 自愈网络：自动化可以修复已知问题的已知解决方案。那不是 AI，那是好的工程。对于新问题的真正"自愈"还不存在。当厂商演示它时，要求他们展示失败案例。

• “AIOps 取代你的 NOC”：不。AIOps 帮助你的 NOC 更有效。人工判断、业务上下文和处理边缘案例的能力？那仍然是人工的。

底线：将 ML 用于异常检测和告警排名。对其他一切保持怀疑，直到你在自己的实际网络上测试过，而不是厂商演示。

6.2.6.2. 告警到行动的接口#

人工读取的告警是通知。自动化消费的告警是合同。这两种消费者有不同的需求，将它们混淆是告警管道在编排器边界失败的最常见原因之一。

当告警发往自动化时，其负载必须无需解析就可以被机器消费。这意味着结构化数据，而不是人类可读的主题行。至少，发往自动化的告警负载应包括：

• 设备标识：与 SoT 记录完全匹配的规范标识符（而不是可能在 DNS 和 CMDB 之间不同的主机名）
• 告警类别：编排器可以路由的稳定枚举类型（而不是当有人编辑告警规则时会变化的自由文本描述）
• 严重性：已定义的枚举，而不是数字阈值
• 时间戳：UTC ISO 8601 格式的事件时间，而不是通知投递时间
• 相关上下文：触发告警的具体指标或状态，在编排器可以直接读取的字段中（例如 "interface": "Ethernet0/1"，而不是嵌入在消息字符串中）
• 来源追踪：返回可观测性系统中原始事件的链接或引用，以便编排器可以重新查询以获取额外上下文

满足此合同的负载允许编排器将告警路由到正确的工作流、将设备标识传递给 SoT 查找，并使用结构化参数调用执行器，无需任何字符串解析。不满足此合同的负载会迫使编排器解析人类可读文本，每次告警描述发生变化时就会出问题。

在构建告警规则之前定义此合同，而不是之后。为人类可读性编写的告警规则作者会产生难以自动化的消息。同时为两类受众编写的告警规则作者会产生两者都不能很好服务的消息。最干净的解决方案是两条并行路由路径：一种用于人工的告警格式（Slack、PagerDuty），一种用于自动化的格式（消息队列、Webhook 端点）。都由同一个检测规则触发；对不同消费者使用不同的负载模板。

6.2.7. 可视化#

目标：所有观测到的数据都应该为决策者提供价值，因此应该根据用户需求设计面向用户的可视化。

最后一个模块是仪表板/报告层。让我直说：大多数仪表板都很糟糕。它们要么是让高管感觉良好的虚荣指标（“99.99% 正常运行时间！"），要么是数据大爆炸（每屏 50 个图表，没有人知道它们的含义）。

以下是构建真正有帮助的仪表板的方法：

• 为决策而建，而不是为装饰。 每个小部件都应该回答一个具体问题或触发一个具体行动。如果有人看着一个图表却不知道如何处理它，就删除那个图表。

• 显示问题，而不仅仅是数据。 绿/黄/红信号胜过原始数字。“接口利用率：45%“毫无用处。“接口利用率：正常"或"接口利用率：警告，趋向饱和"是可操作的。

• 层次化下钻胜过一个大仪表板。 从全局健康摘要开始（“3 个站点有问题”）。点击站点查看设备健康。点击设备查看接口。五个专注的仪表板胜过一个混乱的大仪表板。

• 匹配受众。 NOC 人员需要实时运营状态和下钻能力。管理人员需要趋势摘要和业务影响。工程师需要原始数据访问和查询界面。一个试图服务所有人的仪表板最终谁都服务不好。

• 让它互动，否则就不要做。 静态仪表板很快就会过时。让人们能够过滤、缩放、调整时间范围。支持调查，不只是展示漂亮的图片。

还有一个有争议的观点：大多数团队的仪表板太多了。我见过有 200 多个仪表板的组织，每个人只看其中的 2 个。删除没人用的仪表板。如果 3 个月没人看，它就不重要。

可视化/呈现边界

可视化位于一个值得直接说明而不是作为脚注的架构边界上。呈现层（第 8 章）负责面向用户的界面：访问控制、自助服务门户、ITSM 集成，以及人们如何请求和消费信息的用户体验设计。可观测性数据的可视化归属于本章第 6 章，因为设计决策完全由数据驱动：哪些指标可用、告警是如何结构化的、持久化层支持哪些下钻路径。不了解其背后的数据模型，就无法设计有效的可观测性仪表板。

实践中重要的区别在于：直接基于可观测性数据构建用于运营决策（现在发生了什么，这个服务是否健康）的仪表板是可观测性关注的问题。如何将这些仪表板呈现给非技术用户、嵌入自助服务门户，或与变更管理工作流集成是呈现关注的问题。第 8 章从访问和工作流的角度重新审视这些工具。大多数可视化工具（Grafana 是最常见的）通过同时做两件事来模糊这条线，这就是为什么分离感觉是人为的。但它不是。即使同一工具服务于两者，关注点也是真正不同的。

基本规则：

• 清晰性：易于理解。每个元素都有目的。
• 相关性：只显示支持决策的数据。噪音会扼杀洞察力。
• 以用户为中心：为你的受众而建。NOC 人员和管理人员需要不同的视图。
• 互动性：让人们下钻、缩放、调整时间。支持调查。
• 层次性：先全局概览，然后下钻。许多专注的仪表板胜过一个混乱的仪表板。

flowchart TD
    A[Global Overview] --> B[Site Summary] --> C[Device Summary] --> D[Device Detail] --> E[Interface Detail]

图 6：层次化下钻。

在《Modern Network Observability》一书的第 11 章（“应用你的可观测性数据”）中，你可以找到更多关于构建仪表板架构的详细内容。

请记住，这个模块与用户感知密切相关，因此不要忘记对他们进行访谈并让他们参与到这个过程中。

6.2.8. 自动化系统的可观测性#

大多数团队为网络构建可观测性。几乎没有团队为自动化系统本身构建可观测性。这是一个重大盲点：当自动化管道出故障时，故障往往是无声的。没有告警触发，因为负责生成告警的系统可能正是刚刚停止工作的那个系统。

一个以状态 0 退出的 Playbook，在向零台设备部署后不会产生任何错误。一个悄悄停止轮询厂商特定协议的 Telegraf 实例不会产生缺失数据告警，除非你专门为此进行了仪器化。一个在凌晨 2 点失败并使清单陈旧 12 小时的 SoT 同步作业，会导致每次后续执行都使用过时的设备列表运行，没有任何信号表明这种情况发生了。

在自动化平台中监控什么

• 执行层（AWX、Ansible）：

  • 随时间变化的任务成功率：缓慢上升的失败率是某些东西正在降级的早期预警
  • 执行时长：通常需要 4 分钟的任务需要 40 分钟标志着平台、网络或两者都有问题
  • 任务在挂起或运行状态中超过其预期窗口的情况
  • 回滚频率：不断上升的回滚率通常意味着意图数据或模板有缺陷
  • 每个任务到达的设备数量与预期数量：触及 10 台设备而不是 800 台的部署可能在没有错误的情况下静默失败了其清单同步

• 真实数据源层：

  • API 响应时间和错误率：慢速的 SoT API 会停滞每个查询它的执行任务
  • 每个来源的同步任务健康状况：上次成功同步时间、连续失败次数
  • 数据完整性：有多少设备记录缺少执行依赖的必填字段

• 采集层：

  • 每台设备上次成功采集的时间戳：三个连续间隔内未轮询的设备实际上是一个监控盲点
  • 整个网络的采集滞后：如果平均数据年龄在增长，采集器就落后了
  • 每种协议的遗漏轮询周期：SNMP 失败和 gNMI 订阅丢弃应该分别计数和告警

静默故障问题

最难检测的自动化故障是那些成功完成但没有产生有意义变化的任务。由于清单过滤器损坏而部署到零台设备的 Playbook 将以状态 0 退出。捕获这类故障的唯一方法是在结果层面进行仪器化：“预期数量的设备是否改变了状态？“而不是"任务进程是否干净地退出？”

这意味着向执行任务添加结果指标：成功配置的设备计数器、需要回滚的设备仪表，以及在将任务标记为成功之前检查任务至少触及了 N 台设备。

架构建议

在单独的、最小化的可观测性栈中监控自动化平台，该栈不依赖于它所支持的主可观测性系统。如果主 Prometheus 实例宕机，自动化管道的告警不应该随之宕机。覆盖核心自动化组件（AWX、Telegraf、SoT API、同步任务）健康状况的轻量级辅助栈（或 SaaS 告警服务）提供了主可观测性系统无法为自身提供的安全网。

这与第 7 章（编排）直接相关：健康的编排器应该将自己的运营状态作为一级关注点进行报告。如果编排器无法被观测，它所协调的自动化也无法被观测。

6.3. 实施示例#

本节通过使用 Telegraf、Prometheus 和 Grafana 栈以及其他工具的实际用例，说明可观测性功能如何协同工作。

这完全不是工具推荐，但由于它完全建立在开源组件之上，你可以尝试一下。

6.3.1. 用例：园区服务的部署后验证和持续监控#

我们继续第 5 章的园区网络。执行模块已将新的 VLAN 服务部署到 building-b 的目标交换机上。现在可观测性接手：首先从网络状态的角度验证部署是否真正成功，然后持续监控整个园区的服务健康状况。

场景：在向 Cisco、Arista 和 HPE 的约 800 台园区交换机部署新的 VLAN 服务段后，运维团队需要确认服务在所有目标设备上处于活跃且一致的状态，检测配置漂移（如果某台交换机丢失了 VLAN），以及随时间监控流量健康状况，无需手动逐台检查。

需求：

• 部署后验证所有目标交换机上的 VLAN 成员关系处于活跃且一致的状态
• 对配置漂移告警：交换机上缺少 VLAN，意外的中继成员关系变化
• 监控服务流量健康状况：每个接入端口的利用率水平和错误率
• 检测可能表示流量误路由的突然流量峰值（变化 > 50%）
• 以 30 秒分辨率维护 30 天的数据用于合规和容量规划
• 与 Nautobot 集成用于设备清单和 VLAN 意图数据
• 检测到漂移时触发编排工作流进行自动修复

6.3.2. 解决方案架构#

在开始解决方案分析之前，重要的是对场景的规模进行估算。约 800 台园区交换机 × 48 个端口 × 8 个指标 = 大约 307K 个活跃时间序列。这在单个 Prometheus 节点可以处理的范围内（舒适地处理约 100 万个序列），但采集器层需要多个 Telegraf 实例来在 30 秒间隔内分配对 800 台设备的轮询负载。

组件选择理由：

• Telegraf 因其多协议支持（为旧 HPE 和旧 Cisco 设备使用 SNMP，为 Arista 和更新 Cisco 平台使用 gNMI）、丰富的插件生态系统和用于数据规范化的内置处理器而被选中。在 800 台设备的规模下，单个 Telegraf 实例在 30 秒轮询间隔时会过于紧张，因此部署了两三个实例，由 Consul 协调每个实例拥有哪些目标。
• Prometheus 作为持久化层，针对时间序列数据进行了优化，其强大的 PromQL 查询语言适用于复杂的告警条件。在 307K 个序列的规模下，它在其舒适区内运行，同时提供与 Alertmanager 的原生集成。
• Grafana 通过多数据源支持提供可视化，同时查询 Prometheus 指标和 Nautobot 元数据，为不同受众（NOC、容量规划、管理层）创建富含上下文的仪表板。

架构

从高层次来看，下图描述了主要组件和角色：

flowchart TB
    subgraph Sources["Data Sources"]
        NB[Nautobot<br/>Source of Truth]
        SW[Network Devices<br/>SNMP/gNMI]
    end

    subgraph Collection["Collection Layer"]
        T[Telegraf<br/>Collectors]
        SD[Consul<br/>Service Discovery]
    end

    subgraph Storage["Storage"]
        P[Prometheus<br/>TSDB]
    end

    subgraph Alerting["Alerting"]
        AM[Alertmanager<br/>Routing]
    end

    subgraph Presentation["Visualization"]
        G[Grafana<br/>Dashboards]
    end

    subgraph Integration["External Systems"]
        ORCH[Orchestrator<br/>Automation]
        SLACK[Slack<br/>Notifications]
    end

    NB -->|Device Inventory| SD
    SD -->|Dynamic Targets| T
    SW -->|Metrics| T
    T -->|Expose HTTP| P
    P -->|Alert Rules| AM
    P <-->|Queries| G
    NB -->|Metadata| G
    AM -->|Webhook| ORCH
    AM -->|Alerts| SLACK

图 7：可观测性解决方案示例。

这个简化的解决方案架构在《Modern Network Observability》一书中有详细介绍。如果你想要一个带实验室场景的动手实践方法，不妨一试。

6.3.3. 实施流程#

清单集成：Nautobot 作为唯一的真实数据来源，定义要监控的设备、监控配置文件和 SNMP 凭证。一个轻量级同步服务（例如使用 Webhook 的 Python 脚本）持续更新 Consul 的服务注册表中的设备信息，使采集器能够进行动态发现。

数据采集：Telegraf 使用 Consul 进行服务发现，随着设备出现在 Nautobot 中自动轮询 SNMP。Telegraf 处理器规范化和丰富数据（将状态代码转换为标签，将字段重命名为标准名称，并从 Nautobot 添加上下文信息），并在 HTTP 端点上以 Prometheus 格式暴露指标。

持久化和分析：Prometheus 使用 Consul 服务发现抓取 Telegraf 端点，将指标存储在其时间序列数据库中。记录规则预先计算接口利用率百分比和带宽速率，以优化查询性能。

告警逻辑：Prometheus 中的告警规则定义条件（例如接口利用率 > 80% 持续 5 分钟，流量峰值增加 > 50%）。当条件匹配时，Alertmanager 处理路由，带有 automation: enabled 标签的关键告警发往编排器 Webhook，其他告警根据严重性路由到 Slack 或 PagerDuty。

可视化：Grafana 仪表板提供多种视图：结构范围的带宽趋势、最饱和的接口 Top 列表、带接口热图的每台设备下钻。模板变量支持按站点、角色或设备进行过滤。仪表板同时查询 Prometheus（指标）和 Nautobot（设备元数据）以获取上下文丰富。

闭环自动化：当关键饱和告警触发时，Alertmanager 向编排平台发送 Webhook，后者触发自动流量工程工作流以在可用路径间重新分配负载。我们在第 7 章中介绍这个组件。

6.3.4. 解决方案总结#

运营优势：

• 通过 SoT 集成减少手动监控工作
• 以亚分钟级延迟主动检测问题
• 闭环修复将 MTTR 从数小时缩短到数分钟
• 将指标与清单数据结合的丰富上下文

可扩展性考量：

• 当前架构使用 Consul 背后的 2-3 个分布式 Telegraf 实例处理约 800 台园区交换机；添加更多建筑或设备意味着添加更多采集器实例，而不是重新架构
• Prometheus 容量在约 307K 个序列时绰绰有余，还有增长空间；单个节点可以处理约 100 万个序列，之后才需要联邦或分布式后端

这个简短的解决方案练习为本章画上句号，本章定义了可观测性在网络自动化架构中的基本目标和功能。

6.4. 总结#

网络自动化中的可观测性远超传统监控，为理解网络行为、主动检测问题和在规模化下实现自动修复提供了架构基础。建立在七个核心目标之上，从以最少人力自动发现到复杂实时分析和以用户为中心的可视化，可观测性通过从被动故障排查转向主动、数据驱动的运营，根本改变了组织对网络事件的响应方式。

实现这些目标需要七个相互连接的架构支柱和功能：与 SoT 集成以自动发现清单，支持通过流式遥测和现代协议进行近实时数据摄入的多协议采集器，将异构数据与上下文元数据规范化和丰富的处理器，用于高容量可扩展数据移动的分布式系统，针对不同可观测性工作负载优化的专用数据库（如时间序列、列式和文本搜索），具有 AI/ML 增强检测和路由到编排器或人工响应者的智能告警，以及为不同受众以适当抽象级别呈现信息的定制化可视化。

实施可观测性需要在设计过程早期做出架构决策。组织必须在传统本地平台、提供快速部署和 AI 驱动分析的云原生 SaaS 解决方案，以及提供最大灵活性的可组合开源栈之间做出选择。每种方法都涉及成本、控制、运营开销和能力方面的权衡。成功还取决于理解数据处理需求，从规范化和丰富到过滤和聚合，以及新兴的 AIOps 能力如何减少告警疲劳并实现预测性运营。

可观测性不是单一工具，而是一种连贯的架构模式。成功取决于将其视为一个系统，其中清单驱动采集，采集实现处理，处理输入分发，分发连接到持久化，持久化告知告警，告警最终驱动可视化和自动化响应。通过仔细设计每个组件及其交互方式，组织可以构建与网络一同扩展的可观测性系统，与 OpenTelemetry 和 gNMI 等现代协议集成，并将运营可见性转化为驱动闭环自动化的可操作情报。

参考文献和延伸阅读#

• Modern Network Observability（David Flores、Christian Adell、Josh Vanderaa 著）：使用 Telegraf、Prometheus 和 Grafana 等开源工具的动手实践方法

💬 Found something to improve? Send feedback for this chapter