Рисунок: Маргарита Закиева
Что будет под катом:
- Базовые настройки Nagios в связке с Telegram.
- Общая концепция нашего с коллегами мониторинга проектов.
- Разбор граблей, на которые мы успели наступить при работе с этой системой.
Наша статья будет полезна для тех, кто:
- Недоволен информативностью своего текущего мониторинга.
- Испытывает ежедневную боль ниже спины с оповещениями о проблемах.
Эта статья не про «Telegram Bot API»
Настраивать связку, о которой пойдёт речь, мы начали ещё за месяц до публичного релиза API, поэтому с самого начала для отправки алярмов с сервера мониторинга был использован «Telegram CLI for Linux». Статья, в первую очередь, посвящена именно этому консольному клиенту. В конце статьи мы подробно объяснили, почему не стали отказываться от него в пользу новшеств из мира ботов.
Кто мы и чем занимаемся
Мы — дружная команда «Operations» компании МедиаТех. Админить приходится десятки серверов, это могут быть как VPS, так и «железные» сервера, в том числе в Colocation, а разбросаны они по всему миру. Правильная и эффективная работа с мониторингом — наш основной приоритет.
Общая концепция
У нас вообще нет людей в штате, в обязанности которых входило бы ночью не спать и следить за мониторингом, зато мы имеем один зарегистрированный на «левую» SIM-карту аккаунт, от чьего имени отправляем сообщения и некое количество:
- Инстансов Nagios — это никак не связано с реализацией отправки уведомлений, просто мы хотим подчеркнуть, что с несколькими Nagios одновременно, всё работает без каких-либо сбоев.
Факап №0 — Не замониторить мониторинг
Рано или поздно вы столкнётесь с тем фактом, что мониторинг тоже может сломаться, а узнать об этом хочется сразу, а не в понедельник, после выходных. В то же время, логично проверять некоторые сервисы «изнутри», а другие, например статус ответа вашего сайта по HTTP — «снаружи». Чтобы «убить двух зайцев одним камнем» настройте себе ещё один Nagios у другого провайдера и распределите нужные вам проверки между двумя мониторингами, не забыв настроить проверку check_nagios одного инстанса на другой и зеркально наоборот. Надеюсь для вас, так же как и для нас, одновременное падения двух провайдеров в разных странах — сценарий крайне маловероятный.
Как выглядит наш мониторинг мониторинга
- Настроенных уведомлений для сервисов — ключевой момент здесь — это настройка в месенджер только самых важных уведомлений, скорее всего это будет CRITICAL нотисы по самым ключевым метрикам на самых важных хостах. Остальное, например, WARNING или хосты-песочницы настраиваются на отправку сообщений вне той схемы, которая описана в данной статье. Это может быть, например, почта или «личка» c роботом в том же Телеграме.
Факап №1 — Отправлять нотификации, которые требуют немедленного вмешательства в систему, для исправления проблемы в тот же чат, что и те алярмы, которые могут подождать или вообще вскоре пропадут, после автоматической починки сервиса.
Если так делать, то все, кто будут просматривать чат вскоре совсем перестанут обращать на него внимание, тем более, если им придётся проснуться в 4 утра из-за ложного срабатывания. Обратная ситуация — полное выключение на ночь мониторинга для лога важного веб-сервера. Не нужно этого делать, всегда существует вероятность, что именно ночью туда закралась очень важная информация, с которой будет необходимо разобраться днём, достаточная мера — отправка таких сообщений на почту, которую вы прочтёте в рабочее время. Разделяйте и властвуйте.
Типичный канал, на который реагирует дежурный
- Системных администраторов, которые по очереди приступают к ежедневному «дежурству» на мониторинге, которое длится сутки с 23:00 до 23:00. Администратор, который находится на дежурстве, должен включить (или не выключать) уведомления для канала, который настроен как адресат по умолчанию для критических алярмов из Nagios.
Факап №2 — Реагировать на нотификации по принципу «кто первый увидел».
Если не назначать дежурного, то однажды ночью никто не проснётся, а утром никто виноватым не окажется. Чтобы не проспать ни одного уведомления ночью во время дежурства, на мобильном девайсе, мы советуем настроить уведомления, как представлено на картинке ниже.
Настройка уведомлений на телефоне или планшете
- Резервных каналов. Идея проста — если на конкретную поломку никто не отреагировал в течение получаса, мониторинг в автоматическом режиме переключается с обычного чата, на «экстренный», в котором, так же как и в предыдущем, находятся все администраторы. Его отличие заключается в том, что игнорировать его нельзя никому, уведомления должны быть включены всегда и у всех. Также можно сделать ещё один чат не только с администраторами, но и, например, с директорами, на случай, если сервис не работает уже час и никто, в чьи обязанности входит за ними следить, не реагирует на мониторинг. Как именно они реализованы с технической точки зрения — в самом конце статьи.
Факап №3 — Полагаться только на дежурного.
Горький опыт показал нам, что авария в вашем ДЦ может случиться одновременно с отключением доступа в интернет у дежурного системного администратора дома. Несмотря на то, что мобильный интернет есть у всех, по-умолчанию смартфон у всех подключен к домашнему Wi-Fi и то, что доступа в глобальную паутину там нет его не волнует, «палочки то все три». Впрочем, админ может оказаться недоступен и из-за более простых и линейных жизненных сценариев.
Резервные каналы, для которых у всех всегда включены уведодмления
- Тематических каналов. Системный администратор может устранить далеко не все неисправности, обнаруженные мониторингом, например, ошибки в логах приложения или специфичные дедлоки в базе данных. Концепция «разбудить системного администратора, чтобы он разбудил бекенд разработчика» нам кажется неправильной, поэтому под такие уведомления отдельно созданы «тематические» каналы, ответственность за которые несут не системные администраторы, а другие профильные специалисты.
Факап №4 — Отправлять уведомления от робота в чаты, где проходят рабочие обсуждения.
Вам может показаться, что так вы привлечёте к проблеме больше внимания и она решится быстрее, но на самом деле это не так, вы будете только раздражать людей присутствием непонятных сообщений посреди важного обсуждения квартального отчёта. В случае необходимости, просто самостоятельно перешлите сообщение с описанием проблемы из специального канала в рабочий чат.
В качестве примера демонстрирую скриншот с «резервными» каналами и одним тематическим, посвящённом базе данных.
Тематический канал, посвящённый базе данных
Небольшое резюме: после принятия описанных выше договорённостей, системным администраторам стало работать намного проще. Это позволило им отвлекаться на уведомления от смартфона реже и дало возможность научиться тратить рабочее время на совершенствование инфраструктуры фирмы. Качество сна админов улучшилось, а «топы» больше не беспокоятся о том, что ночью случиться факап с даутаймом жизненно важных для компании сервисов и её репутация будет подорвана.
Отправляем Nagios уведомления в Telegram.
Установка и первый запуск консольного клиента
Даже если вы найдёте telegram-cli в репозиториях своего дистрибутива(например RPMfusion Repository для CentOS) или готовый пакет на просторах интернета, настоятельно рекомендуем самостоятельно «собрать и скомпилять», благо данная процедура детально рассмотрена прямо на github страничке проекта для многих *nix систем.
Примечание для любителей Fedora и CentOS
для Fedora 20 и CentOS 6, необходимо предварительно самостоятельно скомпилировать libjansson, которого не оказалось в стандартных репах.
После успешной компиляции бинарника, необходимо создать в системе пользователя с логином «telegramd», для того, чтобы после первого запуска клиента у вас в системе создалась директория /home/telegramd/.telegram-cli, внутри которой клиент после подтверждения своей авторизации будет хранить служебные файлы, например, полученный приватный ключ с серверов Telegram.
Почему имя пользователя именно 'telegramd'
telegramd — именно такое дефолтное имя пользователя используется клиентом, если вы запускаете его в системе от имени суперпользователя, в документации такой информации мы не нашли, зато подсмотрели её в «main.c».
Как не потерять доступ к аккаунту, зарегистрированному на «левую симку»
Достаточно бекапить ту самую папку «.telegram-cli», которая упомянута ранее. Перенеся её на другой сервер, Telegram сразу будет запускать с нужной вам авторизацией и настройками.
И так, у вас в руках телефон с симкой, на которую будем регистрировать Телеграм, а на компьютере открыта консоль сервера с мониторингом.
adduser telegramd # --disabled-login
./bin/telegram-cli -k tg-server.pub
Следуем инструкциям на экране и попадаем в консольный телеграм
Теперь можно добавить кого-нибудь в «contact_list» по его номеру телефона, насколько нам известно — это единственный способ занести пользователя в «контакты» так, чтобы в последствии отправлять туда уведомления из Nagios. Сделать это можно из консоли или из любого другого клиента, включая Telegram Web-version, разумеется, предварительно авторизовавшись там с тем же телефонным номером, который вы только что использовали. Для отправки сообщений в общий чат или канал на стороне «робота» вообще ничего делать не нужно, достаточно позаботиться о том, чтобы он был администратором, если вы отправляете сообщения в «канал».
add_contact +79991112233 My Contact
quit
Настройка клиента под отправку алертов
Теперь у нас есть настроенный консольный клиент с одним контактом для отправления туда нотификаций. Для удобства использования обернём это в скрипт на баше.
/usr/local/bin/telegram.sh
#!/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 $?
Настраиваем права в системе (проверено в Debian 8 jessie)
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
Отправим «foo» сообщение для «My Contact»
/usr/local/bin/telegram.sh My_Contact foo # обратите внимание на нижнее подчёркивание
Отправим «bar» в канал«Monitoring»
/usr/local/bin/telegram.sh Monitoring bar
Отправляем уведомление из Nagios
Описание команд основано на классическом шаблоне для Jabber. В тексте сообщения используется #ИМЯ_МОНИТОРИНГА, таким образом, оно становится хэш-тегом в тексте сообщения, для нас это удобно.
Определение контакта для конфига Nagios
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 ; Название канала
}
Определение команд для конфига Nagios
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 по следующим метрикам:
- Каждую минуту запускаем клиент, в котором запрашиваем список контактов, после — проверяем код выхода из клиента, если всё хорошо — это всегда должен быть ноль. (Делается отдельным bash скриптом, мы думаем у вас не возникнет проблем в написании своей реализации такой проверки)
- Проверяем, что в логе отправки сообщений нету строк, содержащих «FAIL», именно это ключевое слово свидетельствует о том, что при отправке уведомлений что-то идёт не так. (Мы используем для этой проверки check_logfiles)
- Проверяем, что экземпляры telegram-cli не подвисли, а в системе не появляется всё больше и больше экземпляров этого процесса, которые стремятся оставить ваш сервер без оперативной памяти. (Для такого мониторинга отлично подойдёт стандартный check_procs)
Факап №5 — Не замониторить локального агента отправки уведомлений в Telegram.
Почти сразу после того, как мы начали использовать этот набирающий популярность месенджер на серверах с Nagios, оказалось, что Телеграм может сломаться, а мы — на многие часы полностью остаться без уведомлений, а частично — даже на пару дней. В случае, если мониторинг обнаруживает какие-либо проблемами с отправки уведомлений через Телеграм, об этом сообщается через email.
Почему локальный неофициальный клиент, вместо официального API в облаке?
1. telegram-cli регулярно обновляется, поэтому работает он стабильно и имеет весь нужный нам функционал.
2. За API всё равно нужно следить, например во время релиза Bot Api 2.0 с ним были замечены сбои, в то время, как обычный клиент работал исправно.
3. Так как мы не используем никакое общение с нашим роботом и не управляем с его помощью мониторингом, нас просто устраивает текущее решение. Работает — не трогай.
Нераскрытые возможности Телеграм в связке мониторингом
При срабатывание на ошибку в логе, часто хочется грепнуть проблемную часть, не включая свой рабочий компьютер или увидеть красивый график, иллюстрирующий масштабы проблемы рядом с очередным критическим алярмом, чтобы, например, оперативно форварднуть его своим коллегам.
Разумеется отправка изображений и других типов документов в Телеграме есть из коробки, так что возможности такого мониторинга ограничены только вашим воображений.
Вот как, к примеру, как у нас реализован механизм «резервных» каналов, здесь представлена упрощенная версия кода, для того, чтобы вам проще было в нём разобраться.
Обещанная ранее программная часть, отвечающая за механизм резервирования каналов.
Удачи с мониторингом ваших проектов и большого аптайма вам, коллеги!
Комментарии (0)