Esta página se ha traducido con Cloud Translation API.

Consultas de SQL de ejemplo

Este documento contiene consultas de ejemplo sobre las entradas de registro almacenadas en contenedores de registro que se han actualizado para usar analíticas de registros. En estos contenedores, puedes ejecutar consultas de SQL desde la página Analíticas de registros de la Google Cloud consola. Para ver más ejemplos, consulta los repositorios de GitHub logging-analytics-samples y security-analytics.

En este documento no se describe SQL ni cómo enrutar y almacenar entradas de registro. Para obtener información sobre estos temas, consulta la sección Pasos siguientes.

Antes de empezar

En esta sección se describen los pasos que debe completar para poder usar Log Analytics.

Configurar segmentos de registros

Comprueba que tus contenedores de registros se hayan actualizado para usar Analíticas de registros:

En la Google Cloud consola, ve a la página Almacenamiento de registros:
Ve a Almacenamiento de registros.

Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Registro.
En cada contenedor de registros que tenga una vista de registro que quieras consultar, comprueba que en la columna Analíticas de registros disponibles se muestre Abrir. Si se muestra Cambiar a plan superior, haz clic en Cambiar a plan superior y completa el cuadro de diálogo.

Configurar roles y permisos de gestión de identidades y accesos

En esta sección se describen los roles o permisos de gestión de identidades y accesos que se necesitan para usar Log Analytics:

Para obtener los permisos que necesitas para usar Log Analytics y consultar vistas de registro, pide a tu administrador que te conceda los siguientes roles de gestión de identidades y accesos en tu proyecto:
- Para consultar los segmentos de registros _Required y _Default, sigue estos pasos: Visualizador de registros (roles/logging.viewer)
- Para consultar todas las vistas de registro de un proyecto, sigue estos pasos: Usuario con permiso para ver registros (roles/logging.viewAccessor)
Puede restringir un principal a una vista de registro específica añadiendo una condición de IAM a la concesión del rol de acceso a la vista de registros que se haya hecho a nivel de proyecto o añadiendo un enlace de IAM al archivo de política de la vista de registro. Para obtener más información, consulta Controlar el acceso a una vista de registro.

Estos son los mismos permisos que necesitas para ver las entradas de registro en la página Explorador de registros. Para obtener información sobre los roles adicionales que necesitas para consultar vistas en segmentos definidos por el usuario o para consultar la vista _AllLogs del segmento de registro _Default, consulta Roles de Cloud Logging.
Para obtener los permisos que necesitas para consultar vistas de analíticas, pide a tu administrador que te conceda el rol de gestión de identidades y accesos Usuario de Observabilidad Analytics (roles/observability.analyticsUser) en tu proyecto.

Cómo usar estas consultas

Para usar las consultas que se muestran en este documento en la página Analíticas de registros, sustituya TABLE_NAME_OF_LOG_VIEW por el nombre de la tabla de la vista de registro o de la vista de analíticas que quiera consultar.

