如何使用InfluxDB和Kafka现代化WOW!的遗留基础设施监控

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

WOW!（宽泛的开放式西部）在美国多个市场的住宅、商业和批发客户超过50万，是美国最大的宽带提供商之一。他们旨在通过快速可靠的网络、电视和电话服务将家庭和企业连接到世界各地。

WOW!的挑战

作为一个数据驱动的组织，WOW!的支持团队希望通过使用网络节点（设备）的数据来检测网络故障，而不是客户的电话。但是，WOW!的支持工程团队面临来自他们分布式现场设备的多样性带来的挑战。WOW!的网络包括棕色现场建设和绿色现场建设，分别是电缆和光纤或全光纤网络。WOW!的节点（调制解调器和其它DOCSIS设备）是由不同厂商制造的不同型号，并带有自己的规格。对于WOW!来说，因为WOW!在美国各地都有网络，并监控超过80万台调制解调器，所以将每个网络都改为绿色现场建设并购买统一的技术成本过高。监测如此大量的不同技术让WOW!的工程团队陷入了分裂的遗留可观察性解决方案。

WOW！的遗产监控平台提供了对基础设施的洞察，但由于数据收集、监控限制和技术要求多样化且厂商锁定，导致不同网络和节点组有各自独立的平台和仪表板。缺乏集中式可观测平台意味着WOW！工程师无法在一个地方分析所有节点和网络。除了WOW！零散的仪表板和平台带来的复杂性外，WOW！的工程团队使用的时序数据库经常出现故障。

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

解决方案

时序基准测试让WOW！的工程师了解了InfluxDB卓越的写入速度。当WOW！的工程师决定现代化其遗留系统时，他们选择了InfluxDB企业版（现作为InfluxDB集群版）作为时序数据库的后端。InfluxDB为WOW！的工程师提供了其他厂商或监控解决方案无法提供的功能——灵活性，以绕过所有限制来创建一个单一的监控平台。

架构

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

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

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

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