世界最大のデジタルフェスティバル、DreamHackのモニタリング

編集者注: この記事は、Prometheusユーザーによって書かれたゲスト投稿です。

何万人もの要求の厳しいゲーマー向けのネットワークを運用する場合、ネットワーク内部で何が起こっているかを本当に知る必要があります。しかも、すべてをわずか5日間でゼロから構築する必要があります。

DreamHack について聞いたことがない方のために、簡単に説明すると、2万人を集めて、その大半に自分のコンピューターを持参してもらいます。プロのゲーム(eスポーツ)、プログラミングコンテスト、ライブミュージックコンサートを組み合わせます。その結果が、デジタルのすべてに特化した世界最大のフェスティバルです。

このようなイベントを可能にするには、多くのインフラストラクチャが必要です。この規模の通常のインフラストラクチャの構築には数か月かかりますが、DreamHackのクルーはわずか5日間でゼロからすべてを構築します。これには、ネットワークスイッチの設定はもちろん、配電の構築、飲食店の設置、さらには実際のテーブルの構築なども含まれます。

ネットワークに関連するすべてのものを構築および運用するチームは、正式にはネットワークチームと呼ばれていますが、通常は自分たちを *tech* または *dhtech* と呼んでいます。この記事では、dhtechの仕事と、DreamHack Summer 2015でPrometheusを使用してモニタリングをさらに強化しようとした方法に焦点を当てます。

機器

1万人以上のコンピューター向けの高性能ネットワークを構築するには、少なくとも同数のネットワークポートが必要であることがわかりました。私たちの場合、これらは約400台のCisco 2950スイッチという形で提供されます。これらをアクセススイッチと呼びます。これらは、参加者がコンピューターと一緒に座る会場の至る所にあります。

Access switches

きちんと並んで、アクセススイッチはDreamHackersを高速接続で迎える準備ができています。

明らかに、これらすべてのコンピューターをスイッチに接続するだけでは不十分です。そのスイッチは、他のスイッチにも接続する必要があります。ここで、ディストリビューションスイッチ(またはdistスイッチ)が登場します。これらは、すべてのアクセススイッチからの数百のリンクを取得し、それらをより管理しやすい10ギガビット/秒の高速ファイバーに集約するスイッチです。distスイッチはさらにコアに集約され、そこでトラフィックが宛先にルーティングされます。

これらすべてに加えて、独自のWiFiネットワーク、DNS / DHCPサーバー、およびその他のインフラストラクチャを運用しています。完成すると、私たちのコアは以下の画像のようになります。

Network planning map

ディストリビューション層とコア層の計画図。コアは「ホールD」で明確に見えます

全体として、これはモニタリングするものが長くなるので、本題に入りましょう。どのようにして何が起こっているかを確認するのでしょうか?

dhmonの紹介

dhmonは、ネットワークを監視するだけでなく、他のチームが好きなようにメトリックを収集できるようにするシステムの総称です。

ネットワークは5日間で構築する必要があるため、モニタリングシステムはセットアップが簡単で、土壇場でのインフラストラクチャの変更(デバイスの追加や削除など)が必要な場合に同期を維持できることが不可欠です。ネットワークの構築を開始するときは、機器の問題や予期していなかったその他の問題を早期に発見できるように、できるだけ早くモニタリングする必要があります。

過去には、Cacti、SNMPc、Opsviewなど、一般的に利用可能なソフトウェアを組み合わせて使用しようとしました。これらは機能していましたが、閉鎖系であることに重点を置いており、必要最小限のことしか提供していませんでした。数年前、チームの数人が「もうたくさんだ、自分たちでより良いことができる!」と言い、カスタムモニタリングソリューションの開発を始めました。

当時は選択肢が限られていました。長年にわたり、システムはGraphite(スケーラビリティの問題)、カスタムCassandraストア(高複雑度)、InfluxDB(未成熟なソフトウェア)を使用するようになり、最終的にPrometheusを使用するようになりました。私は2014年にJulius Volzに会ったときにPrometheusについて初めて知り、それ以来ずっと試してみたいと思っていました。この夏、ついにPrometheusを使用して、私たちが書いていたカスタムのInfluxDBベースのメトリックストアを置き換えました。ネタバレ:私たちは戻りません。

アーキテクチャ

モニタリングソリューションは、収集、保存、提示の3つの層で構成されています。最も重要なコレクターはsnmpcollector(SNMP)とipplan-pinger(ICMP)で、dhcpinfo(DHCPリース統計)がそれに続きます。また、他のシステムに関する統計をnode_exporterのテキストファイルコレクターにダンプするスクリプトもいくつかあります。

