Monitoruj postęp programu na wielu serwerach


9

Mamy trzy serwery, na których działają programy w języku Python, które wykonują zadania analizy danych w ramach tmuxsesji. Obecnie używamy metody ssh'ing do każdego z nich, łącząc tmuxsesję i obserwując dane wyjściowe w linii poleceń.

Ta metoda jest nużąca, dlatego szukamy rozwiązania automatyzującego monitorowanie postępu programu (danych wyjściowych w interfejsie CLI) dla wielu serwerów jednocześnie. Idealnie chcielibyśmy mieć interfejs WWW, ale interfejs CLI byłby również doskonale odpowiedni.

Dziękuję za przeczytanie.


Odpowiedzi:


8

Za każdym razem, gdy uruchamiasz długo działające polecenia ad-hoc, powinieneś cofnąć się i przemyśleć swój proces, ponieważ powinno to być zautomatyzowane, w tym obsługę błędów.

Zamiast łączyć się z serwerami, aby zobaczyć status, lepszym rozwiązaniem jest wypchnięcie tych informacji. Możesz zrobić wiele różnych rzeczy, jeśli chcesz napisać kilka niestandardowych kodów, ale najprostszą rzeczą jest prawdopodobnie rozpoczęcie wysyłania danych wyjściowych przez syslog do scentralizowanego systemu rejestrowania (sam syslog, ELK lub cokolwiek innego). W ten sposób możesz monitorować wszystko z centralnej lokalizacji.

Myśląc naprzód, jeśli nie jest to jednorazowe zadanie, monitorowanie powinno zostać zautomatyzowane. Oznacza to, że nigdy nie powinieneś po prostu oglądać dzienników, aby sprawdzić, czy wszystko idzie zgodnie z planem. Zamiast tego powinieneś założyć, że są (i kontynuować z innymi pracami), dopóki alarm nie wyłączy się . Jest to inwestycja czasu w uzyskiwanie niezawodnych i szeroko zakrojonych alertów, ale gdy systemy stają się coraz bardziej złożone, to się opłaci, ponieważ nie musisz monitorować wszystkiego za każdym razem, gdy coś zmienisz .


To nie jest jednorazowa sprawa. Podoba mi się twój pomysł poświęcenia czasu na automatyzację monitorowania i centralizację rejestrowania. Czy masz jakieś sugestie dotyczące narzędzi, z których można korzystać bezpłatnie i które działają dobrze z hostami Ubuntu z uruchomionymi programami?
guano

@guano Myślę, że Wissam omówił wszystkie narzędzia , o których wspomniałbym, oprócz używania czegoś takiego jak Sensu do zasilania alarmowania.
Xiong Chiamiov

4

Graylog

Ponieważ dwie osoby już doradziły ci przemyślenie twojego obecnego procesu (który popieram, ponieważ w pewnym momencie spowoduje to nieprzespane noce;)), wybiorę inną drogę i zalecę konkretne oprogramowanie, które - moim zdaniem - pasuje do większości twoje potrzeby: Graylog .

Wdrożyłem i stosowałem kilka stosów ELK zarówno do agregacji dzienników, jak i analizy biznesowej, a także prowadzę / utrzymuję graylog od około dwóch lat u mojego obecnego pracodawcy. Polecam graylog, ponieważ ma on wbudowane następujące funkcje i jest - moim zdaniem - nieco łatwiejszy w konfiguracji i utrzymaniu:

  • Interfejs internetowy
  • Możliwości dla wielu użytkowników
  • Alarmowanie

O ile rozumiem twój scenariusz, wygląda na to, że musisz działać lub otrzymywać powiadomienia o określonych zdarzeniach pojawiających się w strumieniu komunikatów dziennika. Jeśli spojrzymy na funkcje Graylog :

Wyzwalaj działania lub otrzymuj powiadomienia, gdy coś wymaga uwagi, na przykład nieudane próby logowania, wyjątki lub obniżenie wydajności.

Pomysły: Wyślij e-mail lub wiadomość Slack do swojego zespołu. Odradzaj nową maszynę w celu zrównoważenia obciążenia przetwarzania. Automatycznie blokuj zakresy adresów IP w zaporach po wykryciu ataku.

Aby wypróbować graylog, zaleciłbym następujące dwa kroki:

  • Skonfiguruj dedykowanego hosta, który jest dostępny dla wszystkich hostów aplikacji do uruchamiania graylog (i jego zależności MongoDB i ElasticSearch)
  • Wysyłaj dzienniki z aplikacji do graylog (prawdopodobnie jako wiadomości GELF )

Uwaga: te dwa kroki umożliwiają zapełnianie stron najlepszych stron i powinny otrzymać co najmniej kilka przemyśleń. Nie wspominając już o tym, że graylog nie jest rozwiązaniem monitorującym, a sam graylog powinien być monitorowany za pomocą odpowiedniego narzędzia do monitorowania (np. Icinga, Prometheus, Nagios, aby wymienić tylko kilka).


3

Zgadzam się z @Xiong Chiamiov i chcę dać więcej wyjaśnień. Jeśli chcesz monitorować każdą linię w interfejsie CLI, sugeruję przekierowanie wszystkich danych wyjściowych do określonego pliku i błędu do innego pliku, a następnie użyj logstash lub bebe pliku, aby wysłać oba te pliki do Elasticsearch , a następnie możesz skonfigurować Logtril za pomocą Kibana umożliwia przeglądanie, analizowanie, wyszukiwanie i rejestrowanie zdarzeń z wielu hostów w czasie rzeczywistym dzięki przyjaznemu interfejsowi programistów


1

scentralizowany tmux

Podczas gdy inne odpowiedzi są mądrzejsze i mądrzejsze w dłuższej perspektywie, myślę, że warto wspomnieć o szybkim, zhackowanym rozwiązaniu CLI. Uruchom tmuxna jednym serwerze, który może dotrzeć do wszystkich pozostałych. Dobrym miejscem do tego byłoby pole skoku lub inne miejsce, w którym ludzie są często zalogowani. W ramach tego „centralnego” tmuxssh do każdego pola w innym okienku i ogonem, wszystkie niezbędne pliki dziennika. Możesz użyć ctrl-, b "aby uzyskać więcej paneli w jednej zakładce tmux. Teraz wszystko, co ktoś musi zrobić, aby sprawdzić, jest dołączone do tmuxsesji „centralnej” i może zobaczyć cały klaster na pierwszy rzut oka.

Spędziłem dużo czasu na tworzeniu internetowych interfejsów użytkownika, nad którymi pracujesz, ale jeśli potrzebujesz go dzisiaj, zhakowanie czegoś razem tmuxmoże uratować dzień.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.