Jiří Hýbek
Jak jsem programoval monitoring páteřní sítě pro Cryonix

Jak jsem programoval monitoring páteřní sítě pro Cryonix

Popis architektury aplikace pro monitoring páteřní sítě Cryonix.

V rámci poskytování připojení k internetu v Písku jsme již delší dobu potřebovali mít přehledný monitoring páteřní sítě.

Naše páteřní síť je postavena na L2 vrstvě (switch) a využívá protokolu STP pro redundanci (záložní spoje).

Co jsme potřebovali monitorovat?

  • Zda jsou switche živé
  • Stav STP (otevřené / zavřené porty / smyčky)
  • Provoz na jednotlivých spojích, abychom viděli jejich zatížení a mohli identifikovat tzv. bottlenecky (slabá a přetížená místa v síti)

Celé řešení se skládá z:

  • Agenta, který síť monitoruje a sbírá data
  • Databáze, kam se ukládají naměřená data
  • Uživatelského rozhraní, které umožňuje data prohlížet

#Jak získávat data ze switchů?

Dnes již valná většina síťových zařízení podporuje protokol SNMP (Simple Network Management Protocol), který nám umožňuje číst ze zařízení různé užitečné informace. Tento protokol je velmi jednoduchý a datově nenáročný.

Většina zařízení přes SMTP poskytuje:

  • Základní informace o zařízení (název, umístění, model, …)
  • Informace o portech (typ, název, stav, přenesená data, …)
  • Informace o protokolech (IP, STP, VLANy, …)
  • Možnost vzdálené konfigurace

#Agent – sběr dat

Agent je vcelku jednoduchá aplikace, která běží na monitorovacím serveru v pozadí jako služba. Periodicky se pomocí SNMP ptá zařízení na jejich stav a tyto data ukládá do databáze.

Agent jsem napsal v Pythonu a to protože Python je:

  • Jednoduchý a velmi pěkný skriptovací jazyk
  • Rychlý a výkonný
  • V Linuxu je jako doma
  • Je pro něj k dispozici spousta knihoven

Celá aplikace se skládá z několika částí:

  • Agent – modul, který pomocí SNMP získává data ze zařízení, použit modul pysnmp
  • Storage – modul, který získaná data ukládá do databáze, jedná se v podstatě o vrstvu aplikace Model
  • Monitor – modul, který vše spojuje dohromady a dle konfigurace volá Agenta a jeho výsledky ukládá pomocí Storage modulu

#Databáze – ukládání dat

Jako databázový engine jsem vybral MongoDB. Jedná se o NoSQL databázi, která místo řádku do tabulek ukládá dokumenty do kolekcí. Dokument si můžete představit jako objekt (většina jazyků) a nebo asociativní pole (PHP).

Formát dat je jednoduchý. Každý záznam je snapshot (snímek) sítě v daném okamžiku. Každý snímek obsahuje nasbíraná data ze všech zařízení.

Data jsou sbírána v intervalech 3 sekundy, což umožňuje velmi detailní pohled na stav sítě a jeho zpětnou analýzu. Datová náročnost není příliš velká a záznamy se uchovávají po dobu jednoho týdne, což čítá v průměru cca 200 000 záznamů.

#Uživatelské rozhraní – prezentace dat

Uživatelské rozhraní je na tom všem asi to nejúžasnější, jelikož stav sítě prezentuje vizuálně, hezky barevně a ve webovém prohlížeči. Umožňuje sledovat stav sítě v reálném čase a přehrávat historická data.

Aplikaci jsem postavil na vlastní HTML5 knihovně MetaJS, která podporuje modulární architekturu.

UI se skládá z těchto modulů:

  • Toolbar – obsahuje ovládání aplikace, načítání historických dat a aktivaci real-time režimu
  • Mapa – Google Mapa zobrazující rozložení jednotlivých páteřních bodů, spojů mezi nimi a stav sítě
  • Sidebar – postranní panel zobrazující porty jednotlivých zařízení, jejich stavy a detailní pohled na port
    • Zařízení – MetaJS fragment zobrazující konkrétní zařízení a jeho porty
    • Detail portu – MetaJS fragment zobrazující detailní pohled na port – popisky, stav, průtok dat

Celá aplikace se poté skládá z:

  • API – jednoduchý PHP skript, který načítá data z databáze
  • Provider – model v JS, který volá API, načítá data a poskytuje je zbytku aplikace
  • UI – MetaJS aktivita, která vytváří Provider a integruje výše uvedené UI moduly

#Nejvíce záleží na Provideru – proč?

Provider je dostupný všem modulům, kterým poskytuje data z databáze. Největší výhoda je v tom, že je jakýmsi centrálním bodem aplikace. Např. Toolbar, který ovládá aplikaci, reálně ovládá Provider. Říká mu, která data má načíst a který time-frame má poskytovat. Provider dále řeší i real-time režim, tedy v intervalech se API ptá na poslední stav sítě.

MetaJS aplikace jsou založeny na architektuře, kde Provideru (modelu) říkáme, která data má načíst / upravit a Provider poté pomocí událostí oznamuje změnu všem, které to zajímá. V praxi to funguje tak, že komponenty aplikace poslouchají Provider a v případě oznámení změny zaktualizují svou podobu.

#Ukázka aplikace na demo síti

Ukázka aplikace na Backbone monitor

#Kudy se vydat dále?

Aktuálně je monitoring páteře jedno-účelová aplikace, která umí pracovat jen se specifickými zařízeními, které v síti používáme. Jelikož naše síť je unifikovaná a všude máme stejnou technologii, v tuto chvíli nám to zas tak nevadí.

Do budoucna bychom chtěli takto přehledně monitorovat nejen páteř, ale i celou síť, kde nejsou jen switche. Aplikaci by bylo potřeba rozšířit o možnost konfigurace profilů, pro jednotlivé typy hardwaru, aby dokázala sbírat i jiná data z jiných typů zařízení.

#Výhoda MetaJS

Knihovna MetaJS byla vytvořena v rámci vývoje MetaPlatform – našeho informačního systému pro celou firmu (zákazníci, fakturace, evidence, síť) a díky tomu je aplikace pro monitoring sama o sobě modulem, který lze v budoucnu velmi snadno integrovat do celého systému.

Jedno číslo závěrem – vývoj této aplikace pro monitoring zabral přibližně 30 hodin čistého času.