Skocz do zawartości
Matix8981

Monitorowanie portów TCP/UDP

Polecane posty

Witajcie,

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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ć :)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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. 

  • Lubię 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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. 

  • Lubię 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

  • Lubię 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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 :)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

@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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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

 

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

@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.  

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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 :-)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

@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 :-)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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. 

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Dołącz do rozmowy

Możesz pisać i zarejestrować się później. Jeśli masz konto,Zaloguj się teraz, aby publikować na swoim koncie.

Gość
Odpowiedz...

×   Wklejony jako tekst z formatowaniem.   Wklej jako zwykły tekst

  Dozwolonych jest tylko 75 emoji.

×   Twój link będzie automatycznie osadzony.   Wyświetlać jako link

×   Twoja poprzednia zawartość została przywrócona.   Wyczyść edytor

×   Nie możesz wkleić zdjęć bezpośrednio. Prześlij lub wstaw obrazy z adresu URL.


  • Kto przegląda   0 użytkowników

    Brak zalogowanych użytkowników przeglądających tę stronę.

×
×
  • Utwórz nowe...

Ważne informacje

Korzystając z forum, wyrażasz zgodę na: Warunki korzystania z serwisu, Regulamin, Polityka prywatności.