60 segundos para localizar el problema, diez veces la rutina de depuración del programador

Autor: Tao Jianhui

Este es un blog interno que escribí en mayo de 2020. En ese momento, esperaba que los estudiantes de I + D y soporte técnico pudieran ayudar a los usuarios a localizar errores y resolver problemas rápidamente. En diciembre de 2020, iteré otra versión y también realicé capacitación interna sobre esto. Durante este período de tiempo, también presté atención a las preguntas en el grupo de WeChat y descubrí que muchos usuarios sienten que es difícil analizar los registros de TEngine o cualquier otro sistema distribuido. Ahora haré público este blog. Tomando el análisis de los registros de TEngine como ejemplo, presentaré un conjunto de métodos. Si puede dominarlo, analizar los registros de los sistemas distribuidos será extremadamente simple.

TEngine es un sistema de clúster, cualquier operación involucrará nodos lógicos como APP, taosc, mnode y vnode. La comunicación entre estos nodos es a través de Socket. Además, en una prueba, puede haber varias instancias de TEngine, lo que complica el análisis. Para una operación, cómo coludir la coincidencia de registros de diferentes nodos lógicos y filtrarlos y procesarlos de manera eficiente se convierte en la clave para analizar el problema.

Este artículo resume un conjunto de métodos que le permiten encontrar rápidamente dónde está el error.

Encienda el interruptor de registro correspondiente

Cada módulo independiente de TEngine tiene su propio debugFlag, incluidos taosc, dnode, vnode, mnode, tsdb, wal, sync, query, rpc, timer, etc. Actualmente, la salida de registro de cada módulo se puede controlar para:

• Fatal/Error, error, ERROR se mostrará en el registro
• Advertencia, advertencia, WARN se mostrará en el registro
• Información, información importante
• Depuración, información general
• Seguimiento, información de depuración muy detallada y recurrente
• Volcado, datos sin procesar

El registro de salida puede controlar la salida para:

• documento
• Pantalla

Todo el control anterior está controlado por un byte de debugFlag. El mapa de bits en este byte es el siguiente:

Por lo tanto, si desea generar errores, advertencias, información y depuración en el archivo de registro, la depuración debe establecerse en: 135; si también desea generar registros de nivel de seguimiento, la depuración debe establecerse en: 143; si solo se emiten errores y advertencias, depuración Establecido en 131. En circunstancias normales, se recomienda establecer la depuración en 135 .

La configuración del indicador de depuración de cada módulo está controlada por el archivo de configuración taos.cfg. Los parámetros específicos de cada módulo y el nombre del módulo que se muestra en el registro son los siguientes:

Si cree que hay demasiados parámetros de configuración, la forma más fácil es establecer el parámetro general debugFlag de debug.Después de establecer este parámetro, a excepción del registro tmr, las depuraciones de todos los módulos se establecen uniformemente en el mismo parámetro debugFlag. El valor predeterminado de debugFlag es 0. Cuando debugFlag es un valor distinto de cero, anulará todos los parámetros de configuración de registro.
A menos que haya casos especiales, no se recomienda configurar util, el indicador de depuración del temporizador es 135 y 131 es apropiado.

archivo de registro

TEngine generará registros de cliente y servidor y los almacenará en el directorio de registro. El directorio de registro predeterminado es /var/log/taos, pero se puede especificar modificando el parámetro de configuración logDir en taos.cfg

• El archivo de registro del cliente se llama taoslogY.X (porque se pueden ejecutar varios clientes, por lo que se pueden generar varios archivos de registro en una máquina)
• El archivo de registro del lado del servidor es taosdlog.X

El tamaño del archivo de registro está controlado.Después de alcanzar un cierto número de líneas (controlado por el parámetro de configuración numOfLogLines en taos.cfg), se generará un nuevo archivo de registro. Pero TEngine solo guarda dos archivos de registro con nombres de archivo que terminan en 0 o 1, alternativamente.

formato de registro:

El archivo de registro, de izquierda a derecha, se divide en cuatro bloques

1. Marca de tiempo, precisa al microsegundo
2. Id. de subproceso, debido a que es multiproceso, este parámetro es muy importante, porque solo los registros generados por el mismo subproceso tienen una temporización garantizada y se emiten de acuerdo con el flujo diseñado
3. Nombre del módulo, tres letras
4. registro de salida por cada módulo

