Статьи

New Relic: мониторинг Ruby в реальном времени

Эта статья была спонсирована New Relic . Спасибо за поддержку компаний, которые делают SitePoint возможным!

Анализ производительности вашего веб-приложения очень важен. Могут быть узкие места, которые затрагивают определенную группу пользователей, или могут быть ошибки, которые не были выявлены в ходе тестирования. Зачастую приложение не реагирует одинаково в процессе разработки или подготовки по сравнению с производственной средой, где тысячи (или более) пользователей одновременно сталкиваются с ним. Когда появятся нюансы вашей производственной среды, вы захотите измерить, что происходит. Какие запросы медленные или падают? Есть ли внешняя система, которую вы используете, которая забивает трубы? Ваши пользователи счастливы или разочарованы? Мониторинг производительности в режиме реального времени — единственный способ найти ответы на подобные вопросы.

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

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

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

Служба поддержки

New Relic начал свою жизнь как приложение на Ruby, поэтому у него очень хорошая поддержка различных версий Ruby. Он поддерживает все версии MRI от 1.87 и выше, JRuby от 1.6.0 и выше, а Rubinius от 2.2.1 и выше. Существует также хорошая поддержка для большинства веб-серверов Ruby, включая Passenger, Thin, Puma, Unicorn, Rainbows !, и Webrick. Вы можете использовать Rails, Sinatra, Padrino или просто простое приложение Rack. Поддержка баз данных также превосходна, с поддержкой Active Record, DataMapper, Sequel и MongoDB.

Что мы будем покрывать

В этой статье я собираюсь объяснить, как создать базовое приложение Sinatra с нуля, развернуть его в Heroku и использовать клиент New Relic для анализа его производительности. Мы рассмотрим следующее:

  • Создайте базовое приложение Sinatra
  • Развернуть к героку
  • Настройте новую реликвию
  • Контролировать приложение в режиме реального времени

Если вы не хотите развертывать свое приложение с помощью Heroku, вы можете просто зайти на https://newrelic.com/#signup и зарегистрировать бесплатную учетную запись. После регистрации вы попадете на стартовую страницу, где вы начнете следовать инструкциям. Вы также можете легко использовать Rails-приложение или любой другой каркас на основе Rack вместо Sinatra.

Создание тестовой заявки

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

source 'https://rubygems.org'
ruby '2.1.0'
gem "sinatra"
gem "newrelic_rpm"

group :test do
  gem "rack-test"
  gem "rake"
end

Установите драгоценные камни, введя следующее в терминале:

 $ bundle install

Теперь создайте файл с именем test.rb в том же каталоге и добавьте следующий код:

 ENV['RACK_ENV'] = 'test'
require 'minitest/autorun'
require 'rack/test'
require_relative 'main.rb'

include Rack::Test::Methods

def app
  Sinatra::Application
end

describe "Application" do

  it "should say hello" do
    get '/'
    last_response.must_be :ok?
    last_response.body.must_equal "Hello New Relic!"
  end

end

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

Создайте файл с именем main.rb и сохраните его в том же каталоге со следующим кодом:

 require 'sinatra'
require 'newrelic_rpm'

get '/' do
  "Hello New Relic!"
end

Давайте проверим, что это работает:

 $ ruby test.rb
Run options: --seed 5936

# Running:

.

Finished in 0.086612s, 11.5457 runs/s, 23.0914 assertions/s.

1 runs, 2 assertions, 0 failures, 0 errors, 0 skips

Кажется, все в порядке, поэтому давайте развернем его с помощью Heroku. Прежде всего нам нужно создать файл config.ru , сохраненный в том же каталоге, со следующим содержимым:

 require './main'
run Sinatra::Application

Теперь нам нужно использовать Git для контроля версий:

 $ git init
$ git add .
$ git commit -m 'initial commit'

Создайте приложение с помощью Heroku:

 $ heroku create

Развертывание:

 $ git push heroku master

Это позволит успешно развернуть наше приложение в Heroku, и теперь мы готовы начать использовать New Relic. Мы сделаем это с помощью клиента Heroku в терминале:

 $ heroku addons:add newrelic:stark

Это установит план Stark, который включает в себя все функции, но ограничен в среднем 1,5 дина в месяц (вы можете перейти на платный план в любое время).

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

 $ heroku config:set NEW_RELIC_APP_NAME="Test Sinatra App"

Чтобы просмотреть интерфейс New Relic, вам нужно пройти через веб-сайт Heroku: выберите приложение, в которое вы установили аддон New Relic, затем нажмите New Relic в списке дополнений.

Интерфейс New Relic начнет загружаться.

Screenshot1

Через несколько секунд вы должны увидеть такой экран:

screenshot2

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

screenshot3

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

Чтобы начать видеть некоторые данные, нашему приложению нужно несколько запросов. Поскольку мы только запустили его, вряд ли у него будет много посетителей. К счастью, мы можем использовать инструмент Apache Benchmarking для генерации большого количества запросов. Чтобы установить этот инструмент в операционной системе на основе Debian, вы можете использовать следующую команду:

 $ sudo apt-get update
$ sudo apt-get install apache2-utils

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

 $ ab -n 2000 -c 10 http://hidden-coast-2573.herokuapp.com/

Очевидно, вы должны заменить URL своего собственного приложения здесь!

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

screenshot4

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

Время отклика, пропускная способность и оценка Apdex

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

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

