Начните с мониторинга вашего веб-приложения с помощью новых оповещений Relic

Вступление

Давайте начнем с крайнего примера. Спустя три года на рынке, по оценкам аналитического сайта Think Gaming , популярная игра Clash of Clans для защиты башни все еще остается самой прибыльной мобильной игрой на сегодняшний день, принося удивительные 1,5 миллиона долларов в день или чуть более 1000 долларов в минуту , В основе игры лежит кластер веб-серверов, которые заботятся обо всем: от учетных записей пользователей до игровых событий и обработки платежей.

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

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

Теперь представьте, что эта ошибка появилась ночью, когда никого не было на работе …

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

Еще хуже: если ошибка возникает в куске кода, который вы не тестируете каждый день, например, при обмене данными между вашей корзиной покупок и внешним поставщиком платежей, может пройти несколько дней, прежде чем один из ваших клиентов отправит вам электронное письмо, чтобы сообщить вам о проблеме!

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

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

Об этом мы и поговорим в этом уроке.

В этом уроке

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

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

В этом уроке мы будем использовать New Relic Alerts для создания набора предупреждений для мониторинга простого приложения PHP, работающего на экземпляре Amazon EC2. При этом мы также поговорим об общих принципах и передовых методах определения программных оповещений, которые помогут вам создать максимально возможную настройку оповещений для нужд вашего бизнеса.

Установите новую реликвию на вашем сервере

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

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

Предыдущие уроки Джеффа Райфмана и Алана Скоркина также помогут вам освоиться. Для получения дополнительной информации об Amazon EC2 ознакомьтесь с этим руководством по установке WordPress в Amazon Cloud .

Если вы уже используете New Relic на своем сервере, вы можете пропустить этот раздел и перейти к следующему разделу « Начало работы с оповещениями о новых реликвиях».

Шаг 1. Создайте новый экземпляр Amazon EC2

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

Чтобы создать тестовый экземпляр в Amazon EC2, сначала войдите в консоль администратора Amazon Web Services (если у вас еще нет учетной записи, ее необходимо создать, прежде чем продолжить). Затем в главном меню выберите EC2 (Виртуальные серверы в облаке).

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

Далее вам будет предложено выбрать образ машины Amazon (AMI) для виртуального сервера, который вы собираетесь запустить. Для этого учебника по умолчанию нам нужен вариант быстрого запуска Amazon Linux AMI 2015.03 .

Нажмите Выбрать, чтобы выбрать тот.

После выбора AMI вам будет предложено выбрать тип экземпляра — в основном размер машины. Поскольку мы будем использовать машину для экспериментов и обучения, t2.micro :

Убедитесь, что вы установили флажок напротив правильного типа экземпляра. Затем нажмите « Просмотр и запуск», чтобы перейти к последнему шагу в мастере запуска.

На этой странице вы увидите уведомление об улучшении ваших групп безопасности.

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

• Измените существующее правило SSH, чтобы ограничить доступ SSH только вашим IP-адресом (выберите « Мой IP» в раскрывающемся списке « Источник» ).
• Добавьте новое правило, чтобы открыть порт HTTP для всех (выберите Anywhere в раскрывающемся списке Source ).

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

После внесения изменений нажмите « Обзор и запуск», чтобы вернуться на страницу « Запуск экземпляра обзора» и запустить сервер.

В качестве последнего шага Amazon попросит вас создать новую пару ключей (или выбрать существующую) для подключения к новому серверу по SSH. Дайте паре ключей имя, загрузите ее, нажав « Загрузить пару ключей» , а затем нажмите « Запустить экземпляры» .

На вашем компьютере переместите загруженный файл пары ключей, например test_keypair.pem , из каталога загрузок в лучшее место и измените его свойства доступа, чтобы никто, кроме вас, не мог открыть файл.

Вот пример того, как это сделать в Mac OS X:

Теперь, чтобы подключиться к серверу, проверьте IP-адрес нового экземпляра на панели мониторинга Amazon EC2 и подключитесь к нему с помощью файла пары ключей (замените IP-адрес на соответствующий вашему серверу):

Если ваш сервер запущен и работает, вы должны войти в систему.

Установите PHP с помощью следующей команды. Принять предложенные пакеты.

Затем запустите Apache:

Вы создали простую настройку сервера Apache и PHP на Amazon EC2. Далее давайте начнем мониторинг с помощью New Relic APM.

Шаг 2. Включите новый Relic APM на вашем сервере

Во-первых, если у вас еще нет учетной записи New Relic, начните с ее создания.

На странице регистрации заполните все поля и нажмите « Зарегистрироваться для получения новой реликвии» .

Далее, давайте настроим инструмент мониторинга веб-приложений New Relic, APM .

На экране приветствия щелкните элемент New Relic APM :

После выбора APM вы увидите страницу с инструкциями по включению мониторинга в разных средах.

Если вы устанавливаете New Relic на сервере, отличном от сервера на основе Amazon EC2, который мы создали на предыдущем шаге, на этой странице « Начало работы с новой реликвией» вы, скорее всего, найдете инструкции, относящиеся к вашей среде.

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

Теперь нажмите на логотип PHP, чтобы просмотреть инструкции по установке агента PHP.

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

Затем в вашем окне SSH введите следующую команду, чтобы добавить репозиторий New Relic (для определенного выше экземпляра EC2 мы используем 64-битную версию):

Затем, чтобы установить агент PHP:

В конце установки скрипт попросит вас ввести лицензионный ключ New Relic:

Чтобы получить лицензионный ключ, вернитесь на страницу « Начало работы с новой версией» и нажмите « Открыть лицензионный ключ» .

Скопируйте ключ и вставьте его в подсказку оболочки для завершения установки.

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

Как только New Relic APM получает данные с вашего сервера, вместо экрана настройки, показанного выше, вы увидите панель управления APM с приложением PHP, перечисленным на ней:

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

Начните с новых оповещений о реликвиях

Теперь, когда вы настроили свой сервер, и New Relic APM следит за ним, пришло время перейти к актуальной теме этого урока: оповещения .

Шаг 1. Включите новые оповещения о реликвиях

Первое, что нужно сделать, это включить оповещения в вашей новой учетной записи Relic.

Нажмите на ссылку Atats ^Beta в верхнем правом углу окна New Relic. Оповещения по-прежнему являются бета-функцией, поэтому перед началом работы вам будет представлен экран с описанием его функций, а также список вещей, которые еще находятся в стадии разработки.

Хотя большинство функций уже реализовано, New Relic заявляет, что оповещения будут сохранять бета-статус, пока не будут добавлены оповещения «сервер не сообщает», поддержка API и метод переноса существующих оповещений в новую систему.

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

Чтобы начать использовать оповещения о новых реликвиях, прокрутите вниз до нижней части страницы, установите флажок «Я согласен принять условия и положения ^{бета-версии} новых оповещений о реликвиях» и нажмите кнопку « Испытать» .

Шаг 2. Создайте первую политику оповещения

После включения оповещений первое, что вы увидите, это страница для создания политики оповещений .

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

Вот почему лучший способ думать о политике оповещений — это уведомления.

Задайте себе два вопроса:

• Кому нужно получать уведомления из этого набора оповещений?
• Как они должны получать уведомления?

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

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

В этом руководстве мы начнем с создания простой, всеобъемлющей политики предупреждений, которую мы будем называть просто « Приложение ».

Введите имя в текстовое поле с названием «Team name» или «Service Name» и нажмите « Создать политику» .

Шаг 3. Знакомство с информационной панелью оповещений

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

Начиная слева, варианты:

• Инциденты: список нарушений, разделенных на две вкладки. Открытые инциденты — это оповещения, которые еще не разрешены и требуют вашего внимания прямо сейчас. Все происшествия — это исторический список, который вы можете использовать для поиска прошлых нарушений условий оповещения и просмотра того, что было сделано для их устранения.
• События : список всех событий из системы оповещений, разделенный на две вкладки. Нарушения показывают все нарушения состояния тревоги. События также перечисляют уведомления, отправленные на разные каналы уведомлений, и изменения в статусах инцидентов.
• Политики оповещений . Это сердце системы оповещений, набора правил, определяющих, как и когда отправляются оповещения.
• Каналы уведомлений . Здесь вы настраиваете каналы уведомлений, используемые в политиках оповещений, чтобы уведомлять вас и вашу команду об инцидентах в вашем приложении.

Пункт меню, который идет после этих четырех, Switch to Alerts ^Beta , сначала смутил меня. Из-за его названия у меня сложилось впечатление, что я еще не включил новые оповещения. Однако это было не так. Вместо этого это вариант, который вы можете использовать, чтобы пойти ва-банк и полностью интегрировать новую систему оповещений в свой опыт New Relic, оставив устаревшие оповещения позади.

Если вы нажмете на элемент меню, вы увидите следующую страницу:

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

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

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

Выбор ваш. И какой бы путь вы ни выбрали, теперь вы готовы создать свое первое оповещение.

Создайте свое первое оповещение

Теперь, когда вы включили оповещения о новых реликвиях и имеете общее представление об инструменте, пришло время приступить к работе и создать свое первое оповещение: оповещение, отправляющее уведомление по электронной почте, и Slack, если частота ошибок в вашем приложении PHP превышает 5%. хотя бы раз в 5 минут.

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

Но сначала давайте немного поговорим о том, что делает хороший программный сигнал тревоги.

Шаг 1. Решите проблемы, о которых вы хотите получать оповещения

В классической басне Эзопа « Мальчик, который плакал волк» скучающий мальчик-пастух снова и снова выкрикивает ложную тревогу о волке, атакующем его стадо. В конце концов, когда волк наконец появляется, жители деревни думают, что это просто еще одна ложная тревога, и никто не приходит ему на помощь.

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

Вот почему вы всегда должны начинать планировать свои оповещения, задаваясь вопросом: «Насколько важно это оповещение?» и «Как я (или моя команда) отреагирую на это предупреждение?»

Ваш ответ будет определять, что вы будете делать дальше:

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

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

Еще одна вещь, которую следует учитывать, — это порог оповещения или такие вопросы, как:

• Как скоро должно быть отправлено оповещение?
• Какой допустимый процент ошибок?
• Насколько низко может занять место на диске сервера, прежде чем что-то с этим делать?

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

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

Шаг 2: Выберите продукт и цель для мониторинга

Как я объяснял ранее, каждое условие оповещения в оповещениях о новых реликвиях принадлежит политике оповещения. Итак, чтобы добавить новое условие оповещения, сначала перейдите на вкладку « Политики оповещений » и выберите только что созданную политику « Приложение» .

Поскольку вы еще не создали ни одного условия оповещения, вы увидите следующий заполнитель в середине страницы:

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

Нажатие на кнопку запускает трехэтапный Мастер создания нового условия :

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

Ошибки PHP отслеживаются с помощью APM , поэтому давайте выберем эту.

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

• Метрика приложения . Этот параметр предоставляет доступ к метрикам приложения по умолчанию, измеряемым APM (Apdex, процент ошибок, время отклика и пропускная способность), а также к любым пользовательским метрикам, определенным в инструменте мониторинга.
• Ключевая метрика транзакции : как платная функция в APM, вы можете пометить некоторые транзакции в вашем приложении как «ключевые транзакции» — транзакции, которые имеют особое значение для вашего бизнеса или вашего продукта. Если вы выберете эту опцию, вы создадите условие оповещения таким же образом, как и при использовании параметра Метрика приложения , за исключением того, что вместо мониторинга всего приложения (или нескольких приложений) оповещение будет срабатывать только в том случае, если условие выполнено в пределах ключевая транзакция, которую вы выбираете.
• Внешняя служба . Этот параметр позволяет создавать условия оповещения на основе API или других вызовов внешних служб.

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

