Ao executar aplicações Django ou Flask no uWSGI, importe o agente Python do Application Real-Time Monitoring Service (ARMS) diretamente no arquivo de entrada da aplicação e ative o modo lazy-apps.
Não use o prefixo de comando aliyun-instrument com o uWSGI. Em vez disso, importe o agente diretamente no código da sua aplicação.
Pré-requisitos
Antes de começar, verifique se você tem:
O ARMS agent for Python instalado
Importe o agente no arquivo de entrada
Adicione a seguinte importação na primeira linha do arquivo de entrada do uWSGI (wsgi.py para Django ou app.py para Flask):
from aliyun.opentelemetry.instrumentation.auto_instrumentation import sitecustomizeEssa importação inicializa o agente do ARMS antes do carregamento do framework da aplicação e permite a instrumentação automática das bibliotecas compatíveis.
Inicie o uWSGI com lazy-apps
Adicione --lazy-apps ao comando de inicialização do uWSGI ou defina lazy-apps = true no arquivo de configuração.
Exemplo de CLI:
uwsgi --http :8000 --wsgi-file app.py --callable application --master --enable-threads --threads 2 --processes 4 --lazy-appsExemplo de arquivo de configuração (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 = trueSubstitua os placeholders abaixo pelos valores reais:
|
Placeholder |
Descrição |
Exemplo |
|
|
Caminho para o arquivo de entrada WSGI |
|
|
|
Caminho para o arquivo de socket Unix |
|
Por que lazy-apps é obrigatório
A opção lazy-apps no uWSGI controla o carregamento dos módulos da aplicação. Por padrão, o uWSGI carrega a aplicação quando o processo mestre inicia e, em seguida, cria os processos worker via fork. Com lazy-apps = true, o uWSGI carrega a aplicação após o início de cada processo worker.
Efeitos da ativação do lazy-apps
Isolamento de memória: cada processo worker carrega a aplicação em seu próprio contexto. Isso evita interferência entre estados de processos diferentes.
Recarregamento dinâmico: no modo de desenvolvimento, as atualizações de código em tempo real tornam-se mais práticas. Cada processo worker recarrega a aplicação na inicialização sem exigir o reinício do processo mestre.
Prevenção de problemas de estado global: com o
lazy-appsativado, cada processo worker mantém seu próprio estado. Isso reduz falhas causadas pelo compartilhamento de estado.
Efeitos da não ativação do lazy-apps
Compartilhamento de estado global: se a aplicação usar variáveis globais, elas serão compartilhadas entre todos os processos worker. Esse comportamento pode gerar resultados imprevisíveis.
Velocidade de inicialização: como todos os processos worker carregam a aplicação junto com o processo mestre, a inicialização geral tende a ser mais rápida. Esse ganho é notável ao iniciar muitos workers.
Tratamento de alterações de código: sem o
lazy-apps, qualquer modificação no código exige o reinício completo do processo uWSGI para surtir efeito. Não basta reiniciar apenas um processo worker.
Verifique os dados de rastreamento
Após iniciar a aplicação com a configuração acima, abra o console do ARMS e confirme a exibição dos dados de rastreamento. Se os dados não aparecerem, verifique os itens a seguir:
A instrução de importação está na primeira linha do arquivo de entrada.
O parâmetro
lazy-appsestá ativado na configuração do uWSGI.