Prometheus logo

Prometheus

文档下载社区支持与培训博客

Ctrl + K

GitHub Logo

监控 DreamHack - 全球最大的数字节

2015年6月24日作者 Christian Svensson (DreamHack 网络团队)

编者注：本文是一位 Prometheus 用户撰写的客座文章。

如果您正在为一个拥有数万名要求苛刻的游戏玩家的网络提供运营服务，那么您需要真正了解网络内部正在发生的一切。哦，所有东西都必须在短短五天内从零开始构建。

如果您从未听说过 DreamHack，那么这里是它的简介：召集20,000人，其中大部分人会带着自己的电脑。融合专业的游戏比赛（电子竞技）、编程竞赛和现场音乐会。结果就是全球最大的专门致力于一切数字化的节庆活动。

为了使这样的活动成为可能，需要大量的基础设施到位。通常，这种规模的基础设施需要数月才能建成，但 DreamHack 的工作人员在短短五天内从零开始构建一切。这当然包括配置网络交换机等工作，但也包括构建电力分配系统、设立餐饮商店，甚至建造实际的桌子。

负责构建和运营与网络相关的一切的团队官方名称是网络团队，但我们通常称自己为 tech 或 dhtech。本文将重点介绍 dhtech 的工作，以及我们在 2015 年 DreamHack 夏季赛期间如何使用 Prometheus 来尝试将我们的监控水平提升到一个新的高度。

设备

事实证明，要为 10,000 多台计算机构建一个高性能网络，您至少需要相同数量的网络端口。在我们的案例中，这些以大约 400 台 Cisco 2950 交换机的形式出现。我们称之为接入交换机。这些交换机遍布场馆内参与者将坐着使用电脑的每个地方。

Access switches

*接入交换机尽职地排队等候，随时准备以高速连接迎接 DreamHack 参与者。*

显然，仅仅将所有这些计算机连接到一台交换机是不够的。该交换机还需要连接到其他交换机。这就是分布式交换机（或称分发交换机）发挥作用的地方。这些交换机将所有接入交换机数百个链路汇聚成更易管理的 10-Gbit/s 高容量光纤。然后，这些分发交换机进一步汇聚到我们的核心层，流量在那里被路由到其目的地。

除此之外，我们还运营自己的 WiFi 网络、DNS/DHCP 服务器以及其他基础设施。完成后，我们的核心层看起来就像下图所示。

Network planning map

*分发和核心层的规划图。核心层在“D厅”清晰可见*

总而言之，这是一长串需要监控的东西，所以让我们回到您在此的原因：我们如何确保我们了解正在发生的一切？

隆重推出：dhmon

dhmon 是一个系统集合的统称，它不仅监控网络，还允许其他团队收集他们想要的任何指标。

由于网络需要在五天内建成，因此监控系统必须易于设置，并且在我们需要进行最后一刻的基础设施变更（例如添加或移除设备）时保持同步。当我们开始构建网络时，我们需要尽快进行监控，以便能够发现设备问题或我们未曾预料到的其他问题。

过去，我们曾尝试使用各种常用软件，例如 Cacti、SNMPc 和 Opsview 等。虽然它们都起作用了，但它们主要侧重于封闭系统，并且只提供最基本的功能。几年前，团队中的几个人说“够了，我们可以做得更好！”，并开始编写一个自定义监控解决方案。

当时的选择有限。多年来，该系统从使用 Graphite（可伸缩性问题）、自定义 Cassandra 存储（高复杂性）和 InfluxDB（不成熟的软件），最终转向使用 Prometheus。我第一次听说 Prometheus 是在 2014 年，当时我遇到了 Julius Volz，从那时起我就一直渴望尝试它。今年夏天，我们最终用 Prometheus 替换了我们自己编写的基于 InfluxDB 的自定义指标存储。剧透：我们不会再回去了。

架构

监控解决方案由三层组成：收集、存储、展示。我们最关键的收集器是 snmpcollector (SNMP) 和 ipplan-pinger (ICMP)，紧随其后的是 dhcpinfo (DHCP 租约统计)。我们还有一些脚本将其他系统的统计数据导入 node_exporter 的 textfile collector。

dhmon Architecture

*截至 2015 年夏季 dhmon 的当前架构计划*

我们使用 Prometheus 作为中央时间序列存储和查询引擎，但我们也使用 Redis 和 memcached 来导出我们收集的二进制信息的快照视图，这些信息无法以任何合理的方式存储在 Prometheus 中，或者在我们需要访问非常新的数据时使用。

一个这样的例子是在我们的展示层。我们使用 dhmap Web 应用程序来获取接入交换机的整体健康状况概览。为了有效地解决错误，我们需要从数据收集到展示的延迟约为 10 秒。我们的目标是在客户注意到问题之前解决问题，或者至少在他们走到支持人员那里报告问题之前解决。因此，我们从一开始就使用 memcached 来访问网络的最新快照。

今年我们继续使用 memcached 来处理低延迟数据，同时使用 Prometheus 来处理所有历史数据或对延迟不敏感的数据。做出这个决定仅仅是因为我们不确定 Prometheus 在非常短的采样间隔下会如何表现。最终，我们发现没有理由不能将 Prometheus 用于这些数据——在下一次 DreamHack 活动中，我们肯定会尝试用 Prometheus 替换我们的 memcached。

dhmon Visualization

*dhmon 可视化的接入层概览*

Prometheus 设置

到目前为止被称作 Prometheus 的模块实际上由三个产品组成：Prometheus、PromDash 和 Alertmanager。该设置相当基础，所有三个组件都在同一个主机上运行。所有服务都由一个充当反向代理的 Apache Web 服务器提供。

