16 modemów, 4 operatorów komórkowych = Prędkość wychodząca 933,45 Mbit/s
Wprowadzenie
Cześć! To artykuł o tym, jak stworzyliśmy nasz nowy system monitorowania. Różni się on od istniejących możliwością wysokoczęstotliwościowego, synchronicznego pozyskiwania metryk oraz bardzo niskim zużyciem zasobów. Częstotliwość zapytań może osiągać 0,1 milisekundy przy dokładności synchronizacji między metrykami wynoszącej 10 nanosekund. Wszystkie pliki binarne zajmują 6 megabajtów.
O projekcie
Mamy dość specyficzny produkt. Oferujemy kompleksowe rozwiązanie do sumowania przepustowości i odporności kanałów przesyłania danych. To wtedy, gdy istnieje kilka kanałów, na przykład Operator1 (40 Mbit/s) + Operator2 (30 Mbit/s) + Coś jeszcze (5 Mbit/s), co daje jeden stabilny i szybki kanał, którego prędkość wynosić będzie mniej więcej: (40+30+5)x0,92=75×0,92=69 Mbit/s.
Takie rozwiązania są poszukiwane tam, gdzie pojemność jakiegokolwiek jednego kanału jest niewystarczająca. Na przykład w transporcie, systemach monitoringu wideo oraz transmisyjnych wideo w czasie rzeczywistym, transmisjach na żywo radiowych i telewizyjnych, wszelkich obiektach poza miastem, gdzie operatorami są tylko przedstawiciele wielkiej czwórki, a prędkości na jednym modemie/kanałach nie są wystarczające.
Dla każdego z tych kierunków wydajemy osobną linię urządzeń, jednak ich część programowa jest prawie identyczna, a jakościowy system monitorowania to jeden z jego kluczowych modułów, bez prawidłowej realizacji którego produkt byłby niemożliwy.
W ciągu kilku lat udało nam się stworzyć wielowarstwowy, szybki, wieloplatformowy i lekki system monitorowania. Chcemy się tym podzielić z szanowaną społecznością.
Sformułowanie zadania
System monitorowania zapewnia pozyskiwanie metryk dwóch zasadniczo różnych klas: metryk czasu rzeczywistego i wszystkich pozostałych. Do systemu monitorowania były tylko następujące wymagania:
- Wysokoczęstotliwościowe synchroniczne pozyskiwanie metryk czasu rzeczywistego i ich przesyłanie do systemu zarządzania komunikacją bez opóźnień.
Wysoka częstotliwość i synchronizacja różnych metryk – nie tylko są ważne, ale są niezbędne do analizy entropii kanałów transmisji danych. Jeśli w jednym kanale transmisji danych średnie opóźnienie wynosi 30 milisekund, to błąd w synchronizacji między pozostałymi metrykami zaledwie o jedną milisekundę spowoduje degradację prędkości wynikowego kanału o około 5%. Jeśli popełnimy błąd w synchronizacji na 1 milisekundę w 4 kanałach, degradacja prędkości może łatwo spaść do 30%. Ponadto entropia w kanałach zmienia się bardzo szybko, dlatego jeśli będziemy mierzyć ją rzadziej niż raz na 0,5 milisekundy, na szybkich kanałach o małym opóźnieniu otrzymamy dużą degradację prędkości. Oczywiście taka precyzja nie jest potrzebna we wszystkich metrykach i nie w każdych warunkach. Gdy opóźnienie w kanale wynosi 500 milisekund, a pracujemy nawet w takich warunkach, błąd o 1 milisekundę będzie prawie niezauważalny. Również dla metryk systemów zapewnienia życia wystarczy częstotliwość pomiarów i synchronizacji co 2 sekundy, jednak sama w sobie system monitorowania powinna być w stanie działać z ultra wysokimi częstotliwościami pomiarów i bardzo precyzyjną synchronizacją metryk. - Minimalne zużycie zasobów i jednolity stos technologiczny.
Urządzenie końcowe może być zarówno potężnym kompleksem pokładowym, który potrafi analizować sytuację na drodze lub prowadzić biometryczną rejestrację osób, jak i jednopłytowym komputerem wielkości dłoni, który jest noszony pod kamizelką kuloodporną przez żołnierza jednostek specjalnych w celu przesyłania wideo w czasie rzeczywistym w trudnych warunkach komunikacyjnych. Pomimo takiej różnorodności architektur i mocy obliczeniowych, chcielibyśmy mieć ten sam stos oprogramowania. - Architektura parasolowa
Metryki powinny być zbierane i agregowane na urządzeniu końcowym, mieć lokalny system przechowywania i wizualizacji w czasie rzeczywistym oraz retrospektywnie. W przypadku posiadania połączenia – dane powinny być przesyłane do centralnego systemu monitorowania. Gdy połączenie jest niedostępne – kolejka do wysyłki powinna się gromadzić i nie zużywać pamięci operacyjnej. - API do integracji z systemem monitorowania klienta, ponieważ nikt nie potrzebuje wielu systemów monitorowania. Klient powinien zbierać dane z dowolnych urządzeń i sieci w jedną platformę monitorującą.
Co uzyskaliśmy
Aby nie obciążać już i tak długiego artykułu, nie będę podawać przykładów oraz pomiarów wszystkich systemów monitorowania. To zajmie jeszcze jeden artykuł. Po prostu powiem, że nie udało nam się znaleźć systemu monitorowania, który potrafiłby jednocześnie zrealizować dwa pomiary z dokładnością mniejszą niż 1 milisekunda i który działałby tak samo skutecznie zarówno na architekturze ARM z 64 MB RAM, jak i na architekturze x86_64 z 32 GB RAM. Dlatego postanowiliśmy napisać własny, który potrafi to wszystko. Oto, co nam się udało osiągnąć:
Sumowanie przepustowości trzech kanałów dla różnych topologii sieci
Wizualizacja niektórych kluczowych metryk
Architektura
Jako główny język programowania, zarówno na urządzeniu, jak i w centrum danych, używamy Golang. Zdecydowanie uprościł życie dzięki realizacji współbieżności i możliwości uzyskania jednego statycznie linkowanego pliku wykonywalnego dla każdej usługi. W rezultacie znacząco oszczędzamy zasoby, metody i ruch w procesie wdrażania usług na urządzenia końcowe, a także czas na rozwój i debugowanie kodu.
System został zrealizowany na klasycznym, modułowym zasadzie i zawiera kilka podsystemów:
- Rejestracja metryk.
Każda metryka jest obsługiwana przez własny wątek i synchronizowana za pomocą kanałów. Udało nam się osiągnąć dokładność synchronizacji do 10 nanosekund. - Przechowywanie metryk
Wybieraliśmy między stworzeniem własnego magazynu do przechowywania danych szeregów czasowych a używaniem czegoś już istniejącego. Baza danych jest potrzebna do danych retrospektywnych, które będą poddane dalszej wizualizacji. To znaczy, nie ma w niej danych o opóźnieniach w kanale co 0,5 milisekundy ani odczytach błędów w sieci transportowej, ale są prędkości na każdym interfejsie co 500 milisekund. Oprócz wysokich wymagań dotyczących wieloplatformowości i niskiego zużycia zasobów, niezwykle ważne jest dla nas, aby móc przetwarzać dane tam, gdzie są przechowywane. To ogromnie oszczędza zasoby obliczeniowe. Od 2016 roku używamy bazy danych Tarantool w tym projekcie i na razie nie widzimy alternatywy. Jest elastyczny, z optymalnym zużyciem zasobów i więcej niż adekwatnym wsparciem technicznym. W Tarantool zrealizowano także moduł GIS. Oczywiście nie jest tak potężny jak PostGIS, ale wystarcza do naszych potrzeb przechowywania pewnych metryk związanych z lokalizacją (aktualne dla transportu). - Wizualizacja metryk
Tutaj wszystko jest stosunkowo proste. Pobieramy dane z magazynu i pokazujemy je w czasie rzeczywistym lub retrospektywnie. - Synchronizacja danych z centralnym systemem monitorowania.
Centralny system monitorowania przyjmuje dane ze wszystkich urządzeń, przechowuje je z określoną retrospektywą i przez API przekazuje je do systemu monitorowania klienta. W przeciwieństwie do klasycznych systemów monitorowania, w których 'centralna jednostka' zbiera dane, u nas to działa w odwrotny sposób. Urządzenia same wysyłają dane wtedy, gdy mają połączenie. To bardzo ważny aspekt, ponieważ pozwala uzyskać dane z urządzenia w okresach, gdy było niedostępne, i nie obciąża kanałów oraz zasobów, kiedy urządzenie nie działa. Jako centralny system monitorowania używamy serwera monitorowania Influx. W przeciwieństwie do podobnych, potrafi importować dane retrospektywne (tj. z czasem różnym od momentu otrzymania metryki). Zebrane metryki wizualizuje zmodyfikowany Grafana. Ten standardowy stos został wybrany również dlatego, że ma gotowe API do integracji praktycznie z każdym systemem monitorowania klienta. - Synchronizacja danych z centralnym systemem zarządzania urządzeniami.
System zarządzania urządzeniami wdraża Zero Touch Provisioning (aktualizacja oprogramowania, konfiguracji itp.) i w przeciwieństwie do systemu monitorowania, odbiera tylko problemy z urządzeniami. To są wyzwalacze pracy wbudowanych serwisów monitorujących i wszystkie metryki systemów utrzymania: temperatura CPU i SSD, obciążenie CPU, wolne miejsce i zdrowie S.M.A.R.T na dyskach. Przechowalnia podsystemu jest również oparta na Tarantool. Daje nam to znaczną prędkość w agregacji szeregów czasowych na tysiącach urządzeń, a także całkowicie rozwiązuje problem synchronizacji danych z tymi urządzeniami. Tarantool ma wbudowany doskonały system kolejek i gwarantowanej dostawy. Otrzymaliśmy tę ważną funkcję z pudełka, świetnie!
System zarządzania siecią
Co dalej
Obecnie najsłabszym ogniwem jest centralny system monitorowania. Jest on zrealizowany w 99,9% na standardowym stosie i ma kilka wad:
- InfluxDB traci dane podczas wyłączenia zasilania. Zazwyczaj Klient szybko odbiera wszystko, co przychodzi z urządzeń i w samej bazie danych nie ma danych starszych niż 5 minut, jednak w przyszłości może to stać się problemem.
- Grafana ma szereg problemów z agregacją danych i synchronizacją ich wyświetlania. Najczęstszym problemem jest sytuacja, gdy w bazie znajduje się szereg czasowy z interwałem 2 sekund zaczynając na przykład od 00:00:00, a Grafana zaczyna pokazywać dane w agregacji od +1 sekundy. W wyniku tego użytkownik widzi skaczący wykres.
- Nadmiar kodu do integracji API z zewnętrznymi systemami monitorowania. Można to zrobić znacznie bardziej zwięźle i oczywiście przepisując to w Go :)
Sądząc po tym, co widzieliście, wszyscy znają wygląd Grafany i jej problemy, dlatego nie będę obciążać posta zdjęciami.
Podsumowanie
Świadome nie opisałem szczegółów technicznych, a tylko ogólny projekt tego systemu. Po pierwsze, aby technicznie pełni opisać system, potrzebny byłby jeszcze jeden artykuł. Po drugie, nie wszyscy będą tym zainteresowani. Napiszcie w komentarzach, jakie techniczne szczegóły chcielibyście poznać.
Jeśli ktoś ma pytania poza tym artykułem, można pisać na adres a.rodin @ qedr.com
Źródło: habr.com
