Telemetria nie jest czymś nowym. Od zawsze administratorzy zbierali informacje o administrowanych systemach i wyciągali z nich wnioski. Mieli do tego odpowiednie protokoły (choćby znane wszystkim SNMP) i narzędzia (na przykład Nagios). Narzędzia te są jednak niewystarczające w środowisku opartym o modele. Tak powstało Model Driven Telemetry, czyli telemetria oparta na modelach.
Czym jest telemetria oparta na modelach
Automatyzacja jest ściśle powiązana z aspektami “widzialności” (ang. visibility), czyli zdolności do zbierania informacji o środowisku czy urządzeniu, na którym wykonuje się zautomatyzowane czynności. Dlatego niezmiernie ważne jest odpowiednie zbieranie, analizowanie i korelowanie danych. Takie protokołu jak SNMP, syslog, a w szczególności zbieranie danych za pomocą CLI, to już przeżytek. Są to metody powolne, często dają niekompletny obraz, do tego oparty o zachowania czy parametry specyficzne dla danej platformy. Co więcej, opierają się one na założeniu, że to stacja monitorująca ma za zadanie odpytywać urządzenia o ich stan. Wszyscy dobrze z doświadczenia wiemy, że nie jest to proces ani doskonały, ani szybki.
Zbieranie danych w coraz bardziej skomplikowanych i rozbudowanych sieciach staje się żmudnym zadaniem. Związane jest ono z monitorowaniem infrastruktury, rozwiązywaniem problemów i zapobieganiem ich powstawaniu. Istnieje potrzeba gromadzenia dużej ilości danych pochodzących z różnych urządzeń w sieci. Z tych danych następnie korzystają różne grupy inżynierów i aplikacji, które wspólnie pracują nad analizą i rozwiązaniem problemu.
Modele, o których mowa w Model Driven Telemetry (MDT), to nic innego jak wykorzystanie modeli YANG. Dlatego często mówi się o YANG-based Telemetry. Telemetria taka zapewnia mechanizm przesyłania strumieniowego danych z urządzenia do miejsca docelowego. Zatem to nie stacja monitorująca pyta o dane, ale oczekuje na ich strumień z urządzenia. Wykorzystuje się nowe podejście do monitorowania sieci, w którym dane są przesyłane strumieniowo, w sposób ciągły za pomocą modelu “wypychania”. Zapewnia to dostęp w czasie niemal rzeczywistym do statystyk operacyjnych w celu monitorowania danych. Aplikacje mogą subskrybować określone elementy danych, których potrzebują. Opierają się jednak na wspomnianych standardach modeli danych YANG zamiast korzystania z otwartych protokołów. Dane strukturalne są publikowane w określonym rytmie lub w czasie zmiany, na podstawie kryteriów subskrypcji i typu danych.
Model Driven Telemetry w IOS XE
Telemetria MDT została wprowadzona w wersji Cisco IOS XE 16.10. Wykorzystywany jest mechanizm gRPC. Służy on do przesyłania danych modelowanych przez YANG z urządzenia IOS XE do urządzenia zbierającego informacje.
W IOS XE dostępne mamy dwa tryby publikacji danych:
- On-change – dane publikowane są w momencie wystąpienia określonego zdarzenia na przykład rozłączenia sąsiedztwa BGP.
- Periodic – informacje publikowane są w określonych odstępach czasu
Bardziej elastyczny jest tryb dial-out, w którym to monitorowane urządzenie (na przykład router) nawiązuje połączenie ze stacją zbierającą dane (ang. collector). To on jest inicjatorem tego połączenie za pomocą protokołów UDP, TCP i gRPC jako warstwy transportowej. Pamiętajmy, że dostępne protokołu mogą się różnić w zależności od urządzenia i wersji oprogramowania. W trybie tym wspierany jest też ruch typu Anycast oraz load balancing. Przeciwieństwem jest tryb dial-in, w którym to kolektor nawiązuje połączenie. Jednak w takiej konfiguracji do transportu użyjemy jedynie protokołu gRPC/gNMI, a kanał komunikacji łączony będzie zarówno do telemetrii jak i konfiguracji.
Niezbędne narzędzia
Aby korzystać z MDT potrzebujemy kilku komponentów zaczynając od samego urządzenia działającego pod kontrolą systemu IOS XE w wersji co najmniej 16.10 (dla niektórych platform jak Catalyst 9600 od wersji 16.11). Nie jest to oczywiście jedyna platforma Cisco wspierająca MDT. W przypadku NX-OS musi to być wersja minimum 7.0(3)I5(1), a w IOS-XR wersja 6.2.1.
Drugim komponentem jest odbiorca komunikatów gRPC. Jego zadaniem jest dekodowanie przesłanych komunikatów i umieszczanie ich we wskazanym kolektorze. Cisco rekomenduje do tego celu oprogramowanie Telegraf z rozszerzeniem cisco_telemetry_mdt.
Rolę kolektora pełni InfluxDB. Jest to baza danych oparta o rekordu oparte o znaczniki czasu (szeregi czasowye). Dostępna jest ona na licencji open source i zoptymalizowana pod kątem szybkiego przechowywania i wyszukiwania danych szeregów czasowych. Bardzo powszechnie wykorzystuje się ją w takich obszarach monitorowanie operacji, zbieranie metryki aplikacji czy dane z czujników IoT oraz analizy tych danych w czasie rzeczywistym. Udostępnia ona język podobny do SQL z wbudowanymi funkcjami czasu do wykonywania zapytań dotyczących struktury danych składającej się z pomiarów, serii i punktów.
Surowe dane są jednak przede wszystkim mało czytelne, dlatego potrzebujemy narzędzia do ich wizualizacji. W tym celu doskonale sprawdzi się Grafana.
E-BOOK
Zaczynasz swój pierwszy projekt związany z automatyzacją?
Ten e-book jest dla Ciebie! Zawiera sprawdzone podejście, które realizowałem w wielu projektach. Sprawdź co możesz zrobić, by odnieść sukces!
