Recopilación de diagnósticos en contenedores de Linux

Las mismas herramientas de diagnóstico que son útiles para diagnosticar problemas de .NET en otros escenarios también funcionan en contenedores. Las herramientas se pueden ejecutar en el mismo contenedor que el proceso de destino, desde el host o desde un contenedor auxiliar.

Uso de herramientas de la CLI de .NET en un contenedor

Estas herramientas se aplican a: ✔️ SDK de .NET Core 3.1 y versiones posteriores

Todas las herramientas de diagnóstico de la CLI dotnet-* pueden funcionar cuando se ejecutan dentro del mismo contenedor que la aplicación que inspeccionan, pero tienen cuidado con estos posibles puntos de problemas:

• Las herramientas que se ejecutan dentro de un contenedor estarán sujetas a límites de recursos de contenedor. Las herramientas se pueden ejecutar lentamente o generar errores si los límites de recursos son demasiado bajos. La mayoría de las herramientas tienen requisitos modestos, pero dotnet-dump y dotnet-gcdump pueden usar considerable memoria y espacio en disco cuando el destino es un proceso que tiene una superficie de memoria grande. dotnet-trace y dotnet-counters también pueden crear archivos grandes si están configurados para capturar una gran cantidad de eventos de seguimiento o datos de serie temporal de métricas.
• dotnet-dump provocará que un proceso auxiliar se ejecute que necesita permisos de ptrace. Linux tiene numerosas opciones de configuración de seguridad que pueden afectar a si esto se realiza correctamente, por lo que, en algunos casos, es posible que tenga que ajustar la configuración de seguridad del contenedor. Consulte las preguntas más frecuentes sobre volcado de memoria para obtener más instrucciones sobre cómo diagnosticar privilegios de seguridad.
• Al ejecutar herramientas dentro del contenedor, puede instalarlas de antemano al compilar el contenedor o descargarlas a petición. Instalarlos con antelación facilita cuando los necesite, pero aumenta el tamaño del contenedor y crea una superficie de ataque más grande que los actores malintencionados podrían intentar aprovechar.

Uso de herramientas de la CLI de .NET en un contenedor sidecar o desde el host

Las herramientas de diagnóstico de la CLI dotnet-* también admiten la ejecución desde el host o en un contenedor "sidecar". Esto evita en gran medida las limitaciones de tamaño, seguridad y recursos de ejecución en el mismo contenedor, pero tiene algunos requisitos adicionales para que las herramientas se comuniquen correctamente.

Al identificar un proceso objetivo para inspeccionar mediante los argumentos de línea de comandos de las herramientas --process-id o --name, se requiere:

1. Los contenedores deben compartir un espacio de nombres de proceso para que las herramientas del contenedor sidecar puedan acceder a los procesos del contenedor de destino.
2. Las herramientas necesitan acceso al socket de dominio de Unix del puerto de diagnóstico que el entorno de ejecución de .NET escribe en el directorio /tmp, por lo que el directorio /tmp debe compartirse entre el contenedor de destino y el contenedor auxiliar a través de un montaje de volumen. Esto puede hacerse, por ejemplo, haciendo que los contenedores compartan un volumen común o un volumen emptyDir de Kubernetes. Si intenta usar las herramientas de diagnóstico de un contenedor sidecar sin compartir el directorio /tmp , obtendrá un error sobre el proceso "no se está ejecutando el entorno de ejecución de .NET compatible".

Si no desea compartir el espacio de nombres del proceso y el directorio /tmp , muchas de las herramientas también admiten una opción de línea de comandos más avanzada --diagnostic-port . Esto le permite especificar directamente la ruta de acceso al puerto de diagnóstico del proceso de destino dentro del sistema de archivos del host o sidecar. El directorio /tmp del contenedor de destino debe asignarse a algún lugar para que exista esta ruta de acceso, pero no tiene que compartirse con el host o sidecar /tmp.

Nota:

Incluso cuando se ejecutan las herramientas de diagnóstico desde el host o sidecar, podría ser solicitado que el proceso de destino continúe trabajando, lo que aumente su consumo de recursos dentro del contenedor de destino. Hemos observado dotnet-dump puede provocar que el proceso de destino se pagina en memoria virtual sustancial al recopilar un volcado de memoria. Otras herramientas pueden causar impactos más pequeños, aunque no hemos visto estos problemas en la práctica. Por ejemplo, dotnet-trace solicita al proceso de destino que asigne un búfer de eventos y dotnet-counters solicite una pequeña región de memoria donde se agregan los datos de métricas. Recomendamos realizar pruebas para asegurarse de que los límites de memoria no son tan ajustados que la ejecución de las herramientas provoca que el sistema operativo detenga sus contenedores.

Nota:

Cuando dotnet-dump escribe un archivo de volcado en disco, la ruta de acceso de salida se interpreta en el contexto de la vista del proceso de destino del sistema de archivos. Esto puede diferir del contenedor host o sidecar.

Uso de PerfCollect en un contenedor

Esta herramienta se aplica a: ✔️ .NET Core 2.1 y versiones posteriores

El PerfCollect script es útil para recopilar seguimientos de rendimiento que contienen eventos del kernel como muestras de CPU o cambios de contexto. Si utiliza PerfCollect en un contenedor, tenga en cuenta los siguientes requisitos:

• PerfCollect requiere funcionalidades adicionales para ejecutar la herramienta perf. El conjunto mínimo de funcionalidades necesarias es PERFMON y SYS_PTRACE. Algunos entornos requieren SYS_ADMIN. Asegúrese de iniciar el contenedor con las funcionalidades necesarias. Si el conjunto mínimo no funciona, pruebe con el conjunto completo.

• PerfCollect requiere que se establezcan algunas variables de entorno antes de que se inicie la generación de perfiles de la aplicación. Se pueden establecer en un Dockerfile o cuando se inicia el contenedor. Dado que estas variables no deben establecerse en entornos de producción normales, es habitual simplemente agregarlas al iniciar un contenedor del que se va a crear un perfil. Las dos variables que requiere PerfCollect son:

  • DOTNET_PerfMapEnabled=1
  • DOTNET_EnableEventLog=1

Nota:

Al ejecutar la aplicación con .NET 7, también debe establecer DOTNET_EnableWriteXorExecute=0, además de las variables de entorno anteriores.

Nota:

.NET 6 estandariza en el prefijo DOTNET_ en lugar de en COMPlus_ para las variables de entorno que configuran el comportamiento en tiempo de ejecución de .NET. Sin embargo, el prefijo COMPlus_ seguirá funcionando. Si usa una versión anterior del runtime de .NET, debe seguir usando el prefijo COMPlus_ para las variables de entorno.

Uso de PerfCollect en un contenedor sidecar

Si desea ejecutar PerfCollect en un contenedor para generar un perfil de un proceso de .NET en un contenedor diferente, la experiencia es casi la misma. Las diferencias son:

• Las variables de entorno mencionadas anteriormente (DOTNET_PerfMapEnabled y DOTNET_EnableEventLog) se deben establecer para el contenedor de destino (no el que ejecuta PerfCollect).
• El contenedor que ejecuta PerfCollect debe tener la funcionalidad SYS_ADMIN (no el contenedor de destino).
• Los dos contenedores deben compartir un espacio de nombres de proceso.