На этом втором экране вы выберете контролируемые приложения APM, о которых должно уведомить вас условие оповещения.

Сначала нажмите « Все приложения», чтобы открыть список приложений.

Затем установите флажок напротив нашего приложения (в нашем примере у нас есть только одно приложение, PHP-приложение ) и перейдите к последнему шагу в мастере, нажав кнопку Далее, определить пороговые значения .  

Шаг 3. Определите условие оповещения

Третий и последний шаг в мастере создания новых условий — это определение фактического условия предупреждения.

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

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

1. Выберите Процент ошибок в качестве метрики приложения для мониторинга.
2. Затем выберите подходящий оператор сравнения. В этом случае выше имеет смысл   (другие варианты ниже и равны ).
3. Определите порог: какой процент ошибок имеет смысл для отчета об ошибке? Сделайте это число слишком большим, и вы пропустите важные ошибки. Сделайте это слишком низким, и вы утонете в оповещениях. 5% — хорошая отправная точка, но в реальной жизни вы можете изменить порог вверх или вниз в зависимости от вашего приложения и ваших предпочтений.
4. Определите временные рамки: чтобы поймать наибольшее количество ошибок, выберите « хотя бы раз в » « 5 минут ». Это немедленно предупредит вас, если порог ошибки будет превышен хотя бы один раз в течение выбранного периода времени. С другой стороны, если вы хотите немного замедлить работу приложения, вы можете выбрать « по крайней мере » и получать уведомление только в том случае, если процент ошибок остается высоким в течение всей продолжительности выбранного периода времени.
5. При желании вы также можете определить порог предупреждения, используя меньший процент ошибок. Предупреждения не будут вызывать оповещения по электронной почте, но вы увидите их в списке событий, а также в представлении APM (если вы пошли олл-ин и стали ранним последователем — см. Обсуждение ранее в этом руководстве).
6. Дайте условию описательное имя или — если вы удовлетворены им — используйте имя по умолчанию, предложенное инструментом.
7. Если вы хотите предоставить своей команде информацию об инциденте и о том, как его исправить, вы можете добавить «URL-адрес runbook»: ссылку на внешнюю веб-страницу, например страницу документации, которая объясняет, что означает это предупреждение, и описывает шаги решить это. Чтобы сделать это, нажмите Add r unbook URL и введите URL в текстовое поле.

Когда вы будете удовлетворены условием оповещения, нажмите « Создать условие», чтобы сохранить его. Помните, что вы всегда можете вернуться, чтобы настроить его позже.

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

Если в любое время вы хотите изменить условие оповещения, просто нажмите на его правила. Обратите также внимание на кнопки « Копировать» и « Удалить» в правом верхнем углу вашего нового условия оповещения: они пригодятся, если в какой-то момент вы захотите переместить оповещение в другую политику оповещения.

Шаг 4. Настройка уведомлений по электронной почте для политики предупреждений

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

Давайте начнем с самого распространенного, электронной почты.

Чтобы начать создавать свой первый канал уведомлений, нажмите на пункт меню каналов уведомлений . Затем нажмите на большую кнопку с надписью Создать канал уведомлений .

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

Доступные на данный момент опции (согласно документации, в будущем будет добавлено больше каналов):

