Рисунок: Маргарита Закиева
Что будет под катом:
- Базовые настройки 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 систем.
После успешной компиляции бинарника, необходимо создать в системе пользователя с логином «telegramd», для того, чтобы после первого запуска клиента у вас в системе создалась директория /home/telegramd/.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
Настройка клиента под отправку алертов
Теперь у нас есть настроенный консольный клиент с одним контактом для отправления туда нотификаций. Для удобства использования обернём это в скрипт на баше.
#!/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 nagios:telegramd /var/log/telegram -R
chmod 740 /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
Отправляем уведомление из Nagios
Описание команд основано на классическом шаблоне для 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 по следующим метрикам:
- Каждую минуту запускаем клиент, в котором запрашиваем список контактов, после — проверяем код выхода из клиента, если всё хорошо — это всегда должен быть ноль. (Делается отдельным bash скриптом, мы думаем у вас не возникнет проблем в написании своей реализации такой проверки)
- Проверяем, что в логе отправки сообщений нету строк, содержащих «FAIL», именно это ключевое слово свидетельствует о том, что при отправке уведомлений что-то идёт не так. (Мы используем для этой проверки check_logfiles)
- Проверяем, что экземпляры telegram-cli не подвисли, а в системе не появляется всё больше и больше экземпляров этого процесса, которые стремятся оставить ваш сервер без оперативной памяти. (Для такого мониторинга отлично подойдёт стандартный check_procs)
Факап №5 — Не замониторить локального агента отправки уведомлений в Telegram.
Почти сразу после того, как мы начали использовать этот набирающий популярность месенджер на серверах с Nagios, оказалось, что Телеграм может сломаться, а мы — на многие часы полностью остаться без уведомлений, а частично — даже на пару дней. В случае, если мониторинг обнаруживает какие-либо проблемами с отправки уведомлений через Телеграм, об этом сообщается через email.
Почему локальный неофициальный клиент, вместо официального API в облаке?
1. telegram-cli регулярно обновляется, поэтому работает он стабильно и имеет весь нужный нам функционал.
2. За API всё равно нужно следить, например во время релиза Bot Api 2.0 с ним были замечены сбои, в то время, как обычный клиент работал исправно.
3. Так как мы не используем никакое общение с нашим роботом и не управляем с его помощью мониторингом, нас просто устраивает текущее решение. Работает — не трогай.
Нераскрытые возможности Телеграм в связке мониторингом
При срабатывание на ошибку в логе, часто хочется грепнуть проблемную часть, не включая свой рабочий компьютер или увидеть красивый график, иллюстрирующий масштабы проблемы рядом с очередным критическим алярмом, чтобы, например, оперативно форварднуть его своим коллегам.
Разумеется отправка изображений и других типов документов в Телеграме есть из коробки, так что возможности такого мониторинга ограничены только вашим воображением.
Вот как, к примеру, как у нас реализован механизм «резервных» каналов, здесь представлена упрощенная версия кода, для того, чтобы вам проще было в нём разобраться.
Обещанная ранее программная часть, отвечающая за механизм резервирования каналов.
Удачи с мониторингом ваших проектов и большого аптайма вам, коллеги!
Комментарии (30)
sudoroot
24.07.2016 19:04Советую посмотреть в сторону slack. Там есть возможность создать несколько каналов и они очень удобно отображаются. У меня сейчас тоже через телеграмм, правда система мониторинга zabbix. Но суть та же. Все руки не дойдут на slack переделать.
Zeka13
24.07.2016 19:29Спасибо за замечание. Да, конечно же, мы слышали про Slack, но так сложилось, что в компании используется Telegram, он нам нравится и переезжать с него на другой мессенджер пока что не планируем.
sublimity
24.07.2016 20:36Для своей работы делал сервис skype|telegram <=> mail|restapi
используем его в проде, для
алертов из приложений и nagios и получить состояние иsublimity
24.07.2016 20:37+1доступен в паблике https://gates.pw
Zeka13
25.07.2016 02:52В конце статьи я довольно подробно описал, почему мы не используем «настоящего» бота, с блекджеком и REST API. Не совсем уловил связь между статьёй и предложенным вами сервисом. Не могли бы вы раскрыть свою мысль чуть подробнее, пожалуйста.
varnav
24.07.2016 22:27+1Nagios разве не устарел в пользу Icinga?
Zeka13
25.07.2016 02:08Самый подробный материал на эту тему, известный мне, собран в этой статье. Обычная версия Nagios, как 3я, так и 4я, безусловно, не выглядит как современный способ мониторинга чего-либо и мы и в правду не против переехать на Icinga, Zabbix или другой активно развивающийся софт, но ещё не определились с выбором.
Хотя статья, на самом деле, вовсе не про Nagios и даже не про Telegram.
guglez
25.07.2016 11:59А как вы определяете, что дежурный получил, увидел и принял к сведению отправленное ему сообщение? Вдруг он ушел в запой/крепко заснул/сидит без интернета и т.д.? Как эскаляция будет работать в таком случае? Я так и не увидел в статье упоминаний о том, что при получении тревоги ответственный должен как-то уведомить мониторинг о том, что сообщение принято к сведению.
Zeka13
25.07.2016 21:01Вы задали действительно правильный вопрос, потому что я не расскрыл мысль возможно до конца, как мы понимаем, что дежурный 'на стрёме'.
Сам принцип мониторинга, описанный в статье и есть своебразный регламент на тот счёт, как именно нужно реагировать в любое время суток на алярмы в мониторинге.
Если дежурный их принял в течение получаса, то никого зря не отвлечёт нотификация, потому что ответственный человек их временно отключит на время работ, либо сразу восстановит сам проблемный сервис. Если нотификации продалжаются, должны среагировать уже все админы, если ушли в запой все, после того как сервис лежит уже час, сообщения будут ходить в канал с директорами.
Подробнее с картинками в статье, читайте
Факап №3 — Полагаться только на дежурного.
А код, который за это отвечает — ссылкой в самом конце
billyevans
24.07.2016 23:07Идея интересная. Но не стремно ли полагаться на бесплатный чат, который вообще говоря не обязан всегда работать и не терять сообщения. Я так понимаю, что нет возможности платить за телеграм, чтоб он работал надежно, а в случае отказов, они бы вам деньги платили? Если он поломан, вы, конечно, знаете про это, но всеравно это как то не очень. Мы, например, используем pagerduty, что я думаю сейчас одно из самых популярных решений для этого. Но если они не будут укладываться в то, что они обещают по контракту, то будут платить деньги в таком случае нам.
Zeka13
25.07.2016 02:36Не знал, что существует такая вещь, как «облачный мониторинг с SLA». Спасибо за расширение моего кругозора, я обязательно взгляну на эту систему и изучу её возможности, может быть и для нас эта вещь окажется незаменимым инструментом.
Я думаю используемый подход к мониторингу всегда обусловлен бизнес-требованиям и другой спецификой компании.
Возможно подход с SLA для нас не подойдёт, в случае серьёзного многочасового простоя ключевых сервисов прямые потери компании будут очень большие, что наврятли кто-то захочет возмещать(нам же придётся ещё доказывать, что из-за недоставленный сообщений всё случилось), а в случае относительно незначительной аварии, возмещение этих потерь не будет для нас вопросом горящим и на Телеграм мы не обидимся. Разумеется у нас есть и автоматические сценарии для фаловеров и автоматический «хилинг» каких-то поломок, основная задача — обслуживание распределённого кластера.
Кроме того, самое страшное не те деньги, что мы сможем посчитать и выставить в счёт по SLA, их и так можно снова заработать, пускай даже за месяца работы. Самый неблагоприятный сценарий — это потеря лица компании на рынке и восстановление репутации годами. Надеямся, что и Телеграму свой авторитет подставлять не хочется и они будут и дальше делать всё для того, чтобы работать стабильно и без серьёзных сбоев.
Работа описанной в статье связки нас не подводит и мы ей доверяем, её разовый отказ мы переживём, если косяки начнутся на регулярной основе, разумеется задуемся о миграции куда-то в срочном порядке, например на pagerduty.
В то же время, нам, как OPs отделу, нравится держать всё у себя и под своим чутким контролем. Как вы правильно заметили, если бесплатный чатик от Дурова сломается, мы об этом узнаем и ситуация быстро вернётся под контроль.
Мы также используем бесплатный Linux, если на экране появится Kernel Panic, нам это тоже никто не возместит, к сожалению.guglez
25.07.2016 13:58Посмотрите еще VictorOps. Он куда более продвинут по фичам.
По поводу kernel panic — некоторые вендоры дают (или давали) коммерческие гарантии на такое. Но стоит это очень много денег.Zeka13
25.07.2016 16:15Спасибо, обязательно гляну на сервис, который используете вы. Про SLA на СПО типо PostgreSQL и Linux кажется забавным, но возможно людям, больше отвечающий за бизнес часть это будет интересно.
YaakovTooth
25.07.2016 03:19Это telegram-cli постоянно обновляется?
Да ну ладно.Zeka13
25.07.2016 03:37в его последний версии есть поддержка всех актуальных фич Телеграма, в статье я не написал «постоянно обновляется», лишь указал, что он делает это
регулярно
.YaakovTooth
25.07.2016 10:41Последняя версия отстаёт от изменения протокола на несколько месяцев, и не обновляется регулярно, а не обновляется вообще, что очень грустно. И я не к тому, что вас уличить в чём-то, я думал, что у вас собственный форк, официальный действительно перманентно сломан.
Zeka13
25.07.2016 12:39Почему вы считаете его 'перманентно сломанным'? За год использования не обнаружил никаких проблем. На счёт протокола тоже не понял, на наших серверах всё работает как часы.
YaakovTooth
25.07.2016 12:44Ну откройте же репозиторий в гите, попробуйте использовать его бинды в lua и в python, оно в корку отваливатся просто с ровного места.
Zeka13
25.07.2016 12:52Понял, спасибо. Нам повезло, нам нужна только функция отправки сообщений из мониторинга и она хорошо работает.
Возможно для вас больше подойдёт полноценный API.YaakovTooth
25.07.2016 12:53+1Да, конечно, пора уже завязывать с этими глупостями и работать напрямую с API.
Спасибо за статью.
konshyn
25.07.2016 10:42Недавно также вознимкло желание попробовать отправку сообщений в телеграм о сбоях сервера.
У меня возник вопрос по поводу этой отправки.
В описании, что такое Бот, написано: «Telegram Bots are special accounts that do not require an additional phone number to set up.»
Вопрос вот в чем: можно ли бота привязать к номеру телефона и отправлять с него сообщения? Судя по
это можно сделать, а вот в BotApi я не могу найти, как это сделать.
Может кто знает, как это сделать?Zeka13
25.07.2016 12:50Во второй части статьи довольно подробно описан процесс установки и настройки связки Telegram+Nagios и отправка уведомлений, ищите информацию под спойлерами. Мы не используем бота, а пользуемся консольным клиентом, поэтому нам нужна была симка, почему мы так сделали — в конце статьи. Для ботов сим не нужна. Если вам нужна ещё какая-то помощь, можете стукнуть мне в личку.
Mephistophele
26.07.2016 22:33Почему не почта?
Zeka13
26.07.2016 23:53На дворе 2016 год, объективно мессенджер это гибче, проще, надежнее, быстрее и так далее во всех смыслах, именно такие вещи сегодня позволяют компании расти и развиваться максимально быстро. Таковы современные тенденции, все рабочие процессы и обсуждения во многих фирмах практически полностью игнорирует такую вещь как email и нравится нам это или нет, приходится соответствовать бизнесу, мониторинг и события в нём это тоже частенько предмет живого обсуждения в реальном времени.
Mephistophele
27.07.2016 12:15На вкус и цвет все фламастеры разные. Только у почты есть возможность хорошо настроить фильтры и избежать целого ряда проблем. Хотя здесь больше диктует необходимость именно бизнес.
Zeka13
27.07.2016 12:56Если вам удобно использовать почту и фильтры для мониторинга, очевидно вам нужны оповещения мониторинга для других целей, нежели нам. Мы не храним нотификайии и их историю, это лишнее, но разделяем их адресатов, об этом есть в статье.Для анализа есть другой, аналитический мониторинг, с красивыми графичками. Мы используем месендежер не потому-что нам так кто-то диктует, а потому, что при правильном применение, в 2016, это лучший способ покрыть кейсы, которые нам нужны. Если в вашей схеме есть реальные преимущества, позволяющие сохранять нервы админам, топам, а сложному highload кластеру работать без сбоев, обязательно расскажите об этом всё таки подробнее.
de1m
Недавно пересели на icinga2 и там тоже встала проблема, как получать сообщения. Пока для icinga2 ещё нету клиета для android'a или iphone. Тоже думал слать сообщения черзе бота, но проблема в том, что он просто шлёт сообщения со статусом. То есть если мне пришло три сообщения с «critical», а потом три с «ок». То мне надо самому искать, где теперь нормально, а где ещё нет.
То есть нужен клиент, который показывает статус сервиса, а не шлёт сообщения.
Проблему удалось решить, для старой версии есть «anag» для андроида и в «icinga2» можно установить «icinga2-classicui».
Zeka13
Не понял проблему с тем, что сложно понять где сервис починился, а где сломался. У нас сервис легко идентифицировать по уникальному сочетанию hostname — servicename и если последнее сообщение для него RECOVERY, значит с ним всё порядке, если же другое — значит до сих пор лежит.
С другой стороны согласен, что когда сообщений не 3, а 33 — это проблема и «апки для мобилки» не хватает, поэтому мы тоже пользуемся aNag.
На счёт замечания про icinga2 — спасибо за предложенное вами решения.
ilyaplot
А если упадет телеграм?
Zeka13
Об этом кейсе есть информация в статье, также я отвечал на похожий вопрос в коментариях ниже. Телеграм замониторен, если он упадёт, мы об этом узнаем и будет автоматически активирован резервный способ оповещений (это может быть что угодно sms/почта/sip телефония/другой мессенджер) и на всякий случай повалятся алярмы, чтобы разбудить дежурного, даже если если всё кроме телеграма работает.
Если телеграм сломается у дежурного — сработает механизм экстренного канала, об этом тоже в статье.
Да, кстати, если дежурный не среагировал на аварию через телеграм, ему через 15 минут будет звонит робот на мобильный/домашний — это как раз резервный механизм оповещения, об этом я не стал упоминать в статье, потому что технической реализацией пока не готов поделиться.