Како ја напишав мојата мониторинг

Реших да споделя моята история. Може би ще е полезна на някого като икономично решение на една добре известна проблема.

Когато бях млад и пълен с енергия и не знаех какво да правя с нея, реших да пофриланся. Успях бързо да изградя рейтинг и намерих няколко постоянни клиенти, които ме помолиха да поддържам техните сървъри на постоянна основа.

Първото, за което pomislih, беше необходимостта от мониторинг. Реших да направя както умните хора, да не изобретявам велосипед, а да разгледам готовите решения, като Munin или Zabbix. Но веднага установих, че уеб версията изисква добро интернет свързване, особено ако я отворите за първи път от телефона. Ако пък почивате на природа далеч от града, е трудно да получите стабилна свързаност. Затова избрах конзолния вариант за мониторинг.

Като конзолен мониторинг много ми помогна atop и програмата за четене на логове atop’а — atopsar. Те вече бяха споменавани на habr, atop дори беше разбран, но почти не се споменава за atopsar.

Инсталиране на

Много лесна инсталация, само три команди.

#Centos

yum install atop

#Debian/Ubuntu

apt-get install atop

След това можете да настроите работата на мониторинга според себе си или да използвате настройките по подразбиране.

#Debian/Ubuntu/Centos

/etc/default/atop 

Стандартен файл:

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

Добавяме в автозапуск
#Debian/Ubuntu/Centos

systemctl enable atop 

Стартираме atop като демон
#Debian/Ubuntu/Centos

systemctl start atop  

За мързеливите събрах в една команда
#Centos

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

#Debian/Ubuntu

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

Atopsar

Заедно с atop се инсталира и atopsar, удобен конзолен анализатор на бинарни логове, водени от демона atop. Разбира се, можете да четете логовете и с atop, но не е толкова удобно, ако трябва да уловите голям интервал от време.

Няколко основни неща за работа с atopsar.

При стартиране на atopsar без ключове се отваря логът за днешния ден и се показва натоварването на всяко ядро поотделно и редът idl за всички ядра.

Ключовете, които използвам:

-A = показва цялата информация от лога
-c = показва информация за натоварването на ядрата на процесора, ключ по подразбиране
-m = натоварване на оперативната памет и swap
-d = дискова активност
-O = топ-3 процеси с натоварване на CPU
-G = топ-3 процеси с натоварване на RAM
-D = топ-3 процеси с натоварване на диск
-N = топ-3 процеси с натоварване на мрежата
-r = посочете пътя до лога, който искате да прочетете, ако искате да видите натоварването за предишни дни
-b = времето, от което да започнете извеждането
-e = времето, до което трябва да завършите извеждането
-M = създава допълнителна колона в края, в която се обозначава критичността на реда (+ има натоварване, * — критично натоварване)

Благодарение на мониторинга можем да разберем причината за некоректното поведение на сървъра по всяко време.

Уведомления

И така, мониторинг на натоварването има, но все пак не дава възможност за бързо намиране и решаване на проблеми. Нуждаем се от уведомления за възникнали проблеми.

Аз единствено следя сървърите, затова трябва да получавам уведомления там, където винаги мога да ги видя и поне малко да реагирам на тях.

В началото имаше SMS – бързи, надеждни, безплатни. Но после мобилните оператори затвориха безплатното SMS разпространение през своите шлюзове.
Пощата – дълго, могат да има проблеми с доставката.
Месинджърите – трябва да се инсталират на телефона, необходимо е да се създават ботове.

В резултат на търсенето беше избран месинджърът Телеграм заради простотата и удобното приложение на телефона и десктопа.

Създадох своя бот с помощта на botfather.
След това поставих на сървъра няколко скрипта, наблюдаващи натоварването на сървъра (IDL, smartct и други), наличието на грешки от вида „oom killer“, грешки при създаване на бекъп и други операции, които трябва да се контролират.

Скриптовете са доста прости, написани на bash, например, проверка на LA и уведомление за превишаване на Load Average над броя ядра на сървър.

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=На сървъра $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=Топ 5 процеси `top -b -n 1 | grep -A 5 'PID USER' | tail -5`"
    fi

Простотата на синтаксиса предлага много варианти за използване (и може да напише/допълни всеки, който малко владее програмния език).

Единственото нещо е, че ако сървърът е в Русия (и нямате IPv6 на сървъра), трябва да ползвате прокси. За целта в началото на скрипта трябва да зададете строката за свързване с прокси:

export https_proxy=http://логин:парола@IP.адрес:порт

Това не е краят

Вървиш спокойно из планините с раница на гърба, отдъхваш от цивилизацията, и изведнъж телефонът, случайно улавяйки сигнал, ти изпраща уведомление за проблем, възникнал на сървъра ти. Какво да правиш? Безгрижното настроение като с вятър се издухва. Да звъня на жена си и да диктувам команди? Ха-ха!

Трябваше бързо да измисля начин за отстраняване на възникналите проблеми бързо и без добър интернет. Тук отново ме спаси мессенджърът (#телеграммживи). Научих своя бот да общува само с мен, игнорирайки всички останали. Сега, заедно с уведомлението за проблема, получавам малко повече данни, от които разбирам кой е източникът на проблема и мога да опитам да го реша отдалеч. Достатъчно е просто да напиша съобщение на бота, да повдигна телефона нагоре, за да потегли съобщението, и ето — ботът започва да върши работата ти. По този начин мога, например, да убия някой нежелан процес, да рестартирам демона, да блокирам IP и още.

Тук пренесох бъдещите нужни заявки от клиентите, например, спешен нулиране на пароли на потребители (защото "Аааа, не можем да влезем на сървъра, губим милиони!"), намиране на потребител, който има достъп до нужната папка, включване и изключване на сайта и други. Разбира се, постоянно усъвършенствам функционалността на бота, тъй като фантазията на клиентите понякога предлага неочаквани и не предвидени от мен заявки. Но основните са доволни.

Съществува и версия за VK, но тя сякаш не успя да се наложи.

Сега спокойно пътувам и изследвам този свят, без да се страхувам, че нещо може да се счупи и аз няма да мога да разбера или да го поправя.

Източник: habr.com