作者来自 Elastic Mark Bernard了解 Network Operations CenterNOC团队如何使用 Elasticsearch、ML 和 Elastic AI Assistant 来缩短 MTTR、缓解告警疲劳并快速解决网络问题。一名 Level 1 NOC 分析师如果面对 Cisco ISE 部署中的大量 802.1x 身份认证失败通常需要依赖高级网络工程师并花费 20 分钟进行人工关联分析才能整理出一份调查清单。而借助 Elastic 的 ML anomaly detection 和 AI Assistant同样的清单 —— 包括按可能性排序的根因、证书检查项、RADIUS 配置步骤 —— 现在只需通过一条告警就能在数秒内自动生成。本文将详细介绍完整配置流程Elastic Agent、Cisco ISE integration、实时 anomaly detection job以及基于 Knowledge Base 的 AI Assistant如何自动将告警上下文转化为故障修复指导。勇敢探索无人涉足之地。《星际迷航》不仅仅是一部太空史诗。对于今天的网络工程师来说它也恰好象征着 NOC 运维正在迈向的新前沿一个由 Machine Learning、AI 和大规模统一遥测驱动的新时代。任何在 Network Operations CenterNOC工作过的人都熟悉这种 “苦战” —— 满墙的仪表板、“系统还活着吗” 的 ping 工具以及在凌晨两点从成千上万条日志中艰难定位服务故障原因的过程。随着网络变得越来越复杂、越来越分布式依赖人工关联分析、经验知识和 war room 电话会议的传统方法已经逐渐触及极限。新的运维模式已经不同。NOC 分析师不再只是被动盯着仪表板而是借助先进的 Machine Learning 算法和人工智能来聚合内部与外部遥测数据、自动发现异常并引导工程师完成故障修复 —— 从而大幅缩短Mean Time to Resolution平均故障恢复时间 - MTTR很多团队也称之为 Mean Time to Innocence证明自己无责所需的平均时间” - MTTI。Elastic 正处于这一转变的核心。它具备可扩展、schema-on-write 的架构能够摄取 TB 级网络遥测数据对其运行实时 ML jobs并直接在分析师工作流中提供 AI 生成的修复建议。本文将通过一个真实客户案例详细展示如何完成这一整套配置。网络遥测数据源Elastic 可接入的数据类型网络遥测数据有很多种形式。Elastic 可以将它们全部接入并在同一平台中进行关联分析从而让你的 NOC 获得统一视图而不是依赖彼此割裂的工具Router 与 Switch SyslogsNetFlow / IPFIXSNMP Traps 与轮询数据DNS 与 DHCP 日志Firewall 与 VPN 日志VPC Flow LogsAWS / GCP / Azure802.1x / NAC 事件SD-WAN 遥测数据直到最近还没有一种真正智能的方法能够对这些数据源进行整体聚合与分析。NetFlow 可以提供大规模的五元组 IP 流量信息但如果你想把它与 NAC 平台中的 802.1x 认证失败进行关联就必须在多个工具之间手动切换和关联分析。Elastic 从根本上改变了这一局面。下面是一个真实客户案例展示 Elastic 如何解决这个问题。在阅读案例时请设想一下当高管网络无法使用时你需要在巨大的压力下尽快定位并修复问题。在客户案例之后我会一步一步说明如何利用 Elastic 的 Machine Learning 和 AI Assistant 来快速识别并解决问题。客户案例某客户需要排查 Cisco ISE 身份认证日志。高管们在办公室工位 docking 状态下可以正常登录笔记本但一旦移动到会议室或餐厅就会失去网络访问能力。NOC 团队怀疑这是一个 802.1x 无线认证问题但面对 Cisco ISE 平台上的大量失败日志他们已经无法手动完成关联分析。下面是他们如何一步一步使用 Elastic 解决这个问题。逐步配置1. 安装 Elastic AgentSetupElastic Agent 是采集网络设备与基础设施遥测数据的统一方式。在大多数场景下它可以替代多个 Beats 或 Logstash pipeline。你需要将它部署在一个能够通过 syslog、SNMP 或 API 访问网络设备的 collector host 上。在 Kibana 中进入Fleet→Agents→Add Agent选择你的平台复制生成的安装命令并在 collector host 上运行。Agent 会自动向 Fleet 注册 —— 之后所有 policy 变更都可以集中管理无需再通过 SSH 登录每台机器。提示对于高可用 NOC 部署建议在负载均衡器后部署多个 Elastic Agents并将其指向 Fleet Server 集群。这样即使某个 collector host 宕机遥测数据采集仍然可以继续。请参见下方截图2. 配置 Agent PolicySetupAgent Policies 用于定义 Elastic Agent 需要采集哪些数据。在 Fleet 中创建一个名为 “NOC-Network-Telemetry” 的新 policy。Policy 用于组织 integrations并可应用到一个或多个 agents —— 这使你能够把整类 collector hosts 作为一个统一单元进行管理。在该 policy 中你需要为不同的遥测数据源添加 integrations。你可以先从当前环境最相关的 integration 开始本案例中为 Cisco ISE之后再逐步扩展到 NetFlow、SNMP 等其他数据源。请参见下方截图3. 添加 Cisco ISE 集成Integration在 Fleet 中进入Integrations→ 搜索 “Cisco ISE” 并将其添加到你的 policy。该 integration 自带预构建的 ingest pipelines可以将 ISE 的 syslog 格式自动解析为结构化 ECS 字段 —— 无需自定义 Grok patterns。配置 ISE将 syslog 转发到 Elastic Agent collector 的 UDP/TCP 514 端口。在 integration 设置中匹配该端口并设置 log categoriesauthentication events、posture assessments、guest access 和 profiler logs 是用于 802.1x 故障排查最有价值的日志类型。# ISE syslog target configuration # Administration → System → Logging → Remote Logging Targets Target Name: elastic-noc-collector IP Address: 10.10.5.20 # Your Elastic Agent host Port: 514 Facility: LOCAL7提示在初始故障排查期间在你的 ISE syslog 目标上启用所有严重级别从 DEBUG 到 EMERGENCY。你可以在 Elastic 中进行过滤而不是在数据源端丢失事件。你也可以配置 ingest pipelines在 integration pipeline 中修改或丢弃字段。请参见下方截图4. 在 Discover 中探索数据Analysis当 ISE 日志开始流入后进入 Kibana → Discover并选择 logs-cisco_ise.* data view。你会看到已经被解析的结构化事件字段例如 cisco.ise.message.id、event.outcome 和 cisco.ise.nas.ip。针对高管 802.1x 问题过滤失败的 authentication events。查找 event.outcome: failure并结合 cisco.ise.message.id: 5200authentication failure。将 cisco.ise.nas.ip 添加到列中可以立即看到哪些 access points 正在产生失败——你会很快发现与会议室和餐厅相关的模式。# Quick KQL filters to start with in Discover: # All authentication failures event.outcome: failure AND cisco.ise.message.id: 5200* # Failures on wireless only event.outcome: failure AND cisco.ise.network.device.groups: *Wireless* # Specific endpoint MAC address cisco.ise.endpoint.mac: AA:BB:CC:DD:EE:FF5. 使用 ES|QL 进行高级查询AnalysisElastic 的 ES|QL 相比 KQL 提供了更深入的分析能力它允许你直接在数据上执行类似 SQL 的转换、聚合和 enrichment 操作。对于 NOC 来说这意味着可以直接得到 failure rate 统计、top-N 故障设备以及按时间分桶的趋势分析 —— 而无需先构建 dashboard。// Top access points by authentication failure count FROM logs-logen-logen_events-cisco_ise-log-* | WHERE cisco_ise.log.failure_reason IS NOT NULL | STATS failure_count COUNT(*), unique_endpoints COUNT_DISTINCT(cisco_ise.log.network_device_ip) BY cisco_ise.log.network_device_ip | SORT failure_count DESC提示ES|QL 的结果可以直接固定pin到 Kibana 仪表板中。你可以先在 Discover 中构建调查查询然后将其保存为面板——这样 NOC 在排查问题的同时就能获得一个实时更新的问题视图。请参见下方截图6. 创建 Machine Learning 作业Machine Learning进入 Machine Learning → Anomaly Detection → Create Job。选择 “rare” 作业类型并将其指向你的 logs-cisco_ise.* 索引你的索引名称可能不同。该 ML 作业会学习每个设备历史的 authentication failure 基线并自动标记统计上异常的偏差。不需要配置阈值也不需要手动训练模型 —— Elastic 会自动完成这些工作。# ML Job Configuration Job ID: ise_auth_failure_anomaly Detectors: rare by cisco_ise.log.failure.reason influencers: cisco_ise.log.failure.reason host.hostname Bucket span: 15m Datafeed: Real-time (continuous)请参见下方截图7. 创建可观测性告警规则Alerting进入 Observability → Alerts → Manage Rules → “Create Rule”。选择 “Anomaly detection alert”并引用你的 ise_auth_failure_anomaly 作业。将 anomaly score 阈值设置为 70–80并配置 action通过 Slack、PagerDuty 或 ServiceNow 通知你的 NOC。在完成后点击页面底部的 “Create Rule”。提示建议设置 30 分钟的 flapping detection window以避免在短暂瞬时峰值期间产生告警风暴。NOC 只应在持续异常发生时被通知而不是那些会自动恢复的短暂波动。请参见下方截图8. 在 Observability 中查看告警详情AI Assistant当告警触发时进入 Observability → Alerts 并点击 “Alert details”。你会看到 anomaly score trend、受影响的 devices、异常的时间范围以及关联 events——所有信息都在同一个视图中展示。请参见下方截图9. 调用 AI AssistantAI Assistant在告警详情页面点击 “Help me understand this alert”。Elastic AI Assistant 会读取完整的告警上下文并提供一份通俗易懂的摘要、按可能性排序的潜在根因以及建议的排查步骤AI Assistant Response (example): Alert Summary: Anomalous spike in 802.1x authentication failures detected across 3 wireless APs between 09:15 and 09:45 UTC. Failure count is 847% above the learned baseline.Probable Root Causes: 1. RADIUS server certificate expiry (ISE error 5406 in logs) 2. VLAN misconfiguration on the wireless controller 3. 802.1x supplicant profile mismatch on endpoints Recommended Next Steps: 1. Check ISE certificate validity: Admin System Certificates 2. Verify RADIUS shared secret between WLC and ISE PSN 3. Review Authentication Detail Report for affected MACs请参见下方截图在几秒钟内你的 Level 1 NOC 分析师就获得了一份优先级排序的调查清单而这份清单原本需要高级网络工程师花费 20 分钟手动构建。这就是 MTTR 降低的实际体现。配置 AI 知识库Knowledge Base打开 AI Assistant点击 Actions → Manage Knowledge Base。添加静态条目——例如你的 ISE 故障排查 runbooks、架构说明或历史 incident post-mortems。Assistant 会在生成分析时引用这些内容并根据你的环境定制建议。# Example Knowledge Base entry: Title: ISE Error 5406 - RADIUS Authentication Failure Resolution When ISE error 5406 is observed with wireless endpoints: 1. Verify ISE System Certificate: Admin Certificates 2. Check PSN health: Admin Deployment 3. Confirm RADIUS CoA is enabled on WLC for the affected SSID 4. Review Authentication Policy matching order Escalate to: noc-tier2company.com if not resolved in 30 min请参见下方截图11. 通过 Connectors 连接外部数据源Integrations对于更动态的知识库你可以使用 connectors 来实现。为此进入 Stack Management → Connectors → “Create Connector”。可用类型包括 ServiceNow、Jira、PagerDuty、GitHub以及通用 webhook。一旦连接完成AI Assistant 在分析告警时就可以查询这些系统 —— 例如检查最近变更、未关闭工单、已知 bug、playbooks 或 RSS feeds——而无需分析师在不同工具之间手动切换。提示ServiceNow CMDB connector 尤其有价值。当 AI 识别到受影响的设备时它可以自动拉取设备 owner、维护窗口计划以及变更历史 —— 这些上下文信息能够显著加速升级escalation决策。你还可以订阅 vendor product feeds从而在软件发布后第一时间获取新增 bug 信息并更新上下文。请参见下方截图12. 未来展望MCP、工作流与 Agentic 运维即将推出当前的 AI Assistant 已经在改变 NOC 运维方式但这只是开始。下一阶段是 agentic AIAI 不再只是被动回答问题而是能够主动替你执行操作。Elastic 正在投入 Model Context ProtocolMCP支持以及 AI Workflows这将使 AI 能够自动完成一整套操作流程例如自动创建 ServiceNow 工单、从 CMDB 查询设备负责人、生成面向高管的影响分析摘要并引导 Level 1 分析师逐步完成修复流程——这一切都可以由单个 anomaly alert 触发。分析师将从“调查者”转变为“最终确认者”。后续我会在系列文章中进一步展开这个方向。总结今天的全新前沿未来的 NOC 并不取决于墙上有多少 dashboard而取决于团队从告警到恢复服务的速度有多快。Elastic 技术栈通过统一的遥测数据接入、实时 ML 异常检测、AI Assistant 以及可扩展的 Knowledge Base让今天的 NOC 团队已经具备了实现这一跃迁的能力。本文中的 Cisco ISE 用例只是其中一个例子。同样的模式——数据接入、ML 检测、AI 分诊、知识库驱动的修复——也适用于 NetFlow 异常、BGP 路由抖动、Firewall 策略违规、SD-WAN 路径退化以及团队每天面对的数十种网络事件。前沿已经开启。从一个 integration、一个 ML job、以及一个 Knowledge Base 条目开始你就能看到 MTTR 的显著改善会自然发生。原文https://www.elastic.co/observability-labs/blog/elasticsearch-network-monitoring-noc-mttr