{"id":14262,"url":"\/distributions\/14262\/click?bit=1&hash=8ff33b918bfe3f5206b0198c93dd25bdafcdc76b2eaa61d9664863bd76247e56","title":"\u041f\u0440\u0435\u0434\u043b\u043e\u0436\u0438\u0442\u0435 \u041c\u043e\u0441\u043a\u0432\u0435 \u0438\u043d\u043d\u043e\u0432\u0430\u0446\u0438\u044e \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u0435 \u0434\u043e 1,5 \u043c\u043b\u043d \u0440\u0443\u0431\u043b\u0435\u0439","buttonText":"\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435","imageUuid":"726c984a-5b07-5c75-81f7-6664571134e6"}

getNotifiedBot — Telegram-бот для получения оповещений о коммерчески важных событиях и ошибках в вашем приложении

Проблематика

Говорят, есть программисты, которых однажды начинает волновать не только формальное выполнение задачи, но и то, как будет работать написанный ими код в широком диапазоне боевых юскейсов:

  • Почему пользователь уйдет в одном шаге от покупки.
  • Какие и в каких ситуациях возникают ошибки.
  • Где пользователь ведет себя не так, как ожидается.
  • Выполнение какого кода должно сигнализировать об атаке.
  • Что произойдет если упадет один из необходимых API или рестартнется сервер.

Забавно, но эта проблематика становится тем насущней, чем дальше человек от работы с кодом: тим-лиды, QA, PM, CTO, CEO, собственники, инвесторы — всех их эти вопросы волнуют гораздо больше, чем программиста, непосредственно пишущего код. Самого программиста эти вопросы начинают волновать только тогда, когда он начинает пилить собственный продукт, от которого зависит его завтрашний хлеб.

Причины этого положения вещей стары как мир, и их раскрытие потребует отдельной статьи. В этой статье я хочу рассказать, как, затратив пять минут, с помощью нашего бота вы можете настроить мгновенное информирование о том, что в вашем приложении что-то пошло не так и в каких количествах — или, наоборот, что произошло что-то хорошее, о чем вам важно будет узнать сразу.

Начнем с коммерчески важных событий

Этот бот появился как сайд-проект нашего основного сервиса ActualizeBot, и вот какие коммерчески важные оповещения мы получаем в нем уже сегодня:

  • Регистрация нового пользователя с указанием реферала.
  • Возвращение старых пользователей.
  • Начало и успешное завершение различных критически важных флоу.
  • Важные достижения пользователя в приложении, например мэтч.

Эта информация в прямом эфире, во-первых, добавляет позитивного настроя и понимания того, что в продукте что-то происходит и мы тут все работаем не просто так. Что называется, эффект присутствия.

Во-вторых, вы, скорее всего, увидите, что одних событий происходит больше и чаще, чем вы ожидали, а других, наоборот, меньше. Вы увидите поведение вашего массового пользователя — и деловые инсайты не заставят себя ждать.

Ошибки

В программировании есть аксиома, которую можно сформулировать так: «У вас будут ошибки». Некоторые из этих ошибок не будут вам стоить ничего, а некоторые будут стоить нескольких месяцев простоя или светлого будущего вообще.

Хорошей иллюстрацией такой ошибки был баг на форуме Searchengines, не позволявший зарегистрироваться, — новому пользователю просто не приходили письма с подтверждением. Другая иллюстрация — то, сколько денег сейчас теряет Facebook из-за некорректной и ужасающе неинтуитивной рекламной панели.

В поиске таких слабых мест нам отчасти помогают:

  • Тестировщики, глаз которых рано или поздно замыливается.
  • Автотесты (мифические сущности из объявлений о вакансиях), которых надо написать очень много и регулярно вдумчиво переписывать.
  • Пользователи, столкнувшиеся с ними и не поленившиеся сообщить.

На мой взгляд, гораздо лучше узнавать обо всех исключениях от компьютера, а не от пользователя или сотрудника, ибо слаб человек — и узнавать сразу после их происшествия, а не тогда когда программист найдет в себе силы нырнуть в мегабайты логов.

Минусы существующих систем мониторинга

