Share
Cuando te introduces en New Relic por primera vez, es fácil sentirse abrumado por todas las funciones. Pero al igual que con la mayoría de las herramientas, a medida que sube lentamente la curva de aprendizaje y se familiariza con las funciones proporcionadas fuera de la caja, comienza a preguntarse cómo se integra todo bajo el capó y si puede hacer más con lo que tiene a mano.
Hoy veré cómo New Relic realmente supervisa las transacciones y cómo puede conectarse al proceso. Echaremos un vistazo rápido al soporte proporcionado por New Relic para monitorear trabajos en segundo plano y también analizaremos las métricas personalizadas de New Relic, cómo las usaría y los beneficios que obtendrá al hacerlo. Al final, comprenderá mejor cómo funciona New Relic y podrá utilizarlo más plenamente. En otras palabras, tendremos un conocimiento más profundo de nuestras herramientas, algo que todos los desarrolladores deben esforzarse por lograr.
Comencemos por echar un vistazo rápido a cómo New Relic en realidad se conecta para rastrear el rendimiento de su aplicación.
Contenido PatrocinadoEste contenido fue encargado por New Relic y fue escrito y / o editado por el equipo de Tuts +. Nuestro objetivo con el contenido patrocinado es publicar tutoriales relevantes y objetivos, estudios de casos y entrevistas inspiradoras que ofrezcan un valor educativo genuino a nuestros lectores y nos permitan financiar la creación de contenido más útil..
Puede parecer un poco mágico, incluye una gema en su Gemfile:
gema 'newrelic_rpm'
Y de alguna manera New Relic monitorea todo tu código. Por supuesto, es solo código, así que veamos cómo New Relic realmente implementa su aplicación para que pueda comenzar a monitorearla cuando se requiere la gema del agente. Haremos esto en el contexto de una aplicación Rails 4..
El primer lugar para mirar es newrelic_rpm.rb, que tiene el siguiente código relevante en él:
… Si Rails :: VERSION :: MAJOR.to_i> = 3 módulo de la clase NewRelic Railtie < Rails::Railtie initializer "newrelic_rpm.start_plugin" do |app| NewRelic::Control.instance.init_plugin(:config => app.config) end end end else else ...
Así que un Railtie se crea cuando la versión de Rails está por encima de tres, esto obtiene un NuevoRelic :: Control instancia de singleton (cuando se inicializa) y llamadas init_plugin. Cuando el NuevoRelic :: Control se crea una instancia que determina qué marco se está ejecutando (Rails 4 en nuestro caso) y carga un código relevante; podemos ver esto en new_relic / control / class_methods # load_framework_class. los init_plugin Método que se ejecuta en vidas new_relic / control / instance_methods. El código interesante aquí es:
… Si Agent.config [: agent_enabled] &&! NewRelic :: Agent.instance.started? start_agent install_instrumentation load_samplers a menos que Agent.config [: disable_samplers] ...
los instrumentación_instalación La llamada es la importante. La implementación vive en new_relic / control / instrumentation. Al saltarse los bits de repetición, esto determina qué archivos de instrumentación necesita cargar y luego los requiere uno por uno. En nuestro caso, cargará archivos bajo new_relic / agent / instrumentation / rails4. Uno de los archivos aquí es action_controller.rb, cuando esto se requiere, finalmente se ejecuta el siguiente código a través de un poco de magia de metaprogramación:
ejecuta do class ActionController :: Base include NewRelic :: Agent :: Instrumentation :: ControllerInstrumentation include NewRelic :: Agent :: Instrumentation :: Rails4 :: ActionController end NewRelic :: Agent :: Instrumentation :: ActionControllerSubscriber \ .subscribe (/ ^ process_action .action_controller $ /) end
Y aquí llegamos al punto crucial: ActionController :: Base (de la que heredan todos sus controladores) se incluyen un par de módulos, el más importante de los cuales es NewRelic :: Agent :: Instrumentation :: ControllerInstrumentation. Este es el comienzo de cómo New Relic comienza a monitorear todas las acciones de su controlador como 'transacciones'. Por supuesto, es una vista algo simplificada y estamos pasando por alto muchos detalles, pero te da una idea de cómo New Relic supervisa tu código. La pregunta es, ¿cómo se puede utilizar esta información??
Es muy poco probable que se encuentre en una situación en la que esté utilizando un marco web para el que New Relic no tiene ya instrumentación (en el mundo de Ruby), pero digamos que sí. Sabiendo lo que sabemos ahora, podemos instrumentar manualmente las acciones del controlador de este marco personalizado. Si tenemos un controlador como este:
clase CustomController def custom_action ... end end end
Podemos instrumentarlo así:
la clase CustomController incluye NewRelic :: Agent :: Instrumentation :: ControllerInstrumentation def custom_action… end add_transaction_tracer: custom_action end
Ahora su método de controlador será rastreado como una transacción de la misma manera que las acciones de Rails son rastreadas. Por supuesto, si ha implementado su propio marco web que incluye código de manejo de base de datos, deberá realizar un trabajo adicional para instrumentar gran parte de ese código, para permitir que New Relic monitoree más que solo las acciones del controlador. Pero la idea general sigue siendo sólida..
El patrón anterior se vuelve más útil cuando desea que New Relic realice un seguimiento de los trabajos en segundo plano en su aplicación. Es mucho más probable que haya introducido algún código de manejo de trabajos en segundo plano personalizado que haber escrito su propio marco web. De hecho, hicimos esto con Tuts + inicialmente, aunque ahora estamos migrando a Sidekiq. Si está utilizando uno de los sistemas de trabajos en segundo plano conocidos como Sidekiq, Resque o Trabajo con retraso, New Relic ya tiene instrumentación incorporada, pero si hizo su propio rollo, el patrón anterior es todo lo que necesita para monitorear sus tareas..
Por ejemplo, nuestros trabajos en segundo plano personalizados de Tuts + eran clases regulares de ruby que respondían al ejecutar Método, así que todo lo que tenemos que hacer es esto:
la clase SomeBackgroundJob incluye NewRelic :: Agent :: Instrumentation :: ControllerInstrumentation def execute… end add_transaction_tracer: custom_action, category:: task end
El ultimo bit, categoría:: tarea, es para asegurarse de que New Relic no lo rastree como una transacción web, sino que lo trate como una tarea en segundo plano y lo haga aparecer en la pestaña de tareas en segundo plano en la interfaz de usuario de New Relic. Si creamos una clase base para todos nuestros trabajos, podemos poner la instrumentación allí y las clases secundarias lo heredarán, por lo que no tenemos que preocuparnos por hacer lo anterior en cada clase de trabajo..
Curiosamente, incluso las transacciones web que New Relic monitorea automáticamente no son sacrosantas. Por ejemplo, puede agregar algunos parámetros personalizados para enviarlos a New Relic para la transacción que se está ejecutando actualmente (si ha activado la captura de parámetros).
Puede hacer esto en cualquier momento durante la transacción. todo lo que tienes que hacer es llamar :: NewRelic :: Agent.add_custom_parameters (: key => 'value') en cualquier momento y los parámetros que pase se agregarán a los datos de parámetros que vea dentro de New Relic. Por ejemplo, si tuviéramos un controlador que se viera así:
clase HelloController < ApplicationController def index ::NewRelic::Agent.add_custom_parameters(:hello => 'mundo') fin fin
Las transacciones lentas nos darían lo siguiente:
Esto no es todo lo que podemos hacer. Podemos segmentar una transacción mientras se está ejecutando al cambiarle el nombre. Digamos que queremos tratar una transacción como especial cuando la realiza un usuario en particular. Puedes hacer algo como esto:
Accentsconagua
clase HelloController < ApplicationController def index new_relic_name = NewRelic::Agent.get_transaction_name if current_user.name == 'Joe Customer' NewRelic::Agent.set_transaction_name("#new_relic_name - Joe Customer") end end end Ahora esta transacción se tratará como una transacción separada en la interfaz de usuario de New Relic:
Incluso la instrumentación predeterminada de New Relic tiene algo de espacio para la personalización, pero a veces, como el Capitán Kirk, solo necesitas más poder. Aquí es donde entran las métricas personalizadas.
En el pasado, habría usado métricas personalizadas para monitorear cosas como la comunicación de servicio externo y el uso de varias herramientas comunes como Redis. En estos días, New Relic tiene mejores formas de monitorear esas cosas, ¿para qué necesitamos métricas personalizadas? He encontrado que las métricas personalizadas son útiles en cuatro situaciones:
Echemos un vistazo rápido a cada uno de ellos..
New Relic es bastante bueno para desglosar el rendimiento de sus diversos métodos de aplicación en un rastreo de transacciones, pero a veces verá algo como esto en un rastreo:
Parece que hay un código de aplicación que New Relic no pudo instrumentar por alguna razón. Lo que podemos hacer es ayudar a New Relic (ya nosotros mismos) con algunas métricas personalizadas. Necesitamos averiguar qué método New Relic tuvo problemas para monitorear y enlazar algunas métricas personalizadas para rastrear cuánto tiempo tardó en ejecutarse este método. Esto luego aparecerá en todas las trazas posteriores. Digamos que tenemos una clase con un método que queremos monitorear a través de métricas personalizadas:
clase Orden cantidad de importe ... final fin
Podemos comenzar a rastrear el cantidad método como tal:
requiere la clase 'new_relic / agent / method_tracer' Orden incluye: NewRelic :: Agent :: MethodTracer def importe ... fin add_method_tracer: cantidad, final 'Custom / amount'
El segundo parámetro para add_method_tracer es el nombre que esta métrica personalizada obtendrá en la interfaz de usuario de New Relic. Los nombres de las métricas son cadenas separadas por barras y todas las métricas personalizadas deben comenzar con 'Personalizado /'. Podría, por ejemplo, nombrar su métrica personalizada como 'Personalizada /cantidad Método en sus trazas de transacciones, en la interfaz de usuario de New Relic. Pero, ¿y si nuestro cantidad ¿El método es muy complejo y queremos monitorear las partes que sospechamos que son lentas? Mi consejo es que debes refactorizar tu método, es demasiado grande, pero si no puedes hacerlo, puedes instrumentar un código aleatorio de la siguiente manera:
clase Orden extend :: NewRelic :: Agent :: MethodTracer def monto ... self.class.trace_execution_scoped (['Custom / amount / complex_code']) do ... código complejo ... end ... end end end end
Ahora la parte instrumentada del método se informará por separado en sus trazados de transacción. Si ha instrumentado previamente el método en sí, su nueva métrica 'interna' se agrupará bajo la anterior.
Esta es, con mucho, la forma más común en que terminará utilizando métricas personalizadas en su código, pero veamos las demás de todos modos..
A menudo puede estar usando una biblioteca que, sospecha, está ralentizando su aplicación. New Relic no instrumentará ninguna gema aleatoria para ti por defecto, entonces, ¿qué puedes hacer? Puede bifurcar la gema y agregar algunos instrumentos utilizando el método que vimos anteriormente, pero existe una solución aún más simple: usar inicializadores. Digamos que estás usando el foobar biblioteca que tiene una clase Foo con un metodo bar que sospechas tiene un código lento en él. Todo lo que necesitas hacer es crear un inicializador foobar_instrumentation.rb, y poner en ella lo siguiente:
require 'new_relic / agent / method_tracer' Foo.class_eval do include :: NewRelic :: Agent :: MethodTracer add_method_tracer: final de barra
Como puede ver, el código es muy similar al que teníamos anteriormente, New Relic elaborará un nombre adecuado para su nueva métrica personalizada en función de la clase y el nombre del método, y comenzará a verlo en los trazados de sus transacciones. Use esto para averiguar si esa biblioteca sospechosa está haciendo que su código funcione mal, pero no mantenga esta instrumentación permanentemente. Envía spam a los inicializadores innecesarios en su aplicación Rails y contamina su nueva interfaz de usuario de Relic con métricas personalizadas que no necesita rastrear permanentemente.
Una parte de las aplicaciones web que a menudo se descuida son los scripts. Parafraseando una presentación que hice recientemente, todavía son códigos de producción y deben ser tratados como tales. No desea que el código de producción tenga un mal desempeño, especialmente si lo ejecuta de forma continua mediante trabajos cron (o un método similar que no es un trabajo de fondo en su sistema), por lo que podemos usar New Relic para averiguar si tus guiones son lentos.
Puede instrumentar su código de script usando métricas personalizadas como se describe anteriormente. No se mostrará en las trazas de transacciones, ya que no formará parte de una transacción. Sin embargo, lo que podrá hacer es crear un panel de control personalizado a partir de las métricas que recopile, lo que le dará una idea de si el script está funcionando mal..
La otra cosa que puede hacer es tratar su guión como un tipo de trabajo de fondo e instrumentarlo en consecuencia (incluya NewRelic :: Agent :: Instrumentation :: ControllerInstrumentation y así). Se agrupará con otros trabajos en segundo plano en la interfaz de usuario, pero no tiene que preocuparse por los paneles personalizados.
La única advertencia con los scripts es esta: New Relic solo envía datos a través del cable periódicamente. Con un script único que se ejecuta rápidamente, deberá asegurarse de que los datos recopilados se envíen, por lo que es posible que deba cerrar el agente de New Relic manualmente. Una buena regla general es iniciar manualmente el agente al comienzo de cada script y apagarlo al final:
require 'newrelic_rpm' :: NewRelic :: Agent.manual_start… codez… :: NewRelic :: Agent.shutdown
De esta manera, nunca tendrá que preguntarse por qué sus datos no aparecen en la interfaz de usuario..
Una de las cosas interesantes de New Relic es que le permite aprovechar su interfaz de usuario y sus instalaciones de agregación de datos para mediciones que no tienen nada que ver con el rendimiento (en teoría). Por ejemplo, es posible que desee tener cierta visibilidad sobre la frecuencia con la que los usuarios se registran en su aplicación, la frecuencia de las ventas o el monto total que pagan los usuarios cuando realizan compras. Estas son más métricas de negocios que de rendimiento, pero si es demasiado difícil rastrearlas por separado, puede usar New Relic para hacerlo..
New Relic te permite grabar métricas personalizadas directamente a través de dos llamadas a la API:
record_metricincrement_metricPuedes usar record_metric para rastrear cualquier métrica que tenga una cantidad y increment_metric es bastante autoexplicativo Así que, por ejemplo, podemos hacer esto:
… Def compra (cantidad)… :: NewRelic :: Agent.record_metric ('Custom / purchase_amount', cantidad) :: NewRelic :: Agent.increment_metric ('Custom / purchase_count') ... final ... La única forma de ver estas métricas en la interfaz de usuario sería crear algunos paneles personalizados. Tengo que mencionar que este sería un uso un tanto "creativo" de la API de New Relic, ya que está diseñado teniendo en cuenta los datos de rendimiento, pero sin duda es útil saber cuándo se necesita un panel rápido y no lo hacen. quiere configurar un montón de infraestructura extra.
Por supuesto, todo este poder tiene un costo. Si recopila demasiadas métricas personalizadas, puede comenzar a ralentizar su aplicación. También puede ralentizar la interfaz de usuario de New Relic y dificultar la interpretación de los datos, ya que New Relic colapsará métricas similares en una de resumen. New Relic recomienda mantener la cantidad de métricas personalizadas que recopila por debajo de 2000. Descubrí que las métricas personalizadas se utilizan mejor periódicamente. Instale el código que necesita, use la instrumentación para resolver el problema que está teniendo y luego elimine la instrumentación. De esta manera, podrá resolver sus problemas de rendimiento y es poco probable que la cantidad de métricas personalizadas que utiliza crezca demasiado.
Hemos cavado en el interior de la newrelic_rpm gema y ha aprendido a decirle a New Relic el código que considera una transacción web. Hemos examinado cómo modificar las transacciones sobre la marcha, cómo supervisar los trabajos en segundo plano y las diversas situaciones en las que tiene sentido utilizar métricas personalizadas. Hay mucho que puede hacer con New Relic más allá de la funcionalidad que proporciona de inmediato y ahora es mucho más capaz de utilizarlo en todo su potencial. Pero, siempre hay más que aprender, como cómo crear paneles personalizados a partir de las métricas que capture o cómo monitorear la infraestructura con complementos. Cubriremos esos temas y más en los artículos subsiguientes, así que asegúrate de visitarnos con frecuencia. Y como siempre, si tiene una pregunta, desea compartir su propia historia de New Relic o simplemente quiere saludar, no olvide dejar un comentario..
