Использование Slack для мониторинга вашего приложения

Все началось с посещения небольшого стартапа в Денвере, штат Колорадо. Во время моего визита я начал слышать тонкое и чарующее «дзынь» в углу офиса каждые несколько минут. Когда я отправился исследовать этот странный шум, я обнаружил служебный звонок, подключенный к Raspberry Pi, с крошечным металлическим молотком, прикрепленным к печатной плате. Как оказалось, Pi получал сообщения с сервера команды и бил молоточком каждый раз, когда регистрировался новый клиент .

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

Поскольку мы уже использовали Slack для командного чата, а у него прекрасно документированный API, это был очевидный выбор для эксперимента.

Дальнейшее чтение на SmashingMag:

• Диалоговые интерфейсы: где мы сегодня? Куда мы направляемся?
• Командное сотрудничество и устранение пробелов в эффективности адаптивного дизайна
• Что вы должны знать о процессе разработки приложений
• Навстречу гонкам: начало работы с дизайнерскими спринтами
  

Настроить слабину

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

Теперь, когда у нас есть URL-адрес веб-перехватчика, пришло время интегрировать сообщения Slack в наше приложение Node.js. Для этого я нашел удобный модуль Node.js с именем node-slack.

Сначала мы установили модуль Node.js:

 npm install node-slack --save

Теперь мы можем отправлять сообщения Slack на выбранный нами канал с помощью нескольких строк кода.

 // dependency setup var Slack = require('node-slack'); var hook_url = 'hook_url_goes_here'; var slack = new Slack(hook_url); // send a test Slack message slack.send({ text: ':rocket: Nice job, I\'m all set up!', channel: '#test', username: 'MyApp Bot' });

(Вы можете найти аналогичные пакеты интеграции Slack для Ruby, Python и практически любого другого языка.)

При выполнении этот код выдал следующее сообщение в нашем канале #test Slack:

Приведенный выше код минимален, но он специфичен для Slack API и модуля node-slack. Я не хотел быть привязанным к какой-либо конкретной службе обмена сообщениями, поэтому я создал общую функцию модуля Node.js для выполнения кода, специфичного для службы:

 // Messenger.js // dependency setup var hook_url = my_hook_url; var Slack = require('node-slack'); var slack = new Slack(hook_url); module.exports = { sendMessage: function(message, channel, username) { if (!message){ console.log('Error: No message sent. You must define a message.') } else { // set defaults if username or channel is not passed in var channel = (typeof channel !== 'undefined') ? channel : "#general"; var username = (typeof username !== 'undefined') ? username : "MyApp"; // send the Slack message slack.send({ text: message, channel: channel, username: username }); return; } } };

Теперь мы можем использовать этот модуль в любом месте приложения с помощью двух строк кода, и если мы когда-нибудь решим в будущем отправлять сообщения в другую службу, мы можем легко заменить это в Messenger.js.

 var messenger = require('./utilities/messenger'); messenger.sendMessage(':rocket: Nice job, I\'m all set up!', '#test');

Теперь, когда мы настроили основы, мы были готовы начать отправлять сообщения из приложения.

Отслеживание регистраций

Первым делом нужно было добиться паритета обслуживания и звонка. Я нашел успешный обратный вызов функции регистрации пользователя и добавил этот код:

 messenger.sendMessage('New user registration! ' + user.email);

Теперь, когда кто-то регистрируется, мы получим это сообщение:

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

Погрузитесь глубже

По мере того, как мое любопытство росло с каждым звонком, я начал задаваться вопросом, что, если бы не удалось создать нового пользователя? Что делать, если пользователь зарегистрировался, вошел в систему, но не завершил процесс регистрации? Каков результат наших запланированных задач? Теперь, когда основа была готова, ответить на эти вопросы было проще простого.

Мониторинг исключений и критических ошибок на серверной части

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

 messenger.sendMessage(':x: Error While adding a new user ' + formData.email + ' to the DB. Registration aborted!' + error.code + ' ' + error.message);

Теперь мы сразу знали, когда регистрация не удалась, почему она не удалась и, что более важно, для кого она не удалась:

Были всевозможные интересные места, куда мы могли отправлять сообщения (практически везде с обратным вызовом ошибки). Одним из таких мест была эта общая функция обработки ошибок:

 app.use(function(err, req, res, next) { var message = ':x: Generic Server Error! '+ err + '\n Request: \n' + req.protocol + '://' + req.get('host') + req.originalUrl + '\n' + JSON.stringify(req.headers) + 'Request Payload:\n' + JSON.stringify(req.body); messenger.sendMessage(message, '#server-errors'); res.status(err.status || 500); res.json({'error': true }); });

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

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