В верхнем правом углу приборной панели находится метрика, называемая счетом Apdex. Это стандартная мера удовлетворенности пользователей, основанная на времени загрузки страницы. Он работает, устанавливая T-значение, которое является пороговым временем, за которое следует ожидать загрузки страницы. Новый Relic по умолчанию имеет значение 0,5 секунды. Затем Apdex отслеживает, сколько времени занимает загрузка каждой страницы, и классифицирует их следующим образом:

  • Удовлетворено: время отклика меньше или равно T (0,5 секунды или меньше)
  • Допуск: время отклика больше T и меньше или равно 4T (от 0,5 до 2 секунд)
  • Разочарование: время отклика превышает 4T (2 секунды или более)

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

Уровень ошибок показан в середине нижней части панели инструментов, и в настоящее время мы преуспеваем, так как он составляет 0% — ошибок нет вообще!

Замедление

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

Прежде всего, давайте добавим дополнительную спецификацию в блок описания в файле test.rb :

 it "should get there in the end" do
  get '/delay'
  last_response.must_be :ok?
  last_response.body.must_equal "Sorry for keeping you waiting"
end

Добавьте соответствующий обработчик маршрута в конец main.rb :

 get '/delay' do
  sleep rand(3)
  "Sorry for keeping you waiting"
end

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

Давайте проверим, работает ли код:

 $ ruby test.rb

Run options: --seed 44113

# Running:

..

Finished in 1.140616s, 1.7534 runs/s, 3.5069 assertions/s.

2 runs, 4 assertions, 0 failures, 0 errors, 0 skips

Все работает нормально, поэтому давайте развернем на Heroku:

 $ git commit -a -m 'Added a delay'
$ git push heroku master

Теперь нам нужно сгенерировать несколько запросов для этого URL:

 $ ab -n 2000 -c 10 http://hidden-coast-2573.herokuapp.com/delay

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

Теперь мы можем еще раз взглянуть на результаты в New Relic:

screenshot5

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

Теперь мы видим, что время запроса намного больше, чем раньше. График разбит на две части — зеленую для времени запроса и синюю для времени обработки Ruby. Большой синий блок говорит нам, что задержка вызвана не сервером, а рубином. Пропускная способность теперь снижается до 200-500 запросов в минуту, и это привело к тому, что наша оценка Apdex оказалась на высоте, а некоторые запросы были классифицированы как «Разочарованные». В столбце «Недавние события» также появится предупреждение о том, что показатель Apdex падает ниже 0,85.

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

У нас все еще есть ноль ошибок, что мы рассмотрим в следующем разделе.

Отчет об ошибках

Чтобы увидеть, как New Relic сообщает об ошибках, добавьте еще один обработчик маршрута, который генерирует случайную ошибку в 10% случаев. Для начала давайте добавим спецификацию в блок описания в test.rb :

 it "should be fine" do
  get '/error'
  last_response.must_be :ok?
  last_response.body.must_equal "Everything is fine"
end

Затем добавьте обработчик маршрута в конец main.rb

 get '/error' do
  if rand(10) == 0
    raise "A Gremlin has got into the system!"
  else
    "Everything is fine"
  end
end

Это вызовет случайную ошибку 1 в 10 раз.

Давайте проверим код:

 $ ruby test.rb
Run options: --seed 36091

# Running:

...

Finished in 0.105132s, 28.5355 runs/s, 57.0709 assertions/s.

3 runs, 6 assertions, 0 failures, 0 errors, 0 skips

Кажется, все в порядке, поэтому давайте развернем код:

 $ git commit -a -m 'Added an error'
$ git push heroku master

Создайте несколько запросов для этого URL:

 $ ab -n 2000 -c 10 http://hidden-coast-2573.herokuapp.com/error

Давайте еще раз посмотрим на New Relic:

screenshot6

Мы видим, что уровень ошибок вырос до 9,71%, что мы и ожидали. Кроме того, запись в столбце «Недавние события» говорит о том, что уровень ошибок превысил 5%.

Если вы нажмете на вкладку «События» вверху и выберите «Ошибки», вы увидите разбивку всех произошедших ошибок. Как вы можете видеть на скриншоте ниже, ошибки называются, поэтому мы видим, что ошибка в нашем приложении — «Гремлин попал в систему!»

screenshot7

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

Отчеты

New Relic может генерировать несколько отчетов для обобщения метрик приложения. Если вы нажмете на вкладку «Отчеты» вверху, а затем выберите «SLA», вы увидите отчет «Соглашение об уровне обслуживания», в котором будет указано, сколько запросов было сделано за день, каков был показатель Apdex, частота ошибок и сколько пользователей были довольны, терпимы или разочарованы.

Резюме

На этом завершается данное руководство по развертыванию базового приложения Ruby в Heroku и использованию New Relic для мониторинга его производительности. Мы рассмотрели, как измерить время отклика, пропускную способность и оценку Apdex, а также как увидеть изменения в этих показателях в режиме реального времени после развертывания обновления кода.

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

Вещи дальше

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

  • Вы можете установить оповещения для определенных событий, например, когда происходит определенная частота ошибок или если показатель Apdex падает ниже определенного уровня
  • Вы можете использовать вкладку браузера для мониторинга информации о конечном пользователе, такой как браузер, операционная система и географический регион. Это работает аналогично Google Analytics
  • Вы можете контролировать производительность взаимодействия с базой данных
  • Вы можете контролировать производительность внешних сервисов
  • Вы можете контролировать производительность фоновых процессов
  • Настраиваемые информационные панели — это мощная функция, позволяющая создавать собственные информационные панели, содержащие настраиваемые диаграммы и таблицы для любых конкретных показателей.

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

Выводы

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

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