Instalación del agente de ARMS para Python con uWSGI - Application Real-Time Monitoring Service

Cuando las aplicaciones Django o Flask se ejecutan en uWSGI, debe importar el agente de Python de Application Real-Time Monitoring Service (ARMS) directamente en el archivo de entrada de la aplicación y habilitar el modo lazy-apps.

Importante

No utilice el prefijo de comando aliyun-instrument con uWSGI. En su lugar, importe el agente directamente en el código de su aplicación.

Requisitos previos

Antes de empezar, asegúrese de contar con lo siguiente:

El ARMS agent for Python instalado

Importación del agente en el archivo de entrada

Agregue la siguiente importación en la primera línea del archivo de entrada de uWSGI (wsgi.py para Django o app.py para Flask):

from aliyun.opentelemetry.instrumentation.auto_instrumentation import sitecustomize

Esta importación inicializa el agente de ARMS antes de que se cargue el framework de la aplicación, lo que permite la instrumentación automática de las bibliotecas compatibles.

Inicio de uWSGI con lazy-apps

Agregue --lazy-apps al comando de inicio de uWSGI o establezca lazy-apps = true en el archivo de configuración.

Ejemplo de CLI:

uwsgi --http :8000 --wsgi-file app.py --callable application --master --enable-threads --threads 2 --processes 4 --lazy-apps

Ejemplo de archivo de configuración (formato INI):

[uwsgi]
http = :8000
wsgi-file = <your-wsgi-file-path>
callable = application
socket = <your-socket-file-path>
chmod-socket = 660

# Process settings
master = true
processes = 4
threads = 4

# ARMS agent: required settings
enable-threads = true
lazy-apps = true

Reemplace los siguientes marcadores de posición con sus valores reales:

Marcador de posición	Descripción	Ejemplo
`<your-wsgi-file-path>`	Ruta al archivo de entrada WSGI	`/myproject/myproject/wsgi.py`
`<your-socket-file-path>`	Ruta al archivo de socket Unix	`/myproject/wsgi.sock`

Por qué lazy-apps es obligatorio

lazy-apps es una opción de configuración en uWSGI que controla cómo se cargan los módulos de la aplicación. De forma predeterminada, uWSGI carga la aplicación cuando se inicia el proceso maestro y luego bifurca los procesos de trabajo. Con lazy-apps = true, uWSGI carga la aplicación después de que se inicia cada proceso de trabajo.

Efectos de habilitar lazy-apps

Aislamiento de memoria: cada proceso de trabajo carga la aplicación en su propio contexto, lo que evita que los estados de diferentes procesos interfieran entre sí.
Recarga dinámica: en modo de desarrollo, las actualizaciones en caliente del código resultan más prácticas porque cada proceso de trabajo recarga la aplicación al iniciarse sin necesidad de reiniciar todo el proceso maestro.
Prevención de problemas de estado global: cada proceso de trabajo mantiene su propio estado cuando lazy-apps está habilitado, lo que reduce los problemas causados por el estado compartido.

Efectos de no habilitar lazy-apps

Estado global compartido: si la aplicación utiliza variables globales, estas se comparten entre todos los procesos de trabajo, lo que puede provocar un comportamiento impredecible.
Velocidad de inicio: dado que todos los procesos de trabajo cargan la aplicación cuando se inicia el proceso maestro, la velocidad general de arranque puede ser relativamente mayor, especialmente al iniciar una gran cantidad de procesos de trabajo.
Gestión de cambios en el código: sin lazy-apps, si se realizan modificaciones en el código, debe reiniciar todo el proceso de uWSGI para que los cambios surtan efecto, en lugar de reiniciar solo un proceso de trabajo individual.

Verificación de datos de rastreo

Después de iniciar la aplicación con la configuración anterior, abra la consola de ARMS y confirme que aparezcan los datos de rastreo. Si no se muestran datos, compruebe lo siguiente:

La declaración de importación se encuentra en la primera línea del archivo de entrada.
lazy-apps está habilitado en la configuración de uWSGI.