🥇Buscando o problema no lugar errado

Esta é uma pequena história da prática real, onde um pequeno problema, bem disfarçado pela redundância, se transforma em uma dor de cabeça.

Uma pequena disposição:

Uma pequena filial, que possui seu próprio PABX (Asterisk + FreePBX) baseado em hardware de desktop, e um servidor local de terminal com 1C, um depósito de arquivos e um controlador de domínio virtual. A internet é fornecida por Mikrotik. A filial é pequena, e isso é suficiente para eles.
Tudo começou com a monitoração (devido à falta de tempo e preguiça, a monitoração não cobre tudo), que alertou sobre o superaquecimento de um servidor (do PABX) na filial. Enquanto os locais tentavam resolver o problema, o sistema travou e acabou corrompendo um pouco o banco de dados MySQL.

Muito já indicava um problema, mas não este…

Não há problema, o banco foi consertado, tudo deveria funcionar. Mas os locais reclamam, as chamadas estão caindo. Ok — problemas no FreePBX acontecem, eu pego um backup, restauro, tudo certo.
Mas o problema persistia, os locais ainda reclamavam, as chamadas não estavam funcionando corretamente. Para eles, a chamada parecia normal, mas quando eles ligavam, ou se ligavam entre si, havia um atraso de vários segundos. Começo a olhar logs volumosos e inconclusivos do Asterisk e do FreePBX, e não consigo identificar o problema neles. Lembro que houve um problema com STUN e ICE, que causava um atraso semelhante. Desativo tudo, mas o resultado é nulo.

Desânimo — o caminho para decisões ruins:

Eu caí no desânimo; horas de fuçar no PABX não levam a nada bom, já é alta noite e o problema não é resolvido.
Deixei o problema para a manhã, na esperança de que uma cabeça fresca ajudaria. Na manhã seguinte, uma nova decisão mal sucedida foi tomada: uma vez que o sistema quebrou (embora o travamento não pudesse ser tão destrutivo), eu tento consertar o sistema reinstalando todos os pacotes. O resultado foi um pouco melhor que zero, o atraso diminuiu (não significativamente, mas é um progresso).
Tomo mais uma decisão ruim: se o reparo parcial do SO (e do banco de dados a partir do backup) teve um pequeno sucesso, e a raiz do problema ainda não está clara, e já foi gasto muito tempo na busca da causa, decido agir radicalmente: apagamos o SO e reinstalamos tudo do zero (ainda bem que a automação do processo faz isso em um tempo aceitável). Restaurei a configuração do FreePBX a partir do backup. Mais um fracasso. O resultado é nulo!

Desespero — a razão se ofusca, as decisões se tornam ainda piores.

Estou caindo em desespero. Começam a aparecer pensamentos bem ruins, penso: talvez o backup da configuração esteja corrompido (já passei por isso após várias atualizações, em que nada funcionava, e não consegui encontrar a causa), não resta nada: preciso recomeçar tudo do zero à mão. Que vergonha! O resultado é estritamente nulo, e ainda perdi um monte de tempo!

Aceitação - o caminho para a compreensão

Em tentativas desesperadas de entender o que está acontecendo, começo a examinar atentamente os logs. Percebo uma regularidade. A chamada de Extension ocorre exatamente em 5 segundos, e para um grupo de chamadas de 3 Extensions em 15! Começo a pesquisar sobre o atraso na chamada, mas já especificando o atraso concreto. E encontro uma resposta que já havia encontrado, as pessoas dizem que o problema está no DNS, mas eu sei que não há problema, todos os endereços são resolvidos!

O óbvio - não o improvável

Não tenho o que fazer, pego o nslookup e bingo (se eu tivesse feito isso logo de cara)! O DNS primário está fora do ar (máquina virtual com controlador), e eu nem percebi! Se houvesse apenas um DNS, haveria imediatamente um erro 😉

Resultado

Um problema elementar, que poderia ter sido detectado pela monitorização (que deve ser configurada para todos os nós), disfarçado pela redundância do DNS, resultou na perda de quase dois dias úteis para resolver uma situação estúpida. A preguiça traz dor de cabeça, configurar a monitorização leva um minuto - procurar um problema onde não existe leva dois dias.

Apenas usuários registrados podem participar da pesquisa. Entre, por favor.