dhmon Architecture

2015年夏の時点でのdhmonの現在のアーキテクチャ計画

Prometheusを中央の時系列ストレージおよびクエリエンジンとして使用していますが、収集したバイナリ情報の Prometheus に格納できない、または非常に新しいデータにアクセスする必要がある場合に、スナップショットビューをエクスポートするためにRedisとmemcachedも使用しています。

そのようなケースの1つは、プレゼンテーション層にあります。 dhmap Webアプリケーションを使用して、アクセススイッチの全体的な状態の概要を取得します。エラーを効果的に解決するには、データ収集からプレゼンテーションまでのレイテンシが約10秒である必要があります。私たちの目標は、顧客が気づかないうちに、または少なくとも顧客がサポート担当者に問題を報告するために歩き回る前に、問題を解決することです。このため、ネットワークの最新のスナップショットにアクセスするために、最初からmemcachedを使用しています。

今年も低レイテンシデータにはmemcachedを使用し続け、履歴データやレイテンシの影響を受けにくいデータにはPrometheusを使用しました。この決定は、Prometheusが非常に短いサンプリング間隔でどのように機能するかわからなかったために行われました。結局、このデータにもPrometheusを使用できない理由は見つかりませんでした。次のDreamHackでは、memcachedをPrometheusに置き換えることを definitely 試みます。

dhmon Visualization

dhmonによって視覚化されたアクセス層の概要

Prometheusのセットアップ

これまでは* Prometheus *と呼ばれていたブロックは、実際には3つの製品で構成されています。PrometheusPromDash、およびAlertmanagerです。セットアップはかなり基本的なもので、3つのコンポーネントすべてが同じホストで実行されています。すべては、リバースプロキシとして機能する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のレコーディングルールを使用することにしました。

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メトリックを生成するときに、この種の相互参照をサポートしています。これにより、データを照会するだけでなく、有用なアラートを定義することもできます。セットアップでは、 `IF-MIB :: ifTable`および` IF-MIB :: ifXTable` OIDの下にあるメトリックに` ifDescr`で注釈を付けるようにSNMPコレクションを構成しました。`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概要ダッシュボード

未来

システムの不可欠な部分を変えることは複雑な作業であり、わずか1つのイベントでPrometheusを統合できたことを嬉しく思いますが、間違いなく改善すべき領域がたくさんあります。一部の領域はかなり基本的です。事前計算されたメトリックを davantage 使用してパフォーマンスを向上させ、アラートを追加し、既存のアラートを調整します。もう1つの領域は、オペレーターにとって使いやすいものにすることです。ネットワークオペレーションセンター(NOC)に適したアラートダッシュボードを作成し、オンコールの担当者にページを送信するか、NOCにアラートをエスカレーションさせるかを判断します。

追加を計画している大きな機能は次のとおりです。syslog分析(syslogがたくさんあります!)、侵入検知システムからのアラート、Puppetセットアップとの統合、およびDreamHackのさまざまなチーム間の統合です。電気電流センサーの1つからデータをモニタリングに取り込む概念実証を作成することができました。これにより、デバイスに障害が発生しているのか、単に電気がなくなっているのかを簡単に確認できます。また、イベントの店舗で使用されているPOSシステムとの統合にも取り組んでいます。アイスクリームの売上をグラフ化したい人はいませんか?

最後に、チームが運用するすべてのサービスがオンサイトであるとは限らず、イベント後も24時間365日稼働するものもあります。これらのサービスもPrometheusで監視し、Prometheusがフェデレーションをサポートするようになったら、長期的にはオフサイトPrometheusを利用してイベントPrometheusからメトリックを複製したいと考えています。

結びの言葉

私たちはPrometheusと、それがいかに簡単にスケーラブルなモニタリングとアラートをゼロからセットアップできるかについて、本当に興奮しています。

イベント期間中、FreeNodeの#prometheusチャンネルで私たちを支援してくださった皆様に心より感謝申し上げます。Brian Brazil氏、Fabian Reinartz氏、Julius Volz氏には特に感謝いたします。ドキュメントをよく読んでいなかったことが明らかな場合でも、助けていただきありがとうございました。

最後に、dhmonはすべてオープンソースです。興味のある方は、https://github.com/dhtech/ をご覧ください。参加にご興味のある方は、QuakeNet#dreamhack チャンネルで私たちにご連絡ください。もしかしたら、あなたが次のDreamHackの構築を手伝ってくれるかもしれません。