Мониторинг финансов

Далее я хотел отправить уведомление, когда в приложении происходит финансовое событие. Поскольку наш продукт SaaS интегрируется с Stripe, мы создали конечную точку веб-перехватчика, которая получает пинг от Stripe, когда люди обновляют свой план, понижают свой план, добавляют информацию об оплате, изменяют информацию об оплате и многие другие события, связанные с оплатой подписки, все из которых отправляются на Слабый:

Мониторинг поведения пользователей во внешнем интерфейсе

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

Теперь, когда конечная точка установлена, мы можем отправлять сообщения Slack с помощью простого вызова AngularJS $http.post :

 // send Slack notification from the front end var message = ":warning: Slack disconnected by " + $scope.user.username; $http.post('/endpoint', message);

Это помогает нам ответить на важные вопросы о бизнесе: Регистрируют ли люди и добавляют ли доменное имя? Разве это не так? Если кто-то да, то это действительно высококлассный домен, с владельцем которого мы хотели бы связаться лично вскоре после того, как он его добавил. Теперь мы можем подключиться к этому:

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

Есть также признаки того, что пользователь недоволен сервисом, и о них полезно знать. Кто-то удалил доменное имя? Они отключили Slack?

Эта обратная связь дает нам возможность проактивно связаться и предложить восхитительную поддержку клиентов, когда это наиболее важно.

Мониторинг запланированных задач

Одна из самых интересных вещей, которые можно увидеть в Slack, — это результат запланированных задач. Наш продукт SaaS выполняет задачи, чтобы уведомлять людей о производительности их веб-сайта (наша основная услуга), отправлять транзакционные электронные письма, очищать базу данных и некоторые другие вещи. Запуск и результаты этих задач отправляют сообщение в Slack:

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

Примените эту концепцию к своему приложению

Приведенный выше пример — это практический пример того, что мы сделали для мониторинга приложения и службы GoFaster.io. Для нас это сработало фантастически, но как масштабировать эту концепцию на большие приложения, которые отправляют сотни, а то и тысячи сообщений в день? Как вы можете себе представить, это быстро превратилось бы в ситуацию «Слэкбот, который кричал волка», и значение потерялось бы в шуме.

Не относитесь ко всем уведомлениям одинаково

Некоторые уведомления более важны, чем другие, и важность зависит от сотрудника и его роли. Например, специалистов по разработке программного обеспечения и ИТ-эксплуатантов (DevOps) могут интересовать только сообщения сервера, в то время как персонал службы поддержки больше всего заботится о том, что происходит с пользователями.

К счастью, у Slack есть отличное решение этой проблемы: каналы .

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

Воплощая эту идею на практике, вот как более крупная организация может организовать уведомления на основе мониторов в Slack по каналам:

#Critical-Server-Errors

• Что: ошибки регистрации, ошибки входа в систему, ошибки чтения и записи базы данных
• Кто: системные администраторы, DevOps, технический директор, генеральный директор, разработчики
• Настройки оповещений: всегда уведомлять на телефоне или компьютере.

#Некритические-ошибки-сервера

• Что: 404 ошибки, всеохватывающие ошибки сервера и т. д.
• Кто: DevOps, разработчики
• Настройки предупреждений: сделайте жирным, но не звените.

#Финансы

• Что: платежные транзакции, неудачные транзакции, обновления, понижения, карты с истекшим сроком действия
• Кто: финансовый директор, генеральный директор
• Настройки предупреждений: Сделать дождь.

#Поведение пользователя

• Что: регистрация, процесс адаптации, обновление типа плана, добавление информации, удаление информации, удаление учетной записи.
• Кто: служба поддержки, менеджеры социальных сетей, разработчики, генеральный директор
• Настройки оповещений: всегда уведомлять на телефоне или компьютере.

#Приложение-Статистика

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

Заключение

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

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

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

Получите свежий взгляд на поведение пользователей и серверов

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

Быстро реагируйте, когда что-то не получается

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

Предлагайте исключительное обслуживание клиентов

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

Связь команды с приложением сделает вас более эффективным

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

Уведомления и каналы могут масштабироваться вместе с вашим приложением

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

Поиск силен

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

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