Utilice combinaciones de subconsultas para combinar consultas

Gran parte de los datos almacenados en New Relic se relacionan con otros datos: Transaction y TransactionError, PageView y PageAction, Log y eventos de infraestructura, y más. Puede realizar análisis y calcular correlaciones entre estos eventos utilizando combinaciones de subconsultas.

Cómo escribir una unión de subconsulta

Una subconsulta es una consulta anidada dentro de otra consulta. Con las uniones de subconsultas, puede combinar el resultado de una subconsulta con el resultado de su consulta externa basada en una clave, lo que permite el análisis y el enriquecimiento de todos los conjuntos de datos.

Una unión de subconsulta requiere tres componentes: dos conjuntos de datos y una clave principal para vincularlos.

FROM Event [INNER|LEFT] JOIN (subquery) ON [key =] key SELECT ...

Las uniones de subconsultas contienen reglas simples de sintaxis:

• La cláusula JOIN siempre debe seguir inmediatamente a la cláusula FROM .
• Puede anteponer el JOIN con el tipo de unión. INNER o LEFT es opcional y el valor predeterminado es INNER cuando se omite.
• Los paréntesis que contengan una subconsulta deben seguir inmediatamente a la cláusula JOIN .
• La cláusula ON debe seguir inmediatamente a la subconsulta y tiene dos formatos (más detalles a continuación).

También puede tener varias cláusulas JOIN en una consulta. Por ejemplo, esta consulta utiliza dos JOINdentro de las subconsultas:

FROM JavaScriptError
  JOIN (
    FROM PageAction
      JOIN (
        FROM PageView SELECT count(*) FACET session as pageViewSession, city
        LIMIT MAX
      ) ON session = pageViewSession
    SELECT count(*) FACET city, currentUrl, session as pageActionSession
  ) ON session = pageActionSession
SELECT count(*) FACET city, currentUrl, session, errorClass

La siguiente imagen contiene dos conjuntos de datos: el porcentaje promedio de CPU del contenedor de infraestructura (ProcessSample) y la duración promedio de la transacción de la aplicación por contenedor.

A menudo, los datos de diferentes fuentes están correlacionados. En este caso, puede determinar si el mayor uso de CPU de un contenedor está provocando una transacción más lenta utilizando la siguiente combinación de subconsulta:

FROM Transaction
  JOIN (FROM ProcessSample SELECT average(cpuPercent) AS cpu
  FACET containerId LIMIT MAX) ON containerId
SELECT average(duration)/latest(cpu) FACET containerId, containerName

Con esta consulta, puede ver el contenedor que tiene una duración promedio de transacción más alta dado su uso de CPU e investigar el valor atípico para ver si hay algún error que corregir u optimizaciones que realizar.

Limitaciones de unión de subconsultas

Las uniones de subconsultas tienen las siguientes limitaciones:

• La subconsulta unida seguirá teniendo un LIMIT predeterminado de 10, con un máximo de LIMIT de 5000. Tenga en cuenta que el LIMIT de la consulta externa no afecta la consulta interna.
• No se admite el uso de TIMESERIES en la subconsulta unida. Si su consulta externa utiliza TIMESERIES, tenga en cuenta que la subconsulta unida proporcionará un resultado único durante todo el período de la consulta.
• No se admite el uso de COMPARE WITH en la subconsulta unida. Si su consulta externa utiliza COMPARE WITH, tenga en cuenta que la subconsulta unida proporcionará un resultado único basado en el período de tiempo de la base de consulta y no proporcionará un valor separado para la comparación de la consulta externa con el período de tiempo.
• Como todas las subconsultas, las subconsultas unidas no se pueden utilizar en condición de alerta.
• Si bien SELECT * se admite en la consulta principal, no se admite en la subconsulta unida.
• La cardinalidad de la combinación está limitada a 1:100, lo que significa que una única clave de combinación no puede asignarse a más de cien filas en el resultado de la subconsulta.
• La cláusula ON solo admite condiciones de igualdad.
• La clave JOIN no puede ser un atributo complejo, como un valor de métrica.
• No aplicamos coerción a los tipos de atributos en la condición JOIN . El lado izquierdo de la condición ON de JOIN debe ser del mismo tipo que el lado derecho de la condición ON .
• Los comodines de métrica no se admiten en la condición ON de JOIN
• La subconsulta no puede ser una consulta métrica por filas.
• El lado derecho de la condición ON de JOIN debe ser un identificador proyectado por la consulta. No puede utilizar una función u operación matemática.
• La subconsulta unida no puede proyectar un resultado uniques() .

Ejemplos de unión de subconsultas

A continuación se muestran algunos ejemplos de combinaciones de subconsultas:

Agregar datos faltantes

En este ejemplo, los datos de APM se encuentran en dos lugares: PageView proporciona información sobre una página visitada por un usuario final, mientras que PageAction proporciona las acciones realizadas en la página. Estos dos eventos tienen ID de sesión que identifican la sesión de un usuario final, pero algunos datos están contenidos en un evento y no en el otro.

Aquí, city es un atributo en PageView pero no en PageAction, mientras que currentUrl es un atributo en PageAction pero no en PageView.

Con las combinaciones de subconsultas, puede enriquecer el conjunto de datos PageAction con los datos que faltan. Al combinar los datos usando el ID de sesión, puedes ver no solo la URL con más clics, sino también de qué parte del mundo provienen estas acciones:

FROM PageAction
  JOIN (FROM PageView SELECT count(*) FACET session, city
  LIMIT MAX) ON session
SELECT count(*) FACET city, currentUrl

Copia

Consejo: incluya LIMIT MAX en la subconsulta interna para maximizar la cantidad de resultados unidos a la consulta externa. El límite máximo de resultados actual es de 5000 filas.

Cálculos entre conjuntos de datos

En este ejemplo, se analizarán dos conjuntos de datos log para que coincidan entre sí y luego se ejecutarán cálculos para encontrar el porcentaje de error log .

Log a menudo puede tener datos ocultos dentro del mensaje de log. Al utilizar funciones mejoradas de análisis de cadenas como aparse() , puede extraer el valor principal. En este caso, el ID de la aplicación de clave principal se encuentra en el mensaje de registro de Log y Log_Error:

Para encontrar el porcentaje de error por aplicación, se requiere un LEFT JOIN . Esto se debe a que no todas las aplicaciones tienen errores y un INNER JOIN excluiría estas aplicaciones.

WITH numeric(aparse(message, '%applicationId: * %')) AS application_Id
FROM Log
  LEFT JOIN (FROM Log_Error SELECT count(*) AS errCnt
     FACET numeric(aparse(message, '%appId: * %')) AS app_Id
     SINCE 1 day ago LIMIT MAX) ON application_Id=app_Id
SELECT (latest(errorCount) OR 0)/count(*) AS errorPercentage
FACET app_name, application_Id SINCE 1 day ago

Copia

Aunque había datos almacenados en dos particiones log diferentes y la ID de la aplicación estaba oculta en el mensaje de registro, las uniones de subconsultas permitieron analizar los datos necesarios y calcular el porcentaje de error. Usar latest() también fue útil para garantizar que las agregaciones de la consulta interna se calcularan correctamente con la consulta externa.