WOW! 如何通过 InfluxDB 和 Kafka 实现传统基础设施监控的现代化

作者：Jessica Wachtel / 用例
2023年11月01日

WideOpenWest (WOW!) 是美国最大的宽带提供商之一，在美国多个市场拥有超过 50 万住宅、商业和批发客户。他们的目标是通过快速可靠的互联网、电视和电话服务将家庭和企业与世界连接起来。

WOW! 的挑战

作为一个数据驱动型组织，WOW! 的支持团队希望使用来自网络节点（设备）的数据，而不是客户电话来检测网络中断。但 WOW! 的支持工程团队面临着来自其分布式现场设备多样性的挑战。WOW! 的网络由棕地和绿地建设组成，分别是电缆和光纤网络或全光纤网络。WOW! 的节点（调制解调器和其他 DOCSIS 设备）是不同型号，由不同供应商创建，并附带各自的规格。对于 WOW! 来说，将每个网络都建成绿地并购买统一技术在成本上是不可行的，因为 WOW! 在美国各地都有网络，并监控着超过 80 万个调制解调器。监控如此大量的不同技术使 WOW! 的工程团队受限于一个分散的传统可观测性解决方案。

WOW! 的传统监控平台提供了对其基础设施的洞察力，但多样化的供应商锁定数据收集、监控限制和技术要求导致不同组的网络和节点使用单独的平台和仪表板。缺乏集中式可观测性平台意味着 WOW! 工程师无法在一个地方分析其所有节点和网络。除了 WOW! 分散的仪表板和平台增加的复杂性之外，WOW! 的工程团队还使用了一个经常发生故障的时间序列数据库。

WOW! 的工程团队需要更好地了解每个节点及其网络的整体健康状况。工程师们假设，具有实时和历史分析查看功能的集中式数据存储将提供更高的节点和网络健康状况可见性。

解决方案

时间序列基准测试使 WOW! 工程师了解了 InfluxDB 出色的写入速度。当 WOW! 工程师决定对其传统系统进行现代化改造时，他们选择了 InfluxDB Enterprise（现在以 InfluxDB Clustered 的形式提供）作为时间序列数据库后端。InfluxDB 为 WOW! 工程师提供了一些其他供应商或监控解决方案无法提供的功能——绕过所有限制以创建一个单一监控平台的灵活性。

架构

WOW! 的监控平台由一个生产环境中的四节点 InfluxDB 集群和一个在 OpenStack 上运行的用于测试的双节点 InfluxDB 集群组成。WOW! 工程师使用 InfluxDB 从实时分析中获取洞察力，创建可视化效果，并触发警报和故障排除过程。WOW! 工程师利用 InfluxDB 的警报框架通过 Slack、电子邮件和 ServiceNow（他们的自动票务平台）发送警报。WOW! 工程师使用 Grafana 创建自定义仪表板。这包括用于实时分析和历史趋势分析的自定义仪表板。

工程师们构建了一个 Kafka 集群，并将其放置在数据源和 InfluxDB 之间。这提供了额外的数据流冗余和控制层。WOW! 工程师使用简单网络管理协议 (SNMP) 轮询和陷阱，以五分钟为周期从大约 65 万个有线调制解调器收集数据。WOW! 工程师使用 Telegraf 从他们的大多数虚拟机 (VM) 和容器中收集数据。现代化改造后，WOW! 工程师使用 Ansible 实施了基础设施即代码系统。工程师们现在使用 Ansible 来自动化集群设置和安装。

利用 Telegraf、InfluxDB 和 Grafana，也称为 TIG 堆栈，创建了 WOW! 设备和网络健康的完整视图。这带来了更高的功能和更低的停机时间。

要了解有关 WideOpenWest 的更多信息，请在此处阅读完整的案例研究。