Para consultar una vista de registro en la cláusula FROM, utiliza el siguiente formato:
```
FROM `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
```
Para consultar una vista de Analytics, en la cláusula FROM, usa el siguiente formato:
```
FROM `analytics_view.PROJECT_ID.LOCATION.ANALYTICS_VIEW_ID`
```

A continuación, se describe el significado de los campos de las expresiones anteriores:

PROJECT_ID: identificador del proyecto.
LOCATION: la ubicación de la vista de registro o de la vista de analíticas.
BUCKET_ID: nombre o ID del segmento de registro.
LOG_VIEW_ID: identificador de la vista de registro, que tiene un límite de 100 caracteres y solo puede incluir letras, dígitos, guiones bajos y guiones.
ANALYTICS_VIEW_ID: ID de la vista de analíticas, que tiene un límite de 100 caracteres y solo puede incluir letras, números, guiones bajos y guiones.

Si has creado un conjunto de datos de BigQuery vinculado, puedes consultar el conjunto de datos vinculado desde la página BigQuery Studio. En esa página, sustituye TABLE_NAME_OF_LOG_VIEW por la ruta a la tabla del conjunto de datos vinculado. Por ejemplo, para consultar la vista _AllLogs del conjunto de datos vinculado mydataset que está en el proyecto myproject, asigna a este campo el valor myproject.mydataset._AllLogs.

Ir a la página Analíticas de registros

Para abrir la página Log Analytics, haga lo siguiente:

En la Google Cloud consola, ve a la página Analíticas de registros:
Vaya a Analíticas de registros.

Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Registro.
Para identificar las vistas de registro y las vistas de analíticas, vaya al panel Vistas.

Las vistas de registro se muestran en la sección Logs (segmento de registros), y las vistas de analíticas se muestran en la sección Analytics Views (tabla de datos de vistas de analíticas).
Opcional: Para identificar el esquema de una vista de registro o de una vista de analíticas, selecciona la vista de registro o la vista de analíticas.

Se muestra el esquema. Puedes usar el campo Filtrar para buscar campos específicos. No puedes modificar el esquema.

Para obtener información sobre cómo acceder a la consulta predeterminada de un elemento que aparece en el panel Vistas, consulta Consultar y analizar registros con Analíticas de registros.

Filtrar registros

Las consultas SQL determinan qué entradas de la vista de registro se van a procesar. Después, agrupan estas entradas y realizan operaciones de agregación. Si no se indica ninguna operación de agrupación ni de agregación, el resultado de la consulta incluye las filas seleccionadas por la operación de filtro. Los ejemplos de esta sección muestran cómo se aplica el filtrado.

Filtrar por hora

Para definir el periodo de tu consulta, te recomendamos que uses el selector de periodo. Este selector se usa automáticamente cuando una consulta no especifica un campo timestamp en la cláusula WHERE. Por ejemplo, para ver los datos de la semana pasada, seleccione Últimos 7 días en el selector de intervalo de tiempo. También puedes usar el selector de intervalo de tiempo para especificar una hora de inicio y de finalización, especificar una hora para ver los datos de ese momento y cambiar la zona horaria.

Si incluye un campo timestamp en la cláusula WHERE, no se usará el ajuste del selector de intervalo de tiempo. En el siguiente ejemplo se filtran los datos mediante la función TIMESTAMP_SUB, que te permite especificar un intervalo retrospectivo a partir de la hora actual:

WHERE
  timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)

Para obtener más información sobre cómo filtrar por tiempo, consulta las secciones Funciones de tiempo y Funciones de marca de tiempo.

Filtrar por recurso

Para filtrar por recurso, añade una restricción resource.type.

Por ejemplo, la siguiente consulta lee los datos de la última hora, conserva las filas cuyo tipo de recurso coincide con gce_instance y, a continuación, ordena y muestra hasta 100 entradas:

SELECT
  timestamp, log_name, severity, json_payload, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  resource.type = "gce_instance"
ORDER BY timestamp ASC
LIMIT 100

Filtrar por gravedad

Puedes filtrar por una gravedad específica con una restricción como severity = 'ERROR'. Otra opción es usar la instrucción IN y especificar un conjunto de valores válidos.

Por ejemplo, la siguiente consulta lee los datos de la última hora y, a continuación, solo conserva las filas que contienen un campo severity cuyo valor es 'INFO' o 'ERROR':

SELECT
  timestamp, log_name, severity, json_payload, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  severity IS NOT NULL AND
  severity IN ('INFO', 'ERROR')
ORDER BY timestamp ASC
LIMIT 100

La consulta anterior filtra por el valor del campo severity. Sin embargo, también puede escribir consultas que filtren por el valor numérico de la gravedad del registro. Por ejemplo, si sustituyes las líneas de severity por las siguientes, la consulta devolverá todas las entradas de registro cuyo nivel de gravedad sea al menos NOTICE:

  severity_number IS NOT NULL AND
  severity_number > 200

Para obtener información sobre los valores enumerados, consulta LogSeverity.

Filtrar por nombre de registro

Para filtrar por nombre de registro, puedes añadir una restricción al valor del campo log_name o log_id. El campo log_name incluye la ruta del recurso. Es decir, este campo tiene valores como projects/myproject/logs/mylog. El campo log_id solo almacena el nombre del registro, como mylog.

Por ejemplo, la siguiente consulta lee los datos de la última hora, conserva las filas en las que el valor del campo log_id es cloudaudit.googleapis.com/data_access y, a continuación, ordena y muestra los resultados:

SELECT
  timestamp, log_id, severity, json_payload, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  log_id = "cloudaudit.googleapis.com/data_access"
ORDER BY timestamp ASC
LIMIT 100

Filtrar por etiqueta de recurso

La mayoría de los descriptores de recursos monitorizados definen etiquetas que se usan para identificar el recurso específico. Por ejemplo, el descriptor de una instancia de Compute Engine incluye etiquetas de la zona, el ID del proyecto y el ID de la instancia. Cuando se escribe la entrada de registro, se asignan valores a cada campo. A continuación, se muestra un ejemplo:

{
   type: "gce_instance"
   labels: {
      instance_id: "1234512345123451"
      project_id: "my-project"
      zone: "us-central1-f"
   }
}

Como el tipo de datos del campo labels es JSON, si se incluye una restricción como resource.labels.zone = "us-centra1-f" en una consulta, se producirá un error de sintaxis. Para obtener el valor de un campo con el tipo de datos JSON, usa la función JSON_VALUE.

Por ejemplo, la siguiente consulta lee los datos más recientes y, a continuación, conserva las filas en las que el recurso es una instancia de Compute Engine ubicada en la zona us-central1-f:

SELECT
  timestamp, log_name, severity, JSON_VALUE(resource.labels.zone) AS zone, json_payload, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  resource.type = "gce_instance" AND
  JSON_VALUE(resource.labels.zone) = "us-central1-f"
ORDER BY timestamp ASC
LIMIT 100

Para obtener información sobre todas las funciones que pueden recuperar y transformar datos JSON, consulta Funciones JSON.

Filtrar por solicitud HTTP

Para filtrar la vista de registro de forma que solo se incluyan las entradas de registro que correspondan a una solicitud o respuesta HTTP, añade una restricción http_request IS NOT NULL:

SELECT
  timestamp, log_name, severity, http_request, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  http_request IS NOT NULL
ORDER BY timestamp
LIMIT 100

La siguiente consulta solo incluye las filas que corresponden a solicitudes de GET o POST:

SELECT
  timestamp, log_name, severity, http_request, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  http_request IS NOT NULL AND
  http_request.request_method IN ('GET', 'POST')
ORDER BY timestamp ASC
LIMIT 100

Filtrar por estado HTTP

Para filtrar por estado HTTP, modifique la cláusula WHERE para que se defina el campo http_request.status:

SELECT
  timestamp, log_name, http_request.status, http_request, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  http_request IS NOT NULL AND
  http_request.status IS NOT NULL
ORDER BY timestamp ASC
LIMIT 100

Para determinar el tipo de datos almacenados en un campo, consulta el esquema o muestra el campo. Los resultados de la consulta anterior muestran que el campo http_request.status almacena valores enteros.

Filtrar por un campo con un tipo JSON

Para extraer un valor de una columna cuyo tipo de datos sea JSON, usa la función JSON_VALUE.

Considera las siguientes consultas:

SELECT
  json_payload
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  json_payload.status IS NOT NULL

SELECT
  json_payload
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  JSON_VALUE(json_payload.status) IS NOT NULL

Las consultas anteriores comprueban el valor del campo json_payload en la entrada de registro. Ambas consultas descartan las entradas de registro que no contienen un campo etiquetado como json_payload. La diferencia entre estas dos consultas es la última línea, que define con qué se compara NULL. Ahora, considera una vista de registro que tenga dos entradas de registro. En una entrada de registro, el campo json_payload tiene el siguiente formato:

{
    status: {
        measureTime: "1661517845"
    }
}

En la otra entrada de registro, el campo json_payload tiene una estructura 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"
}

Ambas entradas de registro anteriores cumplen la restricción json_payload.status IS NOT NULL. Es decir, el resultado de la primera consulta incluye ambas entradas de registro. Sin embargo, cuando la restricción es JSON_VALUE(json_payload.status) IS NOT NULL, solo se incluye la segunda entrada de registro en el resultado de la consulta.

Filtrar por expresión regular

Para devolver la subcadena que coincide con una expresión regular, usa la función REGEXP_EXTRACT. El tipo de valor devuelto de esta función es STRING o BYTES.

La siguiente consulta muestra las entradas de registro más recientes recibidas, conserva las entradas con un campo json_payload.jobName y, a continuación, muestra la parte del nombre que empieza por test:

SELECT
  timestamp, REGEXP_EXTRACT(JSON_VALUE(json_payload.jobName), r".*(test.*)$") AS name,
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  json_payload.jobName IS NOT NULL
ORDER BY timestamp DESC
LIMIT 20

Para ver más ejemplos, consulta la documentación de REGEXP_EXTRACT. Para ver ejemplos de otras expresiones regulares que puedes usar, consulta Funciones, operadores y condicionales.

La consulta que se muestra en este ejemplo no es eficiente. Para buscar una subcadena, como la que se muestra en la imagen, usa la función CONTAINS_SUBSTR.

Agrupar y agregar entradas de registro

En esta sección se amplían los ejemplos anteriores y se muestra cómo puedes agrupar y agregar entradas de registro. Si no especifica una agrupación, pero sí una agregación, se imprimirá un único resultado porque SQL trata todas las filas que cumplen la cláusula WHERE como un solo grupo.

Todas las expresiones SELECT deben incluirse en los campos de grupo o agregarse.

Agrupar por hora

Para agrupar datos por tiempo, usa la función TIMESTAMP_TRUNC, que trunca una marca de tiempo a una granularidad especificada, como MINUTE. Por ejemplo, una marca de tiempo 15:30:11, que tiene el formato hours:minutes:seconds, se convierte en 15:30:00 cuando la granularidad se define como MINUTE.

La siguiente consulta lee los datos recibidos en el intervalo especificado por el selector de periodo y, a continuación, conserva las filas en las que el valor del campo json_payload.status no es NULL. La consulta trunca la marca de tiempo de cada fila por hora y, a continuación, agrupa las filas por la marca de tiempo truncada y el estado:

SELECT
  TIMESTAMP_TRUNC(timestamp, HOUR) AS hour,
  JSON_VALUE(json_payload.status) AS status,
  COUNT(*) AS count
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  json_payload IS NOT NULL AND
  JSON_VALUE(json_payload.status) IS NOT NULL
GROUP BY hour,status
ORDER BY hour ASC

Para ver más ejemplos, consulta la documentación de TIMESTAMP_TRUNC. Para obtener información sobre otras funciones basadas en el tiempo, consulta Funciones de fecha y hora.

Agrupar por recurso

La siguiente consulta lee los datos de la última hora y, a continuación, agrupa las entradas de registro por tipo de recurso. A continuación, cuenta el número de filas de cada tipo de recurso y devuelve una tabla con dos columnas. En la primera columna se indica el tipo de recurso, mientras que en la segunda se muestra el número de filas de ese tipo de recurso:

SELECT
   resource.type, COUNT(*) AS count
FROM
  `TABLE_NAME_OF_LOG_VIEW`
GROUP BY resource.type
LIMIT 100

Agrupar por gravedad

La siguiente consulta lee los datos de la última hora y, a continuación, conserva las filas que tienen un campo de gravedad. A continuación, la consulta agrupa las filas por gravedad y cuenta el número de filas de cada grupo:

SELECT
  severity, COUNT(*) AS count
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  severity IS NOT NULL
GROUP BY severity
ORDER BY severity
LIMIT 100

Agrupar por `log_id`

El resultado de la siguiente consulta es una tabla con dos columnas. En la primera columna se muestran los nombres de los registros y, en la segunda, el número de entradas de registro que se han escrito en el registro. La consulta ordena los resultados por el número de entradas:

SELECT
  log_id, COUNT(*) AS count
FROM
  `TABLE_NAME_OF_LOG_VIEW`
GROUP BY log_id
ORDER BY count DESC
LIMIT 100

Calcula la latencia media de las solicitudes HTTP.

La siguiente consulta muestra cómo agrupar por varias columnas y calcular un valor medio. La consulta agrupa las filas por la URL contenida en la solicitud HTTP y por el valor del campo labels.checker_location. Después de agrupar las filas, la consulta calcula la latencia media de cada grupo:

SELECT
  JSON_VALUE(labels.checker_location) AS location,
  AVG(http_request.latency.seconds) AS secs, http_request.request_url
FROM
  `TABLE_NAME_OF_LOG_VIEW`
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

En la expresión anterior, JSON_VALUE es obligatorio para extraer el valor del campo labels.checker_location porque el tipo de datos de labels es JSON. Sin embargo, no se usa esta función para extraer el valor del campo http_request.latency.seconds. Este último campo tiene el tipo de datos entero.

Calcula la media de bytes enviados en una prueba de subred.

La siguiente consulta muestra cómo se puede mostrar el número medio de bytes enviados por ubicación.

La consulta lee los datos de la última hora y, a continuación, conserva solo las filas cuya columna de tipo de recurso sea gce_subnetwork y cuya columna json_payload no sea NULL. A continuación, la consulta agrupa las filas por la ubicación del recurso. A diferencia del ejemplo anterior, en el que los datos se almacenan como un valor numérico, el valor del campo bytes_sent es una cadena. Por lo tanto, debe convertir el valor a FLOAT64 antes de calcular la media:

SELECT JSON_VALUE(resource.labels.location) AS location,
   AVG(CAST(JSON_VALUE(json_payload.bytes_sent) AS FLOAT64)) AS bytes
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  resource.type = "gce_subnetwork" AND
  json_payload IS NOT NULL
GROUP BY location
LIMIT 100

El resultado de la consulta anterior es una tabla en la que cada fila muestra una ubicación y el número medio de bytes enviados desde esa ubicación.

Para obtener información sobre todas las funciones que pueden recuperar y transformar datos JSON, consulta Funciones JSON.

Para obtener información sobre CAST y otras funciones de conversión, consulte Funciones de conversión.

Contar las entradas de registro con un campo que coincida con un patrón

Para devolver la subcadena que coincide con una expresión regular, usa la función REGEXP_EXTRACT. El tipo de valor devuelto de esta función es STRING o BYTES.

La siguiente consulta conserva las entradas de registro cuyo valor del campo json_payload.jobName no es NULL. Después, agrupa las entradas por el sufijo de nombre que empieza por test. Por último, la consulta cuenta el número de entradas de cada grupo:

SELECT
  REGEXP_EXTRACT(JSON_VALUE(json_payload.jobName), r".*(test.*)$") AS name,
  COUNT(*) AS count
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  json_payload.jobName IS NOT NULL
GROUP BY name
ORDER BY count
LIMIT 20

Para ver más ejemplos, consulta la documentación de REGEXP_EXTRACT. Para ver ejemplos de otras expresiones regulares que puedes usar, consulta Funciones, operadores y condicionales.

Búsqueda en varias columnas

En esta sección se describen dos enfoques diferentes que puedes usar para buscar en varias columnas de una tabla.

Búsqueda basada en tokens

Para buscar en una vista de registro las entradas que coincidan con un conjunto de términos de búsqueda, usa la función SEARCH. Esta función requiere dos parámetros: dónde buscar y la consulta de búsqueda. Como la función SEARCH tiene reglas específicas sobre cómo se buscan los datos, te recomendamos que leas la documentación de SEARCH.

La siguiente consulta solo conserva las filas que tienen un campo que coincide exactamente con "35.193.12.15":

SELECT
  timestamp, log_id, proto_payload, severity, resource.type, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW` 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

En la consulta anterior, las comillas inversas rodean el valor que se va a buscar. De esta forma, la función SEARCH busca una coincidencia exacta entre el valor de un campo y el valor entre las comillas inversas.

Si se omiten las comillas inversas en la cadena de consulta, esta se dividirá según las reglas definidas en la documentación de SEARCH. Por ejemplo, cuando se ejecuta la siguiente instrucción, la cadena de consulta se divide en cuatro tokens: "35", "193", "12" y "15":

  SEARCH(t,"35.193.12.15")

La instrucción SEARCH anterior coincide con una fila cuando un solo campo coincide con los cuatro tokens. El orden de los tokens no importa.

Puedes incluir varias instrucciones SEARCH en una consulta. Por ejemplo, en la consulta anterior, puedes sustituir el filtro del ID de registro por una instrucción como la siguiente:

  SEARCH(t,"`cloudaudit.googleapis.com/data_access`")

La instrucción anterior busca en todos los campos de las entradas de registro de la vista de registro, mientras que la instrucción original solo busca en el campo log_id de las entradas de registro.

Para hacer varias búsquedas en varios campos, separa las cadenas individuales con un espacio. Por ejemplo, la siguiente instrucción coincide con las filas en las que un campo contiene "Hello World", "happy" y "days":

  SEARCH(t,"`Hello World` happy days")

