Este documento contém exemplos de consultas em entradas de registro armazenadas em
buckets de registros que foram atualizados para usar a Análise de registros.
Nesses buckets, é possível executar consultas SQL na página Análise de dados de registros no console Google Cloud . Para mais exemplos, consulte os repositórios do GitHub
logging-analytics-samples
e
security-analytics
.
Este documento não descreve o SQL nem como rotear e armazenar entradas de registro. Para informações sobre esses tópicos, consulte a seção Próximas etapas.
Os exemplos nesta página consultam visualizações de registros. Para consultar uma visualização de análise, use o seguinte formato de caminho: `analytics_view.PROJECT_ID.LOCATION.ANALYTICS_VIEW_ID`
.
Na expressão anterior, PROJECT_ID
é o ID do projeto, e LOCATION
e ANALYTICS_VIEW_ID
são o local e o nome da visualização de análise.
Compatibilidade com a linguagem SQL
As consultas usadas na página Análise de dados de registros são compatíveis com funções do GoogleSQL, com algumas exceções.
Os seguintes comandos SQL não são compatíveis com consultas SQL emitidas usando a página Análise de dados de registros:
- Comandos DDL e DML
- Funções JavaScript definidas pelo usuário
- Funções do BigQuery ML
- Variáveis SQL
Os seguintes recursos só são compatíveis quando você consulta um conjunto de dados vinculado usando as páginas do BigQuery Studio e do Looker Studio e a ferramenta de linha de comando bq:
- Funções JavaScript definidas pelo usuário
- Funções do BigQuery ML
- Variáveis SQL
Antes de começar
Nesta seção, descrevemos as etapas que você precisa concluir antes de usar a análise de registros.
configurar buckets de registros
Confirme se os buckets de registros foram atualizados para usar a Análise de registros:
-
No console Google Cloud , acesse a página Armazenamento de registros:
Acessar o armazenamento de registros
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.
- Para cada bucket de registros com uma visualização que você quer consultar, verifique se a coluna Análise de Dados de Registros disponível mostra Abrir. Se a opção Fazer upgrade aparecer, clique nela e conclua a caixa de diálogo.
Configurar permissões e papéis do IAM
Nesta seção, descrevemos os papéis ou as permissões do IAM necessários para usar a análise de registros:
-
Para receber as permissões necessárias para usar a Análise de registros e consultar visualizações de registros, peça ao administrador para conceder a você os seguintes papéis do IAM no projeto:
-
Para consultar os buckets de registros
_Required
e_Default
: Visualizador de registros (roles/logging.viewer
) -
Para consultar todas as visualizações de registros em um projeto:
Acessador de visualização de registros (
roles/logging.viewAccessor
)
É possível restringir um principal a uma visualização de registros específica adicionando uma condição do IAM à concessão de papel de leitor de acesso à visualização de registros feita no nível do projeto ou adicionando uma vinculação do IAM ao arquivo de política da visualização de registros. Para mais informações, consulte Controlar o acesso a uma visualização de registro.
Essas são as mesmas permissões necessárias para visualizar entradas de registro na página Análise de registros. Para informações sobre outros papéis necessários para consultar visualizações em buckets definidos pelo usuário ou para consultar a visualização
_AllLogs
do bucket de registros_Default
, consulte Papéis do Cloud Logging. -
Para consultar os buckets de registros
-
Para receber as permissões necessárias para consultar visualizações de análise, peça ao administrador para conceder a você o papel Usuário da análise de observabilidade (
roles/observability.analyticsUser
) do IAM no seu projeto.
Como usar as consultas nesta página
-
No console Google Cloud , acesse a página Análise de dados de registros:
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.
No painel Consulta, clique em code SQL e copie e cole uma consulta no painel de consulta SQL.
Antes de copiar uma consulta, na cláusula
FROM
, substitua os seguintes campos:- PROJECT_ID: o identificador do projeto.
- LOCATION: o local da visualização de registros ou da visualização de análise.
- BUCKET_ID: o nome ou ID do bucket de registros.
- LOG_VIEW_ID: o identificador da visualização de registros, que é limitado a 100 caracteres e pode incluir apenas letras, dígitos, sublinhados e hifens.
Veja a seguir o formato da cláusula
FROM
para uma visualização de registros:FROM `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
Os exemplos nesta página consultam uma visualização de registros. Para consultar uma visualização do Analytics, use o seguinte formato de caminho:
`analytics_view.PROJECT_ID.LOCATION.ANALYTICS_VIEW_ID`
. Na expressão anterior,PROJECT_ID
é o ID do projeto, eLOCATION
eANALYTICS_VIEW_ID
são o local e o nome da visualização de análise.
Para usar as consultas mostradas neste documento na página do BigQuery Studio ou
usar a ferramenta de linha de comando bq, edite a cláusula FROM
e insira o
caminho para o conjunto de dados vinculado.
Por exemplo, para consultar a visualização _AllLogs
no conjunto de dados vinculado chamado mydataset
que está no projeto myproject
, o caminho é myproject.mydataset._AllLogs
.
Casos de uso comuns
Para consultar o bucket _Default
,mas limitar os resultados a 1.000 entradas, execute a seguinte consulta:
SELECT
timestamp, severity, resource.type, log_name, text_payload, proto_payload, json_payload
FROM
`PROJECT_ID.LOCATION._Default._AllLogs`
LIMIT 1000
Analisar entradas de registro com uma carga útil de texto
Para analisar apenas entradas de registro que têm um text_payload
,
adicione a seguinte cláusula:
WHERE text_payload IS NOT NULL
O campo text_payload
tem um tipo de dados string
.
Analisar entradas de registro com um payload JSON
Para analisar apenas entradas de registro que têm um json_payload
, adicione a seguinte cláusula:
WHERE json_payload IS NOT NULL
Porque o campo json_payload
tem um tipo de dados JSON
. Nos resultados da consulta, esse payload também está no formato JSON, que você pode navegar.
Analisar entradas de registro com um payload de proto
Para analisar apenas entradas de registro que têm um proto_payload
, adicione a seguinte cláusula:
WHERE json_payload IS NULL AND text_payload IS NULL
Para campos com um tipo de dados RECORD
, não é possível excluir o campo testando o valor dele em relação a NULL
. Para esse cenário, a cláusula WHERE
depende do fato de que toda entrada de registro precisa ter um payload de texto, JSON ou proto.
O proto_payload
tem um tipo de dados RECORD
. Nos resultados da consulta, esse payload é mostrado como uma estrutura formatada em JSON, que você pode navegar.
Filtrar entradas
As consultas SQL determinam quais entradas na visualização serão processadas, agrupam essas entradas e realizam operações de agregação. Quando nenhuma operação de agrupamento e agregação é listada, o resultado da consulta inclui todas as entradas que correspondem aos filtros na cláusula WHERE
.
A forma como você especifica a cláusula WHERE
para incluir ou excluir entradas com base no valor de uma coluna depende do tipo de dados dela. Esta seção
fornece vários exemplos para diferentes tipos de dados.
Filtrar por marcação de tempo
Para definir o período da consulta, recomendamos usar o seletor de período. Esse seletor é usado automaticamente quando uma consulta não especifica um campo timestamp
na cláusula WHERE
.
Por exemplo, para ver os dados da semana passada, selecione Últimos 7 dias no seletor de período. Você também pode usar o seletor de período para especificar um horário de início e de término, especificar um horário para visualizar e mudar os fusos horários.
Se você incluir um campo timestamp
na cláusula WHERE
, a configuração do seletor de período não será usada. O exemplo a seguir filtra os dados usando a função TIMESTAMP_SUB
, que permite especificar um intervalo de retorno do tempo atual:
WHERE
timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)
Para mais informações sobre como filtrar por hora, consulte Funções de tempo e Funções de carimbo de data/hora.
Filtrar por recurso
Para filtrar os dados de registro por recurso, adicione uma instrução resource.type
à cláusula WHERE
.
Por exemplo, a consulta a seguir lê a hora mais recente de dados de registro, retém as linhas cujo tipo de recurso corresponde a gce_instance
e classifica e mostra até 100 entradas:
SELECT
timestamp, log_name, severity, json_payload, resource, labels
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
resource.type = "gce_instance"
ORDER BY timestamp ASC
LIMIT 100
Filtrar por gravidade
É possível filtrar os dados de registro por uma gravidade específica com uma restrição
como severity = 'ERROR'
. Outra opção é usar a instrução IN
e especificar um conjunto de valores válidos.
Por exemplo, a consulta a seguir lê a hora mais recente de dados de registro e retém apenas as linhas que contêm um campo severity
cujo valor é 'INFO'
ou 'ERROR'
:
SELECT
timestamp, log_name, severity, json_payload, resource, labels
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
severity IS NOT NULL AND
severity IN ('INFO', 'ERROR')
ORDER BY timestamp ASC
LIMIT 100
A consulta anterior filtra pelo valor do campo severity
. No entanto, para dados de registro, também é possível escrever consultas que filtram pelo valor numérico da gravidade do registro.
Por exemplo, se você substituir as linhas severity
pelas linhas a seguir,
a consulta vai retornar todas as entradas de registro cujo nível de gravidade seja pelo menos NOTICE
:
severity_number IS NOT NULL AND
severity_number > 200
Para informações sobre os valores enumerados, consulte
LogSeverity
.
Filtrar por nome do registro
Para filtrar os dados de registro por um nome de registro, adicione uma restrição ao valor do campo log_name
ou log_id
. O campo log_name
inclui o caminho do recurso. Ou seja, esse campo tem valores como projects/myproject/logs/mylog
.
O campo log_id
armazena apenas o nome do registro, como mylog
.
Por exemplo, a consulta a seguir lê a hora mais recente de dados, retém as linhas em que o valor no campo log_id
é cloudaudit.googleapis.com/data_access
e classifica e mostra os resultados:
SELECT
timestamp, log_id, severity, json_payload, resource, labels
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
log_id = "cloudaudit.googleapis.com/data_access"
ORDER BY timestamp ASC
LIMIT 100
Filtrar por rótulo de recurso
A maioria dos descritores de recursos monitorados define rótulos usados para identificar o recurso específico. Por exemplo, o descritor de uma instância do Compute Engine inclui rótulos para a zona, o ID do projeto e o ID da instância. Quando a entrada de registro é gravada, os valores são atribuídos a cada campo. Confira um exemplo:
{
type: "gce_instance"
labels: {
instance_id: "1234512345123451"
project_id: "my-project"
zone: "us-central1-f"
}
}
Como o tipo de dados do campo labels
é JSON, incluir uma restrição como resource.labels.zone = "us-centra1-f"
em uma consulta resulta em um erro de sintaxe. Para receber o valor de um campo com um tipo de dados JSON, use a função
JSON_VALUE
.
Por exemplo, a consulta a seguir lê os dados mais recentes e retém as linhas em que o recurso é uma instância do Compute Engine localizada na zona us-central1-f
:
SELECT
timestamp, log_name, severity, JSON_VALUE(resource.labels.zone) AS zone, json_payload, resource, labels
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
resource.type = "gce_instance" AND
JSON_VALUE(resource.labels.zone) = "us-central1-f"
ORDER BY timestamp ASC
LIMIT 100
Para informações sobre todas as funções que podem recuperar e transformar dados JSON, consulte Funções JSON.
Filtrar por solicitação HTTP
Para filtrar a visualização de registros e incluir apenas as entradas que correspondem a uma solicitação ou resposta HTTP, adicione uma restrição http_request IS NOT NULL
:
SELECT
timestamp, log_name, severity, http_request, resource, labels
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
http_request IS NOT NULL
ORDER BY timestamp
LIMIT 100
A consulta a seguir inclui apenas linhas que correspondem a solicitações GET
ou POST
:
SELECT
timestamp, log_name, severity, http_request, resource, labels
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
http_request IS NOT NULL AND
http_request.request_method IN ('GET', 'POST')
ORDER BY timestamp ASC
LIMIT 100
Filtrar por status HTTP
Para filtrar por status HTTP, modifique a cláusula WHERE
para exigir que o campo http_request.status
seja definido:
SELECT
timestamp, log_name, http_request.status, http_request, resource, labels
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
http_request IS NOT NULL AND
http_request.status IS NOT NULL
ORDER BY timestamp ASC
LIMIT 100
Para determinar o tipo de dados armazenados em um campo, consulte o esquema ou mostre o campo. Os resultados da consulta anterior mostram que o campo http_request.status
armazena valores inteiros.
Filtrar por um campo com um tipo JSON
Para extrair um valor de uma coluna cujo tipo de dados é JSON, use a função JSON_VALUE
.
Considere as seguintes consultas:
SELECT
json_payload
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
json_payload.status IS NOT NULL
e
SELECT
json_payload
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
JSON_VALUE(json_payload.status) IS NOT NULL
As consultas anteriores testam o valor do campo json_payload
na
entrada de registro. As duas consultas descartam entradas de registro que não contêm um campo chamado json_payload
.
A diferença entre essas duas consultas é a linha final, que define
o que é testado em relação a NULL
. Agora considere uma visualização de registros que tenha
duas entradas de registro. Para uma entrada de registro, o campo json_payload
tem o seguinte
formato:
{
status: {
measureTime: "1661517845"
}
}
Para a outra entrada de registro, o campo json_payload
tem uma estrutura diferente:
{
@type: "type.googleapis.com/google.cloud.scheduler.logging.AttemptFinished"
jobName: "projects/my-project/locations/us-central1/jobs/test1"
relativeUrl: "/food=cake"
status: "NOT_FOUND"
targetType: "APP_ENGINE_HTTP"
}
As duas entradas de registro anteriores atendem à restrição
json_payload.status IS NOT NULL
.
Ou seja, o resultado da primeira consulta inclui as duas entradas de registro.
No entanto, quando a restrição é JSON_VALUE(json_payload.status) IS NOT NULL
, apenas a segunda entrada de registro é incluída no resultado da consulta.
Filtrar por expressão regular
Para retornar a substring que corresponde a uma expressão regular, use a função
REGEXP_EXTRACT
. O tipo de retorno dessa função é um STRING
ou um BYTES
.
A consulta a seguir mostra as entradas de registro mais recentes recebidas, retém
essas entradas com um campo json_payload.jobName
e mostra a
parte do nome que começa com test
:
SELECT
timestamp, REGEXP_EXTRACT(JSON_VALUE(json_payload.jobName), r".*(test.*)$") AS name,
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
json_payload.jobName IS NOT NULL
ORDER BY timestamp DESC
LIMIT 20
Para mais exemplos, consulte a
documentação do REGEXP_EXTRACT
.
Para ver exemplos de outras expressões regulares que
você pode usar, consulte Funções.
A consulta mostrada neste exemplo não é eficiente. Para uma correspondência de substring, como
a ilustrada, use a função CONTAINS_SUBSTR
.
Agrupar e agregar entradas de registro
Esta seção se baseia nas amostras anteriores e ilustra como agrupar e agregar entradas de registro. Se você não especificar um agrupamento, mas especificar uma agregação, um único resultado será impresso porque o SQL trata todas as linhas que atendem à cláusula WHERE
como um único grupo.
Todas as expressões SELECT
precisam ser incluídas nos campos de grupo ou agregadas.
Agrupar por período
Para agrupar dados por tempo, use a função TIMESTAMP_TRUNC
, que trunca um carimbo de data/hora para uma granularidade especificada, como MINUTE
. Por exemplo, um carimbo de data/hora de 15:30:11
, que é formatado como hours:minutes:seconds
, se torna 15:30:00
quando a granularidade é definida como MINUTE
.
A consulta a seguir lê os dados recebidos no intervalo especificado pelo seletor de período e retém as linhas em que o valor do campo json_payload.status
não é NULL.
A consulta trunca o carimbo de data/hora em cada linha por hora e agrupa as linhas pelo carimbo de data/hora truncado e pelo status:
SELECT
TIMESTAMP_TRUNC(timestamp, HOUR) AS hour,
JSON_VALUE(json_payload.status) AS status,
COUNT(*) AS count
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
json_payload IS NOT NULL AND
JSON_VALUE(json_payload.status) IS NOT NULL
GROUP BY hour,status
ORDER BY hour ASC
Para mais exemplos, consulte a
documentação do TIMESTAMP_TRUNC
.
Para informações sobre outras funções baseadas em tempo, consulte
Funções de data e hora.
Agrupar por recurso
A consulta a seguir lê a hora mais recente de dados e agrupa as entradas de registro por tipo de recurso. Em seguida, ele conta o número de linhas para cada tipo de recurso e retorna uma tabela com duas colunas. A primeira coluna lista o tipo de recurso, enquanto a segunda é o número de linhas para esse tipo de recurso:
SELECT
resource.type, COUNT(*) AS count
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
GROUP BY resource.type
LIMIT 100
Agrupar por gravidade
A consulta a seguir lê a hora mais recente de dados e retém as linhas que têm um campo de gravidade. Em seguida, a consulta agrupa as linhas por gravidade e conta o número de linhas de cada grupo:
SELECT
severity, COUNT(*) AS count
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
severity IS NOT NULL
GROUP BY severity
ORDER BY severity
LIMIT 100
Agrupar por log_id
O resultado da consulta a seguir é uma tabela com duas colunas. A primeira coluna lista os nomes dos registros, e a segunda, o número de entradas gravadas. A consulta classifica os resultados pela contagem de entradas:
SELECT
log_id, COUNT(*) AS count
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
GROUP BY log_id
ORDER BY count DESC
LIMIT 100
Calcular a latência média para solicitações HTTP
A consulta a seguir ilustra o agrupamento por várias colunas e o cálculo de um valor médio. A consulta agrupa as linhas pelo URL contido na solicitação HTTP e pelo valor do campo labels.checker_location
. Depois de agrupar as linhas, a consulta calcula a latência média de cada grupo:
SELECT
JSON_VALUE(labels.checker_location) AS location,
AVG(http_request.latency.seconds) AS secs, http_request.request_url
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
http_request IS NOT NULL AND
http_request.request_method IN ('GET')
GROUP BY http_request.request_url, location
ORDER BY location
LIMIT 100
Na expressão anterior, JSON_VALUE
é necessário para extrair o valor do campo labels.checker_location
porque o tipo de dados de labels
é JSON.
No entanto, não é possível usar essa função para extrair o valor do campo http_request.latency.seconds
. O último campo tem um tipo de dados inteiro.
Calcular a média de bytes enviados para um teste de sub-rede
A consulta a seguir ilustra como mostrar o número médio de bytes enviados por local.
A consulta lê a hora mais recente de dados e retém apenas as linhas em que a coluna de tipo de recurso é gce_subnetwork
e a coluna json_payload
não é NULL. Em seguida, a consulta agrupa as linhas pelo local do recurso. Ao contrário do exemplo anterior, em que os dados são armazenados como um valor numérico, o valor do campo bytes_sent
é uma string. Portanto, é necessário converter o valor em um FLOAT64
antes de calcular a média:
SELECT JSON_VALUE(resource.labels.location) AS location,
AVG(CAST(JSON_VALUE(json_payload.bytes_sent) AS FLOAT64)) AS bytes
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
resource.type = "gce_subnetwork" AND
json_payload IS NOT NULL
GROUP BY location
LIMIT 100
O resultado da consulta anterior é uma tabela em que cada linha lista um local e a média de bytes enviados para ele.
Para informações sobre todas as funções que podem recuperar e transformar dados JSON, consulte Funções JSON.
Para informações sobre CAST
e outras funções de conversão, consulte Funções de conversão.
Contar as entradas de registro com um campo que corresponda a um padrão
Para retornar a substring que corresponde a uma expressão regular, use a função
REGEXP_EXTRACT
. O tipo de retorno dessa função é um STRING
ou um BYTES
.
A consulta a seguir retém as entradas de registro em que o valor do campo json_payload.jobName
não é NULL.
Em seguida, ele agrupa as entradas pelo sufixo do nome que começa com test
. Por fim, a consulta conta o número de entradas em cada grupo:
SELECT
REGEXP_EXTRACT(JSON_VALUE(json_payload.jobName), r".*(test.*)$") AS name,
COUNT(*) AS count
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
json_payload.jobName IS NOT NULL
GROUP BY name
ORDER BY count
LIMIT 20
Para mais exemplos, consulte a
documentação do REGEXP_EXTRACT
.
Para ver exemplos de outras expressões regulares que
você pode usar, consulte Funções.
Pesquisa entre colunas
Esta seção descreve duas abordagens diferentes que podem ser usadas para pesquisar várias colunas de uma tabela.
Pesquisa baseada em token
Para pesquisar em uma visualização de registros entradas que correspondam a um conjunto de termos de pesquisa, use a função SEARCH
. Essa função exige dois parâmetros: onde pesquisar e a consulta de pesquisa.
Como a função SEARCH
tem regras específicas sobre como os dados são pesquisados, recomendamos que você leia a documentação do SEARCH
.
A consulta a seguir retém apenas as linhas que têm um campo que corresponde exatamente a "35.193.12.15":
SELECT
timestamp, log_id, proto_payload, severity, resource.type, resource, labels
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID` AS t
WHERE
proto_payload IS NOT NULL AND
log_id = "cloudaudit.googleapis.com/data_access" AND
SEARCH(t,"`35.193.12.15`")
ORDER BY timestamp ASC
LIMIT 20
Na consulta anterior, as crases envolvem o valor a ser pesquisado. Isso garante que a função SEARCH
procure uma correspondência exata entre um valor de campo e o valor entre as crases.
Quando as crases são omitidas na string de consulta, ela é dividida
com base nas regras definidas na documentação do SEARCH
.
Por exemplo, quando a instrução a seguir é executada, a string de consulta é dividida em quatro tokens: "35", "193", "12" e "15":
SEARCH(t,"35.193.12.15")
A instrução SEARCH
anterior corresponde a uma linha quando um único campo corresponde a todos os quatro tokens. A ordem dos tokens não importa.
É possível incluir várias instruções SEARCH
em uma consulta. Por exemplo, na consulta anterior, você pode substituir o filtro no ID do registro por uma instrução como esta:
SEARCH(t,"`cloudaudit.googleapis.com/data_access`")
A instrução anterior pesquisa todos os campos das entradas de registro na visualização de registros, enquanto a instrução original pesquisa apenas o campo log_id
das entradas de registro.
Para fazer várias pesquisas em vários campos, separe as strings individuais com um espaço. Por exemplo, a instrução a seguir corresponde a linhas em que um campo contém "Hello World", "happy" e "days":
SEARCH(t,"`Hello World` happy days")
Por fim, você pode pesquisar campos específicos em vez de uma tabela inteira. Por exemplo, a instrução a seguir pesquisa apenas
as colunas chamadas text_payload
e json_payload
:
SEARCH((text_payload, json_payload) ,"`35.222.132.245`")
Para informações sobre como os parâmetros da função SEARCH
são processados, consulte a página de referência do BigQuery Funções de pesquisa.
Pesquisa de substring
Para realizar um teste indiferente a maiúsculas e minúsculas e determinar se um valor existe em uma expressão, use a função CONTAINS_SUBSTR
.
Essa função retorna TRUE
quando o valor existe e FALSE
caso contrário. O valor da pesquisa precisa ser um literal STRING
, mas não o
literal NULL
.
Por exemplo, a consulta a seguir busca todas as entradas de registro de auditoria de acesso a dados com um endereço IP específico cujos carimbos de data/hora estão em um intervalo de tempo específico. Por fim, a consulta classifica os resultados e mostra os 20 mais antigos:
SELECT
timestamp, log_id, proto_payload, severity, resource.type, resource, labels
FROM
`PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID` AS t
WHERE
proto_payload IS NOT NULL AND
log_id = "cloudaudit.googleapis.com/data_access" AND
CONTAINS_SUBSTR(t,"35.193.12.15")
ORDER BY timestamp ASC
LIMIT 20
A consulta anterior realiza um teste de substring. Portanto, uma linha que contém "35.193.12.152" corresponde à instrução CONTAINS_SUBSTR
.
Combinar dados de várias fontes
As instruções de consulta verificam uma ou mais tabelas ou expressões e retornam as linhas de resultados calculadas. Por exemplo, é possível usar instruções de consulta para mesclar os resultados de instruções SELECT
em diferentes tabelas ou conjuntos de dados de várias maneiras e, em seguida, selecionar as colunas dos dados combinados.
Combinar dados de duas tabelas com mesclagens
Para combinar informações de duas tabelas, use um dos operadores de junção. O tipo de junção e a cláusula condicional usada determinam como as linhas são combinadas e descartadas.
A consulta a seguir mostra os campos json_payload
de linhas em duas tabelas diferentes gravadas pelo mesmo intervalo de rastreamento. A consulta executa um
JOIN
interno em duas tabelas para linhas em que os valores das
colunas span_id
e trace
em ambas as tabelas correspondem. Com base nesse resultado, a consulta seleciona os campos timestamp
, severity
e json_payload
que vieram de LOG_VIEW_1, o campo json_payload
de LOG_VIEW_1 e os valores dos campos span_id
e trace
em que as duas tabelas foram unidas, retornando até 100 linhas:
SELECT
a.timestamp, a.severity, a.json_payload, b.json_payload, a.span_id, a.trace
FROM `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_1` a
JOIN `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_1` b
ON
a.span_id = b.span_id AND
a.trace = b.trace
LIMIT 100
Combinar várias seleções com uniões
Para combinar os resultados de duas ou mais instruções SELECT
e descartar
linhas duplicadas, use o operador UNION
. Para manter linhas duplicadas, use o operador UNION ALL
.
A consulta a seguir lê a hora mais recente de dados de LOG_VIEW_1, mescla o resultado com a hora mais recente de dados de LOG_VIEW_1, classifica os dados mesclados por carimbo de data/hora crescente e mostra as 100 entradas mais antigas:
SELECT
timestamp, log_name, severity, json_payload, resource, labels
FROM(
SELECT * FROM `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_1`
UNION ALL
SELECT * FROM `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_1`
)
ORDER BY timestamp ASC
LIMIT 100
Remover entradas de registro duplicadas
O Log Analytics não remove entradas de registro duplicadas antes da execução de uma consulta. Esse comportamento é diferente de quando você consulta entradas de registro usando o Explorador de registros, que remove entradas duplicadas comparando os nomes de registro, carimbos de data/hora e campos de ID de inserção.
É possível usar a validação no nível da linha para remover entradas de registro duplicadas.
Para mais informações, consulte Solução de problemas: há entradas de registro duplicadas nos meus resultados da análise de registros.
A seguir
Para informações sobre como rotear e armazenar entradas de registro, consulte os seguintes documentos:
- Criar um bucket de registros
- Fazer upgrade de um bucket para usar a Análise de dados de registros
- Vincular um bucket de registros a um conjunto de dados do BigQuery
- configurar e gerenciar coletores
Para a documentação de referência do SQL, consulte os seguintes documentos: