Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Ruby
Code

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

by
Length:LongLanguages:
This post is part of a series called Performance Monitoring With New Relic.
Getting Started With New Relic in 30 Minutes
3 New Relic Power Features You Should Be Using Today
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)

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

Когда мы в последний раз покидали вас, у нас было базовое Rails приложение «Hello World» (называемое New Relic_rails1, расположенное в ~/project/tmp/New Relic). Мы продолжим использовать это приложение, расширим его и посмотрим, можем ли мы его использовать, чтобы продемонстрировать возможности New Relic, на которые мы будем обращать свое внимание.

Спонсируемый контент

Это содержимое было заказано New Relic и было написано и/или отредактировано командой Tuts +. Наша цель со спонсируемым контентом - публиковать актуальные и объективные обучающие материалы, тематические исследования и вдохновляющие интервью, которые предлагают истинную образовательную ценность для наших читателей и позволяют нам финансировать создание более полезного контента.


Мониторинг доступности

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

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

newrelic_availability_asterisk

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

Давайте посмотрим, как мы можем настроить мониторинг доступности и что мы можем получить от него. Во-первых, вам нужно перейти в ваше приложение, а затем перейти в Настройки-> Мониторинг доступности. Вы увидите что-то вроде этого:

newrelic_availability_monitoring

Вам нужно указать URL-адрес, который вы хотите чтобы New Relic пинговал, установить флажок, сохранить изменения, и готово. New Relic начнет вызывать ваш URL каждые 30 секунд. Но все веселье здесь не прекращается. New Relic будет проверять ваш URL-адрес через HTTP-запрос HEAD (и считать все ОК, если он получает код ответа 200), но вы можете указать строку ответа, которую вы хотите найти в New Relic, и в этом случае он будет выполнять запрос GET и рассмотрит ответ на предмет строки, которую вы предоставили. Это может быть очень удобно, если у вас есть пользовательская страница «Проверка работоспособности», которую вы хотите использовать.

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

newrelic_availability_notifications

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

newrelic_availability_report

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

newrelic_availability_overview

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

Разумеется, вы можете отключить и повторно активировать мониторинг (через New Relic REST API) при выполнении развертываний, чтобы убедиться, что вы не получаете ложных событий о простое.

Другим интересным побочным эффектом является то, что если вы развертываете свой проект в Heroku на single dyno,  вы можете использовать эту функцию ping, чтобы ваш дино не спал, что может сделать ваш сайт раздражающе медленным, если у вас нет большого объема траффика.


Собственный лог ошибок

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

Давайте модифицируем наш HelloController, чтобы вызвать ошибку примерно в 50% случаев:

Теперь мы сделаем несколько сотен вызовов в нашем приложении и посмотрим, что произойдет:

Наш график ошибок New Relic выглядит гораздо интереснее:

newrelic_error_overview

И мы можем разобраться в деталях:

newrelic_error_detailed

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

newrelic_error_trace

