<\/span><\/h2>\nTrzonem projektu jest podzia\u0142 na agent\u00f3w i centralny serwer. Agenci to ma\u0142e binarki rozstawione w r\u00f3\u017cnych lokalizacjach. Wykonuj\u0105 zlecone im testy, przechowuj\u0105 wyniki lokalnie w SQLite, a co 60 sekund tworz\u0105 zagregowane metryki i wysy\u0142aj\u0105 je do centralnego serwera.<\/p>\n
Kluczowy jest kierunek po\u0142\u0105czenia: to agenci aktywnie \u0142\u0105cz\u0105 si\u0119 z serwerem, a nie odwrotnie. Daje to dwie konkretne korzy\u015bci.<\/p>\n
Bezpiecze\u0144stwo.<\/strong> Agent mo\u017ce dzia\u0142a\u0107 na maszynie z firewallem ustawionym wed\u0142ug zasady \u201eblokuj przychodz\u0105ce, zezw\u00f3l na wychodz\u0105ce\u201d. Nie potrzebuje \u017cadnych otwartych port\u00f3w. A brak otwartych port\u00f3w oznacza istotnie mniejsz\u0105 powierzchni\u0119 ataku \u2014 wszyscy s\u0142yszeli\u015bmy o przypadkach przej\u0119cia agent\u00f3w monitoruj\u0105cych, kt\u00f3re potrafi\u0105 sta\u0107 si\u0119 powa\u017cnym zagro\u017ceniem.<\/p>\nProstsze zarz\u0105dzanie.<\/strong> Otwarte porty musi mie\u0107 tylko jedna maszyna \u2014 serwer. Zadbanie o bezpiecze\u0144stwo jednej maszyny jest znacznie prostsze ni\u017c pilnowanie wielu rozproszonych instancji.<\/p>\nTen model ma jeszcze trzeci\u0105 zalet\u0119: masow\u0105 rekonfiguracj\u0119. Konfiguracj\u0119 agent\u00f3w mo\u017cna zmienia\u0107 z poziomu serwera. Wyobra\u017a sobie statek z szesnastoma albo wi\u0119ksz\u0105 liczb\u0105 agent\u00f3w na pok\u0142adzie. Je\u015bli chcesz doda\u0107 im wszystkim jedno nowe zadanie, robisz to jedn\u0105 zmian\u0105 w pliku konfiguracyjnym po stronie serwera. Przy kolejnej aktualizacji agent wykrywa, \u017ce jego konfiguracja jest nieaktualna, pobiera now\u0105 wersj\u0119 z serwera, waliduje j\u0105 i od razu zaczyna z niej korzysta\u0107.<\/p>\n
Architektura jest r\u00f3wnie\u017c \u201elocal-first\u201d, czyli \u201enajpierw lokalnie\u201d. Agent zapisuje wyniki u siebie, na miejscu, i dopiero potem wysy\u0142a je do serwera. Dzi\u0119ki temu nawet je\u015bli serwer chwilowo nie odpowiada, agenci nie trac\u0105 danych i kontynuuj\u0105 monitoring podczas problem\u00f3w sieciowych. Gdy \u0142\u0105czno\u015b\u0107 wraca, dosy\u0142aj\u0105 zebrane metryki. Agent\u00f3w mo\u017cna te\u017c uruchomi\u0107 w trybie w pe\u0142ni samodzielnym, czyli standalone. Je\u015bli traktujesz LinkSense jako ma\u0142y prywatny projekt, nie potrzebujesz centralnego serwera \u2014 wystarczy podejrze\u0107 lokaln\u0105 baz\u0119 SQLite dowolnym narz\u0119dziem.<\/p>\n
<\/span>Co LinkSense potrafi monitorowa\u0107?<\/span><\/h2>\nLinkSense oferuje zestaw gotowych typ\u00f3w zada\u0144.<\/p>\n
Ping<\/strong> \u2014 najprostsze sprawdzenie, jak szybko pakiety wracaj\u0105 i czy nie ma ich utraty, czyli czy cz\u0119\u015b\u0107 wys\u0142anych pakiet\u00f3w nie ginie po drodze.<\/p>\nHTTP GET<\/strong> \u2014 pe\u0142na informacja o \u017c\u0105daniu strony. LinkSense rozbija czas odpowiedzi na sk\u0142adniki: czas nawi\u0105zania po\u0142\u0105czenia TCP, czas zestawienia szyfrowanego po\u0142\u0105czenia, czyli TLS handshake \u2014 moment, w kt\u00f3rym serwer i klient ustalaj\u0105 szyfrowanie, zanim w og\u00f3le zostan\u0105 przes\u0142ane dane \u2014 time-to-first-byte, czyli czas do pierwszego bajtu odpowiedzi i informacj\u0119 o tym, jak d\u0142ugo serwer \u201emy\u015bli\u201d, zanim cokolwiek ode\u015ble, oraz ca\u0142kowity czas pobrania. Do tego dochodz\u0105 kody statusu HTTP, informacja o tym, czy certyfikat jest wa\u017cny, oraz ile dni zosta\u0142o do jego wyga\u015bni\u0119cia.<\/p>\nTCP i TLS<\/strong> \u2014 w praktyce \u201epodzadania\u201d HTTP GET. Czasem nie chcesz pobiera\u0107 ca\u0142ej strony, a jedynie sprawdzi\u0107, czy dany port jest otwarty, czyli TCP, albo czy poprawnie zestawia si\u0119 szyfrowanie, czyli TLS \u2014 bez pe\u0142nego zapytania HTTP.<\/p>\nDNS<\/strong> \u2014 sprawdza, czy nazwy domen poprawnie t\u0142umacz\u0105 si\u0119 na adresy IP. Co wa\u017cne, to zadanie u\u017cywa w\u0142asnego resolvera, a nie systemowego. Resolver to mechanizm, kt\u00f3ry zamienia nazw\u0119, na przyk\u0142ad sycope.com, na adres IP. System operacyjny zwykle zapami\u0119tuje, czyli cache\u2019uje, wyniki, wi\u0119c kolejne zapytania nie trafiaj\u0105 realnie do serwera DNS. W\u0142asny resolver omija ten cache i rzeczywi\u015bcie odpytuje DNS za ka\u017cdym razem. Dzi\u0119ki temu mierzysz faktyczny stan, a nie zapami\u0119tan\u0105 odpowied\u017a.<\/p>\nHTTP content<\/strong> \u2014 pozwala zajrze\u0107 w tre\u015b\u0107 odpowiedzi za pomoc\u0105 wyra\u017cenia regularnego, czyli regexu \u2014 wzorca do wyszukiwania konkretnego tekstu w tre\u015bci strony. To przydatne wtedy, gdy aplikacja zwraca status 200, czyli \u201ewszystko OK\u201d, ale w tre\u015bci komunikuje na przyk\u0142ad okno serwisowe. Sam kod statusu by tego nie wychwyci\u0142, natomiast dopasowanie wzorca w tre\u015bci ju\u017c tak.<\/p>\nBandwidth<\/strong> \u2014 pomiar przepustowo\u015bci \u0142\u0105cza, zawsze pomi\u0119dzy agentem a serwerem. Po stronie serwera dzia\u0142a kolejkowanie, aby kilka test\u00f3w uruchomionych jednocze\u015bnie nie zafa\u0142szowa\u0142o sobie nawzajem wynik\u00f3w.<\/p>\nSQL query i SNMP query<\/strong> \u2014 zadania opcjonalne, wykraczaj\u0105ce poza g\u0142\u00f3wne przeznaczenie narz\u0119dzia. Zapytanie SQL pozwala sprawdzi\u0107 nie tylko, czy baza danych odpowiada, ale te\u017c czy dane w niej s\u0105 poprawne, na przyk\u0142ad policzy\u0107, ile wierszy zwraca konkretne zapytanie. SNMP to standardowy protok\u00f3\u0142 do odpytywania urz\u0105dze\u0144 sieciowych o ich stan. Pozwala pobiera\u0107 konkretne warto\u015bci spod tzw. OID-\u00f3w, czyli numerycznych identyfikator\u00f3w konkretnych informacji w urz\u0105dzeniu \u2014 na przyk\u0142ad obci\u0105\u017cenia CPU, nazwy hosta czy opisu urz\u0105dzenia.<\/p>\n