Laboratorio 1.1 Reproducir y solucionar un problema de bloqueo

Se aplica a:   .NET Core 2.1, .NET Core 3.1, .NET 5

En este artículo se presenta el proceso de reproducción del problema de bloqueo de .NET Core en Linux. En este artículo también se describe cómo comprobar la herramienta Nginx y los registros del sistema en busca de síntomas e indicaciones del bloqueo.

Requisitos previos

El requisito mínimo para seguir estos laboratorios de solución de problemas es tener una aplicación ASP.NET Core para demostrar problemas de bajo rendimiento de CPU y CPU alta.

Puede encontrar varias aplicaciones de ejemplo para lograr este objetivo en Internet. Por ejemplo, puede descargar y configurar el ejemplo de webapi simple de Microsoft para demostrar un comportamiento no deseado. O bien, puede usar la aplicación ASP.NET Core BuggyAmb como proyecto de ejemplo.

Si ha seguido las partes anteriores de esta serie, debe tener lista la siguiente configuración:

• Nginx está configurado para hospedar dos sitios web:
  • El primero escucha las solicitudes mediante el encabezado de host myfirstwebsite ( ) y las solicitudes de enrutamiento a la aplicación de demostración ASP.NET Core que escucha en el puerto http://myfirstwebsite 5000.
  • El segundo escucha las solicitudes mediante el encabezado de host de buggyamb ( ) y las solicitudes de enrutamiento ASP.NET Core la segunda aplicación de ejemplo de errores que escucha en el puerto http://buggyamb 5001.
• Ambas ASP.NET Core deben ejecutarse como servicios que se reinician automáticamente cuando se reinicia el servidor o la aplicación deja de responder.
• El firewall local de Linux está habilitado y configurado para permitir el tráfico SSH y HTTP.

Nota

Si la configuración no está lista, vaya a "Part 2 Create and run ASP.NET Core apps."

Para continuar con este laboratorio, debe tener al menos una aplicación ASP.NET Core web problemática que se ejecute detrás de Nginx.

Objetivo de este laboratorio

Este artículo es el primero de dos partes de laboratorio. El trabajo de laboratorio se divide de la siguiente manera:

• Parte 1: Reproducirá el problema de bloqueo, comprobará Nginx y los registros del sistema para buscar los síntomas e indicadores de bloqueo y, a continuación, solucionará problemas generando un archivo de volcado de memoria. Por último, recopilará el archivo de volcado de núcleo generado por el sistema del informe de bloqueo generado por el administrador de Ubuntu, apport.

• Parte 2:Instalará y configurará lldb para que funcione junto con una extensión de depurador de .NET Core denominada SOS. También analizará el archivo de volcado en lldb.

Reproducir un problema de bloqueo

Cuando vaya a la dirección URL del sitio y seleccione el vínculo Páginas de problemas, verá vínculos http://buggyamb/ a algunos escenarios de problemas. Hay tres escenarios de bloqueo diferentes. Sin embargo, para este laboratorio, solo solucionará el tercer escenario de bloqueo.

Antes de seleccionar cualquier vínculo, seleccione Resultados esperados y compruebe que la aplicación funciona según lo esperado. Debería ver un resultado similar al siguiente.

La página debe cargarse rápidamente (en menos de un segundo) y mostrar una lista de productos.

Para probar el primer escenario de "página lenta", seleccione el vínculo Lento. La página finalmente mostrará el mismo resultado que la página Resultados esperados, pero se representará mucho más lentamente de lo esperado.

Antes de reproducir el problema de bloqueo, anote el identificador de proceso de la aplicación de errores. Usará esta información para comprobar que la aplicación se reinicia. Ejecute el systemctl status buggyamb.service comando para obtener el PID actual. En los siguientes resultados, el PID del proceso que ejecuta el servicio es 2255.

Seleccione el vínculo Bloquear 3. La página se carga y muestra el siguiente mensaje:

Este mensaje pide al usuario que tenga en cuenta la siguiente pregunta: ¿Esta página hará que el proceso se desplome? Ejecute el mismo systemctl status buggyamb.service comando y debería ver el mismo PID. Esto indica que no se ha producir un bloqueo.

Seleccione Resultados esperados y, a continuación, seleccione Lento. Aunque debería ver la página correcta después de seleccionar Resultados esperados, seleccionar Lento debería generar el siguiente mensaje de error.

Incluso si seleccionas cualquier otro vínculo en la página web, experimentarás el mismo error durante un breve período de tiempo. Después de 10-15 segundos, todo empezará a responder como se esperaba de nuevo.

Para comprobar si se ha cambiado el PID, vuelva a systemctl status buggyamb.service ejecutarlo. En esta ocasión, debe observar que el proceso parece que se detuvo porque se cambió el PID. En el ejemplo anterior, el PID del proceso era 2255. En el siguiente ejemplo, se cambia a 2943. Al parecer, el sitio web cumplió su promesa de bloquear el proceso.

Solución de problemas de los pasos de repro

Este es un resumen de los pasos de repro:

1. Seleccione Bloqueo 3. La página se carga correctamente, pero devuelve un mensaje confuso que sugiere que el proceso se bloqueará.
2. Seleccione Lento. Recibe un mensaje de error "HTTP 502 - Bad Gateway" en lugar de la tabla de productos.
3. Después de que se inicie el problema, ninguna de las páginas se representará durante los próximos 10-15 segundos.
4. Después de 10-15 segundos, la aplicación comienza a responder correctamente.

