How Red Hat Uses InfluxDB to Monitor 14,000+ Network Interfaces Across Its Global Network

Overview

Building a unified view of a global network

Red Hat provides open source enterprise IT solutions spanning hybrid cloud infrastructure, middleware, cloud-native applications, and automation. Behind those products is a global network that connects offices and infrastructure across dozens of countries.

Red Hat’s network monitoring team is responsible for understanding how that infrastructure is performing across more than 60 sites, 1,600 devices, and 14,000 network interfaces. That means monitoring switches, routers, firewalls, wireless infrastructure, links, and other systems from multiple vendors, each producing a continuous stream of operational data.

The team uses that data to understand device health, network utilization, latency, packet loss, response times, bandwidth, wireless performance, and other signals. Red Hat needed a way to bring those metrics together so engineers could monitor the network in real time while also retaining the history required for troubleshooting, capacity planning, anomaly detection, and automation.

Challenge

Unifying telemetry across vendors and protocols

Red Hat’s network spans hardware from vendors including Cisco, Juniper, F5, OpenGear, and Mist. That diversity also means different devices support different telemetry protocols.

SNMP remained widely used across the environment, but it limited how frequently the team could collect metrics. Polling consumed resources on the devices being monitored, and Red Hat could collect SNMP metrics at intervals of roughly one minute.

For devices that supported it, Red Hat wanted to move toward gNMI, which could provide telemetry as frequently as every second while exposing data and metrics that were not always available through SNMP. But not every device supported the newer protocol. Red Hat therefore needed a monitoring architecture that could work across both generations of telemetry without creating separate systems for each.

At the same time, the team needed more than raw data collection. Engineers wanted to visualize performance, generate alerts, identify anomalies and bottlenecks, monitor bandwidth, and feed network data into the company’s broader automation environment.

ENTER INFLUXDB

Bringing network telemetry into one data layer

Red Hat built its network monitoring architecture around InfluxDB and Telegraf.

Distributed collectors run Telegraf close to Red Hat’s network infrastructure, using the appropriate plugin to collect data from each device. Wherever possible, Red Hat uses gNMI for higher-frequency telemetry; devices that do not yet support it continue to send metrics through SNMP.

That flexibility was one of the main reasons Red Hat selected Telegraf:

InfluxDB provides the common time series data layer behind the system. Red Hat can keep different telemetry streams separate in storage while combining them at query time, giving engineers a unified view of network behavior across vendors and protocols.

From there, the data supports real-time and historical dashboards covering interface utilization and errors, CPU and memory usage, BGP neighbor status, latency, packet loss, HTTP response times, DNS delay, internet-link utilization, and wireless performance. Red Hat also connects monitoring data to alerting and its Ansible-based network automation environment.

Red Hat uses Grafana dashboards backed by InfluxDB to visualize network performance, utilization, and other operational metrics in real-time.

Results

From minute-level polling to more proactive network operations

By combining gNMI and SNMP telemetry in InfluxDB, Red Hat gained a broader and more timely view of its network without requiring every device to support the same protocol.

For supported devices, gNMI increased metric resolution from roughly once per minute to once per second, giving engineers a more detailed view of changing network conditions. Red Hat could still collect data from older devices through SNMP and analyze both types of telemetry through the same monitoring environment.

That data supports both immediate response and longer-term planning. Engineers can monitor device and interface health, investigate errors and utilization, track site-level performance, and alert on emerging issues. Historical data helps the team understand capacity trends and service-level performance over time.

Red Hat also used its time series data for more advanced analysis, including detecting anomalous wireless access points with poor signal-to-noise ratios and combining multiple measurements for compliance reporting.

Automation reduces the operational burden further. Red Hat uses Ansible to manage network devices and configure components of the monitoring environment, reducing manual intervention and allowing engineers to spend more time on network issues rather than managing the monitoring infrastructure itself.

What’s next

Expanding modern telemetry and network automation

At the time of the case study, Red Hat was continuing to expand its use of gNMI as more devices and metrics gained support for the protocol. Some telemetry, including BGP neighbor status, was still collected through SNMP while the team worked toward broader gNMI coverage.

As that transition continued, Red Hat could bring more high-resolution telemetry into the same monitoring environment while building on its existing connection between network visibility and Ansible-driven automation.