Varios pasos para analizar registros

Cuando una prueba o un cliente informa un error, ya sea de forma manual o automática, ocurre al realizar una acción específica. Esta operación específica generalmente ejecuta una declaración SQL. Este problema puede ser causado por el cliente o por el código del servidor. A continuación se utiliza crear tabla como ejemplo para explicar el análisis del registro. Para facilitar la explicación enfocada, la marca de tiempo se elimina de la figura.

Primero mira al cliente

Lo primero que debe observar es el registro del cliente. La captura de pantalla de muestra es la siguiente:

1. Primero busque la instrucción SQL en cuestión, busque "SQL:" en el registro del cliente y podrá verla (la segunda línea de la captura de pantalla). Busque en el registro "Resultado de SQL:" (línea 11 de la captura de pantalla), si tiene éxito, mostrará "Resultado de SQL: éxito", de lo contrario, mostrará "Resultado de SQL: xxxx", donde xxxx es el mensaje de error. Cómo encontrar rápidamente el SQL fallido, necesita saber el rango de tiempo aproximado y cuál es la declaración SQL, por lo que la búsqueda será muy rápida.
2. En los datos de registro de taoc, un parámetro muy importante es pSql, que es una dirección asignada al SQL Obj interno. taosc coloca esta información de dirección en la parte superior de todos los registros de taosc, inmediatamente después de TSC. Este valor es crítico y es la clave para los registros tradicionales de clientes y servidores. En la captura de pantalla anterior, está marcado con un fondo verde.
3. El parámetro pSql se pasará al módulo RPC como identificador y RPC lo imprimirá (fondo verde) en todos los mensajes. Debido a que muchos módulos llamarán al módulo RPC, RPC también imprimirá quién lo llamó. Por ejemplo, en la captura de pantalla, el TSC lo llama y se imprimirá el RPC TSC.
4. RPC enviará el mensaje create-table al servidor, y se imprimirá el registro de RPC (línea 8 de la captura de pantalla), indicando a qué punto final de dnode se envía. La captura de pantalla muestra que se envía al nombre de host: 9be7010a917e, y el puerto es 6030. Si hay un problema, debemos verificar el registro del servidor donde se encuentra este punto final.
5. Se puede ver que el módulo RPC recibió la respuesta del servidor, pero para evitar el consumo de recursos por la conversión, el registro solo muestra la dirección IP hexadecimal (línea 9 de la captura de pantalla, 0x20012ac) y el número de puerto. El registro del módulo RPC es fundamental porque une los nodos lógicos.

mira el servidor

Después de analizar el registro del cliente, el registro del servidor es muy importante. Lo siguiente todavía toma create-table como ejemplo, vea la captura de pantalla:

1. Desde el registro del cliente, busque pSql, el valor es 0x5572c4fab3a0, así que busque directamente 0x5572c4fab3a0 en taosdlog, puede ver el registro con fondo verde en la captura de pantalla. Por lo tanto, pSql es un parámetro muy importante para unir los registros del cliente y del servidor.
2. Para la operación específica de crear tabla, existe el procesamiento de mnode. En la captura de pantalla, debido a que se crea la primera tabla, primero es necesario crear un vnode y luego crear una serie de operaciones, como una tabla, que involucra muchos módulos, por lo que no lo explicaré en detalle.
3. Finalmente, después de que mnode crea la tabla, envía la respuesta a través del módulo RPC (línea 52 de la captura de pantalla, la última línea), por lo que se puede ver claramente que el servidor está funcionando correctamente.

Nota: Después de que el módulo dnode reciba el mensaje, lo distribuirá a las colas de mensajes de mnode y vnode según el tipo de mensaje. Luego, el subproceso de trabajo consumirá el mensaje en la cola de mensajes y procesará el mensaje. Para vnode, los submódulos tsdb, wal, sync y cq se ejecutan en un solo subproceso, por lo que después de encontrar pSql (la segunda línea de la captura de pantalla), debe mirar hacia abajo en orden según el ID del subproceso y se puede conocer todo el proceso está bien analizado.

