16 modemów, 4 operatorów komórkowych = Prędkość wychodząca 933.45 Mbit/s
Wprowadzenie
Cześć! W tym artykule opowiemy o tym, jak sami napisaliśmy dla siebie nowy system monitorowania. Różni się od istniejących możliwością uzyskiwania metryk synchronicznych o wysokiej częstotliwości i bardzo niskim zużyciem zasobów. Szybkość odpytywania może osiągnąć 0.1 milisekundy przy dokładności synchronizacji między metrykami wynoszącej 10 nanosekund. Wszystkie pliki binarne zajmują 6 megabajtów.
o
Mamy dość specyficzny produkt. Produkujemy kompleksowe rozwiązanie podsumowujące przepustowość i odporność na awarie kanałów transmisji danych. Dzieje się tak, gdy kanałów jest kilka, powiedzmy Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Coś innego (5 Mbit/s), efektem jest jeden stabilny i szybki kanał, którego prędkość będzie mniej więcej taka to: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
Takie rozwiązania są potrzebne tam, gdzie przepustowość jednego kanału jest niewystarczająca. Np. transport, systemy monitoringu wizyjnego i streamingu wideo w czasie rzeczywistym, transmisja na żywo audycji telewizyjnych i radiowych, wszelkie obiekty podmiejskie, gdzie wśród operatorów telekomunikacyjnych są wyłącznie przedstawiciele Wielkiej Czwórki i prędkość na jednym modemie/kanale nie jest wystarczająca .
Dla każdego z tych obszarów produkujemy osobną linię urządzeń, jednak ich część programowa jest niemal identyczna, a jednym z jej głównych modułów jest wysokiej jakości system monitoringu, bez którego prawidłowego wdrożenia produkt nie byłby możliwy.
W ciągu kilku lat udało nam się stworzyć wielopoziomowy, szybki, wieloplatformowy i lekki system monitorowania. Tym właśnie chcemy się podzielić z naszą szanowaną społecznością.
Stwierdzenie problemu
System monitorowania dostarcza metryki dwóch zasadniczo różnych klas: metryki czasu rzeczywistego i wszystkie inne. System monitorowania miał jedynie następujące wymagania:
- Synchroniczne pozyskiwanie danych o wysokiej częstotliwości w czasie rzeczywistym i ich niezwłoczne przesyłanie do systemu zarządzania komunikacją.
Wysoka częstotliwość i synchronizacja różnych metryk jest nie tylko ważna, ale także niezbędna do analizy entropii kanałów transmisji danych. Jeżeli w jednym kanale transmisji danych średnie opóźnienie wynosi 30 milisekund, to błąd synchronizacji pomiędzy pozostałymi metrykami wynoszący zaledwie jedną milisekundę doprowadzi do pogorszenia prędkości wynikowego kanału o około 5%. Jeśli pomylimy synchronizację o 1 milisekundę w 4 kanałach, spadek prędkości może łatwo spaść do 30%. Dodatkowo entropia w kanałach zmienia się bardzo szybko, więc jeśli będziemy ją mierzyć rzadziej niż raz na 0.5 milisekundy, to na szybkich kanałach z niewielkim opóźnieniem uzyskamy dużą degradację prędkości. Oczywiście taka dokładność nie jest wymagana w przypadku wszystkich metryk i nie w każdych warunkach. Gdy opóźnienie w kanale wynosi 500 milisekund i pracujemy z takim, wówczas błąd 1 milisekundy będzie prawie niezauważalny. Ponadto w przypadku wskaźników systemów podtrzymywania życia mamy wystarczającą częstotliwość odpytywania i synchronizacji wynoszącą 2 sekundy, ale sam system monitorowania musi być w stanie pracować z bardzo wysokimi częstotliwościami odpytywania i ultraprecyzyjną synchronizacją wskaźników. - Minimalne zużycie zasobów i pojedynczy stos.
Urządzeniem końcowym może być albo potężny kompleks pokładowy, który może analizować sytuację na drodze lub prowadzić biometryczną rejestrację osób, albo jednopłytkowy komputer wielkości dłoni, który żołnierz sił specjalnych zakłada pod kamizelkę kuloodporną w celu przesyłania obrazu wideo czasie rzeczywistym w złych warunkach komunikacyjnych. Mimo tak różnych architektur i mocy obliczeniowych chcielibyśmy mieć ten sam stos oprogramowania. - Architektura parasolowa
Metryki muszą być gromadzone i agregowane na urządzeniu końcowym, przechowywane lokalnie i wizualizowane w czasie rzeczywistym i retrospektywnie. Jeśli jest połączenie, prześlij dane do centralnego systemu monitorowania. W przypadku braku połączenia kolejka wysyłająca powinna się gromadzić, a nie zużywać pamięci RAM. - API do integracji z systemem monitorowania klienta, ponieważ nikt nie potrzebuje wielu systemów monitorowania. Klient musi zebrać dane z dowolnych urządzeń i sieci w jeden monitoring.
Co się stało
Aby nie obciążać i tak już imponującej lektury, nie będę podawać przykładów i pomiarów wszystkich systemów monitoringu. To doprowadzi do kolejnego artykułu. Powiem tylko, że nie udało nam się znaleźć systemu monitorującego, który byłby w stanie przyjmować jednocześnie dwie metryki z błędem mniejszym niż 1 milisekunda i który działałby równie efektywnie zarówno na architekturze ARM z 64 MB RAM, jak i na architekturze x86_64 z 32 GB pamięci RAM. Dlatego postanowiliśmy napisać własny, który potrafi to wszystko. Oto co otrzymaliśmy:
Podsumowanie przepustowości trzech kanałów dla różnych topologii sieci
Wizualizacja niektórych kluczowych wskaźników
Architektura
Używamy Golang jako głównego języka programowania, zarówno na urządzeniu, jak i w centrum danych. Znacznie uprościło to życie dzięki implementacji wielozadaniowości i możliwości uzyskania jednego statycznie połączonego wykonywalnego pliku binarnego dla każdej usługi. Dzięki temu znacznie oszczędzamy zasoby, metody i ruch związany z wdrażaniem usługi na urządzeniach końcowych, czas programowania i debugowanie kodu.
System realizowany jest według klasycznej zasady modułowej i zawiera kilka podsystemów:
- Rejestracja metryk.
Każda metryka jest obsługiwana przez własny wątek i synchronizowana między kanałami. Udało nam się osiągnąć dokładność synchronizacji do 10 nanosekund. - Przechowywanie metryk
Wybieraliśmy pomiędzy napisaniem własnego magazynu dla szeregów czasowych lub wykorzystaniem czegoś, co było już dostępne. Baza jest potrzebna dla danych retrospektywnych, które podlegają późniejszej wizualizacji, czyli nie zawiera danych o opóźnieniach w kanale co 0.5 milisekundy czy odczytach błędów w sieci transportowej, ale na każdym interfejsie jest prędkość co 500 milisekund. Oprócz wysokich wymagań dotyczących wieloplatformowości i niskiego zużycia zasobów, niezwykle ważna jest dla nas możliwość przetwarzania. dane są tam, gdzie są przechowywane. Oszczędza to ogromne zasoby obliczeniowe. W tym projekcie używamy Tarantool DBMS od 2016 roku i na razie nie widzimy na horyzoncie jego następcy. Elastyczny, z optymalnym zużyciem zasobów, to więcej niż odpowiednie wsparcie techniczne. Tarantool implementuje także moduł GIS. Oczywiście nie jest tak wydajny jak PostGIS, ale wystarcza do naszych zadań związanych z przechowywaniem niektórych wskaźników związanych z lokalizacją (istotnych dla transportu). - Wizualizacja metryk
Tutaj wszystko jest stosunkowo proste. Pobieramy dane z magazynu i wyświetlamy je w czasie rzeczywistym lub retrospektywnie. - Synchronizacja danych z centralnym systemem monitorowania.
Centralny system monitoringu odbiera dane ze wszystkich urządzeń, przechowuje je z określoną historią i przesyła poprzez API do systemu monitoringu Klienta. W przeciwieństwie do klasycznych systemów monitoringu, w których „głowa” chodzi i zbiera dane, mamy odwrotny schemat. Same urządzenia wysyłają dane, gdy istnieje połączenie. Jest to bardzo ważny punkt, ponieważ pozwala odbierać dane z urządzenia przez te okresy, w których nie były one dostępne, i nie ładować kanałów i zasobów, gdy urządzenie jest niedostępne. Serwer monitorujący Influx wykorzystujemy jako centralny system monitorowania. W odróżnieniu od swoich odpowiedników może importować dane retrospektywne (tzn. ze znacznikiem czasowym innym niż moment otrzymania metryki) Zebrane metryki są wizualizowane przez Grafanę i modyfikowane za pomocą pliku. Wybrano ten standardowy stos również dlatego, że posiada gotowe integracje API z niemal 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 sprzętowego, konfiguracja itp.) i w przeciwieństwie do systemu monitorowania odbiera tylko problemy na urządzenie. Są to wyzwalacze działania pokładowych usług nadzoru sprzętu i wszystkich wskaźników systemów podtrzymywania życia: temperatury procesora i dysku SSD, obciążenia procesora, wolnego miejsca i kondycji SMART na dyskach. Pamięć podsystemu jest również zbudowana na Tarantoolu. Daje nam to znaczną prędkość w agregowaniu szeregów czasowych z tysięcy urządzeń, a także całkowicie rozwiązuje problem synchronizacji danych z tymi urządzeniami. Tarantool ma doskonały system kolejkowania i gwarantowanej dostawy. Mamy tę ważną funkcję od razu po wyjęciu z pudełka, świetnie!
System zarządzania siecią
Co dalej
Na razie naszym najsłabszym ogniwem jest centralny system monitoringu. Jest zaimplementowany w 99.9% na standardowym stosie i ma wiele wad:
- InfluxDB traci dane w przypadku utraty zasilania. Z reguły Klient na bieżąco zbiera wszystko, co wychodzi z urządzeń, a sama baza danych nie zawiera danych starszych niż 5 minut, ale w przyszłości może to być uciążliwe.
- Grafana ma szereg problemów z agregacją danych i synchronizacją ich wyświetlania. Najczęstszym problemem jest sytuacja, gdy w bazie danych znajduje się szereg czasowy z interwałem 2 sekund zaczynającym się np. od godziny 00:00:00, a Grafana zaczyna pokazywać dane w agregacji od +1 sekundy. W rezultacie użytkownik widzi tańczący wykres.
- Nadmierna ilość kodu do integracji API z systemami monitorującymi innych firm. Można go uczynić znacznie bardziej kompaktowym i oczywiście przepisać w Go)
Myślę, że wszyscy doskonale widzieliście, jak wygląda Grafana i znacie jej problemy beze mnie, więc nie będę przeładowywać posta zdjęciami.
wniosek
Celowo nie opisałem szczegółów technicznych, a jedynie opisałem podstawową konstrukcję tego układu. Po pierwsze, aby technicznie w pełni opisać system, potrzebny będzie kolejny artykuł. Po drugie, nie każdego to zainteresuje. Napisz w komentarzu jakie szczegóły techniczne chciałbyś poznać.
Jeśli ktoś ma pytania wykraczające poza zakres tego artykułu, może napisać do mnie na adres a.rodin @ qedr.com
Źródło: www.habr.com