Te ofrecemos esta traducción automática para facilitar la lectura.
In the event of any inconsistency between the English version and the translated version, the English versionwill take priority. Please visit this page for more information.
La plataforma New Relic se basa en los cuatro tipos telemetry data fundamentales que creemos que son necesarios para un monitoreo completo y efectivo del sistema: métrica, evento, registros y traza (a menudo denominado "MELT" en la industria de observabilidad).
En este documento, daremos una explicación bastante técnica de nuestros tipos de datos MELT principales, su estructura y cómo se utilizan en nuestra característica. Puede utilizar la mayoría de nuestras características sin necesidad de comprender la estructura de datos subyacente. Pero comprender mejor esto puede ayudarle a introducir datos en New Relic, comprender los datos que ve en nuestra UI y consultar y registrar sus datos.
Métrica
Primero, explicaremos la definición de métrica desde la perspectiva de la industria del monitoreo y luego explicaremos cómo New Relic maneja la métrica.
Métrica en la industria del monitoreo
En la industria del monitoreo de software, una métrica significa una medida numérica de una aplicación o sistema. Las métricas generalmente se informan en un cronograma regular.
Dos tipos principales de métrica son:
Datos agregados. Por ejemplo: un recuento de eventos durante un minuto o la tasa de algún evento por minuto.
Un estado numérico en un momento determinado. Por ejemplo: una lectura de temperatura de la CPU o un estado de "% de CPU usado".
Las métricas son relativamente fáciles de informar y almacenar porque un solo registro puede representar un rango de tiempo. También se pueden agregar cada vez más con el tiempo. Por ejemplo, los datos por minuto pueden "acumularse" en agregaciones por hora después de un cierto período de tiempo y, eventualmente, pueden acumularse en una agregación por día. Este enfoque es eficaz para el almacenamiento de datos a largo plazo.
Métrica es una solución sólida para almacenar datos a largo plazo y comprender las tendencias a lo largo del tiempo. Una posible desventaja es que puede resultar difícil realizar un análisis detallado de datos más antiguos que se han agregado a lo largo del tiempo; cuando se requieren muchos detalles sobre acciones importantes específicas, se pueden utilizar datos de eventos .
Métrica en New Relic
Conceptualmente, "métrica" es una categoría amplia y general. Hay varias formas en que New Relic mide e informa métricas pero, en la práctica, cuando se utiliza la UI de New Relic, normalmente no será necesario comprender cómo sucede esto exactamente. En nuestra documentación, normalmente solo nos referiremos a "métrica", independientemente de cómo se reporten esos datos, a menos que haya una razón por la que necesite saber más (como entender cómo consultar sus datos).
Estas son algunas de las formas en que se informan y almacenan las métricas en la plataforma New Relic:
En la industria del monitoreo, las métricas "dimensionales" se refieren a datos métricos que tienen una variedad de atributos (dimensiones) adjuntos, como atributos relacionados con la duración (hora de inicio, hora de finalización), ID de entidad, región, host y más. Este nivel de detalle permite realizar análisis y consultas en profundidad.
En New Relic, estos datos métricos se adjuntan a nuestro tipo de datos Metric . Este es nuestro tipo de datos de métrica principal y lo utilizan muchas de nuestras herramientas, incluidas:
Para consultar el tipo de datos Metric , podría utilizar una consulta NRQL como:
Select*from Metric
A medida que pasa el tiempo, las métricas se agregan cada vez más en períodos de tiempo más grandes. Esto se hace para optimizar su capacidad de consultar datos durante un largo período de tiempo.
El APM, browser y de New Relic informan y muestran métricas en un formato de datos simple al que nos referimos como metric timeslice data. Un intervalo de tiempo de métrica consta de tres partes: un nombre de métrica, el segmento de tiempo que representa la métrica (el "intervalo de tiempo") y un valor numérico (la medición).
Por ejemplo: un intervalo de tiempo de métrica para el tiempo dedicado a una transacción concreta se denomina WebTransaction/URI/foo y puede tener un tiempo de respuesta de 0,793 para un intervalo de tiempo de un minuto de 10:20 a. m. a 10:21 a. m. Estas métricas suelen seguir un patrón como <category>/<class>/<method>.
Nuestro agente (APM, browser y dispositivo móvil) puede recopilar miles de intervalos de tiempo métricos por minuto para una variedad de rendimiento métrico. Por ejemplo: tasa de errores, uso de ancho de banda y tiempo de recolección de basura. También tienes la posibilidad de crear métricas personalizadas.
Los datos de intervalo de tiempo de métrica son un tipo de datos livianos y carecen del detalle que tienen las métricas dimensionales .
Formas de explorar y consultar intervalo de tiempo de datos métricos:
Para APM: los datos del intervalo de tiempo de métrica se convierten a dimensional métrica y se pueden consultar vía NRQL
Si desea obtener más información sobre la estructura de los datos de intervalo de tiempo de métrica y ver algunos ejemplos, expanda el colapsador a continuación.
A continuación se muestran algunos ejemplos comunes de datos de intervalo de tiempo de métrica, centrándose en los más comunes utilizados por la aplicación Ruby.
ActiveMerchant
New Relic rastrea una variedad de métricas sobre ActiveMerchant transacciones que se pueden utilizar para análisis de negocios y monitoreo del rendimiento. Las métricas se resumen tanto por operación como por puerta de enlace.
ActiveRecord Es la API de mapeo relacional de objetos utilizada por la aplicación Ruby on Rails. Las métricas que se muestran aquí miden el rendimiento de los métodos find y save de ActiveRecord.
Apdex es una medida de satisfacción del usuario con el tiempo de carga de la página.
Controller
En la aplicación Ruby on Rails, las solicitudes HTTP son manejadas por acciones del Controlador. Una aplicación Rails tiene muchos controladores, cada uno de los cuales tiene una o más acciones. Cuando su aplicación Rails recibe una solicitud http, esa solicitud se enruta al controlador y la acción apropiados, según la URL de esa solicitud. Luego, esa acción realiza cualquier procesamiento necesario para generar una respuesta http, que suele ser una página web, pero también podría ser un fragmento de página, un documento xml o cualquier otro tipo de datos solicitados por el cliente.
Las siguientes métricas rastrean el rendimiento de las acciones del controlador, independientemente del enrutamiento y sin tener en cuenta los efectos de la red o del servidor web.
Esta métrica rastrea la cantidad de errores o excepciones generadas al procesar solicitudes.
regex (expresión regular)
métrica de muestra
nombre de la leyenda
Errors/all
Errors/all
External services
La instrumentación de servicios externos captura llamadas a servicios fuera de proceso, como servicios web, recursos en la nube y cualquier otra llamada de red. No incluye otros componentes backend de primera clase como MemCache y la base de datos.
En la aplicación Ruby instrumentamos la biblioteca Net::Http para capturar todos los servicios HTTP.
regex (expresión regular)
métrica de muestra
nombre de la leyenda
External/[^/]+/all$
External/service.example.com/all
Todas las llamadas de service.example.com
External/
External/host.aws.com/Net::Http::POST
Net::Http::POST[host.aws.com]
External/all$
External/all
Servicios externos
External/[^/]+/(?!all)/
External/service.example.com/all
Todas las llamadas de service.example.com
HTTP dispatcher
Esta métrica representa un resumen del rendimiento y el tiempo de respuesta de todas las solicitudes web.
regex (expresión regular)
métrica de muestra
nombre de la leyenda
^HttpDispatcher$
HttpDispatcher
HttpDispatcher
MemCache
MemCache es una tecnología popular que permite que la aplicación acceda a la memoria compartida proporcionada por cualquier número de máquinas físicas como caché global. Las aplicaciones que utilizan mucho la base de datos suelen utilizar MemCache para obtener beneficios de rendimiento y escalabilidad.
Estas métricas miden la frecuencia y el tiempo de respuesta de las llamadas a MemCache para leer y escribir datos del caché. El tiempo de respuesta debe ser bajo (menos de 5 ms) para que MemCache funcione correctamente.
regex (expresión regular)
métrica de muestra
nombre de la leyenda
MemCache/.*
MemCache/read
Operaciones de lectura de MemCache
MemCache/read
MemCache/read
Operaciones de lectura de MemCache
MemCache/write
MemCache/write
Operaciones de escritura de MemCache
Mongrel
Esta métrica mide la longitud de la cola mestiza, que contiene solicitudes http pendientes para ser procesadas por mestiza. El gráfico de actividad HTTP superpone la longitud máxima de la cola para un período determinado. El valor es cero si mongrel está procesando una solicitud pero no tiene otras solicitudes esperando en su cola.
Al observar este valor en un grupo agregado de mestizos, las longitudes de las colas de todos los mestizos se suman, mostrando la suma de todas las longitudes de las colas.
La longitud de una cola mestiza debe ser igual o cercana a cero; si está constantemente en un nivel más alto, entonces indica que su aplicación de rieles tiene problemas para cumplir con sus requisitos de carga.
regex (expresión regular)
métrica de muestra
nombre de la leyenda
Mongrel/Queue Length
Mongrel/Queue Length
Longitud de la cola
View
ActionView es un paquete en Rails que se utiliza para representar la salida que es la respuesta a una solicitud http, como una página html o un documento xml. El View lo representa el controlador que maneja la solicitud.
Si View métrica representa una gran parte del tiempo de respuesta de su controlador, podría significar que está realizando muchas operaciones de base de datos dentro de la plantilla de vista.
Debido a que los datos de tipo evento pueden tener cualquier tipo de datos de par principal de valor adjuntos, una forma en que se puede informar la métrica es como atributo adjunto a un evento.
Un par de ejemplos de esto en New Relic:
Nuestro monitoreo de infraestructura reporta muchas métricas que están adjuntas al evento. Por ejemplo, informamos un evento ProcessSample , que tiene varias métricas basadas en muestras adjuntas, como el porcentaje de CPU. Para obtener más información sobre los datos de monitoreo de infraestructura, consulte Datos de infraestructura.
En APM, el evento Transaction tiene varias métricas adjuntas, incluida databaseDuration.
Para conocer más sobre estos datos y cómo consultarlos, ver evento.
La métrica se puede formar contando eventos New Relic, o haciendo algún otro cálculo matemático sobre esos eventos. Por ejemplo, si desea medir el número total de Transaction evento durante la última media hora, puede ejecutar esta consulta NRQL:
Selectcount(*)fromTransaction since 30 minutes ago
Otro ejemplo: si desea calcular el tiempo de respuesta promedio de su servicio, puede ejecutar una consulta como:
FROMTransactionSELECT average(duration) SINCE 30 minutes ago
Algunos gráficos de New Relic se generan con este tipo de consulta. La desventaja de este enfoque es que existen límites sobre cuántos eventos puede informar un sistema de monitoreo (incluido el nuestro). Esto significa que a veces, para sistemas de alto rendimiento, es posible que el recuento no represente con precisión la actividad total en ese sistema. Para obtener más información sobre cómo se puede abordar esto, consulte límites de eventos y muestreo.
Primero, explicaremos la definición de events desde la perspectiva de la industria de monitoreo y luego explicaremos algunos detalles sobre cómo New Relic maneja los datos de eventos.
Evento en la industria del monitoreo
En la industria del software, los eventos pueden considerarse simplemente “cosas que ocurren en un sistema”. Por ejemplo, el cambio de la configuración del servidor sería un evento. Otro ejemplo: un usuario de un sitio web que hace clic con el mouse.
Algún evento generará un registro almacenado, y ese registro normalmente también se denomina event.
Los datos de eventos representan ocurrencias discretas y normalmente tendrán un alto nivel de detalle, por lo que los datos de eventos son adecuados para consultas y análisis detallados. La desventaja del uso de datos de eventos es que normalmente se informan tantos eventos que puede resultar difícil consultar ese gran conjunto de datos durante períodos de tiempo más largos.
Evento en New Relic
En New Relic, informamos eventos a objetos de datos también llamados events. Estos eventos tienen múltiples atributos (pares de valores principales) adjuntos. Los datos del evento se utilizan en algunos gráficos y tablas UI , y también puedes consultarlos. El tiempo que los datos del evento permanecen disponibles está determinado por las reglas de retención de datos.
Un ejemplo de evento: APM informa un tipo de evento llamado Transaction, que representa una unidad de trabajo lógica en una aplicación. Para ver el atributo adjunto a este evento, puede utilizar una consulta NRQL como:
Select*fromTransaction
Para ver ejemplos de consulta de datos de eventos, consulte Introducción a NRQL.
Otros detalles sobre los datos del evento New Relic:
Algunos sistemas generan una gran cantidad de eventos que exceden los límites de recopilación y generan resultados de consulta incompletos. Para obtener más información sobre esto, consulte muestreo de eventos.
Primero, explicaremos la definición de logs desde la perspectiva de la industria de monitoreo y luego explicaremos algunos detalles sobre cómo New Relic maneja los informes log .
Iniciar sesión en la industria de monitoreo
Un log es un mensaje sobre un sistema que se utiliza para comprender la actividad del sistema y diagnosticar problemas.
Logs at New Relic
Nuestras capacidades le brindan una plataforma centralizada que conecta sus datos de registro con otros datos del monitor New Relic. Por ejemplo, puede ver el registro junto con sus datos de APM.
En New Relic Logs, los datos se informan con múltiples atributos (datos de valor principal) adjuntos. Para consultar sus datos log , puede utilizar una consulta NRQL como:
Select*from Log
Para informar datos log personalizados, consulte la APIlog .
Datos de trazas
Primero, explicaremos la definición de traza desde la perspectiva de la industria del monitoreo y luego explicaremos algunos detalles sobre cómo New Relic maneja el rastreo.
Seguimiento en la industria del monitoreo
En el mundo de las aplicaciones/monitoreo de infraestructura, tracing es un término general utilizado para referirse a varias formas de reportar información sobre cómo está operando un programa o sistema. Por ejemplo, un stack trace proporciona información detallada sobre las subrutinas de un programa.
Para los grandes sistemas modernos, que a menudo se distribuyen en muchos servicios y microservicios, "rastreo" a menudo se refiere a distributed tracing, que es una forma de monitor las solicitudes a medida que se propagan a través de un entorno distribuido complejo.
Rastreo en New Relic
New Relic ofrece una característica de rastreo distribuido que rastrea las solicitudes en todos los sistemas distribuidos y proporciona una UI dedicada para comprender y analizar su traza. En New Relic, los datos de la traza se informan como Span objetos, con múltiples atributos (pares de valores principales) adjuntos.
Para consultar sus datos de seguimiento, puede utilizar una consulta NRQL como: