Właśnie z tej obserwacji narodził się LinkSense — lekkie, open source’owe narzędzie do synthetic monitoringu stworzone przez zespół Sycope.
Synthetic monitoring, czyli monitoring syntetyczny, to podejście, w którym nie czekasz biernie, aż coś się zepsuje i zgłoszą to użytkownicy. Zamiast tego system sam, w regularnych odstępach, sztucznie generuje ruch — wysyła pinga, zapytanie HTTP, sprawdza DNS — i mierzy, jak odpowiada monitorowany system. „Syntetyczny”, ponieważ ten ruch powstaje na potrzeby testu, a nie pochodzi od prawdziwych użytkowników. Dzięki temu o problemie można dowiedzieć się zanim zauważy go klient.
LinkSense to projekt zbudowany wokół trzech bardzo konkretnych zasad: bez zbędnej złożoności, bez vendor lock-inu i bez nadmiernego zużycia zasobów.
Table of Contents
Skąd się wziął LinkSense?
Historia LinkSense jest mniej korporacyjna, a bardziej inżynierska. Maciej Wilamowski, CIO Sycope, oraz Marcin Kaźmierczak, Solution Architect, zauważyli, że klienci z naprawdę dużymi sieciami — obejmującymi wiele lokalizacji, serwerowni, aplikacji i load balancerów — potrzebują prostego sposobu monitorowania połączeń: czy linki między punktami sieci działają i jak faktycznie się zachowują.
Pierwsza reakcja była przewidywalna: „przecież coś takiego na pewno już istnieje”. Żyjemy w czasach, w których na niemal każdy problem można znaleźć gotową bibliotekę albo narzędzie. Owszem, istnieją Zabbix, Nagios i podobne rozwiązania, ale nie udało się znaleźć systemu, który byłby jednocześnie open source, banalnie prosty w konfiguracji i obsłudze oraz dobrze dopasowany do dużych, rozproszonych sieci z wieloma węzłami i lokalizacjami.
Skoro takiego narzędzia nie było, a sama idea wydawała się prosta — wystarczy co jakiś czas wysłać pinga albo zapytanie HTTP, żeby wiedzieć, czy usługa odpowiada — pojawił się wniosek: napiszmy to sami. Tak zaczął się LinkSense.
Trzy zasady, które trzymają projekt w ryzach
1. Bez zbędnej złożoności
LinkSense to jedna mała binarka. Wdrożenie sprowadza się do schematu „skopiuj plik i uruchom usługę”. Cała konfiguracja opiera się na plikach tekstowych w formacie TOML — osobno dla samego agenta, osobno dla listy zadań. Definicja nowego zadania jest na tyle prosta, że w praktyce polega na skopiowaniu jednego wpisu i podmianie kilku wartości. Każdy typ zadania ma własną, krótką dokumentację README, więc nie trzeba zgadywać, co oznaczają poszczególne pola.
Co istotne, projekt jest mocno udokumentowany. README istnieje dla całego projektu, dla agenta, dla serwera i dla każdego pojedynczego zadania z osobna. Dokumentacja zawiera również informacje o bibliotekach z ekosystemu Rusta używanych „pod maską”.
2. Bez vendor lock-inu
Vendor lock-in, czyli uzależnienie od dostawcy, to sytuacja, w której narzędzie przechowuje dane w zamkniętym, własnym formacie i wiąże użytkownika z jednym ekosystemem do tego stopnia, że zmiana rozwiązania staje się kosztowna albo wręcz niewykonalna. Dane trudno wyeksportować, a kluczowe elementy są „zaszyte” w konkretnym narzędziu.
LinkSense działa odwrotnie.
Wszystkie dane trafiają do bazy SQLite — zarówno po stronie agenta, jak i serwera. SQLite to lekka, plikowa baza danych: nie wymaga osobnego serwera bazodanowego, a całość mieści się w jednym pliku, który można otworzyć dowolnym narzędziem do SQL-a. Struktura tabel jest celowo bardzo prosta, aby LinkSense dało się łatwo zintegrować z dowolnym innym narzędziem. Jeśli chcesz wyciągnąć swoje dane i przenieść je gdzie indziej, sprowadza się to do prostego scenariusza: pobrać dane z SQLite i skopiować je w inne miejsce. Licencja jest permisywna, czyli pozwala swobodnie używać, modyfikować i rozwijać kod, a sam kod pozostaje otwarty.
To świadoma decyzja: LinkSense jest narzędziem do zbierania danych, nie do ich wizualizacji. Do tego wątku wrócimy w dalszej części.
3. Bez nadmiernego zużycia zasobów
Tutaj liczby mówią same za siebie. Podczas żywej demonstracji na webinarze agent działający od blisko godziny, wykonujący kilkadziesiąt różnych zadań — wiele pingów, zapytania HTTP co kilkanaście sekund, testy TLS i TCP — zużywał 31 MB pamięci i praktycznie zerowy procent CPU, z wahaniami w okolicach 0–1%. Zespół prowadził również testy długoterminowe trwające ponad miesiąc, sprawdzając, czy nie pojawiają się wycieki pamięci lub inne problemy. Testy zakończyły się bez jednej awarii.
Za tę wydajność odpowiada między innymi wybór Rusta jako języka, w którym napisano LinkSense. Rust jest ceniony za szybkość działania i oszczędne gospodarowanie pamięcią. Kluczowe znaczenie ma także asynchroniczne wykonywanie zadań: zamiast czekać, aż zakończy się jeden test, na przykład ping trwający ułamek sekundy, zanim ruszy kolejny, agent prowadzi wiele zadań „równolegle” i nie blokuje się na żadnym z nich. Dzięki temu jeden niewielki proces może obsłużyć kilkadziesiąt testów naraz bez obciążania maszyny.
Architektura w pigułce: model agent–serwer
Trzonem projektu jest podział na agentów i centralny serwer. Agenci to małe binarki rozstawione w różnych lokalizacjach. Wykonują zlecone im testy, przechowują wyniki lokalnie w SQLite, a co 60 sekund tworzą zagregowane metryki i wysyłają je do centralnego serwera.
Kluczowy jest kierunek połączenia: to agenci aktywnie łączą się z serwerem, a nie odwrotnie. Daje to dwie konkretne korzyści.
Bezpieczeństwo. Agent może działać na maszynie z firewallem ustawionym według zasady „blokuj przychodzące, zezwól na wychodzące”. Nie potrzebuje żadnych otwartych portów. A brak otwartych portów oznacza istotnie mniejszą powierzchnię ataku — wszyscy słyszeliśmy o przypadkach przejęcia agentów monitorujących, które potrafią stać się poważnym zagrożeniem.
Prostsze zarządzanie. Otwarte porty musi mieć tylko jedna maszyna — serwer. Zadbanie o bezpieczeństwo jednej maszyny jest znacznie prostsze niż pilnowanie wielu rozproszonych instancji.
Ten model ma jeszcze trzecią zaletę: masową rekonfigurację. Konfigurację agentów można zmieniać z poziomu serwera. Wyobraź sobie statek z szesnastoma albo większą liczbą agentów na pokładzie. Jeśli chcesz dodać im wszystkim jedno nowe zadanie, robisz to jedną zmianą w pliku konfiguracyjnym po stronie serwera. Przy kolejnej aktualizacji agent wykrywa, że jego konfiguracja jest nieaktualna, pobiera nową wersję z serwera, waliduje ją i od razu zaczyna z niej korzystać.
Architektura jest również „local-first”, czyli „najpierw lokalnie”. Agent zapisuje wyniki u siebie, na miejscu, i dopiero potem wysyła je do serwera. Dzięki temu nawet jeśli serwer chwilowo nie odpowiada, agenci nie tracą danych i kontynuują monitoring podczas problemów sieciowych. Gdy łączność wraca, dosyłają zebrane metryki. Agentów można też uruchomić w trybie w pełni samodzielnym, czyli standalone. Jeśli traktujesz LinkSense jako mały prywatny projekt, nie potrzebujesz centralnego serwera — wystarczy podejrzeć lokalną bazę SQLite dowolnym narzędziem.
Co LinkSense potrafi monitorować?
LinkSense oferuje zestaw gotowych typów zadań.
Ping — najprostsze sprawdzenie, jak szybko pakiety wracają i czy nie ma ich utraty, czyli czy część wysłanych pakietów nie ginie po drodze.
HTTP GET — pełna informacja o żądaniu strony. LinkSense rozbija czas odpowiedzi na składniki: czas nawiązania połączenia TCP, czas zestawienia szyfrowanego połączenia, czyli TLS handshake — moment, w którym serwer i klient ustalają szyfrowanie, zanim w ogóle zostaną przesłane dane — time-to-first-byte, czyli czas do pierwszego bajtu odpowiedzi i informację o tym, jak długo serwer „myśli”, zanim cokolwiek odeśle, oraz całkowity czas pobrania. Do tego dochodzą kody statusu HTTP, informacja o tym, czy certyfikat jest ważny, oraz ile dni zostało do jego wygaśnięcia.
TCP i TLS — w praktyce „podzadania” HTTP GET. Czasem nie chcesz pobierać całej strony, a jedynie sprawdzić, czy dany port jest otwarty, czyli TCP, albo czy poprawnie zestawia się szyfrowanie, czyli TLS — bez pełnego zapytania HTTP.
DNS — sprawdza, czy nazwy domen poprawnie tłumaczą się na adresy IP. Co ważne, to zadanie używa własnego resolvera, a nie systemowego. Resolver to mechanizm, który zamienia nazwę, na przykład sycope.com, na adres IP. System operacyjny zwykle zapamiętuje, czyli cache’uje, wyniki, więc kolejne zapytania nie trafiają realnie do serwera DNS. Własny resolver omija ten cache i rzeczywiście odpytuje DNS za każdym razem. Dzięki temu mierzysz faktyczny stan, a nie zapamiętaną odpowiedź.
HTTP content — pozwala zajrzeć w treść odpowiedzi za pomocą wyrażenia regularnego, czyli regexu — wzorca do wyszukiwania konkretnego tekstu w treści strony. To przydatne wtedy, gdy aplikacja zwraca status 200, czyli „wszystko OK”, ale w treści komunikuje na przykład okno serwisowe. Sam kod statusu by tego nie wychwycił, natomiast dopasowanie wzorca w treści już tak.
Bandwidth — pomiar przepustowości łącza, zawsze pomiędzy agentem a serwerem. Po stronie serwera działa kolejkowanie, aby kilka testów uruchomionych jednocześnie nie zafałszowało sobie nawzajem wyników.
SQL query i SNMP query — zadania opcjonalne, wykraczające poza główne przeznaczenie narzędzia. Zapytanie SQL pozwala sprawdzić nie tylko, czy baza danych odpowiada, ale też czy dane w niej są poprawne, na przykład policzyć, ile wierszy zwraca konkretne zapytanie. SNMP to standardowy protokół do odpytywania urządzeń sieciowych o ich stan. Pozwala pobierać konkretne wartości spod tzw. OID-ów, czyli numerycznych identyfikatorów konkretnych informacji w urządzeniu — na przykład obciążenia CPU, nazwy hosta czy opisu urządzenia.
Typowe zastosowania
Z tych elementów składają się konkretne scenariusze użycia:
- monitoring uptime’u, czyli dostępności — odsetka czasu, w którym usługa realnie działa — w dużych sieciach, oglądany z perspektywy rozproszonych geograficznie endpointów, czyli punktów końcowych: konkretnych maszyn w różnych miejscach, z których prowadzony jest pomiar;
- pomiar wydajności aplikacji i sieci;
- ocena load balancerów — urządzeń lub usług, które rozkładają ruch między wiele serwerów; w praktyce warto wiedzieć, czy każdy z nich faktycznie odpowiada równie sprawnie;
- sprawdzanie kondycji DNS i pilnowanie poziomów SLA, czyli Service Level Agreement — umownych progów dostępności i wydajności, do których dostawca się zobowiązał;
- kontrola dat wygaśnięcia certyfikatów SSL, aby nie obudzić się nagle z komunikatem „połączenie niezaufane” na produkcji.
Świadome „nie”: brak wizualizacji i alertingu
LinkSense z założenia nie ma wbudowanej wizualizacji ani alertingu. To nie jest brak, ale decyzja projektowa. Rozwiązań do wizualizacji, alertowania czy orkiestracji jest na rynku mnóstwo. Brakowało natomiast prostego, lekkiego, open source’owego narzędzia do zbierania danych. Założenie jest takie, że większa organizacja prawdopodobnie ma już system, w którym chce te dane oglądać i dalej przetwarzać. Dzięki rezygnacji z wizualizacji i alertingu LinkSense może pozostać tak oszczędny w zasobach.
Z tej samej filozofii wynika brak oficjalnych kontenerów. Skoro LinkSense to jedna prosta binarka, konteneryzacja jest trywialna do wykonania samodzielnie, na przykład przez własny docker compose, który kopiuje binarkę i uruchamia usługę. Rozwiązanie działa również z Alpine Linux. Dostarczanie gotowych kontenerów nie wnosiłoby tutaj dużej wartości, a mogłoby zabrać część przewagi związanej z niskim zużyciem zasobów.
To nie jest „vibe-coded” projekt
Twórcy świadomie podkreślają tę różnicę. Owszem, do rozwoju i dokumentacji używali narzędzi typu Claude Code, ponieważ realnie przyspieszają pracę. Struktura projektu została jednak zaprojektowana ręcznie, a każda linia kodu została przejrzana. Dokumentacja również została zaplanowana co do treści i struktury przez człowieka, a nie wygenerowana hurtowo. Do tego dochodzą wspomniane intensywne, długoterminowe testy. Stąd przekonanie autorów, że narzędzie działa stabilnie i zgodnie z założeniami.
Drobna uwaga techniczna dotycząca Linuksa: jeśli chcesz wykonywać wiele pingów równolegle, dodaj odpowiedniego użytkownika lub proces do grupy ping. Wynika to z faktu, że LinkSense realizuje pingi asynchronicznie i wydajnie, zamiast być jedynie nakładką na systemowe polecenie ping.
Chcesz dowiedzieć się więcej o LinkSense bezpośrednio od jego twórców? Obejrzyj dedykowany webinar z Maciejem Wilamowskim i Marcinem Kaźmierczakiem, w którym opowiadają, skąd wziął się pomysł na narzędzie, jak działa jego architektura i w jakich scenariuszach LinkSense może realnie pomóc w monitorowaniu rozproszonych środowisk.
