编者注：本文是由 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 的 textfile 收集器中。
我们使用 Prometheus 作为中央时间序列存储和查询引擎，但我们也使用 Redis 和 memcached 来导出我们收集但无法以任何合理方式存储在 Prometheus 中的二进制信息的快照视图，或者当我们需要访问非常新的数据时。
一个这样的例子是在我们的展示层中。我们使用我们的 dhmap Web 应用程序来获取接入交换机整体健康状况的概览。为了有效地解决错误，我们需要从数据收集到展示的延迟约为 10 秒。我们的目标是在客户注意到问题之前，或者至少在他们走到支持人员报告问题之前就解决问题。出于这个原因，自始至终我们一直使用 memcached 来访问网络的最新快照。
今年我们继续将 memcached 用于我们的低延迟数据，同时将 Prometheus 用于所有历史数据或对延迟不敏感的数据。做出这个决定仅仅是因为我们不确定 Prometheus 在非常短的采样间隔下会表现如何。最终，我们没有找到任何理由说明我们不能将 Prometheus 也用于这些数据 - 我们肯定会在下一次 DreamHack 上尝试用 Prometheus 替换我们的 memcached。
Prometheus 设置
到目前为止被称为 Prometheus 的模块实际上由三个产品组成：Prometheus、PromDash 和 Alertmanager。设置非常基本，所有三个组件都在同一主机上运行。一切都由 Apache Web 服务器提供服务，该服务器仅充当反向代理。
ProxyPass /prometheus http://localhost:9090/prometheus
ProxyPass /alertmanager http://localhost:9093/alertmanager
ProxyPass /dash http://localhost:3000/dash
探索网络
Prometheus 具有强大的查询引擎，可让您使用从网络各处收集的流式信息执行非常酷的操作。但是，有时查询需要处理太多数据才能在合理的时间内完成。当我们想要绘制总共约 18,000 个链接中利用率最高的 5 个链接的图表时，这种情况发生在我们身上。虽然查询有效，但它会花费大约我们设置的超时限制的时间，这意味着它既慢又不稳定。我们决定使用 Prometheus 的 recording rules 来预计算繁重的查询。
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？