algunos puntos clave

1. Encuentre primero la instrucción SQL fallida
2. Encuentre el valor de pSql y cópielo, asumiendo que es xxxxx
3. grep "xxxxx" taoslogx.x, encuentre el registro del cliente relacionado con este SQL, vea si puede encontrar el problema
4. Abra el registro del servidor taosdlog, busque el valor xxxxx de pSql, verifique la marca de tiempo para ver si es la operación fallida
5. Luego analice el registro del servidor

Los mensajes del módulo RPC son críticos. Es muy importante que para cada mensaje RPC se imprima el código de análisis: xx, que es el resultado del análisis del protocolo, 0 significa que no hay problema y otros valores indican que el análisis del protocolo no se realizó correctamente. Pero al mismo tiempo, el mensaje en sí también tiene código: 0xXX, que es el código de error que trae el remitente, que generalmente es enviado por el servidor al cliente, si es correcto, el código es 0, de lo contrario, informará un error.

Otro método de coincidencia de registros

Cuando un cliente envía un mensaje a través del módulo RPC, el registro muestra algo como

firma: 0x01000000: 0x01000000: 55893

Este es el ID de origen, el ID de destino y el ID de transacción de la RPC. Combinados, los tres parámetros pueden identificar de forma única un enlace de un cliente. Cada nuevo mensaje que se envía, la identificación de la transacción se incrementará en uno, por lo que es única por un período de tiempo (la identificación de la transacción es de dos bytes y será cíclica).

La versión 1.6 solo puede confiar en la cadena de firma para que coincida con los registros del cliente y del servidor, pero necesita ver mucho contexto, por lo que es problemático e ineficiente.

La versión 2.0 transfiere pSql al lado del servidor, por lo que la coincidencia de registros entre el cliente y el servidor se acelerará considerablemente.

Cómo familiarizarse con los registros

1. Primero, comprenda el diseño de TEngine y comprenda el flujo de cada operación principal.
2. Encienda todos los interruptores de registro (establezca debugFlag en 135), ejecute todas las instrucciones SQL una vez y verifique los registros de cliente y servidor correspondientes con cada SQL.

Ver la sentencia SQL ejecutada por el cliente

El cliente generará una gran cantidad de registros para ver la instrucción SQL ejecutada, que es fácil de analizar y repetir el problema. Hay varias formas de averiguar qué tipo de instrucción SQL ejecutó el sistema

1. Si el registro del cliente está activado, ejecute: grep “SQL:” taoslog*, verá todas las instrucciones SQL ejecutadas en el registro.
2. Si usa taos para ejecutar instrucciones SQL manualmente, verifique el archivo oculto .taos_history en el directorio de inicio, que contiene todos los comandos históricos ejecutados por taos.
3. Configure el cliente En el archivo de configuración, establezca el parámetro tscEnableRecordSql en 1, es decir, imprima la declaración SQL ingresada por el cliente en un archivo separado (tscnote-xxxx.0, donde xxxx es el pid), que es el mismo directorio como el registro del cliente.
4. Para la interfaz de restablecimiento, establezca el parámetro httpEnableRecordSql en 1 en el archivo de configuración taosd y la solicitud htpp se imprimirá en un archivo separado (httpnote.0), que es el mismo directorio que el registro del servidor.

Registro de modificación dinámica

A veces, el servidor o el cliente no se pueden reiniciar, pero la configuración de registro es incorrecta. En este momento, se requieren configuraciones dinámicas. Realice los siguientes pasos:

show dnodes; // Encuentra el ID de cada dnode 
alter dnode id debugFlag 143; // Establece el debugFlag correspondiente

El id del segundo paso se obtiene en el primer paso.

A veces es necesario generar registros posteriores en un nuevo archivo para facilitar la visualización y búsqueda de registros.

alterar dnode id resetlog;

A veces, el shell no se puede vincular en absoluto. En este momento, puede enviar el comando SIGUSR1 al proceso en la máquina que ejecuta taosd, como:

matar -SIGUSR1 pidxxx

El texto original se publicó por primera vez en: https://mp.weixin.qq.com/s/LUz1niYajOR35UpOlfszIQ

{{o.nombre}}

{{m.nombre}}