El mensaje de error "HTTP 502 - Bad Gateway" por sí mismo no le indica mucho. Sin embargo, debe proporcionar una primera pista: se trata de un error de proxy y puede producirse si un proxy no puede comunicarse con la aplicación que se ejecuta detrás del proxy. En la configuración propuesta, Nginx funciona como proxy inverso para la ASP.NET Core aplicación. Por lo tanto, este error de Nginx indica que no pudo llegar a la aplicación back-end cuando reenvía las solicitudes entrantes.

Comprobar que Nginx funciona correctamente

Antes de continuar, es posible que desee comprobar si Nginx funciona correctamente. Este paso no es obligatorio porque sabe que la aplicación se bloquea. Sin embargo, puede comprobar el estado de Nginx comprobando los registros Nginx. Ha practicado pasos de solución de problemas similares anteriormente en la sección "Instalación y configuración de Nginx".

Nginx tiene dos tipos de registros: registros de acceso y registros de errores. Se almacenan en la /var/log/nginx/ carpeta.

Los registros de acceso son iguales a los archivos de registro de IIS. Ábralos y examinelos, tal como lo hizo en la sección anterior. Los registros no muestran ninguna información nueva que no sea el código de estado de respuesta "HTTP 502" que ya encontró durante los intentos de navegación en las páginas del sitio.

Inspeccione los registros de errores mediante el cat /var/log/nginx/error.log comando. Este registro es más útil y claro. Muestra que Nginx pudo procesar la solicitud, pero la conexión entre Nginx y la aplicación de errores se cerró antes de enviar la respuesta final.

Este registro indica claramente que lo que ve no es un problema de Nginx.

Comprobar los registros del sistema mediante el comando journalctl

Si la ASP.NET Core se bloquea, los síntomas deben aparecer en algún lugar.

Dado que la aplicación de errores se ejecuta como un servicio del sistema, su operación se registra en los archivos de registro del sistema. Los archivos de registro del sistema son como registros de eventos del sistema en Windows. El journalctl comando se usa para ver y manipular registros systemd.

Puede ejecutar el comando journalctl sin modificadores para ver todos los registros. Sin embargo, el resultado será un archivo grande. Es de su mejor interés aprender a filtrar el contenido. Por ejemplo, puede ejecutar el siguiente comando:

journalctl -r --identifier=buggyamb-identifier --since "10 minute ago"

Los siguientes modificadores están disponibles:

• -r: Imprima los registros en orden inverso para que el más reciente aparezca primero.
• --identifier: recuerde la SyslogIdentifier=buggyamb-identifier línea en el archivo de servicio de la aplicación de prueba. (Puede usar esto para forzar los registros a mostrar solo las entradas que se aplican a la aplicación problemática).
• --since: muestra la información que se registró durante el período anterior especificado. Ejemplo: --since "10 minute ago" o --since "2 hour ago" .

Hay varios modificadores útiles para el journalctl comando que pueden ayudarle a filtrar los registros. Para familiarizarse con este comando, le recomendamos que consulte la página de ayuda ejecutando man journalctl .

Ejecute journalctl -r --identifier=buggyamb-identifier --since today -o cat. Debe observar que se generan algunos mensajes de advertencia.

Para ver los detalles, desplácese hacia abajo con las teclas de flecha. Encontrará una System.Net.WebException excepción.

Si examina de cerca los registros, verá el nombre del archivo de código y el número de línea en el que se produjo el problema. Para este laboratorio, se supone que esta información no está disponible. Esto se debe a que, en escenarios reales, es posible que no pueda recuperar este tipo de información. Por lo tanto, el objetivo es continuar analizando un volcado de memoria para conocer la causa del bloqueo.

Obtener un archivo de volcado de memoria después de un bloqueo

Recuerde algunos de los comportamientos clave del sistema cuando finaliza un proceso:

• De forma predeterminada, se genera un archivo de volcado de memoria.
• El volcado de núcleo se denomina core y se crea en la carpeta de trabajo actual o en la /var/lib/systemd/coredump carpeta.

Aunque el comportamiento predeterminado es que el sistema genere un archivo de volcado de memoria, esta configuración se puede sobrescribir para canalizar directamente el archivo de volcado de núcleo resultante /proc/sys/kernel/core_pattern a otra aplicación. Cuando usó Ubuntu en las partes anteriores de esta serie, aprendió que apport administra la generación de archivos de volcado de datos principales en Ubuntu. El core_pattern archivo se sobrescribe para canalizar el volcado de núcleo a apport.

Apport usa /var/crash una carpeta para almacenar sus archivos de informe. Si inspecciona esta carpeta, debería ver un archivo que ya se generó después de un bloqueo.

Sin embargo, este no es el archivo de volcado principal. Se trata de un archivo de informe que contiene varias partes de información junto con el archivo de volcado. Debe desempaquetar este archivo para obtener el archivo de volcado de datos principal.

Crea una carpeta de volcados en la carpeta principal. Se le indicará que extraiga el informe allí. El comando para desempaquetar el archivo de informe de apport es apport-unpack . Ejecute el siguiente comando:

sudo apport-unpack /var/crash/_usr_share_dotnet_dotnet.33.crash ~/dumps/dotnet

Este comando crea la carpeta /dumps. El apport-unpack comando creará la carpeta /dumps/dotnet. Este es el resultado.

En la carpeta ~/dumps/dotnet, debería ver el archivo de volcado. El archivo se denomina CoreDump y debe tener alrededor de 191 MB.

Extraer el archivo de volcado de memoria generado automáticamente puede ser un proceso engorroso. En el siguiente laboratorio, verá que es más fácil capturar archivos de volcado de datos principales mediante el uso de createdump .

Siguientes pasos

Laboratorio 1.2Abra y analice los archivos de volcado de datos principales generados por el sistema en el depurador de lldb, verá cómo abrir este archivo de volcado en el depurador de lldb para realizar un análisis rápido.