Комментарии 30
Недавно пересели на icinga2 и там тоже встала проблема, как получать сообщения. Пока для icinga2 ещё нету клиета для android'a или iphone. Тоже думал слать сообщения черзе бота, но проблема в том, что он просто шлёт сообщения со статусом. То есть если мне пришло три сообщения с «critical», а потом три с «ок». То мне надо самому искать, где теперь нормально, а где ещё нет.
То есть нужен клиент, который показывает статус сервиса, а не шлёт сообщения.
Проблему удалось решить, для старой версии есть «anag» для андроида и в «icinga2» можно установить «icinga2-classicui».
То есть нужен клиент, который показывает статус сервиса, а не шлёт сообщения.
Проблему удалось решить, для старой версии есть «anag» для андроида и в «icinga2» можно установить «icinga2-classicui».
Не понял проблему с тем, что сложно понять где сервис починился, а где сломался. У нас сервис легко идентифицировать по уникальному сочетанию hostname — servicename и если последнее сообщение для него RECOVERY, значит с ним всё порядке, если же другое — значит до сих пор лежит.
С другой стороны согласен, что когда сообщений не 3, а 33 — это проблема и «апки для мобилки» не хватает, поэтому мы тоже пользуемся aNag.
На счёт замечания про icinga2 — спасибо за предложенное вами решения.
С другой стороны согласен, что когда сообщений не 3, а 33 — это проблема и «апки для мобилки» не хватает, поэтому мы тоже пользуемся aNag.
На счёт замечания про icinga2 — спасибо за предложенное вами решения.
А если упадет телеграм?
Об этом кейсе есть информация в статье, также я отвечал на похожий вопрос в коментариях ниже. Телеграм замониторен, если он упадёт, мы об этом узнаем и будет автоматически активирован резервный способ оповещений (это может быть что угодно sms/почта/sip телефония/другой мессенджер) и на всякий случай повалятся алярмы, чтобы разбудить дежурного, даже если если всё кроме телеграма работает.
Если телеграм сломается у дежурного — сработает механизм экстренного канала, об этом тоже в статье.
Да, кстати, если дежурный не среагировал на аварию через телеграм, ему через 15 минут будет звонит робот на мобильный/домашний — это как раз резервный механизм оповещения, об этом я не стал упоминать в статье, потому что технической реализацией пока не готов поделиться.
Если телеграм сломается у дежурного — сработает механизм экстренного канала, об этом тоже в статье.
Да, кстати, если дежурный не среагировал на аварию через телеграм, ему через 15 минут будет звонит робот на мобильный/домашний — это как раз резервный механизм оповещения, об этом я не стал упоминать в статье, потому что технической реализацией пока не готов поделиться.
Советую посмотреть в сторону slack. Там есть возможность создать несколько каналов и они очень удобно отображаются. У меня сейчас тоже через телеграмм, правда система мониторинга zabbix. Но суть та же. Все руки не дойдут на slack переделать.
Для своей работы делал сервис skype|telegram <=> mail|restapi
используем его в проде, для
алертов из приложений и nagios и получить состояние и
используем его в проде, для
алертов из приложений и nagios и получить состояние и
Nagios разве не устарел в пользу Icinga?
Самый подробный материал на эту тему, известный мне, собран в этой статье. Обычная версия Nagios, как 3я, так и 4я, безусловно, не выглядит как современный способ мониторинга чего-либо и мы и в правду не против переехать на Icinga, Zabbix или другой активно развивающийся софт, но ещё не определились с выбором.
Хотя статья, на самом деле, вовсе не про Nagios и даже не про Telegram.
Хотя статья, на самом деле, вовсе не про Nagios и даже не про Telegram.
А как вы определяете, что дежурный получил, увидел и принял к сведению отправленное ему сообщение? Вдруг он ушел в запой/крепко заснул/сидит без интернета и т.д.? Как эскаляция будет работать в таком случае? Я так и не увидел в статье упоминаний о том, что при получении тревоги ответственный должен как-то уведомить мониторинг о том, что сообщение принято к сведению.
Вы задали действительно правильный вопрос, потому что я не расскрыл мысль возможно до конца, как мы понимаем, что дежурный 'на стрёме'.
Сам принцип мониторинга, описанный в статье и есть своебразный регламент на тот счёт, как именно нужно реагировать в любое время суток на алярмы в мониторинге.
Если дежурный их принял в течение получаса, то никого зря не отвлечёт нотификация, потому что ответственный человек их временно отключит на время работ, либо сразу восстановит сам проблемный сервис. Если нотификации продалжаются, должны среагировать уже все админы, если ушли в запой все, после того как сервис лежит уже час, сообщения будут ходить в канал с директорами.
Подробнее с картинками в статье, читайте
А код, который за это отвечает — ссылкой в самом конце
Сам принцип мониторинга, описанный в статье и есть своебразный регламент на тот счёт, как именно нужно реагировать в любое время суток на алярмы в мониторинге.
Если дежурный их принял в течение получаса, то никого зря не отвлечёт нотификация, потому что ответственный человек их временно отключит на время работ, либо сразу восстановит сам проблемный сервис. Если нотификации продалжаются, должны среагировать уже все админы, если ушли в запой все, после того как сервис лежит уже час, сообщения будут ходить в канал с директорами.
Подробнее с картинками в статье, читайте
Факап №3 — Полагаться только на дежурного.
А код, который за это отвечает — ссылкой в самом конце
Идея интересная. Но не стремно ли полагаться на бесплатный чат, который вообще говоря не обязан всегда работать и не терять сообщения. Я так понимаю, что нет возможности платить за телеграм, чтоб он работал надежно, а в случае отказов, они бы вам деньги платили? Если он поломан, вы, конечно, знаете про это, но всеравно это как то не очень. Мы, например, используем pagerduty, что я думаю сейчас одно из самых популярных решений для этого. Но если они не будут укладываться в то, что они обещают по контракту, то будут платить деньги в таком случае нам.
Не знал, что существует такая вещь, как «облачный мониторинг с SLA». Спасибо за расширение моего кругозора, я обязательно взгляну на эту систему и изучу её возможности, может быть и для нас эта вещь окажется незаменимым инструментом.
Я думаю используемый подход к мониторингу всегда обусловлен бизнес-требованиям и другой спецификой компании.
Возможно подход с SLA для нас не подойдёт, в случае серьёзного многочасового простоя ключевых сервисов прямые потери компании будут очень большие, что наврятли кто-то захочет возмещать(нам же придётся ещё доказывать, что из-за недоставленный сообщений всё случилось), а в случае относительно незначительной аварии, возмещение этих потерь не будет для нас вопросом горящим и на Телеграм мы не обидимся. Разумеется у нас есть и автоматические сценарии для фаловеров и автоматический «хилинг» каких-то поломок, основная задача — обслуживание распределённого кластера.
Кроме того, самое страшное не те деньги, что мы сможем посчитать и выставить в счёт по SLA, их и так можно снова заработать, пускай даже за месяца работы. Самый неблагоприятный сценарий — это потеря лица компании на рынке и восстановление репутации годами. Надеямся, что и Телеграму свой авторитет подставлять не хочется и они будут и дальше делать всё для того, чтобы работать стабильно и без серьёзных сбоев.
Работа описанной в статье связки нас не подводит и мы ей доверяем, её разовый отказ мы переживём, если косяки начнутся на регулярной основе, разумеется задуемся о миграции куда-то в срочном порядке, например на pagerduty.
В то же время, нам, как OPs отделу, нравится держать всё у себя и под своим чутким контролем. Как вы правильно заметили, если бесплатный чатик от Дурова сломается, мы об этом узнаем и ситуация быстро вернётся под контроль.
Мы также используем бесплатный Linux, если на экране появится Kernel Panic, нам это тоже никто не возместит, к сожалению.
Я думаю используемый подход к мониторингу всегда обусловлен бизнес-требованиям и другой спецификой компании.
Возможно подход с SLA для нас не подойдёт, в случае серьёзного многочасового простоя ключевых сервисов прямые потери компании будут очень большие, что наврятли кто-то захочет возмещать(нам же придётся ещё доказывать, что из-за недоставленный сообщений всё случилось), а в случае относительно незначительной аварии, возмещение этих потерь не будет для нас вопросом горящим и на Телеграм мы не обидимся. Разумеется у нас есть и автоматические сценарии для фаловеров и автоматический «хилинг» каких-то поломок, основная задача — обслуживание распределённого кластера.
Кроме того, самое страшное не те деньги, что мы сможем посчитать и выставить в счёт по SLA, их и так можно снова заработать, пускай даже за месяца работы. Самый неблагоприятный сценарий — это потеря лица компании на рынке и восстановление репутации годами. Надеямся, что и Телеграму свой авторитет подставлять не хочется и они будут и дальше делать всё для того, чтобы работать стабильно и без серьёзных сбоев.
Работа описанной в статье связки нас не подводит и мы ей доверяем, её разовый отказ мы переживём, если косяки начнутся на регулярной основе, разумеется задуемся о миграции куда-то в срочном порядке, например на pagerduty.
В то же время, нам, как OPs отделу, нравится держать всё у себя и под своим чутким контролем. Как вы правильно заметили, если бесплатный чатик от Дурова сломается, мы об этом узнаем и ситуация быстро вернётся под контроль.
Мы также используем бесплатный Linux, если на экране появится Kernel Panic, нам это тоже никто не возместит, к сожалению.
в его последний версии есть поддержка всех актуальных фич Телеграма, в статье я не написал «постоянно обновляется», лишь указал, что он делает это
регулярно.
Последняя версия отстаёт от изменения протокола на несколько месяцев, и не обновляется регулярно, а не обновляется вообще, что очень грустно. И я не к тому, что вас уличить в чём-то, я думал, что у вас собственный форк, официальный действительно перманентно сломан.
Почему вы считаете его 'перманентно сломанным'? За год использования не обнаружил никаких проблем. На счёт протокола тоже не понял, на наших серверах всё работает как часы.
Недавно также вознимкло желание попробовать отправку сообщений в телеграм о сбоях сервера.
У меня возник вопрос по поводу этой отправки.
В описании, что такое Бот, написано: «Telegram Bots are special accounts that do not require an additional phone number to set up.»
Вопрос вот в чем: можно ли бота привязать к номеру телефона и отправлять с него сообщения? Судя по
это можно сделать, а вот в BotApi я не могу найти, как это сделать.
Может кто знает, как это сделать?
У меня возник вопрос по поводу этой отправки.
В описании, что такое Бот, написано: «Telegram Bots are special accounts that do not require an additional phone number to set up.»
Вопрос вот в чем: можно ли бота привязать к номеру телефона и отправлять с него сообщения? Судя по
это можно сделать, а вот в BotApi я не могу найти, как это сделать.
Может кто знает, как это сделать?
Во второй части статьи довольно подробно описан процесс установки и настройки связки Telegram+Nagios и отправка уведомлений, ищите информацию под спойлерами. Мы не используем бота, а пользуемся консольным клиентом, поэтому нам нужна была симка, почему мы так сделали — в конце статьи. Для ботов сим не нужна. Если вам нужна ещё какая-то помощь, можете стукнуть мне в личку.
Почему не почта?
На дворе 2016 год, объективно мессенджер это гибче, проще, надежнее, быстрее и так далее во всех смыслах, именно такие вещи сегодня позволяют компании расти и развиваться максимально быстро. Таковы современные тенденции, все рабочие процессы и обсуждения во многих фирмах практически полностью игнорирует такую вещь как email и нравится нам это или нет, приходится соответствовать бизнесу, мониторинг и события в нём это тоже частенько предмет живого обсуждения в реальном времени.
На вкус и цвет все фламастеры разные. Только у почты есть возможность хорошо настроить фильтры и избежать целого ряда проблем. Хотя здесь больше диктует необходимость именно бизнес.
Если вам удобно использовать почту и фильтры для мониторинга, очевидно вам нужны оповещения мониторинга для других целей, нежели нам. Мы не храним нотификайии и их историю, это лишнее, но разделяем их адресатов, об этом есть в статье.Для анализа есть другой, аналитический мониторинг, с красивыми графичками. Мы используем месендежер не потому-что нам так кто-то диктует, а потому, что при правильном применение, в 2016, это лучший способ покрыть кейсы, которые нам нужны. Если в вашей схеме есть реальные преимущества, позволяющие сохранять нервы админам, топам, а сложному highload кластеру работать без сбоев, обязательно расскажите об этом всё таки подробнее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мониторинг проектов с помощью месенджера на примере Nagios и Telegram, с разбором факапов из жизни Highload 24x7