Monitorowanie portów TCP/UDP

[Matix8981]

Witajcie,

Znacie jakiś pakiet do monitorowania portów TCP i UDP i jeżeli port nie odpowiada powiedzmy po 5min to wykonuje polecenie

[gb1]

@MateuszCODE z ciekawości zapytam jak chcesz monitorować port UDP ?

[SomeGuy]

Sprawdzasz działanie daemona/softu/apki/skryptu poprzez monitor portu? Coś więcej może napisz. 

[Matix8981]

Właśnie aktualnie nie posiadam żadnego monitoringu, Posiadam serwer pewnej gry który posiada protokół główny UDP. Można sprawdzić czy serwer działa poprzez lib GameQ w php lecz nie zawszę poprawnie skomunikuje się z PHP. Również poszukuje monitoringu do innych rzeczy na portach TCP/UDP, lecz głównie pod serwer gry bo czasem lubi się zcrashować

[SomeGuy]

Jeśli stoi na linux to trochę od d strony, wystarczy sprawdzić czy aplikacja chodzi/jaki kod wyjścia przy ew. error. GameQ z tego co widzę po prostu wysyła zapytanie do serwera, zrób to samo z pominięciem PHPa. 

[Matix8981]

3 minuty temu, SomeGuy napisał:

Jeśli stoi na linux to trochę od d strony, wystarczy sprawdzić czy aplikacja chodzi/jaki kod wyjścia przy ew. error. GameQ z tego co widzę po prostu wysyła zapytanie do serwera, zrób to samo z pominięciem PHPa. 

Oczywiście że linux, nie pchał bym się nigdy na Windows'a. W tym jest problem, że proces chodzi lecz crash się robi i serwer stoi w stanie hibernacji i muszę go resetować ręcznie. Więc zostaje napisać coś w stylu GameQ na bash zamiast PHP.

[SomeGuy]

Z grami za wiele wspólnego już nie mam, ale swojego czasu Q3 był całkiem solidnie rozbudowany pod względem remote access, i z serwera zewnętrznego (czy też PCta) można było wysłać zwykłe zapytanie w stylu "get players list" (dawno dosyć i nie pamiętam teraz dokładnie). Jeśli natomiast ta gra jest popularna to na pewno istnieją już rozwiązania na tę bolączkę.  Na przyszłość pytaj wprost, łatwiej nakierować na odpowiedź czy też rozwązanie lub wskazówkę. Monitoring TCP/IP to zbyt obszerne pojęcie. 

[Suspect]

Najlepszą metodą monitoringu będzie query np. w php o którym już wcześniej wspomniałeś. Jeżeli obawiasz się fałszywych wyników to ustaw odpowiednio wyższy timeout a do tego 2-3 krotne powtórzenie komunikacji w przypadku braku odpowiedzi, następnie reakcja w postaci restartu serwera.

 

Inna metoda to analiza logów serwera gry wywoływana z crona. Tworzysz sobie w systemie skrypt w bashu który szuka w logach informacji o crashu serwera. Jeżeli ją znajdzie to wykonuje restart serwera.

[Poziomecki]

Zabbix ma funkcję monitorowania portu. Nie wiem czy UDP, ale TCP na pewno. Możesz też go użyć do wykonania zdalnej komendy / skryptu.

[SomeGuy]

18 minut temu, Poziomecki napisał:

Zabbix ma funkcję monitorowania portu. Nie wiem czy UDP, ale TCP na pewno. Możesz też go użyć do wykonania zdalnej komendy / skryptu.

 

Przerost formy nad treścią IMO

[Archi]

if netstat -tulpn | grep -F udp | grep -Fq ':53'; then echo "stoi"; else echo "zresetuj"; fi

 

Nawet mi się nie chce ładnego basha pisać na takie bzdety.

[SomeGuy]

@Archi Twoje rozwiązanie jest ok o ile serwer się wyłączy, przestanie nadawać, a bywa też tak, że serwer po prostu się wiesza i odrzuca jakiekolwiek requesty.

[gb1]

4 godziny temu, Archi napisał:

Nawet mi się nie chce ładnego basha pisać na takie bzdety

 

a potrafisz ładny bash napisać ? ;-)

Należy jednak przyznać że rozwiązanie @Archi choć "toporne" to jedyne rozsądne. @MateuszCODE zakłąda monitorowanie portu tcp/udp, tak jak w przypadku tcp nie ma większego problemu, tak w przypadku udp nie jest to takie banalne :-) Choć jak rozwiązanie przedstawione przez @Archi wskazuje jeśli monitorujemy z tego samego systemu na którym socket jest otwarty to jest to znacznie prostsze.

Natomiast wygląda na to że @MateuszCODE  nie planuje monitorować portu udp, a jedynie usługę która jest udostępniona na tym porcie, a to znacząco upraszcza zadanie :-) Najwygodniej prosty skrypt w pętli wysyłający request po UDP, czekający na odpowiedź, sprawdzający zawartość po czym czekający "n" czasu do kolejnej próby.

 

Jeśli natomiast monitorując z tego samego hosta jak sugeruje @Archi to ja bym bardziej szedł w kierunku:

 

sudo lsof -Pi UDP:53

 

[Matix8981]

@gb1 Sprawdzę przez lsof. Monitorowanie tego serwera nie jest proste ponieważ , wydarzy się crash i proces nadal jest więc sprawdzanie procesu odpada.

[gb1]

