Advertisement
  1. Code
  2. Web Development

Начало работы с мониторингом вашего веб-приложения с использованием  New Relic Alerts

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Performance Monitoring With New Relic.
Diagnose WordPress Performance Problems With New Relic
How to Use New Relic Browser to Improve Your Web App's User Experience
Sponsored Content

This sponsored post features a product relevant to our readers while meeting our editorial guidelines for being objective and educational.

Russian (Pусский) translation by Ilya Nikov (you can also view the original English article)

Введение

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

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

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

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

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

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

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

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

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

В этом учебнике

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

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

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

Настройка New Relic на вашем сервере

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

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

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

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

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

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

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

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

Launch a new EC2 instance

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

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

The default Amazon Linux AMI is good for what were doing

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

Pick the t2micro instance type

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

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

Review Instance Launch

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

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

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

Example security group settings

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

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

Set up key pair

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

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

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

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

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

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

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

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

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

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

SIgn up for New Relic

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

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

Welcome to New Relic

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

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

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

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

Get started with New Relic APM

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

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

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

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

Enter New Relic license key

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

Get your license key

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

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

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

New Relic APM Dashboard

Как только это произойдет, вы можете начать использовать New Relic Alerts.

Начинаем работу с New Relic Alerts.

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

Шаг 1: включение New Relic Alerts.

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

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

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

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

Welcome to New Relic Alerts screen

Чтобы начать использовать New Relic Alerts, прокрутите вниз до нижней части страницы, отметьте галочкой «Я согласен принять условия и положения New Relic AlertsBeta» и нажмите кнопку «Попробовать».

Enable New Relic Alerts beta

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

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

Create your first alert policy

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

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

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

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

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

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

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

Введите имя в текстовое поле, в котором указано Название команды или имя службы, и нажмите «Создать политику».

Шаг 3: ознакомьтесь с панелью предупреждений

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

Alerts dashboard showing alerts for the Application alert policy

Начиная с левой стороны, параметры:

  • Incidents: список нарушений, разделенных на две вкладки. Open Incidents - это предупреждения, которые еще не решены и требуют вашего внимания прямо сейчас. All Incidents - это исторический список, который вы можете использовать для поиска прошлых нарушений состояния предупреждения и для выяснения того, что было сделано для их устранения.
  • Events: список всех событий из системы оповещений, разделенных на две вкладки. Violations показывают все нарушения состояния предупреждения. Events также перечисляют уведомления, отправленные по разным каналам уведомлений, и изменения статусов инцидентов.
  • Политика оповещений: это основа системы предупреждений, набор правил, которые определяют, как и когда отправляются оповещения.
  • Notification channels: Здесь вы настраиваете каналы уведомлений, используемые в политиках предупреждений, чтобы уведомить вас и вашу команду об инцидентах в вашем приложении.

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

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

Go all-in on New Relic Alerts

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

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

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

Become an early adopter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No conditions yet

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

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

Select a product for the alert

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

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

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

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

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

Select application to monitor

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

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

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

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

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

Define the alert condition

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

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

  1. Выберите процент ошибки в качестве показателя приложения для мониторинга.
  2. Затем выберите подходящий оператор сравнения. В этом случае above имеет смысл (остальные варианты below и equal to).
  3. Определите порог: какой процент ошибок имеет смысл для отчета об ошибке? Сделайте эту цифру слишком высокой, и вы пропустите важные ошибки. Сделайте ее слишком низкой, и вы будете тонуть в предупреждениях. 5% - хорошая отправная точка, но в реальной жизни вы можете изменить порог вверх или вниз в зависимости от вашего приложения и ваших предпочтений.
  4. Определите временные рамки. Чтобы уловить большинство ошибок, выберите «at least once in" "5 mins"». Это немедленно предупредит вас, если порог ошибки будет превышен даже один раз в течение выбранного периода времени. С другой стороны, если вы хотите, чтобы ваше приложение было немного слабее, вы можете выбрать «for at least» и получать уведомление только в том случае, если процент ошибки остается высоким в течение всей продолжительности выбранного периода времени.
  5. Если вам нравится, вы также можете определить порог предупреждения, используя более низкий процент ошибок. Предупреждения не будут вызывать оповещения по электронной почте, но вы увидите их в списке событий, а также в представлении APM.
  6. Дайте условию описательное имя или, если вам нравится, используйте имя по умолчанию, предложенное инструментом.
  7. Если вы хотите предоставить своей команде информацию об инциденте и как его исправить, вы можете добавить «URL-адрес рабочей среды»: ссылку на внешнюю веб-страницу, например страницу документации, в которой объясняется, что означает это оповещение, и описывает этапы его решения. Для этого нажмите «Добавить URL-адрес рабочей книги» и введите URL-адрес в текстовое поле.

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

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

Alert condition added

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

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

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

Начнем с наиболее распространенного сообщения электронной почты.

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

No notification channels configured yet

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

Select the type of notification channel to create

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

  • E-mail: отправляет электронное сообщение на адрес электронной почты, указанный в конфигурации.
  • 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 автоматически создает канал уведомлений Users для каждого пользователя в вашей учетной записи. Этот канал можно использовать для отправки электронной почты и для отправки уведомлений на приложение New Relic для iPhone и Android.

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

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

Create an e-mail notification channel

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

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

The e-mail notification channel was created successfully

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

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

The policy doesnt have any notification channels yet

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

Select the e-mail notification channel

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

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

Шаг 5: Настройка Slack уведомлений для политики предупреждения

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

Во-первых, в окне Slack chat нажмите стрелку вниз рядом с вашим именем пользователя, чтобы открыть меню. Затем выберите опцию Configure Integrations:

In Slack click on Configure Integrations

Это откроет новую вкладку браузера, на которой показана страница Интеграции Slack.

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

Slack Integrations

Прокрутите вниз до параметра «Входящие WebHooks» и нажмите «Добавить».

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

Add New Relic Integration

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

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

New Relic Alerts Beta

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

Notification Channels

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

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

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

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

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

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

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

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

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

Вот как будет выглядеть ошибка в вашей электронной почте:

The alert notification email message

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

Alert notification in Slack

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

View incident details

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

Incident acknowledged

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

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

Incident actions

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

More information about the error

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Предупреждения на основе показателей браузера

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

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

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

3. Оповещения на основе показателей Servers

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

Эти показатели являются важными источниками для обычно-срочных предупреждений:

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

Что дальше?

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

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

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

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

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.