Anatomía de un query NRQL en New Relic

Construir un query en NRQL deja de ser un misterio cuando entiendes su anatomía. Aquí descubres cómo estructurar consultas en New Relic usando los tipos de eventos correctos, las tablas adecuadas y los condicionantes que te ayudan a extraer información precisa de tus aplicaciones monitoreadas.

¿Qué son los event data types en New Relic?

Los event data types son las categorías que New Relic usa para organizar la información que recopila de tus aplicaciones. Piensa en ellos como el primer filtro que defines antes de consultar cualquier dato.

En la plataforma existen cinco tipos principales que vas a usar con frecuencia:

• Browser, asociado a la tabla page view.
• APM, asociado a la tabla transaction.
• Synthetics, asociado a la tabla synthetic checks.
• Infrastructure, asociado a la tabla system sample.
• Mobile, asociado a la tabla mobile request.

Cada categoría apunta a una tabla específica, y esa tabla es la que consultas directamente cuando escribes tu query. Si en una clase anterior usaste page view, estabas trabajando con el tipo browser. Si usaste transaction, estabas en territorio APM.

¿Qué es un event data type en New Relic? Es la categoría que clasifica los datos monitoreados (browser, APM, mobile, infrastructure, synthetics) y te indica a qué tabla debes apuntar tu consulta NRQL.

¿Por qué importa el agente de Infrastructure?

El tipo infrastructure merece atención aparte. Se trata de un agente de código abierto que recopila datos de la infraestructura donde corre tu aplicación, lo que te permite detectar errores probables antes de que escalen [3:00]. Cuando consultas la tabla system sample, estás leyendo justamente esa información de bajo nivel.

¿Cómo se estructura un query básico en NRQL?

La estructura mínima de una consulta NRQL se parece mucho a SQL, pero con piezas propias. Necesitas tres elementos:

1. Un SELECT seguido de una función.
2. Una función con un atributo dentro, por ejemplo count(*), donde el asterisco significa todos los registros. También puedes usar atributos específicos como id o name, según lo que contenga tu tabla.
3. Un FROM seguido del event data type, es decir, la tabla que quieres consultar.

Un ejemplo concreto en APM se vería así:

sql SELECT count(*) FROM Transaction SELECT max(duration) FROM Transaction

El primero cuenta todas las transacciones existentes. El segundo selecciona la duración máxima registrada en una transacción. Son consultas comunes, pero ya sabes cómo clasificarlas por tipo y tabla [4:20].

¿Para qué sirve count(*) en NRQL? Sirve para contar todos los registros de una tabla sin filtrar por un atributo específico. El asterisco representa la totalidad de los datos disponibles.

¿Cómo agregar condicionantes y agrupaciones a un query?

Cuando necesitas más precisión, NRQL te permite encadenar cláusulas adicionales como WHERE, FACET y rangos de tiempo. Aquí entra un ejemplo más complejo usando el tipo browser y la tabla page view:

sql SELECT * FROM PageView WHERE appName = 'Food My App' FACET countryCode, city SINCE 1 week ago

Esta consulta selecciona todos los page view donde el nombre de la aplicación es Food My App, los agrupa por código de país y ciudad, y limita el rango a la última semana [5:10]. La cláusula FACET es la que permite agrupar resultados por uno o más atributos, mientras que WHERE actúa como filtro.

¿Cuándo usar WHERE y cuándo usar FACET?

La diferencia es directa:

• Usa WHERE cuando quieras filtrar registros que cumplan una condición específica, como un nombre de aplicación o un país.
• Usa FACET cuando quieras agrupar los resultados por una o varias dimensiones, parecido a un GROUP BY en SQL.

Combinarlos te da consultas potentes: filtras primero, agrupas después y obtienes una vista segmentada de tus datos.

¿Qué tablas puedo consultar según el tipo de evento?

Para que tengas el mapa completo a la hora de escribir tus queries, esta es la relación entre tipo de evento y tabla principal:

• Browser → PageView.
• APM → Transaction.
• Synthetics → SyntheticCheck.
• Infrastructure → SystemSample.
• Mobile → MobileRequest.

Elegir la tabla correcta depende de qué quieres observar. Si te interesa el comportamiento del usuario en el navegador, vas a PageView. Si quieres medir el desempeño del backend, vas a Transaction. Si monitoreas servidores, SystemSample es tu punto de entrada.

Ahora te toca a ti: toma un query que ya hayas escrito antes e identifica en los comentarios cuál es su SELECT, su función, su atributo, su event data type y, si lo tiene, su WHERE o FACET. Así fijas la anatomía completa.