ProxyPass /prometheus https://:9090/prometheus
ProxyPass /alertmanager https://:9093/alertmanager
ProxyPass /dash https://:3000/dash

探索网络

Prometheus 拥有强大的查询引擎，您可以使用从网络各处收集的流式信息做一些非常酷的事情。然而，有时查询需要处理过多的数据，无法在合理的时间内完成。当我们想要绘制总共约 18,000 个链路中利用率最高的 5 个链路图时就发生了这种情况。虽然查询有效，但它会花费我们设置的超时限制大致相同的时间，这意味着它既慢又不稳定。我们决定使用 Prometheus 的记录规则来预计算耗时查询。

precomputed_link_utilization_percent = rate(ifHCOutOctets{layer!='access'}[10m])*8/1000/1000
                                         / on (device,interface,alias)
                                       ifHighSpeed{layer!='access'}

在此之后，运行 topk(5, precomputed_link_utilization_percent) 变得飞快。

被动响应：告警

所以在这个阶段，我们有了一个可以查询网络状态的系统。既然我们是人类，我们不想一直花时间运行查询来查看系统是否正常运行，所以显然我们需要告警功能。

例如：我们知道我们所有的接入交换机都使用 GigabitEthernet0/2 作为上行链路。有时，当网线存放时间过长时，它们会氧化，无法协商到我们想要的完整 1000 Mbps 速率。

网络端口的协商速度可以在 SNMP OID IF-MIB::ifHighSpeed 中找到。然而，熟悉 SNMP 的人会认识到这个 OID 是通过一个任意接口索引进行索引的。为了理解这个索引，我们需要将其与 SNMP OID IF-MIB::ifDescr 中的数据进行交叉引用，以检索实际的接口名称。

幸运的是，我们的 snmpcollector 在生成 Prometheus 指标时支持这种交叉引用。这使我们能够以简单的方式不仅查询数据，还能定义有用的告警。在我们的设置中，我们将 SNMP 收集配置为使用 ifDescr 注释 IF-MIB::ifTable 和 IF-MIB::ifXTable OID 下的任何指标。这在我们现在需要指定只关心 GigabitEthernet0/2 端口而不是其他接口时会派上用场。

让我们看看这样的告警定义是什么样子的。

ALERT BadUplinkOnAccessSwitch
  IF ifHighSpeed{layer='access', interface='GigabitEthernet0/2'} < 1000 FOR 2m
  SUMMARY "Interface linking at {{$value}} Mbps"
  DESCRIPTION "Interface {{$labels.interface}} on {{$labels.device}} linking at {{$value}} Mbps"

完成！现在，如果交换机的上行链路突然以非最佳速度链接，我们将收到告警。

我们再看看 DHCP 范围快满时的告警是怎样的

ALERT DhcpScopeAlmostFull
  IF ceil((dhcp_leases_current_count / dhcp_leases_max_count)*100) > 90 FOR 2m
  SUMMARY "DHCP scope {{$labels.network}} is almost full"
  DESCRIPTION "DHCP scope {{$labels.network}} is {{$value}}% full"

我们发现定义告警的语法非常易读易懂，即使您之前没有使用 Prometheus 或时间序列数据库的经验。

Prometheus alerts for DreamHack

*糟糕！原来我们有一些不好的上行链路，最好赶紧去修复它！*

主动预防：仪表盘

虽然告警是监控的重要组成部分，但有时您只是想对网络的健康状况有一个良好的概览。为了实现这一点，我们使用了 PromDash。每当有人向我们询问有关网络的问题时，我们就会编写一个查询来获取答案，并将其保存为仪表盘小部件。然后，最有趣的那些被添加到我们自豪地展示的概览仪表盘中。

dhmon Dashboard

*由 PromDash 提供支持的 DreamHack 概览仪表盘*

未来展望

尽管改变任何系统的组成部分都是一项复杂的工作，但我们很高兴能在一个活动中就成功地集成了 Prometheus，毫无疑问，仍有许多方面需要改进。一些方面是相当基础的：使用更多预计算指标来提高性能，添加更多告警，并调整现有告警。另一个方面是让操作人员更轻松：创建一个适合我们网络运营中心 (NOC) 的告警仪表盘，确定我们是否需要呼叫值班人员，或者仅仅让 NOC 升级告警。

我们计划添加一些更大的功能：syslog 分析（我们有很多 syslog！）、来自我们入侵检测系统的告警、与我们的 Puppet 设置集成，以及在 DreamHack 的不同团队之间进行更多集成。我们成功创建了一个概念验证，将来自一个电流传感器的数据导入我们的监控系统，从而轻松查看设备是否故障或是否干脆没有电了。我们还在努力与活动中商店使用的销售点系统（POS 系统）集成。谁不想绘制冰淇淋的销售图表呢？

最后，并非所有团队运营的服务都在现场，有些甚至在活动结束后 24/7 全天候运行。我们也希望用 Prometheus 监控这些服务，并且从长远来看，当 Prometheus 获得联邦支持时，利用异地 Prometheus 来复制活动 Prometheus 的指标。

结语

我们对 Prometheus 及其从零开始设置可扩展监控和告警的简易性感到非常兴奋。

非常感谢活动期间在 FreeNode 上 #prometheus 频道帮助过我们的所有人。特别感谢 Brian Brazil、Fabian Reinartz 和 Julius Volz。感谢你们的帮助，即使在我们明显没有彻底阅读文档的情况下也是如此。

最后，dhmon 是完全开源的，如果您感兴趣，请访问 https://github.com/dhtech/ 查看。如果您觉得自己想成为其中的一员，只需访问 QuakeNet 上的 #dreamhack 频道与我们聊聊。谁知道呢，也许您会帮助我们构建下一个 DreamHack？