编者注：本文是由 Prometheus 用户撰写的客座文章。
如果您为成千上万要求苛刻的游戏玩家运营网络，您需要真正了解网络内部的情况。哦，而且一切都需要在短短五天内从头开始构建。
如果您以前从未听说过 DreamHack，这里是介绍：将 20,000 人聚集在一起，让他们中的大多数人自带电脑。加入职业游戏（电子竞技）、编程竞赛和现场音乐会。结果就是这个世界上最大的专注于一切数字化的节日。
为了使这样一个活动成为可能，需要有大量的基础设施到位。这种规模的普通基础设施需要数月才能建成，但 DreamHack 的工作人员只需五天即可从头开始构建一切。这当然包括配置网络交换机等，还包括构建配电、设置食品和饮料商店，甚至构建实际的桌子。
构建和运营与网络相关的一切的团队正式称为网络团队，但我们通常称自己为tech或 dhtech。这篇文章将重点介绍 dhtech 的工作，以及我们在 2015 年夏季 DreamHack 期间如何使用 Prometheus 来尝试将我们的监控提升到另一个层次。
设备
事实证明，要为 10,000 多台计算机构建高性能网络，您至少需要相同数量的网络端口。在我们的例子中，这些端口以大约 400 个 Cisco 2950 交换机的形式出现。我们称这些为接入交换机。它们遍布参与者坐着使用电脑的场馆各处。
显然，仅仅将所有这些计算机连接到交换机是不够的。该交换机也需要连接到其他交换机。这就是分发交换机（或 dist 交换机）发挥作用的地方。这些交换机接收来自所有接入交换机的数百个链路，并将它们聚合为更易于管理的 10-Gbit/s 高容量光纤。然后，dist 交换机进一步聚合到我们的核心，流量将路由到其目的地。
最重要的是，我们运营自己的 WiFi 网络、DNS/DHCP 服务器和其他基础设施。完成后，我们的核心看起来像下图。
总而言之，这已成为一个需要监控的长长列表，所以让我们进入您来此的原因：我们如何确保我们知道发生了什么？
介绍：dhmon
dhmon 是系统的总称，这些系统不仅监控网络，还允许其他团队收集他们想要的任何指标。
由于网络需要在五天内构建完成，因此至关重要的是，监控系统易于设置，并且如果我们需要进行最后的结构性更改（例如添加或删除设备），则可以保持同步。当我们开始构建网络时，我们需要尽快进行监控，以便能够发现设备或我们没有预见到的其他问题。
过去，我们曾尝试使用混合的常用软件，如 Cacti、SNMPc 和 Opsview 等。虽然这些软件有效，但它们专注于成为封闭系统，并且只提供最基本的功能。几年前，团队中的一些人说“够了，我们可以做得更好！”，并开始编写自定义监控解决方案。
当时，选择有限。多年来，该系统从使用 Graphite（可扩展性问题）、自定义 Cassandra 存储（高复杂性）和 InfluxDB（不成熟的软件）发展到最终使用 Prometheus。我第一次了解 Prometheus 是在 2014 年我遇到 Julius Volz 时，从那时起我就渴望尝试它。今年夏天，我们最终用 Prometheus 取代了我们编写的基于 InfluxDB 的自定义指标存储。剧透：我们不会回头了。
架构
监控解决方案由三层组成：收集、存储和呈现。我们最重要的收集器是 snmpcollector (SNMP) 和 ipplan-pinger (ICMP)，紧随其后的是 dhcpinfo (DHCP 租约统计)。我们还有一些脚本将有关其他系统的统计信息转储到 node_exporter 的文本文件收集器中。
我们使用 Prometheus 作为中央时间序列存储和查询引擎，但我们也使用 Redis 和 memcached 来导出我们收集但无法以任何合理方式存储在 Prometheus 中的二进制信息的快照视图，或者当我们需要访问非常新的数据时。
其中一个案例是在我们的呈现层中。我们使用 dhmap Web 应用程序来概述接入交换机的整体运行状况。为了有效地解决错误，我们需要从数据收集到呈现的延迟约为 10 秒。我们的目标是在客户注意到问题之前，或者至少在他们走到支持人员报告问题之前解决问题。因此，我们从一开始就一直使用 memcached 来访问网络的最新快照。
今年，我们继续将 memcached 用于低延迟数据，同时将 Prometheus 用于所有历史或对延迟不敏感的数据。做出此决定仅仅是因为我们不确定 Prometheus 在非常短的采样间隔下会表现如何。最终，我们发现没有理由不将 Prometheus 也用于此数据 - 我们肯定会在下一个 DreamHack 中尝试用 Prometheus 替换我们的 memcached。
Prometheus 设置
到目前为止被称为Prometheus 的模块实际上由三个产品组成：Prometheus、PromDash 和 Alertmanager。设置相当基本，所有三个组件都在同一主机上运行。一切都由充当反向代理的 Apache Web 服务器提供。
ProxyPass /prometheus https://127.0.0.1:9090/prometheus
ProxyPass /alertmanager https://127.0.0.1:9093/alertmanager
ProxyPass /dash https://127.0.0.1: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 或时间序列数据库的经验也是如此。
保持积极：仪表板
虽然警报是监控的重要组成部分，但有时您只是想很好地了解网络的运行状况。为了实现这一点，我们使用了 PromDash。每次有人问我们关于网络的事情时，我们都会制作一个查询来获取答案，并将其保存为仪表板小部件。然后，最有趣的那些被添加到我们自豪地显示的概览仪表板中。
未来
虽然更改任何系统的组成部分都是一项复杂的工作，并且我们很高兴我们设法在一个活动中集成了 Prometheus，但毫无疑问，还有很多方面需要改进。一些领域相当基础：使用更多预先计算的指标来提高性能、添加更多警报以及调整我们拥有的警报。另一个领域是让操作员更容易：创建一个适合我们网络运营中心 (NOC) 的警报仪表板，弄清楚我们是否要呼叫值班人员，或者只是让 NOC 上报警报。
我们计划添加的一些更大的功能：syslog 分析（我们有很多 syslog！）、来自入侵检测系统的警报、与我们的 Puppet 设置集成以及在 DreamHack 的不同团队之间进行更多集成。我们设法创建了一个概念验证，其中我们从一个电流传感器获取数据到我们的监控中，从而可以轻松地查看设备是否有故障或者是否只是不再有电。我们还在努力与活动商店中使用的销售点系统集成。谁不想绘制冰淇淋的销售额？
最后，该团队运营的并非所有服务都在现场，有些服务甚至在活动结束后 24/7 全天候运行。我们希望也使用 Prometheus 监控这些服务，并且从长远来看，当 Prometheus 获得对联合的支持时，利用异地 Prometheus 复制来自活动 Prometheus 的指标。
结语
我们对 Prometheus 以及它如何轻松地从头开始设置可扩展的监控和警报感到非常兴奋。
在此次活动期间，非常感谢所有在 FreeNode 的 #prometheus 频道帮助过我们的人。特别感谢 Brian Brazil、Fabian Reinartz 和 Julius Volz。感谢你们在即使我们明显没有仔细阅读文档的情况下仍然帮助我们。
最后，dhmon 是完全开源的，如果您感兴趣，请访问 https://github.com/dhtech/ 查看。如果您想成为其中的一员，请前往 QuakeNet 的 #dreamhack 频道与我们聊天。谁知道呢，也许您会帮助我们构建下一个 DreamHack？