• Электронная почта : отправляет сообщение электронной почты на адрес электронной почты, указанный в конфигурации.
• HipChat : отправляет сообщение в комнату HipChat, указанную в конфигурации.
• PagerDuty : отправляет уведомление через инструмент администрирования NetOps PagerDuty . Это расширенный вариант для наиболее важных уведомлений, которые необходимо немедленно адресовать — предупреждения можно даже настроить так, чтобы они звонили вам по телефону!
• VictorOps : аналогично PagerDuty, эта опция отправляет уведомление через инструмент NetOps VictorOps . Функциональность этих двух инструментов довольно схожа, поэтому выбор зависит в основном от того, что вы уже используете.
• Webhook : отправляет уведомление на определенный вами URL. Используйте эту опцию, если вы хотите отправлять уведомления на канал, который в настоящее время не поддерживается непосредственно New Relic Alerts, или если вы хотите создать собственное решение …
• Campfire : отправляет уведомление в чат-комнату Campfire, указанную в конфигурации.
• Slack: отправляет уведомление на канал Slack, указанный в конфигурации.
• OpsGenie : отправляет уведомление с помощью системы оповещений OpsGenie NetOps. OpsGenie — это еще один инструмент, похожий на PagerDuty и VictorOps, который можно использовать, чтобы ваша команда замечала предупреждения по мере их появления.

В дополнение к этому New Relic Alerts автоматически создает канал уведомлений пользователей для каждого пользователя в вашей учетной записи. Этот канал можно использовать для отправки электронной почты и отправки уведомлений в приложение New Relic для iPhone и Android.

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

Когда вы нажимаете на опцию E-mail , остальная часть формы автоматически обновляется, чтобы показать конфигурацию уведомлений по электронной почте:

Введите адрес электронной почты в поле « Электронная почта» и нажмите « Создать канал» . Если вы хотите отправить дополнительные данные об инциденте вместе с сообщением электронной почты (например, если письмо читается программно), установите флажок Включить вложение JSON .

И все, канал уведомлений по электронной почте создан:

Чтобы прикрепить этот канал уведомлений к ранее созданной политике предупреждений, вернитесь на страницу политик предупреждений и выберите политику предупреждений «Приложение».

Затем нажмите, чтобы просмотреть вкладку « Каналы уведомлений ». Поскольку для этой политики предупреждений еще не определены каналы уведомлений, вкладка будет выглядеть следующим образом:

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

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

Затем нажмите « Обновить политику», чтобы сохранить изменения.

Шаг 5. Настройка слабых уведомлений для политики предупреждений

Далее, давайте сделаем уведомления появляться на канале Slack. Если вы не используете Slack, вы можете пропустить этот шаг и перейти к следующему шагу, на котором мы начнем тестировать оповещение.

Сначала в окне чата Slack нажмите стрелку вниз рядом с вашим именем пользователя, чтобы открыть меню. Затем выберите параметр « Настроить интеграцию» :

Откроется новая вкладка браузера со страницей интеграции Slack.

Используйте строку поиска в верхнем правом углу списка служб, чтобы найти тип интеграции New Relic.

Прокрутите вниз до опции Incoming WebHooks и нажмите Add .

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

После выбора канала продолжите, нажав « Добавить новую интеграцию с реликвиями ».

На следующей странице разверните инструкции для первого элемента в списке, « New Relic Alerts [Beta] ». Затем скопируйте URL-адрес Webhook, показанный в разделе « Шаг 2» . Это уникальный сгенерированный URL-адрес, который следует использовать только для этой интеграции. Если у вас есть основания подозревать, что URL-адрес просочился кому-то, у кого его не должно быть, вы можете (и должны) создать новый.

Вернитесь на страницу каналов уведомления о новых реликвиях и создайте новый канал уведомлений, выбрав Slack в качестве типа канала . В опциях этого нового канала вставьте только что скопированный URL-адрес в текстовое поле с меткой URL :

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

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

Шаг 6: протестируйте оповещение, сделав код неудачным

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

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

Чтобы создать ошибку PHP в настройке сервера, которую мы создали ранее, сначала используйте SSH для подключения к вашему серверу. Затем перейдите в корневой каталог вашего веб-сервера:

В этом каталоге создайте файл PHP, например error.php , и напишите какой-нибудь неисправный код, чтобы скрипт сломался при попытке загрузить его в браузере:

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

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

Вот как ошибка будет выглядеть в вашем письме:

И то же самое уведомление в Slack:

Когда вы щелкаете по ссылке « Просмотр сведений об инциденте» в электронном письме или номере инцидента в Slack, вы будете перенаправлены на соответствующую страницу «Новые оповещения о реликвиях» с гораздо более подробной информацией о проблеме, вызвавшей уведомление:

Если вы готовы начать работу с предупреждением, нажмите кнопку « Подтвердить» справа. После того, как вы нажали на кнопку, она заменяется следующей информацией о состоянии:

Вы (и ваша команда, как настроено в каналах уведомлений) также получите уведомление о подтверждении по электронной почте и Slack. Это подтверждение означает, что вы берете на себя ответственность за решение проблемы, и статус не может быть изменен: как только вы подтвердите предупреждение, никто больше не сможет подтвердить его снова.

Прокрутив вниз до нижней части страницы предупреждения, вы увидите следующие кнопки, которые можно использовать для получения дополнительной информации о решении проблемы ( Открыть Runbook ), Изменить условие предупреждения (если вы считаете, что это ложное предупреждение) или Вручную закрыть нарушение (как только вы исправили проблему).

Для получения дополнительной информации о проблеме вы также можете посетить страницу ошибок APM:

Используйте информацию из APM для решения проблемы (на этот раз это просто).

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

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

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

Другие метрики для ваших оповещений

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

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

1. Условия оповещения на основе показателей APM

APM (сокращение от Application Performance Monitoring) — флагманский продукт New Relic: инструмент мониторинга приложений, который опускается до уровня кода, измеряя такие вещи, как ошибки и время, которое ваше приложение занимает в различных точках выполнения.

В дополнение к условию предупреждения о высоком проценте ошибок, которое мы создали выше, для создания предупреждений можно использовать следующие показатели APM.

• Apdex: Apdex (Индекс производительности приложений) — это стандартный метод, определенный для измерения и сравнения производительности программных приложений. Метрика измеряет удовлетворенность конечного пользователя и изменяется от 0 до 1, где 1 означает, что каждый пользователь удовлетворен, а 0 означает, что никто не удовлетворен. Хорошее число для начала — 0,7, что является порогом оповещения по умолчанию в устаревших оповещениях New Relic.
• Время отклика и пропускная способность. Время отклика показывает, сколько времени в среднем обрабатываются запросы к вашему приложению. Пропускная способность — это связанный показатель, который описывает, сколько запросов было успешно обработано вашей службой в течение заданного периода времени. Хотя обе метрики включены в вычисление Apdex, добавление оповещений для них сделает ваши оповещения более конкретными и, таким образом, их будет легче анализировать и направлять нужным людям.
• Пользовательская метрика : если вы записываете свои собственные пользовательские метрики в APM , вы можете использовать их для создания собственных условий оповещения для конкретного приложения.
• Внешняя служба . Используя тип условия внешней службы, вы можете создавать оповещения на основе времени отклика и пропускной способности от HTTP-вызова к внешней службе. Например, на моем собственном сайте мониторинг запросов внешних сервисов помог мне определить API-вызов Tumblr в качестве основной причины медленного времени загрузки.

Если вы выберете Ключевые показатели транзакции (платная функция в APM) в качестве Типа условия , вы получите доступ ко всем тем же показателям, описанным в приведенном выше списке, но они будут использоваться для отслеживания только выбранных транзакций, а не всей заявление.

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

2. Оповещения на основе метрик браузера

Браузер — это новый продукт для мониторинга Relic, разработанный для того, чтобы дать вам представление о том, как реальные пользователи воспринимают ваше веб-приложение: отслеживание того, что происходит внутри браузера. Для более подробного объяснения инструмента и инструкций по его включению в вашей учетной записи New Relic, ознакомьтесь с этим руководством .

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

• Apdex для конечного пользователя : ключевой показатель в оповещениях на основе браузера. Apdex для конечного пользователя измеряет процент пользователей, которые удовлетворены производительностью приложения, принимая во внимание также производительность приложения при его запуске в браузере.
• Время загрузки страницы : группа показателей для измерения времени, затрачиваемого на различные части загрузки страницы: общее время загрузки страницы, отображение страницы, веб-приложение, сеть, обработка DOM и очереди запросов — все это можно использовать для получения более подробных предупреждений о конкретных узкие места в опыте конечного пользователя.
• Просмотры страниц с ошибками JavaScript: Количество ошибок JavaScript в вашем приложении может быть признаком плохого программирования, которое следует быстро устранить. Используя эту метрику, вы можете создать предупреждение, аналогичное предупреждению о проценте ошибок, которое мы создали в этом руководстве — только на этот раз, измеряя ошибки JavaScript вместо ошибок в коде PHP приложения.
• Время отклика AJAX и пропускная способность: Если ваше приложение использует AJAX-вызовы для важных действий со стороны конечного пользователя, важно быстро найти в них проблемы. Для этого вы можете использовать метрики, измеряющие, сколько времени требуется AJAX-запросам для обработки и сколько запросов AJAX было успешно обработано за определенный период времени. 
• Пользовательская метрика . Как и в предупреждениях APM, вы также можете использовать пользовательские метрики в своих предупреждениях браузера.

3. Оповещения на основе метрик серверов

Серверы — это продукт New Relic для измерения того, что происходит на вашем сервере физически. Вместо того, чтобы смотреть на метрики приложений, как мы это делали с APM и браузером, теперь мы говорим о таких вещах, как использование дискового пространства и загрузка ЦП — о тех метриках, которые вы хотите, чтобы ваша команда NetOps (или только вы, если вы маленький операция), чтобы всегда оставаться на вершине. Смотрите этот учебник для получения дополнительной информации о новых серверах Relic.

Все эти показатели являются важными источниками — обычно срочных — оповещений:

• CPU% : если ваше приложение использует много ресурсов ЦП, это может быть признаком того, что вам нужно либо оптимизировать приложение, либо переместить его на более мощный сервер. В обоих случаях полезно знать, когда вы достигнете пределов того, с чем машина может справиться.
• Дисковый ввод-вывод% : на новых серверах Relic метрика дискового ввода-вывода% показывает, сколько времени ваши диски используются, 0% означает отсутствие операций с диском вообще и 100%, что диск используется все время.
• Память% : особенно при работе с приложениями, интенсивно использующими данные, память — это один из первых ресурсов, о котором вам нужно беспокоиться. Удостоверьтесь, что вы получили уведомление достаточно рано, до того, как на машине не хватит свободной памяти.
• Fullest Disk%: когда на вашем сервере заканчивается свободное место на жестком диске, вы можете быть уверены, что ваше приложение не будет работать должным образом. Опять же, лучше решить проблему с дисковым пространством, прежде чем она затронет ваших пользователей: около 90% заполнено или около того.
• Средняя нагрузка : Средняя нагрузка говорит о том, насколько хорошо ЦП сервера справляется с работой, за которую он отвечает. Значение 0 означает полностью бездействующий компьютер, и каждый запущенный или ожидающий процесс добавляет к числу. Порог оповещения зависит от того, сколько ядер у вашего сервера: в одноядерной системе средняя загрузка 1 означает, что процессор используется на полную мощность (с двумя ядрами число равно 2 и т. Д.). Более высокие значения означают, что есть некоторые процессы, ожидающие в очереди.

Что дальше?

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

Если вы хотите повозиться, Alerts предоставляет вам широкий спектр возможностей для настройки и точной настройки ваших предупреждений до тех пор, пока они не станут правильными: добавьте некоторые пользовательские метрики в свой код, используйте данные из плагинов New Relic и отправляйте предупреждения на все виды различных уведомлений. каналы — или, если вы разработчик мобильных приложений, обратите внимание на мобильные оповещения. Мы только поцарапали поверхность.

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

Но сначала идите и создайте несколько предупреждений!