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 agente do ARMS para Python instalado
Importe o agente no arquivo de entrada
Adicione a seguinte instrução de 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 via 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 de trabalho por fork. Com lazy-apps = true, o uWSGI carrega a aplicação após o início de cada processo de trabalho.
Efeitos da ativação do lazy-apps
Isolamento de memória: cada processo de trabalho carrega a aplicação em seu próprio contexto. Isso evita que estados de processos diferentes interfiram entre si.
Recarregamento dinâmico: no modo de desenvolvimento, as atualizações de código em tempo real tornam-se mais práticas. Cada processo de trabalho recarrega a aplicação na inicialização sem exigir o reinício completo do processo mestre.
Prevenção de problemas de estado global: com o
lazy-appsativado, cada processo de trabalho 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: caso a aplicação utilize variáveis globais, elas serão compartilhadas entre todos os processos de trabalho. Esse comportamento pode resultar em imprevisibilidade.
Velocidade de inicialização: como todos os processos de trabalho carregam a aplicação junto com o processo mestre, a inicialização geral tende a ser mais rápida. Esse ganho é especialmente notável ao iniciar uma grande quantidade de processos.
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 que as mudanças tenham efeito. Não basta reiniciar apenas um único processo de trabalho.
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 seguintes pontos:
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.