使用 Elastic 进行网络监控：统一网络可观测性

Elasticsearch
0 阅读12分钟

作者：来自 Elastic Patrick Boulanger

了解如何使用 Elastic observability 和 AI 来统一网络监控。我们将展示如何关联网络数据、识别根本原因并修复问题。

引言：网络监控碎片化问题

在 Elastic 为企业客户工作的五年中，我一再听到同样的挑战：

“我们有多个网络监控工具，我们非常希望能把它们关联到一个平台中。”

对许多组织来说，实现真正关联的障碍并不是数据不足，而是数据存放的位置。我们经常看到 SNMP 指标、流量数据和日志被隔离在为特定用途构建的孤立系统或仪表板中。没有统一的数据存储和合适的关联引擎，要拼接完整的事件叙事 —— 从拓扑变更到性能下降 —— 就会变成一个手动且耗时的难题。

当事件发生时，工程师会变成 “人工关联引擎” —— 在不同系统之间来回跳转，复制时间戳，交叉引用设备名称，并尝试拼凑出到底发生了什么。像 “这个接口故障是否影响了应用性能？” 这样一个简单的问题，都需要查询多个工具并在脑中进行关联。

真正的成本不在于工具许可 —— 而是在关键事件期间所浪费的时间。

这个实验室就是我对一个根本问题的回答：Elastic 能否成为真正关联网络数据的统一基础？

更重要的是，它展示了 Elastic 已完全为网络运维做好准备 —— 能够摄取多样化的遥测数据，并利用 AI 来关联关系、识别根本原因，并在几秒钟内而不是几小时内解决问题。

问题：网络可观测性已经失效

让我描绘一个我在企业网络团队中经常遇到的典型场景：

碎片化的现实：

  • 没有单一事实来源
  • 事件期间需要手动关联（每个事件 15–30 分钟）
  • 团队割裂（网络工程师 vs 平台工程师）
  • 自动化能力有限
  • 没有 AI 驱动的分析

当凌晨 2 点一条链路断开时：

  • 注意到告警 — 2 分钟
  • 登录监控工具查看指标 — 3 分钟
  • 切换到流量分析器检查影响 — 5 分钟
  • 打开日志管理系统搜索相关消息 — 10 分钟
  • 在多个系统之间手动关联时间戳 — 8 分钟
  • 创建工单并从多个工具中复制上下文 — 8 分钟

初始诊断时间：36 分钟

这种工作流成本高、容易出错，而且无法规模化。

愿景：Elastic 作为统一的网络可观测性平台

如果你可以：

  • 在一个平台中采集 SNMP 指标、NetFlow、traps 和拓扑数据
  • 自动将网络事件与应用性能进行关联
  • 无需单独的 BI 工具即可生成高管仪表板
  • 使用 AI 在几秒钟内而不是几小时内分析事件
  • 基于网络事件触发告警

这正是本实验室旨在展示的内容。

我构建了什么：生产级网络仿真

为了展示 Elastic 如何统一网络数据，我需要一个能够生成真实世界遥测数据的真实环境。于是有了 Containerlab —— 一个基于 Docker 的解决方案，使我们能够创建一个网络仿真框架。

实验室架构

我模拟了一个服务提供商核心网络，包括：

  • 7 台 FRR 路由器，形成 OSPF Area 0 网格

  • 2 台 Ubuntu 主机，用于其他用例

  • 2 台二层交换机，用于接入层分段

  • 3 个遥测收集器，将数据发送到 Elastic Cloud

容器总数：14

部署时间：12–15 分钟（完全自动化）

完整的部署说明和拓扑细节可在 GitHub 仓库 README 中找到。

三条遥测管道：验证多源关联

使这个实验室具备生产就绪特性的是其混合可观测性方法 —— 证明 Elastic 能够统一不同的网络数据源。

管道数据类型采集方法收集器用例
SNMP Metrics接口统计、系统健康、LLDP 拓扑主动轮询OTEL Collector容量规划、趋势分析
NetFlow流量流推送式导出Elastic Agent流量主要来源、安全调查
SNMP Traps接口上线/下线事件事件驱动Logstash实时事件检测

这个统一架构证明了 Elastic 可以用一个平台替代多个专用的网络监控工具。

关联的力量：一个平台，一条查询

当网络事件发生时，你需要回答这样的问题：

  • 哪个接口故障了？（SNMP metrics）

  • 哪些流量受到了影响？（NetFlow）

  • 事件的顺序是什么？（SNMP traps）

  • 哪些设备在下游？（LLDP 拓扑）

