JANOG57 NOC サーバー構成紹介（メトリクス監視・ログ収集編）

JANOG57 NOC サーバー構成紹介（DNS・DHCP編） - crashRT のブログに続くJANOG57 NOCのサーバー構成紹介第2弾です。今回はメトリクス監視・ログ収集基盤について紹介します。

監視基盤

監視基盤はネットワークの状態を把握する上で欠かせません。また、今回のNOCではネットワークの利用状況を公開したいという思いもあったため、その点でも重要な要素でした。

今回、監視項目の検討は監視対象を構築したチームそれぞれに依頼しました。そしてSVのメトリクス班にはそれらを監視するための基盤の構築とアラート周りの調整をしてもらいました。構成や設定の詳細についてはメトリクス班のメンバーでブログを書いてくれるとのことなので、公開されたらそちらもぜひ見ていただければと思います。

メトリクス監視基盤の構成

監視基盤の主な構成は下図のとおりです。 ZabbixはアプライアンスとZabbix Proxyを提供していただきました。

ルーターやスイッチの監視はZabbixとPrometheusのハイブリッド構成で構築しました。ベースとなる部分はZabbixのtemplateを活用して設定しました。templateには一通り必要な監視項目が揃っているため、ゼロから書き下ろす場合に比べ設定漏れのリスクを抑えつつBBが求める項目を迅速に設定できました。加えて、細かい部分はPrometheus系を用いて対応しました。 PoE系など標準テンプレートにはないMIBの情報の取得はsnmp_exporterにMIBを追加することで、 SNMPで取得できない値はBBチームのスクリプトでPushgatewayに投げてもらうことで収集しました。ダッシュボードはGrafanaで作成しています。

提供していただいたZabbix Proxyは各会場のゲスト用セグメントに設置し、ユーザー環境からのテストに活用していました。 SNMPなどによる監視はあくまでトラブルの原因となる要素を個別に監視しているだけなので、全体として正しく動いているかのテストはまた別になります。そこで、3台提供していただいたZabbix Proxyを各会場のゲスト用セグメントに設置し、テスト用プローブとして必要なところへのPING監視などをしていました。しかし、前回の記事で触れたDNSまわりのACLミスはPING監視だけでは検知できなかったので、各サーバーへのDNSの監視なども設定しておけばより良い監視システムを構築できたなと反省しています。ユーザー側からの観測からネットワークの状態を評価する手法についてはSINDAN Projectで研究されているため、監視項目はこれを参考にすれば良かったのかもしれないですね。

APやDNS・DHCP等のメトリクスはそれぞれのエンドポイントからPrometheusでメトリクス収集し、Grafanaでダッシュボード作成・アラート発報をしています。全体の死活監視もblackbox_exporterを用いて行っています。 APについてはPrometheus向けのエンドポイントがなかったため、Mist APIから必要なメトリクスを取得しPrometheusに開示するexporterをAPチームに作ってもらいました。

Prometheusで収集したメトリクスはVictoriaMetricsとモニタリングスイートのメトリクスストレージにremote_writeすることで保存・バックアップしています。 VictoriaMetrics に保存したメトリクスデータは今後ダッシュボードと共に公開される予定です。

BB（バックボーン）チームのメンバーによってshumokuを用いたダッシュボードも構築されました。 NetBoxから情報を取得してトポロジとして表示し、さらにトラフィック情報などもトポロジ図の上で表示してくれるツールです。構成変更時にトポロジ図を手で修正せずともNetBoxの更新のみで反映されたため非常に便利でした。

メトリクスだけでは見えないトラフィックの詳細を追うため、Akvorado を用いたフロー監視も導入しました。コアスイッチから送出してもらったsFlowを収集し、宛先ASごとのトラフィック量の可視化などに活用しました。

以上のように様々なコンポーネントを構築してネットワーク全体の情報を収集・可視化していました。さらに、今回はトラフィック品質分析のためのActiveLogicとネットワーク可視化のためのThousand Eyesも提供していただいています。これらはスポンサー様に構築までしていただいたので構成については今回はあまり触れませんが、収集できた情報と得られた知見については別のどこかで紹介できたらと思います。

