红帽使用 InfluxDB 收集 gNMI 数据以进行内部网络监控

导航至

红帽是全球开源企业 IT 解决方案的领导者,其产品组合包括混合云基础设施、中间件、云原生应用和自动化解决方案。

业务挑战

管理红帽的企业 IT 基础设施是一项庞大的任务,涉及监控支持 40,000 多名员工在 40 个不同国家的骨干网络。红帽的内部网络监控团队监控了公司 105 个全球办公室中的 60 多个。总计有 14,000 多个接口和 1,600 多个设备。

红帽的监控主要围绕性能指标和可视化。网络监控团队希望了解网络基础设施的性能,并通过可视化数据更好地理解这种性能。

为了实现这种全球基础设施的可观察性,网络监控团队寻求构建一个作为网络单一事实来源的监控解决方案。为此,他们需要能够收集来自全球的数据,例如设备可用性数据(例如,ping、http、DNS)、查询速度、http响应时间和代码、外部链接利用率、延迟等等。

技术挑战

由于全球有如此多的不同接口和设备,红帽团队需要能够使用最有效的协议收集来自广泛数据源的数据。他们需要可视化网络性能、生成警报、创建网络图、监控网络带宽,并需要一种收集数据以支持这些可观察性目标的方法。

最大的挑战之一是,SNMP协议在网络监控中仍然非常常见。然而,SNMP存在几个关键限制,因此团队尽可能地将使用Google的网络管理接口(gNMI)。gNMI提供了更细粒度的数据轮询间隔,并且可以收集和存储SNMP无法收集的数据类型和指标。

然而,并非红帽环境中每台设备都支持gNMI,那么公司是如何将所有内容整合为单一事实来源的呢?

解决方案

红帽运行InfluxDB的企业实例,这是他们网络监控架构中的一个关键部分。红帽使用Telegraf以及适当的SNMPgNMI插件直接从网络设备收集数据。他们尽可能收集gNMI,但某些设备只支持SNMP,或正在更新为支持gNMI,因此这些设备的数据通过SNMP传入。

Telegraf在必要时丰富数据,然后再将其传递给Kapacitor进行分析。如果Kapacitor检测到问题,系统会向相关人员发送警报。红帽将分析后的SNMP和gNMI数据存储在InfluxDB的不同测量中,并为每个测量编写自定义查询。使用Flux语言,他们可以在查询级别组合不同的测量,同时在存储层保持数据分离。

InfluxDB diagram

由此数据生成的仪表板包括各种信息,如历史SLI/SLO数据和实时数据可视化。

Dashboards generated from data

结果

下面的架构图显示了构成红帽网络监控解决方案的不同组件和数据流。他们依赖Ansible来协调网络自动化以进行设备管理,并配置Telegraf、Kapacitor和InfluxDB实例。

The architecture diagram with components and data flows that comprise Red Hat network monitoring solution

得益于这种高度自动化,此解决方案需要相对较少的手动干预,使支持工程师能够专注于关键问题,而不是管理单个设备和组件。InfluxDB有助于为个人提供最广泛的数据范围,以喂养单一事实来源并促进自动化,从而提高实时监控能力。

有关红帽解决方案的更多详细信息,请阅读完整的案例研究