App Monitor регистрирует каждую ошибку, с которой Twilio сталкивается при взаимодействии с вашим приложением — будь то ошибка валидации или парсинга TwiML-документа, или невозможность получить ответ от URL. Если любая из этих операций (и многие другие) идет не так, Twilio записывает это в App Monitor.
По умолчанию в каждой учетной записи создается три триггера, которые срабатывают при первой, десятой и сотой ошибке за день. По умолчанию эти триггеры отправляют вам электронное письмо с информацией об ошибке. Вы можете создавать собственные триггеры для конкретных ошибок или определенного количества ошибок за период времени. Например: вы можете создать триггер App Monitor, который срабатывает каждый раз, когда возникает ошибка «Неверный код страны» (13266).
Мы — люди, которые работают с программным обеспечением, и не всегда хотим получать уведомления об ошибках по электронной почте. Мы хотим знать об этом быстро, удобным способом и прямо сейчас! Особенно, если мы развертываем критически важный код и хотим убедиться, что он работает эффективно.
Триггеры App Monitor могут вместо отправки электронного письма отправлять HTTP POST-запрос по выбранному вами URL. Этот механизм часто называют веб-хуком. Запрос веб-хука будет содержать много полезной информации об ошибке, которая только что произошла, в виде POST-данных. Вы можете извлечь эти данные из запроса и обрабатывать их в программе по своему усмотрению. Возможно, вы захотите записать их в базу данных или отправить уведомление в Hipchat своим разработчикам, предупредив их, что мир рушится, и им нужно это исправить.
Недавно я создавал приложение, которое использовало веб-хуки триггеров App Monitor, и я понял — какая лучшая платформа для связи в реальном времени, которую я могу использовать для получения оповещений, когда что-то идет не так? Конечно, SMS, и я слышал о Twilio. Я решил поместить Twilio внутрь моего Twilio, чтобы я мог использовать Twilio, пока я использую Twilio.
Давайте создадим систему SMS-оповещений, которая будет отправлять нам SMS-сообщение при получении ошибки App Monitor с помощью веб-хуков триггеров App Monitor.
В этом посте вы узнаете, как:
— Настроить новый триггер App Monitor с сконфигурированным веб-хуком
— Использовать hurl.it для получения имитированных HTTP-запросов к вашему веб-серверу с информацией об имитированных ошибках.
— Использовать Twilio REST API для отправки SMS-сообщения
Все, что вам понадобится (кроме вашего любимого языка программирования, мы будем использовать Python), — это бесплатный пробный аккаунт Twilio, который можно зарегистрировать за 30 секунд.
Эта часть руководства очень проста: мы просто зайдем в Twilio App Monitor в нашей учетной записи на twilio.com и нажмем «Triggers“:
Мы создадим триггер, который срабатывает при ошибке получения HTTP. Это довольно распространенная ошибка при разработке с Twilio, поэтому она является хорошим примером. В продакшене я рекомендую настраивать триггеры App Monitor для наиболее вероятных ошибок, которые могут возникнуть в вашем приложении Twilio. Если вы не уверены, какие это ошибки, проверьте App Monitor на наличие списка ошибок, которые у вас уже есть — они, скорее всего, повторятся!
Здесь мы устанавливаем Friendly Name на *HTTP retrieval error* (Ошибка получения HTTP), это удобочитаемое имя, которое будет полезно вашей команде отладки, поэтому убедитесь, что оно описательное. Код ошибки, который мы отслеживаем, — *11200 – HTTP retrieval failure* (Ошибка получения HTTP), которая возникает, когда Twilio делает HTTP-запрос и получает в ответ статус-код HTTP 404. Мы хотим, чтобы Trigger Value было *1* (триггер будет срабатывать 1 раз), и мы хотим установить Recurring значение на *Daily* (Ежедневно).
Что это нам дает? Триггер App Monitor, который срабатывает при возникновении *ошибки получения HTTP*, *в первый раз*, *каждый день*.
А теперь небольшой трюк: вместо того, чтобы добавлять адрес электронной почты в поле ниже, нажмите ссылку Trigger a Webhook справа, чтобы преобразовать это в программный триггер:
Вы можете узнать больше о триггерах Twilio App Monitor на странице документации.
Наконец, мы можем сохранить новый триггер App Monitor, нажав *Save*.
Теперь, когда у нас есть триггер App Monitor, готовый к срабатыванию, нам нужно написать код на нашем сервере, который будет получать HTTP-запросы и анализировать их.
В этом примере я буду использовать Python и Flask (микрофреймворк для веб-приложений) для создания простого сервера, который будет получать запросы и создавать SMS-сообщения на их основе.
Если у вас еще не установлен Flask, вы можете установить его с помощью pip, выполнив следующую команду в терминале:
Мы также установили библиотеку-помощник Twilio для Python.
Стандартный код Flask, который нам нужен, который будет знаком всем разработчикам Flask, будет сохранен в файле под названием *app.py*:
Нам нужно добавить маршрут URL на сервере, к которому будут поступать HTTP-запросы. Во Flask мы можем сделать это довольно легко:
Новый код, который мы добавляем в строке 4, регистрирует новый маршрут URL в нашем приложении Flask под названием */error_trigger*, точно так же, как мы настроили его выше в нашем триггере App Monitor. Мы также принимаем HTTP POST-запросы в этой строке со вторым параметром.
Этот маршрут связан с функцией, которую мы назвали *error_triggers*, которая не принимает параметров и просто возвращает строку *‘Hello Twilio’* пока что. Это бесполезно для нас, поэтому давайте фактически перехватим входящий запрос и напечатаем что-нибудь из него:
Новый код (в строках 6 и 7) заменяет простую инструкцию *Hello Twilio*. Вместо этого мы получаем значение из HTTP-запроса (в данном случае, *ErrorCode*) и сохраняем его в переменной. В строке 7 мы возвращаем код ошибки.
Мы довели наше приложение до того момента, когда, вероятно, захотим начать тестирование его работоспособности. Искусственно вызывать ошибки из приложения Twilio непрактично и является плохой практикой. Вместо этого я обнаружил отличный инструмент для отправки HTTP-запросов под названием hurl.it, который позволяет отправлять HTTP-запросы, добавлять к ним заголовки или параметры, а также изменять методы HTTP. Он также красиво отображает ответы.
О, и у него в качестве талисмана есть потрясающий единорог, плюющийся радугой, так почему бы не использовать его?
Давайте перейдем на hurl.it и настроим простой HTTP POST-запрос с одним параметром, ErrorCode, и отправим его на наш веб-сервер:
HTTP-ответ успешен (мы получаем ответ 200 OK), а в теле отображается код, который мы хотели вернуть на основе значения, которое мы отправили.
Отлично! Наше приложение может общаться с нами. Давайте изменим код, чтобы он выводил полезное сообщение на основе некоторых параметров, которые может отправить триггер Twilio App Monitor:
Новый код (в строках 8–13) извлекает значения Description (Описание) и ErrorCode из HTTP-запроса и форматирует их для создания приятного сообщения, включая ссылку на документацию Twilio по этой ошибке. Обратите внимание, что URL не будет работать для триггера «любая ошибка».
Давайте отправим еще один запрос hurl.it на наше приложение и посмотрим, как будет выглядеть ответ. Я изменил параметры, чтобы имитировать реальную ошибку — ошибку получения HTTP:
Теперь все выглядит хорошо, но мы еще не отправляем SMS-сообщения, поэтому давайте добавим последний фрагмент кода, чтобы преобразовать это сообщение в SMS Twilio и сделать его действительно полезным.
Здесь происходит много нового, поэтому давайте разберем все по частям.
В строке 4 мы импортируем TwilioRestClient — библиотеку-помощник Python для Twilio. В строке 5 мы инициализируем библиотеку-помощник с нашими Account Sid и Auth Token. Наш ACCOUNT_SID и AUTH_TOKEN можно найти на нашей панели управления Twilio.
Единственный другой код, который мы добавляем, — это несколько строк, начинающихся со строки 16, которые создают новое SMS-сообщение. Параметры, передаваемые этой функции, включают номер телефона получателя, который является номером, на который вы хотите отправить сообщение (ваш телефон, если вы не уверены), и номер отправителя, который должен быть номером Twilio. Если у вас нет номера Twilio (у каждого пробного аккаунта есть один), вы можете получить новый в разделе номеров на вашей странице аккаунта. Наконец, сообщение, которое мы хотим отправить, — это то же самое сообщение, которое мы выводим.
Теперь, когда мы отправляем тот же HTTP-запрос, мы также должны получить SMS-сообщение на указанный номер телефона:
Теперь, если вы развернете этот код на своем сервере, ваша команда разработчиков всегда будет знать о проблемах, как только они возникнут.
Что мы здесь узнали? Мы только что рассмотрели продвинутую тему мониторинга ошибок приложений в ваших приложениях Twilio, настройки веб-хук-триггера и использования SMS Twilio через REST API, создав это милое маленькое приложение.
Я думаю, что сейчас самое время рассмотреть некоторые из лучших триггеров для мониторинга в вашем приложении. Вот мои предложения:
— 11200 – HTTP retrieval failure – Отлично подходит для проверки новых конечных точек, вы захотите отслеживать это, как только оно произойдет, поэтому установите значение триггера на 1.
— 13226 – Dial: Invalid Country Code – Иногда пользователи могут неправильно отформатировать номер, и это хороший способ проверить, происходит ли это. Если это не критично, я бы установил значение триггера довольно низким, чтобы уловить его на ранней стадии.
— 13520 – Say: Invalid Text – Если вы автоматически генерируете текст для речи, этот триггер обязателен. Вы всегда получите какой-нибудь случайный бред, который нарушит работу TTS-движка.
Twilio имеет обширный список ошибок App Monitor, которые могут возникнуть, поэтому стоит их изучить. Не забудьте также прочитать полную документацию по триггерам App Monitor.