Существуют службы, специально предназначенные для захвата ошибок из вашего приложения, некоторые из наиболее известных из них - Airbrake и Bugsnag. Это платные сервисы, используемые многими приложениями, но функциональность, предоставляемая New Relic, делает эти службы избыточными. Фактически, если бы мы могли отправлять пользовательские ошибки в New Relic (вместо того, чтобы позволять ей фиксировать ошибки, которые мы не спасли), мы могли бы сделать убедительный аргумент в пользу того, чтобы не использовать отдельную службу сбора ошибок (и сэкономить деньги и избавиться от дополнительного gem'а).

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

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

newrelic_error_custom

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

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


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

New Relic, как правило, отслеживает ваши транзакции для вас:

newrelic_transaction_tracking

Вы сможете увидеть, где ваше приложение тратит большую часть своего времени (например, в контроллере, модели, базе данных и т.д.). Однако New Relic не будет захватывать подробную трассировку, если транзакция не займет больше времени, чем Appdex * 4 секунды. Обычно это нормально, но иногда у вас есть транзакции, которые гораздо важнее для вашего приложения или для вашего бизнеса. Возможно, эти транзакции чрезвычайно велики или связаны с важными событиями, такими как платежи. Достаточно сказать, что вам нужно убедиться, что этот тип транзакций всегда работает очень хорошо.

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

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

Это именно то, что вам дают ключ Ключевые Транзакции!

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

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

Мы получаем случайную машину из базы данных, и если автомобиль будет «Фордом», у нас будет медленная транзакция. Конечно же, нам понадобится модель Car:

Нам нужно настроить базу данных на использование MySql в разработке (я сделал это, но вы можете использовать sqlite):

Нам нужна миграция для создания таблицы car:

И нам нужны некоторые данные для сидов, которые мы добавим в наш файл db/seeds.rb:

Наконец, мы, вероятно, должны иметь отображение cars/show_random.html.erb:

Вам также нужно будет добавить gem mysql2 в Gemfile, если вы остановили свой выбор на MySql. После этого нам просто нужно создать и заполнить базу данных, перезагрузить наш сервер, и мы будем готовы:

Вам нужно вызвать URL-адрес, чтобы убедиться, что New Relic распознает, что эта транзакция существует:

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

newrelic_transaction_tab

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

newrelic_transaction_create

Мы можем дать нашей новой ключевой транзакции имя, выбрать Apdex T, которым мы довольны, а также настроить некоторые предупреждения. Когда наша транзакция занимает больше времени, чем выбранный нами Apdex, New Relic будет отображать подробную трассировку, которую мы сможем использовать, чтобы выяснить, откуда исходит проблема с производительностью. Давайте сделаем несколько вызовов нашего нового URL-адреса и посмотрим, какие данные мы получим:

Хм, похоже, некоторые из наших транзакций расстраивают наших пользователей:

newrelic_transaction_frustrating

Давайте посмотрим, захватил ли для нас New Relic некоторые трассировки транзакций:

newrelic_transaction_slow_traces

Давайте посмотрим на одну из них. Для ответа потребовалось около 2 секунд, но только процессор использовал всего 10 миллисекунд:

newrelic_transaction_cpu_burn

Все наши SQL-запросы были быстрыми, поэтому база данных не является проблемой:

newrelic_transaction_sql_trace

Похоже, что большую часть времени тратится на действие контроллера:

newrelic_transaction_controller_action

Давайте немного поглядим в трассировку. Похоже, что SQL SELECT был быстрым, вызов Car.find также был быстрым. Затем мы теряем около 2 секунд, за которыми следует очень быстрый рендеринг шаблона:

newrelic_transaction_trace_detail

New Relic любезно выделила для нас, где мы потеряли эти две секунды. Нам нужно посмотреть наш код контроллера после вызова Car.find:

Хм, первоначальный SELECT должен быть вызовом Car.count, а Car.find должен быть вызван вызовом Car.offset. Наша большая задержка идет сразу после этого. Ааа посмотрим на это, какой-то глупый человек поставил 2-секундную задержку в нашем коде, когда маркой автомобиля является «Форд». Это объясняет, почему наша 2-секундная задержка происходит только иногда. Мне лучше сделать git blame в нашем репозитории, чтобы узнать, кто там поставил этот ужасный код! Поразмыслив, мне лучше не стоит так делать, потому что это сделал я.


Запись вызова внешней службы

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

Мы создадим внешний сервис из наших собственных, создав небольшое приложение Sinatra. Сначала мы устанавливаем gem:

Создайте новый файл для нашего сервиса:

И поставьте здесь следующий код:

Эта служба будет спать в течение произвольного времени (от 0 до 2000 миллисекунд), а затем возвращает ответ «Hello» со временем, сколько она спала. Теперь все, что нам нужно сделать, это запустить ее:

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

Наш контроллер вызовет наш сервис Sinatra через HTTP:

И нам нужно представление для отображения результатов:

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

Давайте посмотрим, что для нас создал New Relic.

newrelic_transaction_external_service

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

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

newrelic_transaction_external_call

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

Масштабируемость и анализ мощностей

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

Во-первых, давайте рассмотрим отчеты о производительности:

newrelic_capacity_instance_busy

Хм, этот показывает большой всплеск, но в остальном ничего. Ну, мы работаем в режиме разработки, так что это понятно. Этот всплеск заключается в том, что мы сделали несколько запросов одновременно всего лишь недавно. Как вы можете видеть, когда мы выполняли эти параллельные запросы, мы максимизировали наш бедный одинокий экземпляр Webrick. Если это был боевой сервер и загрузка была постоянной, наш экземпляр всегда был бы на 100% занят, что, вероятно, указывало бы, что нам нужен другой экземпляр.

Отчет анализа сервера несколько отличается:

newrelic_capacity_instance_analysis

В нашем случае мы не получаем многого из этого, но обычно это показывает количество запущенных экземпляров и количество экземпляров, которые нам действительно нужны для обработки нагрузки, если все экземпляры были на 100% заняты. Поэтому, если мы запускали 10 экземпляров, а одновременная загрузка экземпляра составляла 2, мы могли бы сократить вдвое (или даже больше) количество исполняемых экземпляров и вообще не ухудшить производительность. Для небольшого приложения, которое работает только в нескольких экземплярах, это не имеет большого значения, но для большого приложения с десятками и сотнями экземпляров это может привести к значительной экономии затрат.

А затем есть отчеты по масштабируемости. Отчет о времени ответа, вероятно, самый интересный и важный:

newrelic_scalability_response

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

newrelic_scalability_database

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

newrelic_scalability_cpu

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


Вывод

Если одна или все из этих функций смогли у вас подняли бровь (или две), то хорошей новостью является то, что мы только затронули лишь самую малость. Каждая из этих функций более чем заслуживает более подробной статьи. Но у New Relic также есть ряд других возможностей, которые потенциально еще более мощные, включая Real User Monitoring, New Relic Platform, Thread Profiler, Threshold Thresholds and Notification и многие другие. Мы попытаемся охватить некоторые или, возможно, даже все из них в последующих учебниках.

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

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.