GWMS no Protheus: pare de descobrir problemas quando o usuário liga

O GWMS (Groundwork Monitor Suite) é a plataforma proprietária de observabilidade da Groundwork Tecnologia, desenvolvida em parceria com a TOTVS especificamente para ambientes ERP. No Protheus, ele rastreia o caminho completo de cada execução: do clique do usuário no Smart Client, passando pelo método ADVPL ou TLPP chamado no AppServer, chegando até a query SQL gerada no banco de dados, com alertas de negócio integrados aos módulos SIGA em tempo real.

Se o seu Protheus fica lento nos horários de pico, tem rotinas que travam sem erro visível, ou se o seu time de TI vive descobrindo problemas pela ligação de um usuário, boa parte disso tem causa rastreável. E causa rastreável tem resolução.

O que está acontecendo no seu Protheus agora, e que você provavelmente não vê

Antes de falar sobre o GWMS, vale a pena falar sobre o tipo de problema que ele resolve. Porque a maioria deles não aparece em nenhum painel de monitoramento convencional.

Rotinas ADVPL que consomem memória progressivamente. Customizações sem tratamento correto de memória não travam o AppServer imediatamente. Elas o degradam aos poucos, semanas ou meses. O servidor vai ficando mais lento. Os usuários reclamam que "o Protheus está pesado". O administrador reinicia o AppServer, o ambiente melhora por algumas horas e o ciclo recomeça. Ninguém sabe qual rotina está causando o problema porque não existe o rastro da execução.

Queries sem índice que ficam mais lentas conforme o banco cresce. Uma query que levava 2 segundos com 500 mil registros no SIGA leva 40 segundos com 5 milhões. O relatório do SIGAFAT (Faturamento) que o financeiro rodava em minutos começa a demorar uma hora. O problema não surgiu hoje. Ele foi crescendo junto com a base de dados. Sem observabilidade, o time de TI só descobre quando o usuário para de usar o relatório.

Jobs do Protheus que falham silenciosamente. Um job do SIGAATF (Ativo Fixo) agendado para rodar às 2h da manhã não conclui. Não gera erro visível no console do AppServer. O processo de negócio que dependia dele (conciliação bancária, geração de arquivos de remessa, cálculo de custo médio) simplesmente não aconteceu. O time de TI descobre no dia seguinte, quando o financeiro liga.

Integrações REST e SOAP do Protheus que param sem aviso. A integração com o gateway de pagamento, com o e-commerce ou com o sistema de NF-e responde com erro às 3h da manhã. As notas do dia seguinte chegam ao SIGAFAT com pendências que ninguém entende de onde vieram.

Customizações ADVPL com erros não tratados. O fonte customizado não quebra a execução com um MsgStop. Ele simplesmente faz a operação errada e continua rodando. Sem rastreamento de execução, o erro só aparece no dado incorreto no banco de dados, semanas depois, quando alguém tenta fechar o balanço.

Conflito de licenças no pico de uso. No fechamento do mês, o número de conexões simultâneas no Protheus atinge o limite licenciado. Usuários começam a receber erros de licença sem entender o motivo. O administrador não tem visibilidade de quantas licenças estão em uso por módulo, por filial ou por tipo de acesso, Smart Client ou Web.

Esses problemas existem na maioria dos ambientes Protheus que a Groundwork diagnosticou em mais de uma década de operação. A diferença entre os ambientes que funcionam e os que vivem em crise não é o tamanho da empresa nem a versão do release. É visibilidade.

Por que ferramentas genéricas não funcionam no Protheus

Zabbix, Nagios, Datadog e Grafana foram criados para monitorar infraestrutura. Eles respondem perguntas objetivas: o servidor está de pé? A CPU está acima de 90%? O serviço respondeu ao ping?

Para um servidor de aplicação genérico, isso é suficiente. Para o AppServer do Protheus, não é.

O problema está na camada que essas ferramentas não enxergam. Quando um usuário reclama que o SIGAFAT (Faturamento) está lento, o Zabbix pode mostrar CPU normal, memória estável e rede funcionando. Tecnicamente, tudo verde. O negócio está parado. A causa pode estar em uma rotina ADVPL customizada consumindo toda a memória de um thread do AppServer, em um método que dispara centenas de queries com lock no banco de dados, ou em um job do Scheduler que travou silenciosamente sem acionar nenhum alerta de infraestrutura.

Ferramentas genéricas medem métricas de servidor. Observabilidade do Protheus exige três camadas simultâneas: métricas de infraestrutura do AppServer e DbAccess, logs tratados da aplicação e traces de execução ADVPL, o que a indústria chama de APM (Application Performance Monitoring). No Protheus, isso significa rastrear o caminho completo de cada execução: do clique do usuário no Smart Client ou no browser, passando pelo método ADVPL ou TLPP chamado no AppServer, chegando até a query SQL gerada no DbAccess para o banco de dados.

Há ainda uma quarta camada que ferramentas genéricas ignoram por completo: o nível de negócio do ERP. O GWMS inclui o B.A.M (Business Application Monitoring), que acompanha em tempo real indicadores dos módulos SIGA como notas fiscais com transmissão pendente no SIGAFAT (Faturamento), pedidos acumulados na fila do SIGACOM (Compras) ou contabilizações não processadas no SIGACTB (Contabilidade Gerencial). Esse dado não vive na infraestrutura. Vive dentro do Protheus.

A distinção entre B.A.M e BI é direta: BI analisa histórico. B.A.M monitora o momento atual. Se há pedidos acumulados acima do limite configurado agora, o B.A.M dispara alerta. O BI mostraria isso na próxima consulta ao cubo.

Preencher essa lacuna no mundo Protheus exigiu estudos sobre a arquitetura interna do AppServer, implementações específicas no DbAccess e desenvolvimento direto com a própria TOTVS. Não é possível fazer observabilidade nativa do Protheus comprando uma licença de ferramenta de mercado.

GWMS: o diagnóstico que o seu Protheus não tinha

O GWMS não é mais um dashboard de monitoramento. É o instrumento de diagnóstico que permite ao time de TI sair do modo reativo, parar de apagar incêndio após incêndio no AppServer, e começar a identificar e tratar problemas antes que o negócio sinta.

A maioria dos problemas graves no Protheus não nasce de um dia para o outro. Eles se acumulam. Uma rotina ADVPL que começa a consumir mais memória do que deveria a cada execução. Uma query do SIGAEST (Estoque e Custos) que vai ficando mais lenta conforme o volume de itens no estoque cresce. Um job do SIGAATF (Ativo Fixo) que falha uma vez por semana e ninguém percebe. Com o tempo, esses acúmulos viram crises, e crises têm custo: fechamento do mês atrasado, notas fiscais presas no SIGAFAT (Faturamento), dados incorretos no SIGACTB (Contabilidade Gerencial).

O GWMS opera em quatro camadas simultâneas no ambiente Protheus, cada uma respondendo a um tipo diferente de pergunta:

Nível de negócio: B.A.M (Business Application Monitoring)

• SIGAFAT (Faturamento): notas fiscais emitidas, em validação na SEFAZ, em pré-fatura e com transmissão pendente

• SIGACOM (Compras): pedidos em fila de faturamento, aguardando aprovação e não liberados para processamento

• SIGACTB (Contabilidade Gerencial): itens contabilizados, não contabilizados e pendentes de processamento

• SIGAFIN (Financeiro): fluxo de caixa em tempo real, contas a pagar e a receber, inadimplência

• Alertas configuráveis por threshold: volume de transações, tempo em fila ou ausência de movimentação esperada num intervalo

• 
  

Nível de infraestrutura do Protheus

• AppServers: consumo de memória e CPU por instância, com histórico de pico e média

• DbAccess: status das conexões com o banco de dados, queries em execução e locks ativos

• Licenças: total em uso, disponíveis e distribuição por módulo SIGA, filial e tipo de acesso

• Jobs do Scheduler: execução, status de conclusão e tempo de cada job programado

• Serviços: status em tempo real de todos os serviços ativos no ambiente Protheus

  
  

Nível de execução: BT Monitor (desenvolvido em parceria com a TOTVS)

• Rastreamento de rotinas: todas as execuções do Protheus com quantidade de transações por período

• Tempo por método ADVPL e TLPP: mínimo, máximo e média por método dentro de um fonte específico

• Queries geradas pelo DbAccess: SQL disparado em cada execução, com tempo individual e identificação de locks

• Trace único por execução: ID que diferencia duas execuções simultâneas da mesma rotina com filtros ou usuários diferentes

• Histórico antes e depois de release: espelho de performance pré e pós atualização de versão do Protheus

• Fontes customizados: inclui código ADVPL de terceiros, independente das práticas de desenvolvimento usadas

  
  

Nível de integrações e APIs do Protheus

• APIs REST e SOAP externas: disponibilidade, tempo de resposta, verificação de endpoint e resposta de método específico

• SLA por camada: web service, slaves, DbAccess e sistema como indicadores separados

• Ambientes suportados: on-premises Windows e Linux, nuvem pública e cloud TOTVS via robô de captura de logs

  
  

Como o GWMS age no Protheus: do primeiro sinal à resolução

O fluxo começa, na maioria dos casos, antes de o usuário abrir um chamado.

O sinal aparece no negócio primeiro. O dashboard B.A.M mostra acúmulo de notas fiscais não transmitidas no SIGAFAT acima do padrão esperado para aquele horário. O analista identifica o desvio antes de receber ligação do financeiro. A causa pode ser técnica, como o serviço de transmissão do AppServer parado, ou externa, como instabilidade na SEFAZ. O time de TI vê o problema antes de qualquer usuário.

Correlação com o AppServer. O dashboard de infraestrutura confirma que uma instância específica do AppServer está com consumo de memória acima da média. O alerta chega por e-mail ou é capturado pelo NOC 24x7 da Groundwork. O analista correlaciona: o serviço de transmissão de NF-e está rodando no mesmo AppServer sobrecarregado. O desvio no negócio e o desvio na infraestrutura passam a ter contexto comum.

Investigação com histórico. O analista não parte do zero. Os dados históricos mostram o comportamento do AppServer nos dias anteriores. Se o consumo de memória sobe sempre às 23h, o padrão está registrado. O próximo passo é identificar qual rotina ADVPL estava sendo executada naquele momento.

BT Monitor fecha o ciclo. O analista filtra o módulo BT Monitor pelo período problemático. A lista de rotinas executadas no Protheus aparece com quantidade de transações e tempo médio por execução. Em um ambiente real monitorado pela Groundwork, o BT Monitor identificou o recálculo de custo médio do SIGAEST (Estoque e Custos) levando cerca de 1.000.000 ms (aproximadamente 16 minutos) como a segunda rotina mais pesada do ambiente num determinado período. Sem o trace, esse tempo nunca teria aparecido em nenhum relatório de infraestrutura.

Ao abrir a execução específica no BT Monitor, o analista vê os métodos ADVPL chamados em sequência, as queries SQL geradas pelo DbAccess e o tempo de cada uma. Se houver lock no banco durante a execução, está documentado ali. Se o problema estiver num método customizado de terceiro sem otimização, o trace mostra exatamente em qual método o tempo explodiu.

Resolução com contexto completo. O analista chega ao desenvolvedor com informação precisa: nome do fonte, método ADVPL, query SQL, tempo de execução. Não há "o Protheus está lento na minha máquina" nem investigação às cegas. A conversa começa do ponto certo. Após aplicar o ajuste, o BT Monitor registra a nova baseline de performance. A próxima vez que a rotina desviar, o alerta é calibrado sobre o comportamento real daquele ambiente.

O GWMS não resolve o problema por si só. Ele aponta com precisão onde o problema está, e com qual evidência trabalhá-lo.

O que muda quando o Protheus para de operar no escuro

Laerte Bentes, gerente de TI da Pam Plásticos, resumiu o cenário anterior em uma frase: "A gente ficava literalmente no escuro, dependendo de um terceiro monitorando."

A Pam Plásticos tem mais de 100 anos de mercado, opera plantas de injeção plástica e EPS na Zona Franca de Manaus e atende clientes como Honda, LG e TCL. Com 8 anos na empresa e quase 20 anos em TI, Laerte tem histórico para comparar os dois momentos.

Antes do GWMS, o time de TI trabalhava reativamente. Um problema no Protheus aparecia quando um usuário ligava reclamando. A investigação começava do zero: abrir logs do AppServer manualmente, tentar reproduzir o erro no ambiente de homologação, perguntar ao usuário qual rotina estava executando. Sem histórico estruturado, sem correlação entre AppServer e banco de dados, sem evidência objetiva de quando o problema começou.

Depois do GWMS, os painéis ficam expostos em monitores na sala de operações. O time identifica desvios no AppServer antes que se tornem incidentes percebidos pelos usuários. Quando um problema acontece, a investigação começa com dados concretos: qual fonte, qual método, qual query, qual lock.

Um ponto que aparece com frequência na prática: um dia com 81.000 transações de lançamento contábil no SIGACTB (Contabilidade Gerencial) pode não ser problemático. Se o tempo por transação foi baixo, o negócio não sentiu impacto. O dia que merece atenção é aquele com menos transações e tempo de execução no AppServer muito acima da média. Sem observabilidade, os dois dias parecem equivalentes no relatório. Com o GWMS, a distinção é imediata.

A questão da comprovação também se resolve. Por mais de 15 anos acompanhando ambientes Protheus, o time da Groundwork enfrentava o mesmo impasse: o usuário alegava que uma rotina do SIGAFAT ficara lenta após uma atualização de release, mas o time de TI não conseguia provar o contrário porque não tinha o registro do comportamento anterior. Com o BT Monitor, o espelho de performance antes e depois de cada release do Protheus é automático. A discussão sobre "sempre foi assim" passa a ter base objetiva.

A Groundwork opera com mais de 200 clientes, 110+ contratos ativos e 600.000 horas de operação por ano, sendo o Protheus o ambiente mais presente na carteira. Ambientes com alto volume de customizações ADVPL são os que mais sentem a diferença. É exatamente neles que problemas de código sem tratamento de erro surgem sem gerar alertas, por semanas ou meses, antes de alguém perceber.

Perguntas frequentes sobre o GWMS no Protheus

Como saber se meu ambiente Protheus tem problemas que ainda não apareceram?

Provavelmente tem, e você não sabe porque não tem visibilidade. Rotinas ADVPL com degradação progressiva de memória, queries do DbAccess sem índice que ficam mais lentas conforme o banco cresce, jobs do Scheduler que falham silenciosamente: esses problemas existem em boa parte dos ambientes Protheus sem monitoramento nativo. O GWMS foi implantado em mais de 200 ambientes e, na prática, sempre encontra algo que o time de TI não sabia que existia.

Vale a pena implantar o GWMS se o meu Protheus está funcionando bem agora?

Sim, e especialmente nesse caso. Ambientes Protheus que "estão funcionando bem" frequentemente têm problemas acumulando no AppServer. O momento certo para implantar observabilidade não é depois de um incidente grave de fechamento de mês: é antes. O custo de implantar o GWMS num ambiente estável é menor do que o custo de uma semana de investigação às cegas depois de uma crise no SIGAFAT.

O GWMS consegue rastrear uma rotina ADVPL do início ao fim?

Sim. O módulo BT Monitor registra cada execução com início, fim e tempo total. Ele mostra se aquela execução ficou dentro ou fora da média histórica da própria rotina, quais queries SQL foram geradas pelo DbAccess com o tempo de cada uma, e qual método ADVPL específico dentro do fonte foi o mais lento. Um fonte com múltiplos métodos tem cada um rastreado individualmente.

Ativar o GWMS vai comprometer a performance do AppServer?

Não. O GWMS coleta logs específicos do AppServer sem ativar o modo verbose do Protheus, que gera volume massivo de log e compromete a performance. A coleta é direcionada, apenas os dados necessários para observabilidade. O sistema opera sem impacto mensurável mesmo em ambientes com alto volume de transações simultâneas.

É possível monitorar fontes ADVPL customizados desenvolvidos por terceiros?

Sim, e é nesses casos que a observabilidade é mais necessária. Código nativo do Protheus passa por processo formal de QA da TOTVS. Customizações de terceiros, nem sempre. O BT Monitor rastreia qualquer execução no AppServer, independente da origem do fonte. Erros silenciosos que não geram MsgStop mas degradam a performance aparecem nos traces mesmo quando o fonte não tem tratamento de erro implementado.

O GWMS funciona no Protheus em nuvem pública e no cloud da TOTVS?

Sim, nos dois ambientes. O Protheus gera logs independente de onde o AppServer está hospedado. No cloud da TOTVS, a Groundwork utiliza um robô de captura que coleta esses logs e os traz para dentro da plataforma. Em nuvem pública (AWS, Azure, GCP) ou on-premises Windows e Linux, a infraestrutura do GWMS é instalada diretamente no ambiente do cliente.

O GWMS monitora as APIs REST e SOAP que o Protheus aciona?

Sim. O sistema monitora disponibilidade de APIs externas acionadas pelo Protheus: tempo de resposta, status de retorno, resolução de endpoint e disponibilidade de métodos específicos. Isso inclui APIs de parceiros logísticos, gateways de pagamento, integrações com plataformas de e-commerce e qualquer serviço externo chamado por rotinas ADVPL ou TLPP. O GWMS gera SLAs de disponibilidade separados por camada: web service, slaves, DbAccess e sistema.

Quando o GWMS identifica um problema no Protheus, o que acontece?

O GWMS aponta com precisão onde o problema está. Resolver é trabalho técnico. O fluxo: identificar o método ADVPL lento pelo trace do BT Monitor, verificar as queries geradas pelo DbAccess, decidir entre refatorar o fonte ou ajustar índices no banco. Em ambientes com NOC 24x7 da Groundwork, o diagnóstico vai direto para o time responsável com o contexto já documentado. O analista não chega ao desenvolvedor com "o Protheus está lento". Chega com nome do fonte, método, query e tempo.

A Groundwork é prestadora homologada pela TOTVS com mais de 200 clientes ativos em Protheus, Datasul e RM. O GWMS pode ser avaliado em POC no seu ambiente Protheus antes de qualquer decisão de contratação, para que você veja o que está acontecendo antes de decidir o que fazer.

Fale com um especialista em observabilidade do Protheus →

Groundwork Tecnologia. Consultoria especializada em TOTVS Protheus, Datasul e RM. São Paulo, Joinville e Fortaleza.