Como Diagnosticar e Corrigir o Status LAGGED e Falhas de Heartbeat no VICIdial

Em operações de contact center de alta demanda que utilizam VICIdial auto-hospedado, poucos problemas geram tanta frustração quanto agentes sendo colocados involuntariamente em status LAGGED ou PAUSED. Esse comportamento interrompe a distribuição de chamadas, distorce as métricas de produtividade e afeta diretamente a eficiência dos discadores preditivos. Para solucionar essa falha, é necessário compreender a arquitetura de comunicação em tempo real do sistema e como o mecanismo de heartbeat valida a presença do operador.

Como Funciona o Heartbeat no VICIdial

A tela do agente no VICIdial (vicidial.php) comunica-se continuamente com o servidor web por meio de requisições AJAX periódicas (polling). Essas requisições atualizam a tabela vicidial_live_agents no banco de dados MySQL/MariaDB, registrando a data e hora exata da última interação (o chamado heartbeat).

Paralelamente, scripts de backend em Perl (como AST_VDauto_dial.pl e AST_update.pl) monitoram esses registros. Se a diferença entre o timestamp atual e o último heartbeat do agente ultrapassar o limite configurado (geralmente entre 10 e 30 segundos), o sistema assume que houve perda de conexão, marcando o agente automaticamente como LAGGED ou forçando uma pausa de segurança para evitar que chamadas sejam enviadas a uma estação inativa.

Principais Causas de Falha de Heartbeat e Lagging

1. Gargalos e Contenção no Banco de Dados (MySQL/MariaDB)
   Em instâncias com dezenas ou centenas de agentes simultâneos, a tabela vicidial_live_agents sofre atualizações constantes por segundo. Se o banco de dados apresentar lentidão, table locks ou configuração inadequada de buffers (innodb_buffer_pool_size, query_cache, max_connections), as queries de atualização do heartbeat sofrem fila. O script de verificação roda antes da query ser processada, gerando o falso falso-positivo de inatividade.

2. Sobrecarga no Servidor Web (Apache/PHP-FPM)
   Se o servidor web atingir o limite de workers disponíveis (MaxRequestWorkers no Apache), as requisições AJAX do navegador do agente ficam enfileiradas. O navegador do agente envia o pulso no tempo correto, mas o servidor web demora para responder e registrar no banco.

3. Instabilidade de Rede e Latência no Lado do Cliente
   Quedas pontuais de pacotes, oscilações de Wi-Fi nas estações de trabalho dos agentes ou rotas instáveis com o servidor podem atrasar a entrega das requisições HTTP/HTTPS, disparando o timeout do heartbeat.

4. Sobrecarga de I/O de Disco ou Processamento na Instância Asterisk
   Quando banco de dados, web e Asterisk rodam na mesma máquina sem isolamento adequado, a gravação de chamadas e a execução de cron jobs pesados consomem CPU e I/O, atrasando os processos em segundo plano.

Boas Práticas e Arquitetura Recomendada

Em sistemas de telefonia e discagem que desenvolvo e otimizo, a estabilidade do cluster é alcançada por meio de separação de responsabilidades e ajustes finos de infraestrutura:

• Arquitetura em Cluster: Em operações com mais de 30 agentes, separe os papéis em servidores dedicados: um nó para Web/Apache, um para Banco de Dados (otimizado para alto volume de escrita) e nós dedicados para Asterisk (Telefonia/RTP).
• Tuning de Banco de Dados: Mantenha as tabelas do VICIdial convertidas para InnoDB com índices adequados, configurando I/O dedicado (preferencialmente NVMe) e ajustando parâmetros de commit e log buffer (innodb_flush_log_at_trx_commit = 2 para balancear performance e durabilidade).
• Ajuste de Timeouts no Sistema: No menu Admin > System Settings e nas configurações de campanha, avalie os parâmetros de Agent Push Updates e timeouts de heartbeat para evitar sensibilidade excessiva em redes com pequenas variações de latência.
• Keep-Alive e Conexões Persistentes: Otimize as diretivas de KeepAlive no Apache e garanta que certificados SSL não estejam causando overhead desnecessário em cada handshake AJAX.

Processo para Diagnóstico e Resolução

1. Análise de Logs do Servidor: Inspecione /var/log/httpd/error_log (ou /var/log/apache2/), /var/log/astguiclient/ e o Slow Query Log do MySQL para identificar exatamente onde ocorre o gargalo temporal.
2. Validação da Conectividade do Agente: Utilize ferramentas de monitoramento de tráfego de rede para medir latência média e perda de pacotes entre os navegadores dos operadores e o host web.
3. Auditoria de Recursos do Sistema: Monitore consumo de CPU, I/O wait (iostat) e fila de conexões no momento em que os alertas de LAGGED ocorrem em massa.
4. Implementação e Teste de Carga: Realize os ajustes de infraestrutura de forma escalonada, acompanhando a redução de eventos de lag no painel em tempo real (realtime_report.php).

Conclusão e Consultoria Especializada

Identificar a causa raiz de agentes em status LAGGED no VICIdial exige uma abordagem técnica que integra banco de dados, infraestrutura Linux, redes e telefonia Asterisk. Se o seu ambiente VICIdial apresenta instabilidades, lentidão ou falsas pausas que prejudicam a produtividade da sua equipe, entre em contato para uma consultoria técnica e auditoria de infraestrutura.