Вкратце о том, почему большинство тех, кто заморачивается, пишет собственные решения и тратит на это тысячи долларов:

  • Во-первых, их (решений по мониторингу) очень мало.
  • Во-вторых, они монструозны и избыточны для 98% стартапов и бизнеса.
  • В-третьих, они рассчитаны на использование с рабочего места.
  • В-четвертых, их API надо изучать и пользование ими тоже надо изучать.
  • В-пятых, их где-то надо разворачивать и поддерживать, чтобы они сами не упали.

getNotifiedBot

Наши плюсы:

  • Простота и элегантность. Наш интерфейс состоит из четырех команд, которыми вы, скорее, никогда даже не воспользуетесь: /pause (пауза в оповещениях), /unpause (отмена паузы), /show_token (узнать свой токен) и /regen_token (создать новый токен)
  • Не надо думать о поддержке, покупать отдельный сервер для мониторинга, забывать его продлить.
  • Настройка занимает пять минут и полностью описана ниже.

При входе в бот вам будет предложено выполнить команду /help, чтобы узнать ваш токен и уже описанные выше специфические команды.

В этот момент вы получаете персональный секретный токен и адрес вида https://getnotifiedbot.com/notify/<TOKEN> для отправки оповещений. На этот адрес вы можете слать GET- или POST-запросы с текстом сообщения, записанным в параметр message. Мы рекомендуем использовать POST, чтобы не зависеть от URL-кодировки сообщения в случае с GET.

Все что нужно сделать, чтобы бот заработал, — поставить в глобальный перехватчик ошибок вызов нашего API.

Пример интеграции для оповещения обо всех исключениях на Node.JS:

function getNotified(event) { axios.post('https://getnotifiedbot.com/notify/<TOKEN>', { message: JSON.stringify(event) }); } process.on('rejectionHandled', getNotified); process.on('unhandledRejection', getNotified); process.on('uncaughtException', getNotified);

Дальнейшее использование функции getNotified — на ваше усмотрение

Итак, если вы хотите быть в курсе того, что происходит в вашем приложении, welcome: getNotifiedBot!

0
36 комментариев
Написать комментарий...
Nataniel Bampoo

1) Отправлять возможно важную инфу через стороннего бота?
2) Чем разработчику sentry не угодил?
3) Зачем использовать стороннего бота, если можно сделать своего? Для начала бот-прокси, который просто пересылает инфу подписавшимся. Есть 1001 решения для написания ботов.

Я бы, как разработчик, не доверился такому боту. Слишком прост для стороннего решения.

Ответить
Развернуть ветку
Андрей Селин
Автор

3. Сделайте, почему нет. Просто средний разработчик потратит на эту разработку пару-тройку часов и должен будет поддерживать отдельный сервер на отдельном хостинге, на котором должен лежать такой продукт. Это время, деньги и риски.
Хочу обратить ваше внимание, что сделать боевой публичный API as a Service это не то же самое что запустить Express с одним методом.

Мы будем постепенно допиливать наш продукт и делать его более многофункциональным и стоящим заметно меньше, чем трудозатраты программиста.

Если хотите взглянуть на не слишком простой сервис, советую глянуть наш ActualizeBot

Ответить
Развернуть ветку
Nataniel Bampoo

эм.. А бэка нет что-ли у приложения? У вас пример на node.js, а это уже бэк. Зачем нужен ещё один сервер для бота? А если запросов становится очень много, то у всяких сентри и т.п. нет конкурентов. 

Ответить
Развернуть ветку
Андрей Селин
Автор

Функционал отвечающий за мониторинг на мой взгляд должен лежать на отдельном сервере или инстансе, чтобы гарантировать информирование в случае отключения самого ядра. У нас бывали ситуации что наш амазоновский ДЦ был недоступен по полчаса несколько раз в месяц - и мы об этом узнавали сразу (а могли вообще не узнать).
Дело в том что мы хотим в дальнейшем нагрузить этот бот функционалом пингования того или иного адреса чтобы понять вовремя, например, не упал ли сервер и тд.

Ответить
Развернуть ветку
Андрей Селин
Автор

