- PVSM.RU - https://www.pvsm.ru -
Рисунок: Маргарита Закиева
Что будет под катом:
Наша статья будет полезна для тех, кто:
Настраивать связку, о которой пойдёт речь, мы начали ещё за месяц до публичного релиза API, поэтому с самого начала для отправки алярмов с сервера мониторинга был использован «Telegram CLI for Linux [1]». Статья, в первую очередь, посвящена именно этому консольному клиенту. В конце статьи мы подробно объяснили, почему не стали отказываться от него в пользу новшеств из мира ботов.
Мы — дружная команда «Operations» компании МедиаТех [2]. Админить приходится десятки серверов, это могут быть как
У нас вообще нет людей в штате, в обязанности которых входило бы ночью не спать и следить за мониторингом, зато мы имеем один зарегистрированный на «левую» SIM-карту аккаунт, от чьего имени отправляем сообщения и некое количество:
Факап №0 — Не замониторить мониторинг
Рано или поздно вы столкнётесь с тем фактом, что мониторинг тоже может сломаться, а узнать об этом хочется сразу, а не в понедельник, после выходных. В то же время, логично проверять некоторые сервисы «изнутри», а другие, например статус ответа вашего сайта по HTTP — «снаружи». Чтобы «убить двух зайцев одним камнем» настройте себе ещё один Nagios у другого провайдера и распределите нужные вам проверки между двумя мониторингами, не забыв настроить проверку check_nagios [4] одного инстанса на другой и зеркально наоборот. Надеюсь для вас, так же как и для нас, одновременное падения двух провайдеров в разных странах — сценарий крайне маловероятный.
Факап №1 — Отправлять нотификации, которые требуют немедленного вмешательства в систему, для исправления проблемы в тот же чат, что и те алярмы, которые могут подождать или вообще вскоре пропадут, после автоматической починки сервиса.
Если так делать, то все, кто будут просматривать чат вскоре совсем перестанут обращать на него внимание, тем более, если им придётся проснуться в 4 утра из-за ложного срабатывания. Обратная ситуация — полное выключение на ночь мониторинга для лога важного веб-сервера. Не нужно этого делать, всегда существует вероятность, что именно ночью туда закралась очень важная информация, с которой будет необходимо разобраться днём, достаточная мера — отправка таких сообщений на почту, которую вы прочтёте в рабочее время. Разделяйте и властвуйте.
Факап №2 — Реагировать на нотификации по принципу «кто первый увидел».
Если не назначать дежурного, то однажды ночью никто не проснётся, а утром никто виноватым не окажется. Чтобы не проспать ни одного уведомления ночью во время дежурства, на мобильном девайсе, мы советуем настроить уведомления, как представлено на картинке ниже.
Факап №3 — Полагаться только на дежурного.
Горький опыт показал нам, что авария в вашем ДЦ может случиться одновременно с отключением доступа в интернет у дежурного системного администратора дома. Несмотря на то, что мобильный интернет есть у всех, по-умолчанию смартфон у всех подключен к домашнему Wi-Fi и то, что доступа в глобальную паутину там нет его не волнует, «палочки то все три». Впрочем, админ может оказаться недоступен и из-за более простых и линейных жизненных сценариев.
Факап №4 — Отправлять уведомления от робота в чаты, где проходят рабочие обсуждения.
Вам может показаться, что так вы привлечёте к проблеме больше внимания и она решится быстрее, но на самом деле это не так, вы будете только раздражать людей присутствием непонятных сообщений посреди важного обсуждения квартального отчёта. В случае необходимости, просто самостоятельно перешлите сообщение с описанием проблемы из специального канала в рабочий чат.
В качестве примера демонстрирую скриншот с «резервными» каналами и одним тематическим, посвящённом базе данных.
Даже если вы найдёте telegram-cli в репозиториях своего дистрибутива(например RPMfusion Repository для CentOS) или готовый пакет на просторах интернета, настоятельно рекомендуем самостоятельно «собрать и скомпилять», благо данная процедура детально рассмотрена прямо на github страничке проекта [5] для многих *nix систем.
После успешной компиляции бинарника, необходимо создать в системе пользователя с логином «telegramd», для того, чтобы после первого запуска клиента у вас в системе создалась директория /home/telegramd/.telegram-cli, внутри которой клиент после подтверждения своей авторизации будет хранить служебные файлы, например, полученный приватный ключ с серверов Telegram.
И так, у вас в руках телефон с симкой, на которую будем регистрировать Телеграм, а на компьютере открыта консоль сервера с мониторингом.
adduser telegramd # --disabled-login
./bin/telegram-cli -k tg-server.pub
Теперь можно добавить кого-нибудь в «contact_list» по его номеру телефона, насколько нам известно — это единственный способ занести пользователя в «контакты» так, чтобы в последствии отправлять туда уведомления из Nagios. Сделать это можно из консоли или из любого другого клиента [8], включая Telegram Web-version [9], разумеется, предварительно авторизовавшись там с тем же телефонным номером, который вы только что использовали. Для отправки сообщений в общий чат или канал на стороне «робота» вообще ничего делать не нужно, достаточно позаботиться о том, чтобы он был администратором, если вы отправляете сообщения в «канал».
add_contact +79991112233 My Contact
quit
Теперь у нас есть настроенный консольный клиент с одним контактом для отправления туда нотификаций. Для удобства использования обернём это в скрипт на баше.
#!/bin/bash
#This script helps integrate Nagios instances
#with telegrams chats or channels.
sendFunc()
{
"$tgBinPath" `
`--rsa-key "$tgKeyPath" `
`--wait-dialog-list `
`--exec "$tgSendCmd $contactName $messageText" `
`--disable-link-preview `
`--logname "$mesLogFile" `
`>> $mesLogFile
}
#Path setup
tgSendCmd="msg"
tgDir="/usr/local/bin"
tgBinPath=""$tgDir"/telegram-cli"
tgKeyPath=""$tgDir"/tg-server.pub"
logDir="/var/log/telegram"
#dont forget to setup log rotation
mesLogFile=""$logDir"/telegram.log"
#Parse arguments
contactName="$1"
messageText="$2"
sendFunc #send telegram message
exit $?
mkdir -p /var/log/telegram
chown telegramd:nagios /var/log/telegram -R
chmod 770 /var/log/telegram -R
chown telegramd:nagios /usr/local/bin/t*
chmod +x /usr/local/bin/t*
chown telegramd:nagios /home/telegramd/ -R
chmod 770 /home/telegramd/ -R
ln -s /home/telegramd/.telegram-cli/ /var/lib/nagios/.telegram-cli
/usr/local/bin/telegram.sh My_Contact foo # обратите внимание на нижнее подчёркивание
/usr/local/bin/telegram.sh Monitoring bar
Описание команд основано на классическом шаблоне для Jabber. В тексте сообщения используется #ИМЯ_МОНИТОРИНГА, таким образом, оно становится хэш-тегом в тексте сообщения, для нас это удобно.
define contact{
name telegram-contact
service_notification_period 24x7
host_notification_period 24x7
service_notification_options u,c,r,f ; Обратите внимание, уведомления типа "Warning" отправляться не будут
host_notification_options d,u,r,f
service_notification_commands service-notify-by-telegram
host_notification_commands host-notify-by-telegram
register 0
}
define contact{
contact_name telegramonlycrucial
use telegram-contact
alias Telegram OnlyCrucial
address1 Monitoring ; Название канала
}
define command{
command_name host-notify-by-telegram
command_line /usr/local/bin/telegram.sh $CONTACTADDRESS1$ "***** #Nagios_Instance_Name ***** Host $HOSTNAME$ is $HOSTSTATE$ - Info: $HOSTOUTPUT$"
}
define command{
command_name service-notify-by-telegram
command_line /usr/local/bin/telegram.sh $CONTACTADDRESS1$ "***** #Nagios_Instance_Name ***** $NOTIFICATIONTYPE$ $HOSTNAME$ $SERVICEDESC$ $SERVICESTATE$ $SERVICEOUTPUT$ $LONGDATETIME$"
}
Для нас, мониторинг — самая важная и критичная вещь во всей инфраструктуре, а так как уведомления — одна из основных его составляющих, необходимо замониторить сам telegram-cli по следующим метрикам:
1. telegram-cli регулярно обновляется, поэтому работает он стабильно и имеет весь нужный нам функционал.
2. За API всё равно нужно следить, например во время релиза Bot Api 2.0 [12] с ним были замечены сбои, в то время, как обычный клиент работал исправно.
3. Так как мы не используем никакое общение с нашим роботом и не управляем с его помощью мониторингом, нас просто устраивает текущее решение. Работает — не трогай.
При срабатывание на ошибку в логе, часто хочется грепнуть проблемную часть, не включая свой рабочий компьютер или увидеть красивый график, иллюстрирующий масштабы проблемы рядом с очередным критическим алярмом, чтобы, например, оперативно форварднуть его своим коллегам.
Разумеется отправка изображений и других типов документов в Телеграме есть из коробки, так что возможности такого мониторинга ограничены только вашим воображений.
Вот как, к примеру, как у нас реализован механизм «резервных» каналов, здесь представлена упрощенная версия кода, для того, чтобы вам проще было в нём разобраться.
Обещанная ранее программная часть, отвечающая за механизм резервирования каналов. [13]
Удачи с мониторингом ваших проектов и большого аптайма вам, коллеги!
Автор: Zeka13
Источник [14]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/linux/161066
Ссылки в тексте:
[1] Telegram CLI for Linux: https://github.com/vysheng/tg
[2] МедиаТех: https://vk.com/mediatech_spreads
[3] VPS: https://www.reg.ru/?rlink=reflink-717
[4] check_nagios: https://www.monitoring-plugins.org/doc/man/check_nagios.html
[5] github страничке проекта: https://github.com/vysheng/tg/blob/master/README.md
[6] libjansson: https://jansson.readthedocs.org/en/latest/gettingstarted.html
[7] main.c: https://github.com/vysheng/tg/blob/master/main.c#L558
[8] клиента: https://telegram.org/apps
[9] Telegram Web-version: https://telegram.org/dl/webogram
[10] check_logfiles: https://exchange.nagios.org/directory/Plugins/Log-Files/check_logfiles/details
[11] Телеграм может сломаться: https://telegram.org/blog/ddos
[12] Bot Api 2.0: https://core.telegram.org/bots/2-0-intro
[13] Обещанная ранее программная часть, отвечающая за механизм резервирования каналов.: https://github.com/Zeka13/nagios-notify-by-telegram/blob/master/nagios-notify-by-telegram.sh
[14] Источник: https://habrahabr.ru/post/306272/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.