Por último, puedes buscar campos específicos en lugar de buscar en una tabla completa. Por ejemplo, la siguiente instrucción solo busca en las columnas text_payload y json_payload:

   SEARCH((text_payload, json_payload) ,"`35.222.132.245`")

Para obtener información sobre cómo se procesan los parámetros de la función SEARCH, consulta la página de referencia de BigQuery Funciones de búsqueda.

Búsqueda de subcadenas

Para realizar una prueba que no distinga entre mayúsculas y minúsculas para determinar si un valor existe en una expresión, usa la función CONTAINS_SUBSTR. Esta función devuelve TRUE cuando el valor existe y FALSE en caso contrario. El valor de búsqueda debe ser un literal STRING, pero no el literal NULL.

Por ejemplo, la siguiente consulta obtiene todas las entradas de registro de auditoría de acceso a los datos con una dirección IP específica cuyas marcas de tiempo se encuentran en un intervalo de tiempo concreto. Por último, la consulta ordena los resultados y muestra los 20 más antiguos:

SELECT
  timestamp, log_id, proto_payload, severity, resource.type, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW` 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

La consulta anterior realiza una prueba de subcadena. Por lo tanto, una fila que contenga "35.193.12.152" coincide con la instrucción CONTAINS_SUBSTR.

Combinar datos de varias fuentes

Las instrucciones de consulta analizan una o varias tablas o expresiones y devuelven las filas de resultados calculadas. Por ejemplo, puede usar instrucciones de consulta para combinar los resultados de instrucciones SELECT en diferentes tablas o conjuntos de datos de varias formas y, a continuación, seleccionar las columnas de los datos combinados.

Combinar datos de dos tablas con uniones

Para combinar información de dos tablas, usa uno de los operadores de unión. El tipo de unión y la cláusula condicional que uses determinarán cómo se combinan y se descartan las filas.

La siguiente consulta te proporciona los campos json_payload de las filas de dos tablas diferentes escritas por el mismo intervalo de traza. La consulta realiza una unión internaJOIN en dos tablas para obtener las filas en las que coinciden los valores de las columnas span_id y trace de ambas tablas. A partir de este resultado, la consulta selecciona los campos timestamp, severity y json_payload que proceden de TABLE_NAME_OF_LOG_VIEW_1, el campo json_payload de TABLE_NAME_OF_LOG_VIEW_2 y los valores de los campos span_id y trace en los que se han combinado las dos tablas, y devuelve hasta 100 filas:

SELECT
  a.timestamp, a.severity, a.json_payload, b.json_payload, a.span_id, a.trace
FROM `TABLE_NAME_OF_LOG_VIEW_1` a
JOIN `TABLE_NAME_OF_LOG_VIEW_2` b
ON
  a.span_id = b.span_id AND
  a.trace = b.trace
LIMIT 100

Combinar varias selecciones con uniones

Para combinar los resultados de dos o más instrucciones SELECT y descartar las filas duplicadas, usa el operador UNION. Para conservar las filas duplicadas, usa el operador UNION ALL.

La siguiente consulta lee los datos de la última hora de TABLE_NAME_OF_LOG_VIEW_1, combina el resultado con los datos de la última hora de TABLE_NAME_OF_LOG_VIEW_2, ordena los datos combinados por marca de tiempo creciente y, a continuación, muestra las 100 entradas más antiguas:

SELECT
  timestamp, log_name, severity, json_payload, resource, labels
FROM(
  SELECT * FROM `TABLE_NAME_OF_LOG_VIEW_1`
  UNION ALL
  SELECT * FROM `TABLE_NAME_OF_LOG_VIEW_2`
)
ORDER BY timestamp ASC
LIMIT 100

Eliminar entradas de registro duplicadas

Log Analytics no elimina las entradas de registro duplicadas antes de ejecutar una consulta. Este comportamiento es diferente al que se produce cuando consultas entradas de registro mediante el Explorador de registros, que elimina las entradas duplicadas comparando los campos de nombre de registro, marca de tiempo e ID de inserción.

Puedes usar la validación a nivel de fila para eliminar las entradas de registro duplicadas.

Para obtener más información, consulta Solución de problemas: hay entradas de registro duplicadas en mis resultados de Log Analytics.

Limitaciones

Las consultas que se usan en la página Analíticas de registros admiten funciones de GoogleSQL, con algunas excepciones.

Los siguientes comandos de SQL no se admiten en las consultas de SQL que se envían mediante la página Analíticas de registros:

Comandos DDL y DML
Funciones definidas por el usuario de JavaScript
Funciones de BigQuery ML
Variables de SQL

Solo se admiten las siguientes opciones cuando se consulta un conjunto de datos vinculado mediante las páginas BigQuery Studio y Looker Studio, y la herramienta de línea de comandos bq:

Funciones definidas por el usuario de JavaScript
Funciones de BigQuery ML
Variables de SQL

Siguientes pasos

Para obtener información sobre cómo enrutar y almacenar entradas de registro, consulta los siguientes documentos:

Para consultar la documentación de referencia de SQL, consulta los siguientes documentos: