Esta é uma pequena história da prática real, quando um pequeno problema, bem camuflado pela tolerância a falhas, se transforma em dor de cabeça.
Pequena disposição
Uma pequena filial, possui seu próprio PBX (asterisco + FreePBX) baseado em ferro de mesa e o mesmo servidor de terminal local com 1C, armazenamento de arquivos e um controlador de domínio RO virtual. A Internet distribui o Mikrotik. O pequeno ramo é suficiente para eles.
Tudo começou com o monitoramento (devido à falta de tempo e preguiça, nem tudo monitora), que relatava o superaquecimento de um servidor (do PBX) na filial. Enquanto os moradores resolveram o problema, o velho travou e quebrou um pouco do banco de dados MySQL.
Muito problema previsto, mas não isso ...
Não importa, a base foi reparada, tudo deve funcionar. Mas os moradores reclamam, as ligações são interrompidas. Ok - há problemas no FreePBX, pego um backup, implanto-o, está tudo bem.
Mas o problema está no lugar, os moradores ainda estão reclamando, as chamadas não vão bem. Antes deles, a chamada passa normalmente, mas quando eles mesmos ligam ou se ligam, é obtido um atraso de vários segundos. Começo a olhar para os registros volumosos e obscuros do Asterisk e do FreePBX, eles não conseguem discernir o problema. Lembro-me de que houve um problema com o STUN e o ICE, o que causou um atraso semelhante. Eu desligo para o inferno, o resultado é zero.
Desânimo é o caminho para tomar más decisões
Estou desanimado, pegar o PABX por muitas horas não leva a nada de bom, já é tarde da noite, mas o problema não está resolvido.
Ele deixou o problema até de manhã, esperando uma nova cabeça. De manhã, foi tomada outra decisão malsucedida: como o sistema falhou (embora a dependência não pudesse ser tão destrutiva), estou tentando consertar o sistema reinstalando todos os pacotes. O resultado é um pouco mais que zero, o atraso foi reduzido (não significativo, mas já um sucesso).
Tomo mais uma decisão ruim: se o reparo parcial do sistema operacional (e os bancos de dados do backup) teve pouco sucesso, e a raiz do problema ainda não está clara, e ao mesmo tempo já se gastou muito tempo na busca da causa, decido agir radicalmente: desmontamos o sistema operacional e rolamos tudo do zero (o benefício da automação do processo faz isso em um tempo aceitável). Eu rolo a configuração do FreePBX da cópia. Outra falha. O resultado é zero!
Desespero - a mente é ofuscada, as decisões pioram
Estou caindo em desespero. Pensamentos muito ruins começam a surgir, eu acho: talvez o conf no backup seja uma curva (eu o tive após várias atualizações que não funcionaram após eles e não consegui encontrar o motivo), nada resta: você precisa rolar tudo do zero com as mãos. Que pena! O resultado é estritamente zero e até gastou muito tempo!
Aceitação é o caminho para a conscientização
Em tentativas desesperadas de entender o que está acontecendo, começo a estudar cuidadosamente os registros. Percebo um padrão. Chamadas de extensão em exatamente 5 segundos e para um grupo de chamadas de 3 extensões em 15! Começo a pesquisar no Google sobre o atraso de chamadas, mas já indicando um atraso específico. E me deparo com uma resposta que eu já encontrei, as pessoas dizem que o problema está no DNS, mas eu tenho certeza, não há problema, todos os endereços estão resolvidos!
O óbvio é o incrível
Nada a fazer, pegue o nslookup e o bingo (eu gostaria de poder fazer isso imediatamente!) O DNS primário está (virtualka com o controlador), mas eu não percebi! Haveria um DNS, haveria imediatamente um erro;)
Sumário
Um problema elementar que o monitoramento pôde ver (ainda deveria estar configurado para todos os nós), mascarado pela resiliência do DNS, levou à perda de quase dois dias úteis para resolver a situação estúpida. Com muita preguiça, configure o monitoramento por um minuto - procure um problema onde ele não existe - dois dias.