Jak pisałem mój monitoring

Postanowiłem podzielić się swoją historią. Może komuś przyda się takie budżetowe rozwiązanie powszechnego problemu.

Kiedy byłem młody i pełen energii, nie wiedząc, co z nią zrobić, postanowiłem spróbować freelancingu. Szybko zdobyłem ocenę i znalazłem kilku stałych klientów, którzy poprosili mnie o stałe wsparcie ich serwerów.

Pierwsza myśl, która przyszła mi do głowy, to konieczność monitorowania. Postanowiłem zrobić tak, jak mądrzy ludzie, nie wynajdywać koła na nowo i sprawdzić gotowe rozwiązania, takie jak Munin czy Zabbix. Szybko jednak odkryłem, że wersja webowa wymaga dobrej łączności internetowej, szczególnie gdy otwierasz ją po raz pierwszy na telefonie. Gdy odpoczywasz na łonie natury z dala od miasta, uzyskanie stabilnego połączenia jest trudne. Dlatego zdecydowałem się na konsolową wersję monitorowania.

Jako konsolowe monitorowanie dobrze sprawdził się atop oraz program do czytania logów atop’a — atopsar. Były już wspomniane na habr, atop został nawet opisany,natomiast o atopsarze prawie nic nie wspomniano.

Instalacja

Bardzo prosty proces instalacji, tylko trzy komendy.

#Centos

yum install atop

#Debian/Ubuntu

apt-get install atop

Następnie można dostosować ustawienia monitorowania do siebie lub użyć domyślnych.

#Debian/Ubuntu/Centos

/etc/default/atop 

Standardowy plik:

 #cat /etc/default/atop
INTERVAL=60                    #Время, через которое создаётся снимок нагрузки в секундах, по умолчанию каждые 10 минут
LOGPATH="/var/log/atop"        #Путь до папки хранения логов
OUTFILE="$LOGPATH/daily.log"   #Название файла логов за сегодняшний день

Dodajemy do autostartu
#Debian/Ubuntu/Centos

systemctl enable atop 

Uruchamiamy atop jako demon
#Debian/Ubuntu/Centos

systemctl start atop  

Dla leniwych zebrałem w jedną komendę
#Centos

yum install atop && systemctl enable atop && systemctl start atop

#Debian/Ubuntu

apt-get install atop && systemctl enable atop && systemctl start atop

Atopsar

Razem z atopem instalowany jest również atopsar, co jest wygodnym konsolowym analizatorem binarnych logów prowadzonych przez demona atop. Oczywiście można czytać logi samym atopem, ale to nie jest tak wygodne, gdy trzeba uchwycić dużą ilość czasu.

Krótki przewodnik po działaniu atopsar.

Po uruchomieniu atopsar bez parametrów otwierany jest log z dzisiejszego dnia, a obciążenie na każdym rdzeniu jest wyświetlane oddzielnie, a także linia idl dla wszystkich rdzeni.

Parametry, które używam:

-A = wyświetlić wszystkie informacje z logu
-c = wyświetlić informacje o obciążeniu rdzeni procesora, klucz domyślny
-m = obciążenie pamięci RAM i swap
-d = aktywność dyskowa
-O = top 3 procesy obciążające CPU
-G = top 3 procesy obciążające RAM
, to będzie on umieszczał w nim ostatni blok masterchaina: = top 3 procesy obciążające dysk
-N = top 3 procesy obciążające sieć
-r = podaj ścieżkę do logu, który chcesz przeczytać, jeśli chcesz zobaczyć obciążenie z dni przeszłych
-b = czas, od którego zacząć wyświetlanie
-e = czas, do którego należy zakończyć wyjście
-M = tworzy dodatkową kolumnę na końcu, w której oznaczana jest krytyczność wiersza (+ jest obciążenie, * — krytyczne obciążenie)

Dzięki monitorowaniu będziemy mogli zrozumieć przyczynę nieprawidłowego działania serwera w każdym momencie.

Powiadomienia

Zatem monitorowanie obciążenia istnieje, ale nadal nie daje możliwości szybkiego znajdowania i rozwiązywania problemów. Potrzebujemy powiadomień o wystąpieniu problemu.