Prometheus 監視対象の自動設定

監視対象となるルーター・スイッチ・AP・サーバー群は全部合わせるとかなりの数になります。短期間で設計・構築が進むNOCでは構成変更や機器の追加が頻繁に発生するため、手で監視対象を管理し整合性を保ち続けるのは現実的ではありません。そこで、この問題をNetBoxの情報とAnsibleのInventoryの情報から監視対象を設定する仕組みを構築することで解決しました。

ベースとしているのはPrometheusのService Discovery機能です。 JSONまたはYAMLで監視対象を列挙したtargetファイルを作成し、Prometheus側で file_sd_configs として指定すると監視対象として設定されます。 targetファイルを変更すればPrometheusが検知して反映してくれるので、あとはいい感じに監視対象の情報を取得してtargetファイルに書き込めばOKです。 targetファイルに監視対象の設定を切り出すことで prometheus.yml の肥大化を防ぐことができるのも嬉しいポイントです。

ネットワーク機器：NetBox による Service Discovery

ルーターやAPが主な対象であるPING監視とSNMP監視の対象はNetBoxの情報を活用しました。 NetBoxを活用すること自体は良いものの、以下のような要件があり単純な話ではありませんでした。

NetBoxには検証用の機器など監視対象から省きたいものも含めて登録されている
APはPING監視のみ、ルーター・スイッチはPING監視もSNMP監視もしたいというように、PING監視したい機器とSNMP監視したい機器は一致しない
（他チームもNetBoxを中心に設計・構築が進んでいたため、可能であればNetBox自体にはあまり手を付けずに構築できると嬉しい）

Pluginを導入すればできるのだろうか？でも機能が足りないのではないか？という話をしていたらメンバーがいい感じのソフトウェアを書いてくれたので全てが解決しました。このソフトウェアはNetBoxのAPIから ping監視 snmp監視 というタグの付いたデバイス/IPアドレスを取得し、PrometheusのService Discovery形式のファイルに変換してくれるものです。単にIPアドレスが対象として追加されるだけでなく、IPアドレスがデバイスと紐づいていれば instance ラベルにデバイス名を設定してくれます。定期的にファイルを更新してくれるため、NetBoxでタグを付けるだけでPING/SNMP監視対象の追加が完了する仕組みが完成しました。このソフトウェアは以下のリポジトリで公開しています。READMEなども整えてもらったので詳細はこちらを確認していただければと思います。

GitHub - janog57-noc/python-netbox-sd: netboxから特定タグを持つデバイスをPrometheusのService Discoveryで動的にターゲットとして追加 · GitHub

サーバー：Ansible Inventory をもとにした監視対象の列挙

サーバー群は全てAnsibleで構築していたので、サーバーに構築するシステムの監視はAnsibleのInventory情報をソースとしてtargetファイルを生成しています。例えばDNSの監視対象にはAnsible Inventoryで dns グループに所属するサーバーを設定する、という感じです。これにより、サーバーの追加やアドレス変更があった場合も設定ファイルは変更することなく、metricsサーバーにAnsibleを流し込むだけで反映できるようになりました。

アラートの整形

監視基盤を構築する上で、GrafanaおよびZabbixからSlackに送信するアラートはかなり見やすく整形してもらいました。特にGrafanaの場合はデフォルトのままではどの機器で何が起きているかが直感的ではなかったのですが、メンバーのこだわりによってとても見やすくなりました。こだわりの中身はきっとメンバーが書いてくれるはず。

descriptionでアラート発報の原因となった値も表示してくれています。metricsサーバーのリソースは思っていたよりギリギリでした

また、MistからWebhookで通知を受信し整形してSlackに送信する Mist Webhook がBBチームによって作成されました。以下のリポジトリで公開されています。

GitHub - janog57-noc/mist-webhook · GitHub

