Métricas de Recursos (CPU, Memória e Disco)¶

A partir da 0.3.0a4, enquanto o processo roda, o jaylog envia a cada minuto uma amostra de uso de CPU, memória e disco — da máquina e do próprio processo — para POST /logs/host-metrics. O backend usa essas amostras para desenhar gráficos por instância (serviço + máquina + usuário), com a linha de teto de cada recurso.

Os limites da máquina (quantidade de CPUs, RAM total e tamanho do disco) não mudam durante a execução, então não vão em cada amostra: eles seguem uma vez só, junto do Registro de Ambiente. Com os dois, o painel consegue mostrar, por exemplo:

Configuração: 2 CPUs · 8 GB RAM · 10 GB de disco (C:\)

CPU:   80%
RAM:   37,5% — 3 GB de 8 GB
DISCO: 70%   — 7 GB de 10 GB

Como ligar¶

Não é preciso configurar nada novo. Basta o envio HTTP estar configurado (JAYLOG_LOG_HTTP_ENDPOINT e JAYLOG_LOG_HTTP_API_KEY) e o registro de ambiente ligado (padrão):

from jaylog import JaylogSettings, configure

configure(JaylogSettings())  # métricas começam a sair no próximo minuto cheio

O endpoint é derivado do endpoint de log, do mesmo jeito que o de host: https://api.example/logs/add vira https://api.example/logs/host-metrics.

O que é medido¶

E os limites, enviados no registro de ambiente:

Qualquer campo que não puder ser medido vai como null — nunca como 0.

Detalhes que mudam a leitura do gráfico¶

• "Processo" inclui os filhos. Bots de RPA abrem Chrome, Excel e outros programas; o consumo real costuma estar neles, não no Python. O jaylog soma toda a árvore de processos iniciada pelo bot.
• CPU do processo é relativa à máquina. Em uma máquina com 2 CPUs, um bot usando um núcleo inteiro aparece como 50%. Assim proc_cpu_pct e host_cpu_pct ficam na mesma escala e podem ser comparados no mesmo gráfico.
• Disco do processo é E/S, não ocupação. Um processo não "ocupa" uma porcentagem do disco; o que dá para medir é quanto ele lê e escreve. No Windows, esse contador soma toda a E/S do processo — arquivos, rede e dispositivos — por isso o nome é io, e não disk.
• O disco medido é o do script, não o do cwd. Em uma tarefa do Agendador sem "Iniciar em", o diretório de trabalho é C:\Windows\system32; o jaylog mede o disco onde está o script (ou o .exe), para não mostrar o C: quando o bot roda em D:.
• Amostras no minuto cheio. A coleta é alinhada ao relógio (12:01:00, 12:02:00, …), o que dá exatamente um ponto por minuto no gráfico. A primeira leitura depois do configure() serve só de base para os cálculos de CPU e E/S e não é enviada — publicá-la apareceria como "0%".
• Última amostra no encerramento. O shutdown() coleta e envia uma amostra final, para a execução não terminar com um buraco no último minuto.

Um coletor por processo¶

Diferente do registro de ambiente, que sai uma vez por app_name, existe um único coletor por processo. CPU e memória são do processo; com múltiplos loggers, um coletor por logger mandaria a mesma amostra várias vezes. O coletor se vincula ao primeiro item de configure() que tenha métricas habilitadas:

configure([settings_orders, settings_billing])  # um coletor, vinculado a "ORDERS"

Falhas não param o bot¶

A coleta segue a mesma regra do resto do jaylog: nada aqui pode derrubar ou travar a aplicação.

Próximo passo¶

Em produção, credenciais como JAYLOG_LOG_HTTP_API_KEY normalmente não ficam no código nem no .env versionado — veja Secrets em Produção.