1. Отправляйте через нашего бота ту информацию, которую считаете нужной. Мы в приветственном сообщении ответственно заявляем что не храним текстов сообщений.
Не надо отправлять через него ключи от квартиры где деньги лежат — мы сами хотели бы быть подальше от этой информации. А вот отправить сообщение, что не отвечает АПИ курсов валют — это вряд ли является такой чувствительной информацией. Плюс, нелогично заявлять со стороны программиста что getNotifiedBot-у информацию доверять нельзя, а sentry и телеграму, бэка которых никто никогда не видел — можно.

Ответить
Развернуть ветку
Андрей Селин
Автор

2. Зачем сразу не угодил?
Я работал на проектах, использовавших, sentry — приходили такие же оповещения. Но sentry:
а) Заточен на ловлю багов и не заточен на работу с событиями другого порядка
б) Комплексный сервис и требует дополнительного погружения и внедрения — вы не начнете работать с sentry за 1 минуту.
в) Не приспособлен для гибкости, раскрытой в нашем боте — вызывай нотификации оттуда, откуда хочешь и с той целью, с которой хочешь.

Ответить
Развернуть ветку
Dmitry S

Sentry на минималках?

Ответить
Развернуть ветку
Андрей Селин
Автор

Sentry здорового человека )

Ответить
Развернуть ветку
Григорий Молоцев

Почему только на английском ? 

Ответить
Развернуть ветку
Андрей Селин
Автор

Основная причина - все программисты на земле знают английский + проникновение телеграма в их аудиторию высоко глобально. Им уже знакома работа с командной строкой, где никто ничего не переводит на тысячи языков.
Также, нам видится, что в этом есть глобальный тренд и надо уже поменьше заморачиваться на мультиязычность там, где это возможно.

Ответить
Развернуть ветку
Alexey Laptev

В таких ботах надо ошибки разработчику слать, а не факт регистрации. Это как раз бесполезная информация.

Ну и пишется за 1 день + напрямую нельзя слать в бот, эту нужно делать через очередь, иначе при нагрузке все ляжет.

Поэтому ценность сервиса на минимуме для более-менее рабочего проекта.

Ответить
Развернуть ветку
Андрей Селин
Автор

Вы пишете общими словами, которые доказывают вам самому некие ваши мысли о неких событиях, которые известны только вам.
Что ляжет... При какой нагрузке... По-вашему, очередь работает по сильно другому принципу? Очередь делает то же самое, только еще тратит дополнительный ресурс на хранение сообщений в памяти. А еще для скорости она должна лежать на том же сервере, который ляжет и вы не узнаете что он лег. А если она будет находиться на другом сервере, то вам еще и кросс-серверный запрос надо будет подождать.
—-
У 99,99% приложений нет такой нагрузки, о которой вы говорите.
Отправить что-то напрямую в бот невозможно. Отправка идет http api.
Пишется аналогичный бот действительно быстро — ну так вы можете пойти и отдать кому-нибудь 100 долларов за то, чтобы вам его написали вместо того чтобы использовать наш бесплатно или за смешные деньги когда мы допишем функционал.

Ответить
Развернуть ветку
Nataniel Bampoo

у 99.99% проектов нет необходимости следить за ошибками в реалтайме

Ответить
Развернуть ветку
Андрей Селин
Автор

Если у вас кончатся деньги на 2fa сервисе, вы точно не придадите этому особого значения? )

Ответить
Развернуть ветку
Alexey Laptev

Ну сразу виден ваш уровень. Одно дело по http отправлять прямой запрос который длится 1-2 секунды, другое дело закинуть в БД и отправить асинхронно.

По этому в вашем случае будут проблемы даже у самый простых приложений. Это проверено не раз.

Но дело ваше.

У нас есть такой же бот если что.

Ответить
Развернуть ветку
Андрей Селин
Автор

Очевидно, уровень комментирования у вас высок. Тогда расскажите мне, сколько займет amqp-запрос на выделенный сервер с очередью и чем он будет принципиально отличаться от http-запроса?

Ответить
Развернуть ветку
Alexey Laptev

Не хочу ничего доказывать, сами потом все поймете )

Ответить
Развернуть ветку
Sam Beckett

Эм.. Автор ничего не знает о всяких там Kibana и Seq?