@MateuszCODE ja bym nie szedł w kierunku monitorowania otwartego socketu, a na bazie tego co pisałeś bardziej w monitorowanie aplikacji przez otwarty socket. Czyli wysłania zapytania do aplikacji przez sieć, otrzymanie odpowiedzi, podjęcie decyzji co dalej zrobić na tej bazie, odczekanie wyznaczonego czasu i ponownie od początku. Jak sam napisałeś w przypadku "crash" process nadal działa i w takiej sytuacji zapewne także socket nadal jest otwarty wiec monitorowanie samego socketu nic Tobie nie wniesie.  

[Archi]

No jeśli aplikacja jest tak spieprzona, że nawet socketu nie umie zamknąć jak się wywali to rzeczywiście pozostaje Ci wysłanie odpowiednio requesta i czekanie na odpowiedź. W tym wypadku wykorzystanie jakiejś biblioteki API danej gry będzie lepsze niż wysyłanie czystych pakietów po UDP.

[gb1]

17 godzin temu, Archi napisał:

No jeśli aplikacja jest tak spieprzona, że nawet socketu nie umie zamknąć jak się wywali

 

Wszystko zależy od architektury aplikacji, jeśli składa się z licznych komponentów w formie subsystemów, mikroserwisów lub podobnych to część odpowiedzialna za otwarty socket jest tylko gatewayem, zatem jeśli inny komponent zwraca błąd lub jest "crashed" nie oznacza że musi zwolnić socket. Dobrym przykładem jest serwer http (np. apache lub nginx) i serwer aplikacji php działający osobno (w formie fpm lub podobnej). Błąd aplikacji lub serwera aplikacyjnego nie oznacza w takim przypadku konieczności zwolnienia socketu.

Jednak coś czuję że to jest jednak aplikacja monolityczna :-)

[Archi]

14 godzin temu, gb1 napisał:

zatem jeśli inny komponent zwraca błąd lub jest "crashed" nie oznacza że musi zwolnić socket.

 

Jeśli następuje crash aplikacji, w której nie jest ona w stanie poprawnie dalej funkcjonować (a nie jakiś wyjątek pojedynczego requesta), to aplikacyjnym obowiązkiem jest zwolnić wszelkie zasoby, w tym sockety, wątki jak i swoje podprocesy, a następnie zakończyć się z nie-zerowym kodem błędu. Taka sytuacja jest jedynie dopuszczalna w trybie debugowania gdy aplikacja czeka na podpięcie debuggera typu GDB w celu zbadania problemu.

 

Oddziel sobie terminy "błąd aplikacji" od "crash aplikacji". Błąd to sytuacja obsłużona, w której coś co nie powinno się wydarzyć się wydarzyło - nieistotne jest to co tym błędem jest, jeśli aplikacja ma logikę żeby go obsłużyć (niezależnie czy to będzie shutdown, continue, exception czy wpis do logu), to jest w stanie dalej działać (a jak nie to ponownie kończy się z nie-zerowym kodem błędu i zwalnia zasoby). Crash to sytuacja w której aplikacja nie ma logiki do obsługi danego zdarzenia, może to być zarówno native crash jak np. segfault, ale i managed crash jak np. NRE w językach obiektowych czy po prostu stack overflow albo inne przypadki. W takiej sytuacji proces aplikacji ma obowiązek się zakończyć z nie-zerowym kodem błędu, tak aby kernel mógł zwolnić zasoby. W przypadku np. takiego segfaulta, to się dzieje automatycznie i już nie masz pola do manerwu bo kernel robi to za ciebie.

 

Nie ma tutaj pola do dyskusji - jeśli taka aplikacja "zwisa" w miejscu i czeka na killa to jest spieprzona, chyba że działa w trybie debugowania, a takie tryby nie są rozwiązaniami produkcyjnymi.

[gb1]

@Archi zgadzam się z Tobą jednak bierzesz pod uwagę monolityczne aplikacje, trudno aby bardziej złożone aplikacje o architekturze rozproszonej się w taki sposób zachowywały

 

9 godzin temu, Archi napisał:

jeśli taka aplikacja "zwisa" w miejscu i czeka na killa to jest spieprzona, chyba że działa w trybie debugowania, a takie tryby nie są rozwiązaniami produkcyjnymi.

 

Tak powinno być, jednak życie pokazuje że teoria znacznie różni się od praktyki :-)

[Archi]

To czy aplikacja jest monolityczna czy rozproszona nie ma dużo do gadania. Nie oczekuję od slave'a mysql, że zabije mi mastera, bo to jest niedorzeczne, ale jak najbardziej powinien zakończyć proces z nie-zerowym kodem błędu jeśli dojdzie do jakiegoś nieobsłużonego błędu czy crasha. Obowiązkiem procesu w przypadku awarii jest zakończyć wszystkie swoje procesy i procesy dzieci, nie musi od razu rozwalać całej architektury, to tak jak padnięcie pojedynczego node'a.

[gb1]

16 godzin temu, Archi napisał:

Obowiązkiem procesu w przypadku awarii jest zakończyć wszystkie swoje procesy i procesy dzieci, nie musi od razu rozwalać całej architektury, to tak jak padnięcie pojedynczego node'a.

 

Czyli jednak gra rolę czy aplikacja jest monolityczna czy rozproszona :-) Z powyższym się jak najbardziej zgadzam, jednak zaprzecza to Twojemu pierwszemu zdaniu. Jeśli jeden "node" w aplikacji się "crashuje" nie oznacza że socket na którym przyszło zapytanie musi zostać zwolniony, zatem monitorowanie tego socketu nie jest zbytnio istotne. Pamiętajmy jakiego konkretnego przypadku dyskusja dotyczy.