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 buggyAmb ASP.NET aplicación Core como proyecto de ejemplo.

Si ha seguido las partes anteriores de esta serie, debe tener listo el siguiente programa de instalación:

• Nginx está configurado para hospedar dos sitios web:
  • La primera escucha las solicitudes mediante el encabezado de host myfirstwebsite (http://myfirstwebsite) y las solicitudes de enrutamiento a la aplicación de demostración ASP.NET Core que escucha en el puerto 5000.
  • El segundo escucha las solicitudes mediante el encabezado de host buggyamb (http://buggyamb) y las solicitudes de enrutamiento a la segunda aplicación de error de ejemplo de ASP.NET Core que escucha en el puerto 5001.
• Ambas aplicaciones ASP.NET Core deben ejecutarse como servicios que se reinicien automáticamente cuando se reinicie el servidor o la aplicación deje 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 "Parte 2 Crear y ejecutar aplicaciones ASP.NET Core".

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

Objetivo de este laboratorio

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

• Parte 1: Reproducirá el problema de bloqueo, comprobará los registros de Nginx y del sistema para buscar los síntomas e indicadores del bloqueo y, a continuación, solucionará el problema mediante la generación de 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 del 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, http://buggyamb/y seleccione el vínculo Páginas de problemas, verá vínculos 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 previsto. Debería ver una salida similar a la 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 mostrará finalmente la misma salida 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 error. 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 resultados siguientes, el PID del proceso que ejecuta el servicio es 2255.

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

Este mensaje le pide al usuario que tenga en cuenta la siguiente pregunta: ¿Esta página hará que el proceso se bloquee? Ejecute el mismo systemctl status buggyamb.service comando y debería ver el mismo PID. Esto indica que no se produjo 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, la selección de Slow debería generar el siguiente mensaje de error.

Incluso si selecciona algún otro vínculo en la página web, experimentará el mismo error durante un breve tiempo. Después de 10 a 15 segundos, todo comenzará a responder como se esperaba de nuevo.

Para comprobar si se cambia el PID, vuelva a ejecutarse systemctl status buggyamb.service . Esta vez, debería observar que el proceso parece haberse detenido porque se cambia el PID. En el ejemplo anterior, el PID del proceso era 2255. En el ejemplo siguiente, se cambia a 2943. Aparentemente, el sitio web hizo bien en su promesa de bloquear el proceso.

Solución de problemas de los pasos de reproducción

Este es un resumen de los pasos de reproducción:

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. Recibirá un mensaje de error "HTTP 502 - Puerta de enlace incorrecta" en lugar de la tabla de productos.
3. Una vez iniciado el problema, ninguna de las páginas se representa durante los próximos 10-15 segundos.
4. Después de 10 a 15 segundos, la aplicación comienza a responder correctamente.

El mensaje de error "HTTP 502 - Puerta de enlace incorrecta" por sí solo 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 en la aplicación ASP.NET Core. Por lo tanto, este error de Nginx indica que no pudo llegar a la aplicación back-end cuando reenviaba las solicitudes entrantes.

Comprobación de que Nginx funciona correctamente

Antes de continuar, es posible que quiera comprobar si Nginx funciona correctamente. Este paso no es obligatorio porque sabe que la aplicación se bloquea. Sin embargo, todavía puede comprobar el estado de Nginx comprobando los registros de Nginx. Ha aplicado 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. Estos se almacenan en la /var/log/nginx/ carpeta .

Los registros de acceso son como los archivos de registro de IIS. Abra y examinelos, tal como 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 buggy se cerró antes de enviar la respuesta final.

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

Comprobación de los registros del sistema mediante el comando journalctl

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

Dado que la aplicación de buggy 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 los registros de eventos del sistema en Windows. El journalctl comando se usa para ver y manipular los registros del sistema.

Puede ejecutar el journalctl comando sin modificadores para ver todos los registros. Sin embargo, la salida 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"

Están disponibles los siguientes conmutadores:

• -r: imprima los registros en orden inverso para que el más reciente aparezca primero.
• --identifier: recuerde la SyslogIdentifier=buggyamb-identifier línea del archivo de servicio de la aplicación de prueba. (Puede usarlo para forzar los registros a mostrar solo las entradas que se aplican a la aplicación problemática).
• --since: muestra información registrada 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 mediante las teclas de dirección. Encontrará una System.Net.WebException excepción.

Si examina detenidamente los registros, verá el nombre del archivo de código y el número de línea en el que se produjo el problema. En 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 aprender la causa del bloqueo.

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

Recuerde parte del comportamiento del sistema clave cuando finaliza un proceso:

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

Aunque el comportamiento predeterminado es para que el sistema genere un archivo de volcado de núcleo, esta configuración se puede sobrescribir en /proc/sys/kernel/core_pattern para canalizar directamente el archivo de volcado de núcleo resultante 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 memoria principal en Ubuntu. El core_pattern archivo se sobrescribe para canalizar el volcado de núcleo a apport.

Apport usa /var/crash la 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 de memoria principal. Se trata de un archivo de informe que contiene varios fragmentos de información junto con el archivo de volcado de memoria. Tiene que desempaquetar este archivo para obtener el archivo de volcado principal.

Cree una carpeta dumps en la carpeta principal. Se le pedirá que extraiga allí el informe. 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.

La extracción del archivo de volcado de núcleo generado automáticamente puede ser un proceso complicado. En el siguiente laboratorio, verá que es más fácil capturar archivos de volcado de núcleo mediante createdump.

Pasos siguientes

Lab 1.2 Abra y analice los archivos de volcado de núcleo 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.