ログ収集基盤

ログ情報はトラシューでは欠かせない重要な要素であり、一箇所で横断的に検索できると原因の調査がスムーズになります。さらに今回はeduroamとOpenRoamingの提供のため、一定期間通信ログを保存する必要がありました。これらを実現したログ収集基盤について紹介します。構築における技術的な詳細については担当してくれたメンバーが全てを書いてくれたので、ぜひそちらも読んでいただければと思います。

d.taiseiue.jp

ログ収集基盤の構成

ログ収集基盤は下図のとおり Grafana Alloy + Loki を中心とした構成です。

元々Grafanaスタックでログ収集したいねという話をしており、当初はPromtailの採用を検討していました。しかし調べてみると、PromtailがDEPRECATEDになっていることが判明しました*1。

後継のGrafana Alloyに挑戦するか、あるいはよく使われるfluentbitなど他のものを使うか悩みましたが、担当メンバーがこの分野の経験者であり、かつ挑戦してみたいとのことだったので、じゃあよろしく！、とGrafana Alloyを採用することにしました。結果として当初の思いどおりGrafanaスタックでのログ収集構成を実現することができました。

構築時には様々な形式のsyslogが送られてきてうまく受け取れないなどのトラブルもありましたが、rsyslogでうまく変換することで無事解決してくれました。

DNSやDHCPのログは各ソフトウェアがsyslogで出力したログを各サーバーのrsyslogで受け取り、Grafana Alloyに送信する形としています。

Grafana Alloyでログを集約した後はLoki, Splunk, モニタリングスイートに配送しています。 LokiはGrafanaでの可視化およびアラート発報のため、モニタリングスイートは後述するログ保存のため、Splunkはログ分析のために用いています。

ログの保存

今回のNOCでは cityroam からtelhiさんの協力のもとeduroamおよびOpenRoamingを提供しています。これらを提供するための要件として、利用者の通信ログを一定期間確実に保存する必要がありました。しかし、膨大なログデータを自分たちで構築したサーバー内だけで安全に保管し続けるのは簡単ではありません。ちょうど良いことに、さくらのクラウドのモニタリングスイートにログストレージという機能があったので、これを活用することでさくらさんにいい感じにデータ保存をしてもらうことにしました。困ったら中の人に聞けるということもあり安心感を持って使うことができました（実際に色々助けていただきました。ありがとうございました）。

ログストレージへの送信は、対応ソフトウェアとして挙げられているのはfluentbitなのですが*2、OpenTelemetry Protocol (OTLP/HTTP)で投げれば良い*3ならGrafana Alloyでもできるだろう*4ということで、Grafana Alloyからログストレージに投げる構成としました。検証の結果、無事 Grafana Alloy から OTLP/HTTP でログストレージに送信することができました。ログストレージへの書き込みにはレート制限があるので、各チームに不要なログは送らないようにしてもらいつつ、バースト時に備えGrafana Alloy側で一度キューにログを保存した後バッチ送信することで対応してもらいました。

最後に

JANOG57 NOCで構築した監視基盤・ログ収集基盤の構成について紹介しました。 NOCのネットワークについての情報を隅々まで取得するようなリッチな基盤になりました。監視システムのおかげで気づけた事象やトラブルもあり、ネットワークを守ることに役立てたのではないかと思います。

NOCチームで構築したものに加えスポンサー様にも色々なシステムを提供していただいたため、JANOGのネットワークについてのデータをかなり収集できたのではないかと思います。協力してくれたメンバー、そして強力なツールを提供してくださったスポンサーの皆様、ありがとうございました！収集したデータは整理した後公開する予定なので、ぜひそちらも見ていただければと思います。

DNS・DHCPの構成は以下の記事で紹介しています。

JANOG57 NOC サーバー構成紹介（DNS・DHCP編） - crashRT のブログ

その他NOCについての公開情報は以下のNOC公式ページにまとまっています。

JANOG57 NOC 公式ページ

*1: