Checklist QMC: resiliencia de consultas longas (NFSE)¶

Verificacao manual no QMC (Qlik Sense Enterprise on Windows, Nov 2024) para apoiar as melhorias de resiliencia do MCP Guardiao (timeouts, keepalive, checkpoint, retry classificado - ver docs/GUARDIAO.md). Nada aqui e obrigatorio: siga a ordem abaixo e pare assim que o problema estiver resolvido.

Antes de comecar¶

Faca isso depois de colocar o codigo novo em producao (T1-T5 deste plano), nao antes. O keepalive via GetProgress e o chunking mensal ja resolvem boa parte do que motivou esta lista.
O item 1 (mudar o virtual proxy) e o unico passo que afeta usuarios ativos. Leia o aviso antes de executa-lo.

1. Session inactivity timeout do virtual proxy `jwtapi-dados`¶

Hoje esta em 30 minutos. O keepalive (GetProgress a cada GUARDIAO_WS_RECV_TIMEOUT_S, default 60s) ja gera trafego periodico que reseta esse timeout durante um reload longo - entao pode nem ser necessario mudar nada aqui.

No QMC, va em Virtual Proxies e abra jwtapi-dados.
Confira o valor atual de Session inactivity timeout (esperado: 30 min).
Nao mude ainda. Primeiro rode o codigo novo (com o keepalive) contra o cenario que travava antes (ago/2021) e veja se a sessao sobrevive com os 30 min atuais.
Só se ainda cair com o keepalive ativo: suba para 120 minutos.

Aviso: salvar uma mudanca em virtual proxy derruba as sessoes ativas daquele proxy (todo mundo conectado via jwtapi-dados e desconectado na hora). Faca isso fora do expediente (ningem investigando um ticket no momento), depois de validar que as correcoes de codigo (T1-T5) estao no ar, e somente se o passo 3 mostrar que o keepalive nao bastou.

2. Logs do QPS (Qlik Proxy Service)¶

Caminho: %ProgramData%\Qlik\Sense\Log\Proxy\Trace\*Connection*

Procure desconexoes de WebSocket em intervalos regulares (padrao ~60s ou ~300s). Um padrao regular assim indica idle-timeout de um proxy/firewall/VPN no caminho de rede - nao do proprio Qlik. Se encontrar esse padrao, peca a infra o TCP idle timeout configurado para trafego wss/443 no caminho entre o cliente do Guardiao e o QPS.

3. Engine: working set e pressao de memoria¶

No QMC, em Engines, confira Working set limit (min/max esperado: 70%/90%).
Cruze o log do Engine com o horario dos travamentos historicos (ex. ago/2021) e veja se ha sinal de pressao de memoria nesse periodo.
O chunking mensal das tools NFSE (uma consulta por mes em vez de por ano) ja reduz a pressao de memoria por chamada em aproximadamente 12x - vale reavaliar esse item depois de rodar a investigacao real com o codigo novo.

4. Code 11000 (Engine ocupado) e sessoes orfas¶

code 11000 no Engine normalmente indica uma session app orfa recarregando depois de uma queda de WebSocket. Se esse erro (categoria engine_ocupado no Guardiao, ver docs/GUARDIAO.md) aparecer com frequencia:

Confira reloads orfaos travados nas session apps do Engine.
Se acumularem, reinicie o Qlik Sense Engine Service.

5. Sessoes penduradas do usuario do Guardiao¶

Confirme que o usuario/identidade Qlik usado pelo Guardiao (GUARDIAO_QLIK_USER_ID) nao acumula sessoes concorrentes penduradas no QMC (Sessions). Limite de referencia: ~5 sessoes paralelas. O Guardiao ja reusa uma sessao por processo e a encerra explicitamente ao terminar (ver docs/GUARDIAO.md), mas processos que morrem sem close_qrs_session() (kill -9, queda de energia) podem deixar sessao presa - limpe manualmente se acumular.

6. Timeout de reload (nao ha o que mudar no QMC)¶

Nao existe um timeout server-side de reload no Engine API. O controle de tempo de uma consulta longa e todo do lado do cliente (Guardiao): GUARDIAO_BUDGET_S corta a chamada da tool e GUARDIAO_RELOAD_STALL_S detecta reload sem progresso. Nao ha item de configuracao do QMC para isso.

Resumo da ordem de execucao¶

Rode o codigo novo (T1-T5) primeiro.
Repita a investigacao real que travava (itens 2-6 sao so diagnostico, sem risco).
Só mexa no virtual proxy (item 1) se, depois de tudo isso, a sessao ainda cair por inatividade - e escolha um horario de baixo uso para fazer a mudanca.