Ответить
Развернуть ветку
Pasha Rumkin

У Kibana огромный технический долг. Про Seq ничего не знаю. Но и к тому и к другому оповещения нужно прикручивать. Оповещения в телеграм получать удобнее, чем на почту, поэтому алгоритм "ошибка – уведомление в ТГ" для меня выглядит оправданным.

Ответить
Развернуть ветку
Nataniel Bampoo

Конечно. У нас ошибка в коде. Заходит 1000 пользователей и приходит 1000 сообщений в телеграм. Удобно же.

Ответить
Развернуть ветку
Иннокентий Зампольский

Работал с Кибана. Это сервис логгирования. Наш продукт — про оповещения

Ответить
Развернуть ветку
Sam Beckett

Смысл разгребать неструктурированные оповещения в ТГ, если все это можно наблюдать хоть в реальном времени в системе мониторинга, строя графики, срезы, что угодно вообще?

Ответить
Развернуть ветку
Иннокентий Зампольский

Их не надо разгребать, о них надо узнавать. Как уже писали выше — у вас кончились деньги на одном из внешних сервисов или он отвалился и из-за этого ряд методов не отрабатывает должным образом — вам надо узнать об этом как можно быстрей.

Ответить
Развернуть ветку
Sam Beckett

Другими словами это фича для супер-мелкого проекта, где работает полтора разработчика.

Ответить
Развернуть ветку
Иннокентий Зампольский

Или для критических оповещений даже в большом проекте, которые не сыпятся сотнями. Или для того чтобы сказать директору, например: посетитель задал вопрос и ему не ответили в течение 20 секунд

Ответить
Развернуть ветку
Sam Beckett

Представляю что будет, если тимлиду большого проекта в телегу будут сыпаться оповещения, что посетитель задал вопрос и ему не ответили в течение 20 секунд...

Ответить
Развернуть ветку
Nataniel Bampoo

Не тимлиду, а директору. Это очень важно. Директор же только и делает, что следит в реалтайме за такими оповещениями.

Ответить
Развернуть ветку
Андрей Селин
Автор

А я, в свою очередь, представляю что будет если этот поток будет валиться главному по продажам — это будет документированное подтверждение неэффективности работы подчиненных, с которым можно будет работать и его задачей будет сократить этот поток.

Ответить
Развернуть ветку
Pasha Rumkin

Имплементация авторизации на текстовых токенах в 2020 – это нонсенс. Используйте JWT.

Ответить
Развернуть ветку
Андрей Селин
Автор

Мы в этом плане шли самым простым путем и отталкивались от самого близкого к телу примера — телеграм. Надо почитать, мб за 5 лет что изменилось, но пока не совсем понимаю в чем разница. Токены у нас хранятся в памяти, поэтому по скорости мы даже быстрей — не надо ничего расшифровывать.

Ответить
Развернуть ветку
Pasha Rumkin

Телеграм в плане безопасности далеко не лучший пример. Лучшие практики, которые на сегодня есть, разрабатываются в сфере применения цифровой подписи. За 5 лет ситуация поменялась кардинально. Проблема с текстовым токеном – он легко копируется и выносится за пределы периметра безопасности и никто об этом не узнает, пока что-то не случится.

Советую начать с сайта https://jwt.io и https://auth0.com/blog/, чтобы разобраться.

Ответить
Развернуть ветку
Fedor

Код на github планируете выложить?

Ответить
Развернуть ветку
Андрей Селин
Автор

Планируем, в упрощенном виде. Если интересно, подписывайтесь на наш корпоративный блок на хабре — мы там дадим знать: https://habr.com/ru/company/actualizebot/blog

Ответить
Развернуть ветку
Сергей Боцман

Ваш сайт-сервис не работает (может он и не должен был работать), бот не реагирует на команды, "корпоративный блок" на хабре не активен.

Ответить
Развернуть ветку
Ну Как То Так

Ужасный бот, нелепые отмазки о полезности в комментариях. Конструктивную критику не воспринимает. Автор Джуниор студент или школьник.
Проект фо фан загнётся за пару месяцев, ни в коем случае не пользоваться.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
33 комментария
Раскрывать всегда