Примечание редактора. Этот пост изначально появился в блоге Railsware и был переиздан с их разрешения. Railsware является партнером New Relic и компанией по разработке программного обеспечения премиум-класса, ориентированной на поставку отличных веб-приложений и мобильных приложений. Для получения дополнительной информации посетите Railsware.com .
Введение
Новая Relic стала отраслевым стандартом для измерения производительности веб-приложений в сообществе Rails. Простое добавление и настройка newrelic_rpm gem для вашего Rails-приложения дает вам отличный обзор его производительности с адекватным уровнем детализации.
Есть еще несколько улучшений, которые вы можете сделать, чтобы использовать некоторые интересные и чрезвычайно полезные функции мониторинга New Relic. Они помогут вам сэкономить время и усилия при устранении проблем с производительностью, масштабировании приложения, рефакторинге и т. Д.
Итак, что вы должны сделать, чтобы быстро и эффективно использовать New Relic?
Записывайте ваши развертывания
Всегда записывайте развертывания с помощью сценариев Capistrano или Chief. Это сэкономит ваше время при поиске причин для повышения производительности или недостатков.
Подробную информацию о записи развертываний с использованием Capistrano можно найти в официальной документации . Вы также можете использовать простое уведомление о развертывании API, как описано здесь .
В любом случае важно добавить четкое описание развертывания вместе с тегом или именем ветви.
Примечание. Профессиональные пользователи также могут видеть «Отчет об изменениях» для каждого развертывания с подробным обзором изменений метрик производительности (время отклика, пропускная способность, Apdex и т. Д.).
Настройка дополнительных метрик перед началом работы
Важно настроить некоторые дополнительные пользовательские метрики сразу после настройки и включения New Relic, а также до того, как возникнут проблемы с производительностью. Вы можете прочитать больше о коллекции пользовательских метрик здесь .
While you can add traces to almost any method in your code, they are commonly used for tracking important / critical parts of your code. We strongly recommend you to add traces for:
* Application critical parts of code
* External services communication (Redis, RPCs, external APIs, DNS resolve, etc.)
* Encoding / decoding methods (some JSON encode methods implementations can be slow for large objects)
These traces are useful even within internal network. Drawbacks may be caused by network lags or hosting provider problems.
Here are some useful examples of custom traces that you can easily add to your initialization pipeline (e.g. application.rb).
Resque
Resque.add_method_tracer :enqueue
Resolv::DNS
Resolv::DNS.add_method_tracer pen
Resolv::DNS.class_eval {add_method_tracer :getresources}
Redis
Redis.class_eval {add_method_tracer :set}
Redis.class_eval {add_method_tracer :get}
Redis.class_eval {add_method_tracer :sadd}
Redis.class_eval {add_method_tracer :lpop}
Redis.class_eval {add_method_tracer :rpush}
Redis::Connection.class_eval {add_method_tracer :read}
Redis::Connection.class_eval {add_method_tracer :write}
Redis::Connection.class_eval {add_method_tracer :connect}
Setting up additional metrics have two main goals:
* Measuring performance of specific parts of code
* When investigating slow requests with a lot of ‘Application code’ segments, these additional traces can be used as benchmarks
Additional metrics will give you more detailed view of what is going on and when in your application.
Note: New Relic gem implementation already has traces for Net::HTTP methods.
Caution: Don’t be zealous on adding custom metrics, clean obsolete ones. Collecting too many metrics can impact the performance of your application. It is strongly recommended to keep the total number of custom metrics under 2,000.
Setup Server Monitoring
To look beyond the application itself, New Relic has introduced Server Monitoring. It is critically important to setup Server Monitoring for all servers in production and even in staging. It will help you to measure your environment performance and state.
Note: New Relic includes Server Monitoring for free in every subscription level.
You can find information about installation and configuration of Server Monitoring here.
Setup Custom Views & Dashboards
In most cases, application performance strongly depends on application state and user activity. It is also helpful to see how your application performance correlates with business metrics, database activity, internal services state, etc. New Relic gives you an opportunity to setup custom metrics, group and organize them with views and dashboards.
Common useful custom metrics you should define for your applications are:
* Number of active users
* User activity metrics
* Number of active application core entities (e.g. active tables for poker application)
* Number of connections / calls for internal / external services (some have specific thresholds)
* Additional database metrics
The official documentation will help you find out more about creating and managing custom views and custom dashboards.
You can collect any custom metric and setup a specific custom view / dashboard in order to have general view on how they correlate. Along with monitoring, custom dashboards and views also:
* Help you understand the reason of performance changes
* Give you a vision of future load changes depending on custom metrics
* Provide an ability to predict critical thresholds for load values (e.g. active users)
* Help you to improve application architecture by showing bottlenecks of internal infrastructure.
Note: The Custom Dashboards feature is available with New Relic Pro and higher. It is useful to track only those custom metrics that have impact on overall application performance.
Setup Background Jobs / Task Monitoring
Always trace your background jobs performance. While in most cases they don’t directly impact server response time, they still can impact user feedback and overall application performance.
Currently the Ruby agent supports only Delayed::Job and Resque.
Read more about monitoring Ruby background processes and daemons here. Make sure you have enabled and configured everything correctly.
Within one of our products we have employed an actor based architecture where actual action is executing asynchronously in a separate thread (we use JRuby). In such complex cases, it is useful to add traces for these actions and mark them as real web transactions (controller actions).
To complete such tasks or customise your add_method_tracer options please check API documentation.
For more detailed information about available options please read perform_action_with_newrelic_trace API documentation here. The most important options of tracer methods are:
* :category — Defines action type (available options: [:controller, :task, :rack, :uri])
* :name — Action name (will be used as last part of metric name)
* :params — Call context parameters
* :class_name — First part of metric name. Default is a current class
Here is a small example of custom background task implementation using JRuby thread actors.
ApplicationController:
def enqueue_task(opts={})
job_params = {
class_name: "Scheduler::#{self.class.name}",
name: params[:action],
params: params
}
Scheduler.enqueue(job_params) {yield}
end
Scheduler::WorkerActor:
//job_params are stored in job.params after enqueue
def process_job(job)
perform_action_with_newrelic_trace(job.params) do
run_job(job)
end
end
So in this case all enqueued tasks and controller actions appear in ‘Web transactions’ together.
Summary
New Relic is a solid monitoring solution, especially for Rails developers. Make sure you have enabled and configured all basic features described in this article. And moreover – always learn your tools.