Use junções de subconsulta para combinar consulta

Muitos dos dados armazenados no New Relic estão relacionados a outros dados: Transaction e TransactionError, PageView e PageAction, Log e evento de infraestrutura e muito mais. Você pode realizar análises e calcular correlações entre esses eventos usando junções de subconsulta.

Como escrever uma junção de subconsulta

Uma subconsulta é uma consulta aninhada dentro de outra consulta. Com junções de subconsulta, você pode combinar o resultado de uma subconsulta com o resultado de sua consulta externa com base em uma chave, permitindo análise e enriquecimento em conjuntos de dados.

Uma junção de subconsulta requer três componentes: dois conjuntos de dados e uma chave primária para vincular os dois.

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

As junções de subconsulta contêm regras simples para a sintaxe:

• A cláusula JOIN deve sempre seguir imediatamente após a cláusula FROM .
• Você pode prefixar JOIN com o tipo de associação. INNER ou LEFT é opcional e o padrão é INNER quando omitido.
• Os parênteses que contêm uma subconsulta devem seguir imediatamente a cláusula JOIN .
• A cláusula ON deve seguir imediatamente a subconsulta e possui dois formatos (mais detalhes abaixo).

Você também pode ter diversas cláusulas JOIN em uma consulta. Por exemplo, esta consulta usa dois JOINs em 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

A imagem abaixo contém dois conjuntos de dados: o percentual médio de CPU da infraestrutura contêiner (ProcessSample) e a duração média da transação do aplicativo por contêiner.

Muitas vezes, os dados de diferentes fontes estão correlacionados. Nesse caso, você pode determinar se o maior uso de CPU de um contêiner está causando lentidão na transação usando a seguinte junção 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

Com esta consulta, você pode ver os contêineres que possuem maior duração média de transação devido ao uso de CPU, e investigar outliers para ver se há algum bug a ser corrigido ou otimizações a serem feitas.

Limitações de junção de subconsulta

As junções de subconsulta têm as seguintes limitações:

• A subconsulta unida continuará a ter um LIMIT padrão de 10, com um máximo de LIMIT de 5.000. Observe que o LIMIT da consulta externa não afeta a consulta interna.
• O uso de TIMESERIES na subconsulta unida não é compatível. Se sua consulta externa usar TIMESERIES, lembre-se de que a subconsulta unida fornecerá um único resultado para todo o intervalo de tempo da consulta.
• O uso de COMPARE WITH na subconsulta unida não é compatível. Se sua consulta externa usar COMPARE WITH, lembre-se de que a subconsulta unida fornecerá um único resultado com base no intervalo de tempo base da consulta e não fornecerá um valor separado para a consulta externa em comparação com o intervalo de tempo.
• Como todas as subconsultas, as subconsultas unidas não podem ser utilizadas na condição do alerta.
• Embora SELECT * seja compatível com a consulta pai, ele não é compatível com a subconsulta unida.
• A cardinalidade da junção é limitada a 1:100, o que significa que uma única chave de junção não pode mapear mais de cem linhas no resultado da subconsulta.
• A cláusula ON oferece suporte apenas a condições de igualdade.
• A chave JOIN não pode ser um atributo complexo, como um valor de métrica.
• Não fazemos coerção de tipos de atributos na condição JOIN . O lado esquerdo da condição ON de JOIN precisa ser do mesmo tipo que o lado direito da condição ON .
• Curingas de métrica não são suportados na condição ON de JOIN
• A subconsulta não pode ser uma consulta métrica por linha.
• O lado direito da condição ON do JOIN deve ser um identificador projetado pela consulta. Não pode usar uma função ou operação matemática.
• A subconsulta unida não pode projetar um resultado uniques() .

Exemplos de junção de subconsulta

Aqui estão alguns exemplos de junções de subconsulta:

Adicionar dados ausentes

Neste exemplo, os dados do APM estão em dois locais: PageView fornece informações sobre uma página visitada por um usuário final, enquanto PageAction fornece as ações realizadas na página. Esses dois eventos possuem IDs de sessão que identificam a sessão de um usuário final, mas alguns dados estão contidos em um evento e não no outro.

Aqui, city é um atributo em PageView mas não PageAction, enquanto currentUrl é um atributo em PageAction mas não PageView.

Com junções de subconsulta, você pode enriquecer o conjunto de dados PageAction com os dados ausentes. Ao combinar os dados usando o ID da sessão, você pode ver não apenas a URL com mais cliques, mas também de onde vieram essas ações:

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

Copiar

Dica: inclua LIMIT MAX na subconsulta interna para maximizar o número de resultados associados à consulta externa. O limite máximo de resultados atual é de 5.000 linhas.

Cálculos em conjuntos de dados

Neste exemplo, dois conjuntos de dados de log serão analisados para corresponder um ao outro e, em seguida, serão executados cálculos para encontrar a porcentagem de erro de log.

Os logs muitas vezes podem ter dados enterrados na mensagem do log. Usando funções aprimoradas de análise de string como aparse() você pode extrair o valor principal. Neste caso, o ID do aplicativo de chave primária está dentro da mensagem do log de Log e Log_Error:

Para encontrar a porcentagem de erros por aplicativo é necessário um LEFT JOIN . Isso ocorre porque nem todos os aplicativos apresentam erros e um INNER JOIN excluiria esses aplicativos.

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

Copiar

Embora houvesse dados armazenados em duas partições de log diferentes e o ID do aplicativo estivesse oculto na mensagem do log, as junções de subconsulta permitiram analisar os dados necessários e calcular a porcentagem de erro. Usar latest() também foi útil para garantir que as agregações da consulta interna foram calculadas corretamente com a consulta externa.