问题：现代工具提供的是分离的模块拼接在一起，迫使用户在不同空间中导航以获取不同的数据集。

现实：你仍然需要切换视图。你在 Metrics 模块看到一个峰值，但要了解原因，你必须打开 Logs 模块并手动对齐时间选择器。数据分布在不同的表或后端，没有人工干预就无法实现真正的关联。

Elastic 的区别：一个存储，一个语言，一个 AI

Elastic 使这一切变得简单。无论是 SNMP 计数器（metric）、NetFlow 记录（flow）还是 Syslog 消息（log），都存储在由 Elasticsearch 引擎驱动的统一数据存储中。这允许用户在单次查询中轻松搜索多个数据集。

`

1.  FROM logs-*
2.  | WHERE host.name == "csr23" AND interface.name == "eth1"

`AI写代码

所需时间：3 秒

此外，如你稍后将看到的，当利用 AI Assistant 时，数据的具体位置对用户而言是无关紧要的。

数据转换：从神秘 OID 到可执行情报

原始 SNMP traps 很难一眼看懂。在我们当前的实验室设置中，数据到达时如下所示：

`

1.  OID: 1.3.6.1.6.3.1.1.5.3
2.  ifIndex: 2
3.  ifDescr: eth1

`AI写代码

虽然传统的网络管理平台 ( NMPs ) 能够原生处理 OID 转换，但要将这种清晰度引入 Elastic，需要特定配置。

在这个初始实验室中，我们有意使用这些原始数据，以展示 AI assistants 如何在没有预先上下文的情况下解释这些事件。

然而，该项目下一阶段的策略是实现 Elasticsearch Ingest Pipelines。这将允许我们将原始 OID 映射为人类可读的名称。这一步对于弥合网络工具与应用可观测性平台之间的差距至关重要，使网络事件能够即时与应用错误和基础设施日志关联。

目标状态

一旦在下一个实验室中实现管道，我们将把原始 trap 转换为可搜索、有意义的数据：

`

1.  {
2.    "event.action": "interface-down",
3.    "host.name": "csr23",
4.    "interface.name": "eth1",
5.    "interface.oper_status_text": "Link Down"
6.  }

`AI写代码

结果：

  • 人类可读字段

  • 可用于过滤的搜索维度

  • 自动化规则和仪表板的上下文

  • 与指标和流量关联的关联键

在我们的下一篇博客文章中，我们将逐步演示如何构建执行此转换的 ingest pipeline。

智能告警：从噪声到可执行情报

传统网络监控依赖简单阈值告警 —— “接口宕机”、“CPU 高”。这些告警会淹没你的收件箱，但对根本原因、影响或补救措施毫无上下文。

实验室的方法：ES|QL + AI Assistant

1）使用 ES|QL 进行语义检测

实验室不是使用通用阈值告警，而是使用 ES|QL 检测特定事件模式：

`

1.  FROM logs-snmp.trap-prod
2.  | WHERE snmp.trap_oid == "1.3.6.1.6.3.1.1.5.3"
3.  | KEEP @timestamp, host.name, interface.name, message

`AI写代码

2）自动 AI 驱动调查

当告警触发时，它会调用 Observability AI Assistant，并使用结构化调查 prompt 来：

  • 执行即时分诊（哪个设备，哪个接口，何时发生）

  • 评估 OSPF 影响和流量重路由

  • 与其他近期故障关联

  • 生成严重性评估和推荐操作

转变

传统告警智能告警 ( Elastic )
邮件："csr23 接口宕机"带设备上下文的结构化分析
手动调查：20–30 分钟AI 自动调查：90 秒
工程师跨工具关联自动跨源关联
无业务影响评估包含严重性 + 推荐操作

使用 Elastic AI Assistant 加速事件响应

这就是 Elastic AI Assistant 展示其运营价值的地方 —— 不再只是被动收集数据，而是实时主动解释和分析网络事件。

当工程师在 Discover 中查看 trap 文档并询问：

“解释这条日志消息”

AI Assistant 会提供全面分析，包括：

  • 发生了什么：SNMP trap 的通俗解释

  • 设备上下文：路由器角色、接口用途、网络位置

  • 影响分析：OSPF 邻居状态、流量重路由评估

  • 根因可能性：物理层、链路层、管理原因

  • 推荐操作：即时步骤、调查查询、验证检查

  • 严重性评估：业务和技术影响评分

手动分诊 vs AI 辅助调查

前后 ( Elastic AI )
Google OID → 5 分钟点击 "Explain this log" → 20 秒
打开网络拓扑图 → 3 分钟自动提供拓扑上下文
查询多个工具 → 10 分钟跨源关联即时完成
评估业务影响 → 5 分钟自动生成影响分析
总计：约 28 分钟总计：约 20 秒

价值主张：一个平台，一个数据模型，一个 AI

实验室展示内容

Elastic 提供：

  • 一个统一平台，用于 metrics、logs、flows

  • 一个数据模型 ( SemConv )，实现一致的关联

  • 一个搜索界面 ( Kibana )，适用于所有网络数据

  • 一个理解你所有网络遥测的 AI assistant

  • AI 驱动告警，带自动化调查

业务影响

效率提升：

  • 初始诊断 MTTR 减少 85%（36 分钟 → 5 分钟）

  • 手动关联时间减少 90%

  • 初级工程师可以访问 AI 驱动的专家分析

运营收益：

  • 网络工程师专注于策略，而非工具切换

  • 跨职能协作集中在一个平台

  • 减少工具碎片化和管理开销

经验总结

在构建该实验室之后，关于网络数据如何融入更广泛的可观测性生态系统，我们得出了几个关键见解：

1）将可观测性扩展到网络

Elastic 已经是高流量日志和应用追踪的黄金标准。本实验室展示了同一个引擎可以无缝处理网络遥测数据，而无需单独的孤立工具。

  • 规模：同样的架构可处理 PB 级应用日志，也能轻松处理数百万接口计数器。

  • 结构：原生支持复杂嵌套文档，使丰富的 SNMP trap 数据（变量绑定）无需扁平化即可保留上下文。

  • 速度：实时搜索同样适用于网络事件，实现亚秒级故障排查。

2）OpenTelemetry 语义规范 ( SemConv ) 作为通用翻译器

强大之处不仅在于存储数据，而在于标准化数据。通过将 SNMP 和 NetFlow 映射到 OpenTelemetry Semantic Conventions ( SemConv )，网络数据终于能与其余栈使用相同语言。

  • 统一搜索：在单一搜索栏中查询防火墙日志、服务器指标和交换机遥测数据。

  • 即时可视化：预建仪表板可以立即使用，因为字段名已标准化。

  • 跨域关联：轻松将应用延迟的峰值与特定接口饱和事件关联。

3）AI Assistant 依赖上下文

虽然实验室中的 AI 本身已很强大，但实验凸显了一个关键认识：当 AI Assistant 与特定知识库结合时，其效果会呈指数级提升。

上下文为王：当提供丰富的元数据（如设备角色和拓扑图）时，AI 可以提供更好的根因分析。缺少上下文时，建议仍然是通用的。

专业提示（以及下一步）：

若要获得针对组织的建议而非通用建议，你需要将文档输入 AI。

  • 目标：创建包含设备角色、网络拓扑图和故障排查流程的知识库。

  • 下一步：在我的下一篇博客文章中，我将展示如何将知识库连接到 AI Assistant，实现完全上下文感知的故障排查。

结论：完善可观测性全景

Elastic 已被广泛认可为应用和安全可观测性的标准。本实验室的目标不是质疑 Elastic 是否能处理网络，而是展示将网络数据引入现有生态系统所带来的巨大价值。

结论明确：Elastic 作为统一基础平台，有效打破了网络工程与 IT 其他部门之间的孤岛。

这不仅仅是整合仪表板或替换遗留工具，而是将 Elasticsearch AI Platform 建立为单一事实来源，在这里网络遥测与应用和基础设施数据并列存放。

通过将网络数据视为可观测性栈中的一等公民，我们解锁了自动关联、AI 辅助调查以及在事件影响业务前快速解决问题的能力。功能已经到位，基础牢固 —— Elastic 已准备好将你的网络与整个数字业务统一。

准备自己试试吗？

查看 github.com/DeBaker1974…

仓库包含：

  • 完整部署脚本（12–15 分钟自动化设置）
  • 预配置的遥测管道
  • Kibana 仪表板
  • 集成 AI Assistant 的告警规则
  • 详细 README

不准备自己搭建？试试 Elastic Serverless：开启 14 天免费试用，使用你自己的数据探索 AI 驱动的可观测性。

特别感谢 Containerlab 和 FRRouting 社区提供的出色开源工具，以及 Elastic 解决方案架构高级经理 Sheriff Lawal ( CCIE, CISSP ) 对本项目的指导。

原文：www.elastic.co/observabili…

avatar
文章
阅读
粉丝