Seguimiento de consultas distribuidas en Base de datos ilimitada de Aurora PostgreSQL
El seguimiento de consultas distribuidas es una herramienta para hacer el seguimiento y correlacionar las consultas en los registros de PostgreSQL en Base de datos ilimitada de Aurora PostgreSQL. En Aurora PostgreSQL, se utiliza el ID de transacción para identificar una transacción. Sin embargo, en Base de datos ilimitada de Aurora PostgreSQL, el ID de transacción puede repetirse en varios enrutadores. Por lo tanto, recomendamos que utilice el ID de seguimiento en Base de datos ilimitada.
A continuación se muestran casos de uso claves:
-
Utilice la función
rds_aurora.limitless_get_last_trace_id()
para buscar el ID de seguimiento único de la última consulta ejecutada en la sesión actual. A continuación, busque el grupo de registros del clúster de base de datos en Registros de Amazon CloudWatch con ese ID de seguimiento para encontrar todos los registros relacionados.Puede usar los parámetros
log_min_messages
ylog_min_error_statement
juntos para controlar el volumen de registros impresos e imprimir una instrucción que contenga el ID de seguimiento. -
Utilice el parámetro
log_min_duration_statement
para determinar el tiempo de ejecución a partir del cual todas las consultas imprimen su duración de ejecución y su ID de seguimiento. Luego, este tiempo de ejecución se puede buscar en el grupo de registros del clúster de base de datos de Registros de CloudWatch para ayudar a determinar los nodos con cuello de botella y los esfuerzos de optimización del planificador.El parámetro
log_min_duration_statement
habilita el ID de seguimiento de todos los nodos, independientemente de los valores delog_min_messages
y los parámetroslog_min_error_statement
.
ID de seguimiento
El elemento central de esta característica es un identificador único conocido como ID de seguimiento. El ID de seguimiento es una cadena de 31 dígitos que se asocia a las líneas de registro STATEMENT de los registros de PostgreSQL y que actúa como un identificador preciso para correlacionar los registros relacionados con una ejecución de una consulta específica. Algunos ejemplos son 1126253375719408504000000000011
y 1126253375719408495000000000090
.
El ID de seguimiento se compone de lo siguiente:
-
Identificador de la transacción: los primeros 20 dígitos, que identifican de forma exclusiva la transacción.
-
Identificador del comando: los primeros 30 dígitos, que identifican una consulta individual dentro de una transacción.
Si se ejecutan más de 4 294 967 294 consultas dentro de un bloque de transacciones explícito, el identificador del comando se reduce a
1
. Si ocurre esto, recibirá una notificación mediante el siguiente mensajeLOG
en el registro de PostgreSQL:wrapping around the tracing ID back to 1 after running 4294967294 (4.2 billion or 2^32-2) queries inside of an explicit transaction block
-
Identificador del tipo de nodo: es el último dígito que indica si el nodo funciona como enrutador coordinador (
1
) o nodo participante (0
).
En los siguientes ejemplos se ilustran los componentes del ID de seguimiento:
-
1126253375719408504000000000011
:-
Identificador de la transacción:
1126253375719408504
-
Identificador del comando:
112625337571940850400000000001
indica el primer comando del bloque de transacciones -
Identificador de tipo de nodo:
1
indica un enrutador coordinador
-
-
1126253375719408495000000000090
:-
Identificador de la transacción:
1126253375719408495
-
Identificador del comando:
112625337571940849500000000009
indica el noveno comando del bloque de transacciones -
Identificador de tipo de nodo:
0
indica un nodo participante
-
Uso del seguimiento de consultas
Realice las siguientes tareas para utilizar el seguimiento de consultas:
-
Asegúrese de que el seguimiento esté habilitado.
Puede utilizar este comando para realizar la comprobación:
SHOW rds_aurora.limitless_log_distributed_trace_id;
Está habilitado de forma predeterminada (
on
). Si no está habilitado, configúrelo con el comando siguiente:SET rds_aurora.limitless_log_distributed_trace_id = on;
-
Controle el volumen de registros a imprimir configurando el nivel de gravedad del registro.
El volumen de registros lo controla el parámetro
log_min_messages
. El parámetrolog_min_error_statement
se utiliza para imprimir la líneaSTATEMENT
con el ID de seguimiento. Ambos se establecen enERROR
de forma predeterminada. Puede utilizar estos comandos para realizar la comprobación:SHOW log_min_messages; SHOW log_min_error_statement;
Para actualizar el nivel de gravedad e imprimir la línea
STATEMENT
de la sesión actual, utilice los siguientes comandos con uno de estos niveles de gravedad:SET log_min_messages = '
DEBUG5
|DEBUG4
|DEBUG3
|DEBUG2
|DEBUG1
|INFO
|NOTICE
|WARNING
|ERROR
|LOG
|FATAL
|PANIC
'; SET log_min_error_statement = 'DEBUG5
|DEBUG4
|DEBUG3
|DEBUG2
|DEBUG1
|INFO
|NOTICE
|WARNING
|ERROR
|LOG
|FATAL
|PANIC
';Por ejemplo:
SET log_min_messages = 'WARNING'; SET log_min_error_statement = 'WARNING';
-
Habilite la impresión del ID de seguimiento en los registros por encima de un tiempo de ejecución específico.
El parámetro
log_min_duration_statement
se puede cambiar al tiempo mínimo de ejecución de la consulta por encima del cual la consulta imprime una línea de registro con la duración de la ejecución, junto con los ID de seguimiento en todo el clúster de base de datos. Este parámetro está configurado en-1
de forma predeterminada, lo que significa que está deshabilitado. Puede utilizar este comando para realizar la comprobación:SHOW log_min_duration_statement;
Al cambiarlo a
0
, se imprimen la duración y el ID de seguimiento en los registros de cada consulta del clúster de base de datos. Puede configurarlo en0
para la sesión actual mediante el siguiente comando:SET log_min_duration_statement = 0;
-
Obtenga el ID de seguimiento.
Tras ejecutar una consulta (incluso dentro de un bloque de transacciones explícito), llame a la función
rds_aurora.limitless_get_last_trace_id
para obtener el ID de seguimiento de la última consulta ejecutada:SELECT * FROM rds_aurora.limitless_get_last_trace_id();
Esta función devuelve el identificador de la transacción y el identificador del comando. No devuelve el identificador del tipo de nodo.
=> SELECT * FROM customers; customer_id | fname | lname -------------+-------+------- (0 rows) => SELECT * FROM rds_aurora.limitless_get_last_trace_id(); transaction_identifier | command_identifier ------------------------+-------------------------------- 10104661421959001813 | 101046614219590018130000000001 (1 row)
La función devuelve una línea en blanco para las consultas no distribuidas, ya que no tienen un ID de seguimiento.
=> SET search_path = public; SET => SELECT * FROM rds_aurora.limitless_get_last_trace_id(); transaction_identifier | command_identifier ------------------------+-------------------- | (1 row)
nota
En el caso de las consultas VACUUM y ANALYZE, la instrucción de duración no se registra con el ID de seguimiento. Por lo tanto,
limitless_get_last_trace_id()
no devuelve el ID de seguimiento. Si VACUUM o ANALYZE son una operación de larga duración, puede usar la siguiente consulta para obtener el ID de seguimiento de esa operación:SELECT * FROM rds_aurora.limitless_stat_activity WHERE distributed_tracing_id IS NOT NULL;
Si el servidor se detiene antes de que pueda encontrar el último ID de seguimiento, tendrá que buscar manualmente en los registros de PostgreSQL para encontrar los ID de seguimiento en los registros justo antes de que se produjera el error.
-
Busque el ID de seguimiento en los registros del clúster de base de datos mediante CloudWatch.
Utilice Información de CloudWatch para consultar el grupo de registro del clúster de base de datos, tal como se muestra en los siguientes ejemplos.
-
Busque un identificador de transacción concreto y todos los comandos que se ejecuten dentro de él:
fields @timestamp, @message | filter @message like /10104661421959001813/ | sort @timestamp desc
-
Consulte un identificador de comando concreto:
fields @timestamp, @message | filter @message like /101046614219590018130000000001/ | sort @timestamp desc
-
-
Examine todos los registros del clúster de base de datos generados por la consulta distribuida.
Ejemplos de registro
Los siguientes ejemplos muestran el uso del seguimiento de consultas.
Registros correlacionados para consultas propensas a errores
En este ejemplo, el comando TRUNCATE
se ejecuta en la tabla customers
cuando esa tabla no existe.
- Sin seguimiento de consultas
-
Archivo de registro de PostgreSQL en el enrutador coordinador:
2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[27503]:ERROR: failed to execute remote query 2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[27503]:DETAIL: relation "public.customers" does not exist 2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[27503]:CONTEXT: remote SQL command: truncate public.customers; 2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[27503]:STATEMENT: truncate customers;
Archivo de registro de PostgreSQL en una partición participante:
2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[ 27503]:ERROR: failed to execute remote query 2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[ 27503]:STATEMENT: truncate customers;
Estos registros son típicos. Carecen de los identificadores precisos necesarios para correlacionar fácilmente las consultas en el clúster de base de datos.
- Con seguimiento de consultas
-
Archivo de registro de PostgreSQL en el enrutador coordinador:
2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:ERROR: failed to execute remote query 2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:DETAIL: relation "public.customers" does not exist 2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:CONTEXT: remote SQL command: truncate public.customers; 2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:STATEMENT: /* tid = 1126253375719408502700000000011 */ truncate customers;
Archivo de registro de PostgreSQL en una partición participante:
2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:ERROR: failed to execute remote query 2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:STATEMENT: /* tid = 1126253375719408502700000000010 */ truncate customers;
Si hay un seguimiento de consultas, a cada línea de registro se le añade un identificador único de 31 dígitos. Aquí,
1126253375719408502700000000011
y1126253375719408502700000000010
representan los ID de seguimiento de los nodos coordinador y participante, respectivamente.-
Identificador de la transacción:
11262533757194085027
-
Identificador del comando:
112625337571940850270000000001
-
Identificador del tipo de nodo: el último dígito,
1
o0
, indica un enrutador coordinador y un nodo participante, respectivamente.
-
Correlación de los registros para encontrar el tiempo de ejecución de la consulta en varios nodos
En este ejemplo, el parámetro log_min_duration_statement
se ha actualizado a 0
para imprimir la duración de todas las consultas.
- Sin seguimiento de consultas
-
2024-01-15 07:28:46 UTC:[local]:postgres@postgres_limitless:[178322]:LOG: duration: 12.779 ms statement: select * from customers;
- Con seguimiento de consultas
-
Archivo de registro de PostgreSQL en el enrutador coordinador:
2024-01-15 07:32:08 UTC:[local]:postgres@postgres_limitless:[183877]:LOG: duration: 12.618 ms statement: /* tid = 0457669566240497088400000000011 */ select * from customers;
Archivo de registro de PostgreSQL en una partición participante:
2024-01-15 07:32:08 UTC:localhost(46358):postgres@postgres_limitless:[183944]:LOG: duration: 0.279 ms statement: /* tid = 0457669566240497088400000000010 */ START TRANSACTION ISOLATION LEVEL READ COMMITTED 2024-01-15 07:32:08 UTC:localhost(46358):postgres@postgres_limitless:[183944]:LOG: duration: 0.249 ms parse <unnamed>: SELECT customer_id, fname, lname FROM public.customers 2024-01-15 07:32:08 UTC:localhost(46358):postgres@postgres_limitless:[183944]:LOG: duration: 0.398 ms bind <unnamed>/c1: SELECT customer_id, fname, lname FROM public.customers 2024-01-15 07:32:08 UTC:localhost(46358):postgres@postgres_limitless:[183944]:LOG: duration: 0.019 ms execute <unnamed>/c1: SELECT customer_id, fname, lname FROM public.customers 2024-01-15 07:32:08 UTC:localhost(46358):postgres@postgres_limitless:[183944]:LOG: duration: 0.073 ms statement: /* tid = 0457669566240497088400000000010 */ COMMIT TRANSACTION