Эта статья была спонсирована Loggly . Спасибо за поддержку спонсоров, которые делают возможным использование SitePoint.
При запуске приложения или веб-сайта вам будет целесообразно отслеживать не только статистику посещений, но и эффективность. Хотя мы привыкли настраивать мониторинг времени простоя сразу после развертывания, это не всегда так с мониторингом производительности. Медленный сайт означает медленный доход, особенно в наши дни, когда посетители ожидают загрузки сайтов всего за пару секунд.
С такими превосходными инструментами, как New Relic, мониторинг и управление производительностью приложений больше не должны быть такими хлопотами. А еще лучше, они недавно объединились с Loggly, сервисом, который обеспечивает управление журналами и анализ, чтобы еще лучше понять производительность вашего приложения или сайта. Теперь вы можете легко погрузиться дальше от того, что произошло, в то, как это произошло.
В этой статье я покажу вам, как New Relic и Loggly работают как комбинированный инструмент. Как только вы освоите основы, я покажу вам, как эти два мощных инструмента объединяются в мечту разработчиков для анализа плохой производительности или простоев.
Почему вы должны использовать управление производительностью приложений (APM)
Возможно, вы слышали о New Relic до того, как у них были отличные партнерские отношения с SitePoint. Даррен Джонс подробно рассказал о них в своей превосходной статье о мониторинге Ruby в реальном времени .
New Relic предлагает несколько решений для управления производительностью приложений (APM). Если вы хотите контролировать свое веб-приложение, мобильное приложение или сервер, у New Relic есть подходящие инструменты для работы. У них также есть бесплатная версия всех своих продуктов. В этой статье я остановлюсь на New Relic APM и расскажу о его впечатляющей панели инструментов.
Чтобы New Relic работал правильно, вам необходимо иметь доступ администратора к серверу, на котором работает ваше приложение. После установки ваша приборная панель оживет. После запуска небольшого нагрузочного теста вы увидите ваше приложение ( интернет-магазин Magento в моем случае) в действии.
Панель инструментов показывает среднее время загрузки вашего PHP-приложения, базы данных и внешних источников (например, DNS). Вы также можете увидеть свою пропускную способность (75 запросов в минуту на этом снимке экрана) и оценку APDEX (которая по сути является показателем удовлетворенности, основанным на среднем времени загрузки 0,5 секунды по умолчанию). Затем можно дополнительно увеличить все эти параметры, например время загрузки внешних источников или вызовы базы данных.
Существует также ограниченная информация о сервере с использованием процессора и памяти, а также пропускная способность и время отклика. Для более расширенного мониторинга серверов вы должны использовать New Relic Servers , но даже в ограниченном режиме это все еще ценная информация.
Поскольку New Relic предоставляет вам отчеты в реальном времени, вы можете мгновенно увидеть эффект от внесенных вами изменений. При запуске второго теста загрузки я включил кеш Magento во время теста, что привело к мгновенному снижению времени загрузки PHP, а также уменьшению количества запросов к базе данных. New Relic дает вам хороший обзор результатов прямо сейчас.
Наряду с отчетами в режиме реального времени, вы можете запустить множество дополнительных отчетов. Вы также можете настроить оповещения для определенных событий, таких как простои или замедления.
В общем, New Relic — отличный инструмент для тестирования производительности, но в некоторых случаях вам захочется углубиться и посмотреть в своих журналах для подробного анализа. Вот тут и вступает Loggly. Он имеет интеграцию с New Relic, что делает его очень удобным для перехода с события из New Relic в журналы, размещаемые в Loggly. Давайте посмотрим.
Почему вы должны ценить свои журналы
Loggly — это все об управлении и анализе логов, и они предоставляют вам некоторые изящные инструменты для этого. Настройка проста, с парой команд в командной строке. После этого вы находитесь в бревенчатом раю. Loggly дает вам понимание каждой детали вашего приложения.
В то время как New Relic рассказывает вам о том, что происходит в интерфейсе, Loggly дает вам представление о том, что происходит в вашем стеке. На моем скриншоте вы видите, что Loggly сообщает, что моему экземпляру не хватило памяти. New Relic, однако, показывал только «более низкую» или «нет» производительность, потому что они не измеряют ограничение памяти вашего сервера. Без Loggly я бы просто не знал, что произошло в этом случае.
На скриншоте выше вы увидите журналы нескольких перезапусков за короткое время. Как вы можете видеть, Loggly дает вам чрезвычайно подробную информацию о нарастании времени простоя на разных уровнях. Loggly имеет гранулированный подход, поскольку каждое событие хранится отдельно, где New Relic их объединяет.
Ошибка или проблема с производительностью могут иметь несколько основных причин, но New Relic показывает только конечный результат и его влияние. С Loggly вы можете проследить каждое событие до его происхождения и увидеть, что произошло в моменты, прежде чем оно произошло. Это также позволяет вам точно определить проблему конкретного пользователя, например. Также при просмотре журналов я заметил, что кто-то пытался войти в систему как root, попытка была заблокирована. Это вся ценная информация, которую New Relic не может предоставить, и Loggly делает это отлично.
Loggly предоставляет вам несколько способов создания собственных пользовательских панелей мониторинга для мониторинга ваших приложений или даже разделов вашего приложения или сайта. Вы можете интегрировать его с другими инструментами, такими как PagerDuty или HipChat для расширенного уведомления. Вы также можете настроить различные оповещения в самом Loggly, и он имеет универсальную панель поиска, чтобы быстро получить соответствующие журналы на основе ваших условий поиска.
Просмотр тонны журналов может быть утомительной задачей, особенно когда вы не можете точно определить, что означала каждая запись в интерфейсе. Чтобы помочь вам в анализе, New Relic и Loggly объединились, чтобы предоставить вам отличную интеграцию. Используя расширение Chrome, вы можете просто нажать на событие, о котором сообщает New Relic, и найти соответствующие журналы в Loggly. Посмотрим, как это работает.
Получение лучшего из обоих миров: объединение APM с управлением журналами для подробного анализа поломок
Новые Relic и Loggly сами по себе предоставляют отличные способы решения проблем с производительностью. Но когда вы проводите анализ, вы не можете легко поставить их в ряд без постоянного переключения. Особенно с более популярными приложениями или сайтами, о которых мы говорим в миллисекундах, с десятками или даже сотнями событий и транзакций, происходящих каждую секунду.
Для решения установите « New Relic — Loggly Extension ». После того, как вы это сделаете, вы получите кнопку «Поиск событий в Loggly» на экране каждой ошибки и события в New Relic.
Каждый раз, когда вы просматриваете событие, ошибку или транзакцию и нажимаете эту кнопку, точные параметры даты и времени передаются в Loggly. Таким образом, вы получите идеальное совпадение в Loggly без дополнительной настройки времени. Затем Loggly позволяет вам прокручивать полный журнал, чтобы вы могли видеть все, что произошло до того, как произошло фактическое событие.
Давайте посмотрим на несколько нагрузочных тестов, которые я провел на своем демонстрационном сайте . Я загрузил домашнюю страницу несколькими продуктами и отключил кэширование, что приводит к большому количеству обращений к базе данных для каждого посещения. Затем я запустил тестер нагрузки ( Load Impact ) с 50 одновременными пользователями, и через минуту сайт вышел из строя. После первого теста я снова включил кэш и запустил тот же тест, но на этот раз со 100 одновременными пользователями. Снова через минуту сайт закрылся.
Через несколько минут New Relic догнал меня, и я смог проанализировать причины простоя. Я ожидал, что база данных сразу сломается, но с включенным кешем этого не должно быть. В обоих случаях были десятки транзакций PHP (максимум 100 при втором тесте), но в обоих случаях база данных использовалась даже при включенном кэшировании (это может быть связано, например, с отсутствием кэширования виджетов).
Нажатие кнопки «Поиск событий в Loggly» дало мне точно такой же период времени, чтобы я мог начать копать. После сравнения нескольких событий выяснилось, что и Apache, и MySQL исчерпали память. Apache в основном отвечал за включение кеша, но даже тогда MySQL мог бы нанести последний удар.
Поэтому простым решением было бы обновить экземпляр, на котором работал интернет-магазин. Он вырос с 512 МБ с 1-ядерным процессором до 8 ГБ с 4-ядерным процессором.
После обновления я запустил дополнительный тест с включенным кешем и 50 одновременными пользователями. Опять же, обращения к базе данных все еще выполнялись, но производительность была довольно стабильной (хотя и немного медленной) и простоев не было.
Логгли тоже был очень доволен, единственное событие — изменение размера экземпляра. Несмотря на то, что это довольно простой пример, он показывает, насколько просто анализировать события в Loggly на основе определенных моментов, которые вы видите в New Relic. Расширение Chrome облегчает переключение.
Это действительно все, что есть. Но даже если это звучит просто, это сэкономит вам огромное количество времени, когда вы захотите проанализировать несколько событий. Вы можете получить расширение Chrome без дополнительных затрат, а настройка займет не более минуты (просто введите имя своей учетной записи Loggly).
Получите вдохновение: как вы могли бы извлечь выгоду из APM с управлением журналами
Новые Relic и Loggly — мощная комбинация, в которой достаточно функций и инструментов для быстрого анализа проблемы и определения ее причины. Но моя демонстрация — только один пример. Хотя это общая проблема, быстрое решение проблемы не является ракетостроением. Но обновление вашего экземпляра является краткосрочным решением, поскольку оно будет происходить, когда ваш интернет-магазин станет более популярным.
Что если вы захотите поближе взглянуть на то, почему до сих пор существуют обращения к базе данных, даже если включено кэширование? Или как насчет медленного процесса извлечения, где кэширование не поможет из-за динамического характера реального процесса?
Вывод
И New Relic, и Loggly являются эффективными инструментами, позволяющими сначала идентифицировать конкретную проблему, а затем изолировать конкретное происшествие, после чего вы можете выполнить обратную инженерию проблемы и найти решение. Все сделано в (почти) реальном времени и более подробно, чем вам, вероятно, понадобится (но это никогда не повредит иметь их).
Loggly создал отличный интерфейс для просмотра логов и поиска того, что имеет значение среди их миллионов записей. Но давайте не будем забывать: они не просто предлагают инструмент для анализа, они также хранят ваши журналы. С популярным приложением или сайтом ваш журнал быстро станет безумным, иногда превращаясь в проблему с производительностью. Loggly выполняет все операции по хранению и резервному копированию, поэтому вы не рискуете потерять ценные журналы после того, как сервер полностью сошел с ума.
У New Relic и Loggly есть бесплатные пробные версии, в течение 14 и 30 дней соответственно. Они также предлагают планы Lite с New Relic с 24-часовым хранением данных и Loggly 7 дней. Этого достаточно для мониторинга в реальном времени с возможностью последующего анализа.
Можете ли вы вспомнить некоторые умные использования New Relic и Loggly? Дайте нам знать об этом в комментариях.