Sama obserwuję serwery, więc powiadomienia muszą trafiać tam, gdzie zawsze mogę je zobaczyć i w jakiś sposób zareagować.

Na początku były SMS-y — szybko, niezawodnie, za darmo. Ale potem operatorzy komórkowi zamknęli darmową wysyłkę SMS-ów przez swoje bramy.
E-mail — długo, mogą być problemy z dostarczeniem.
Komunikatory — trzeba je zainstalować na telefonie, konieczne jest tworzenie botów.

W wyniku poszukiwań wybrano komunikator Telegram za jego prostotę i wygodne aplikacje na telefonie i desktopie.

Stworzyłem swojego bota za pomocą botfather.
Następnie umieściłem na serwerze kilka skryptów, które monitorują obciążenie serwera (IDL, smartct i inne), obecność błędów typu „oom killer”, błędy przy tworzeniu kopii zapasowej i inne operacje, które należy kontrolować.

Skrypty są dość proste, napisane w bash, na przykład sprawdzanie LA i powiadomienie o przekroczeniu Load Average liczby rdzeni na serwerze.

if [ ${LA[0]} -gt 2000 ] || [ ${LA[1]} -gt 3000 ] || [ ${LA[2]} -gt 4000 ]
    then
        wget -O /dev/null "https://api.telegram.org/$bot_id:$bot_key/sendMessage?chat_id=$chat_id&text=Na serwerze $ip LA $LAd"
        wget -O /dev/null "https://api.telegram.org/$bot_id:$bot_key/sendMessage?chat_id=$chat_id&text=`top -b -n 1 | grep Cpu`"
        wget -O /dev/null "https://api.telegram.org/$bot_id:$bot_key/sendMessage?chat_id=$chat_id&text=Top 5 procesów `top -b -n 1 | grep -A 5 'PID USER' | tail -5`"
    fi

Prostota składni daje wiele możliwości użycia (i napisać/można dodać może każdy, kto choć trochę zna język programowania).

Jedynym szczegółem jest to, że jeśli serwer znajduje się w Rosji (i nie masz IPv6 na serwerze), to należy korzystać z proxy. W tym celu na początku skryptu należy wpisać linię połączenia z proxy:

export https_proxy=http://login:hasło@IP.adres:port

To jeszcze nie koniec

Idziesz sobie spokojnie po górach z plecakiem na plecach, odpoczywając od cywilizacji, gdy nagle telefon, przypadkowo łapiąc sygnał, wysyła powiadomienie o problemie na twoim serwerze. Co robić? Bezmienne nastroje jakby wietrkiem rozwiało. Dzwonić do żony i dyktować komendy? Ha-ha!

Musiałem szybko wymyślić jakiś sposób na rozwiązanie pojawiłych się problemów szybko i bez dostępu do dobrego internetu. Tutaj znów uratował mnie komunikator (#telegramżyje). Nauczyłem swojego bota rozmawiać tylko ze mną, ignorując wszystkich innych. Teraz, razem z powiadomieniem o problemie, otrzymuję trochę więcej danych, dzięki którym rozumiem, kto jest źródłem problemu i mogę spróbować go rozwiązać zdalnie. Wystarczy że napiszę wiadomość do bota, podniosę telefon wyżej, aby ta wiadomość się wysłała, i voila — bot poszedł wykonać twoją pracę. W ten sposób mogę na przykład zabić jakiś niepożądany proces, zrestartować demona, zablokować IP i inne.

Do tego przeniosłem przyszłe potrzebne zapytania od klientów, na przykład pilny reset haseł użytkowników (bo „Aaa, nie możemy dostać się na serwer, tracimy miliony!”), wyszukiwanie użytkownika mającego dostęp do odpowiedniego folderu, włączanie i wyłączanie strony i inne. Oczywiście ciągle rozwijam funkcjonalność bota, ponieważ wyobraźnia klientów czasami przynosi niespodziewane i nieprzewidziane przeze mnie prośby. Ale główni są zadowoleni.

Jest też wersja na VK, ale jakoś się nie przyjęła.

Teraz spokojnie podróżuję i odkrywam ten świat, nie bojąc się, że coś się zepsuje, a ja nie będę o tym wiedział lub nie będę mógł naprawić.

Źródło: habr.com