{"id":32682,"date":"2019-10-31T21:48:22","date_gmt":"2019-10-31T18:48:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ishhem-problemu-ne-v-tom-meste\/"},"modified":"2019-10-31T21:48:22","modified_gmt":"2019-10-31T18:48:22","slug":"ishhem-problemu-ne-v-tom-meste","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/ishhem-problemu-ne-v-tom-meste","title":{"rendered":"Procurando o problema no lugar errado","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Esta \u00e9 uma pequena hist\u00f3ria da pr\u00e1tica real, onde um pequeno problema, bem disfar\u00e7ado pela redund\u00e2ncia, se transforma em uma dor de cabe\u00e7a.
\n<\/a><\/noindex><\/p>\n

Uma pequena disposi\u00e7\u00e3o:<\/h2>\n

\nUma pequena filial, que possui seu pr\u00f3prio PABX (Asterisk + FreePBX) baseado em hardware de desktop, e um servidor local de terminal com 1C, um dep\u00f3sito de arquivos e um controlador de dom\u00ednio virtual. A internet \u00e9 fornecida por Mikrotik. A filial \u00e9 pequena, e isso \u00e9 suficiente para eles.
\nTudo come\u00e7ou com a monitora\u00e7\u00e3o (devido \u00e0 falta de tempo e pregui\u00e7a, a monitora\u00e7\u00e3o n\u00e3o cobre tudo), que alertou sobre o superaquecimento de um servidor<\/a> (do PABX) na filial. Enquanto os locais tentavam resolver o problema, o sistema travou e acabou corrompendo um pouco o banco de dados MySQL.<\/p>\n

Muito anunciava um desastre, mas n\u00e3o este...<\/h3>\n

\nN\u00e3o h\u00e1 problema, o banco foi consertado, tudo deveria funcionar. Mas os locais reclamam, as chamadas est\u00e3o caindo. Ok \u2014 problemas no FreePBX acontecem, eu pego um backup, restauro, tudo certo.
\nMas o problema persistia, os locais ainda reclamavam, as chamadas n\u00e3o estavam funcionando corretamente. Para eles, a chamada parecia normal, mas quando eles ligavam, ou se ligavam entre si, havia um atraso de v\u00e1rios segundos. Come\u00e7o a olhar logs volumosos e inconclusivos do Asterisk e do FreePBX, e n\u00e3o consigo identificar o problema neles. Lembro que houve um problema com STUN e ICE, que causava um atraso semelhante. Desativo tudo, mas o resultado \u00e9 nulo.<\/p>\n

Des\u00e2nimo \u2014 o caminho para decis\u00f5es ruins:<\/h3>\n

\nEu ca\u00ed no des\u00e2nimo; horas de fu\u00e7ar no PABX n\u00e3o levam a nada bom, j\u00e1 \u00e9 alta noite e o problema n\u00e3o \u00e9 resolvido.
\nDeixei o problema para a manh\u00e3, na esperan\u00e7a de que uma cabe\u00e7a fresca ajudaria. Na manh\u00e3 seguinte, uma nova decis\u00e3o mal sucedida foi tomada: uma vez que o sistema quebrou (embora o travamento n\u00e3o pudesse ser t\u00e3o destrutivo), eu tento consertar o sistema reinstalando todos os pacotes. O resultado foi um pouco melhor que zero, o atraso diminuiu (n\u00e3o significativamente, mas \u00e9 um progresso).
\nTomo mais uma decis\u00e3o 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\u00e3o est\u00e1 clara, e j\u00e1 foi gasto muito tempo na busca da causa, decido agir radicalmente: apagamos o SO e reinstalamos tudo do zero (ainda bem que a automa\u00e7\u00e3o do processo faz isso em um tempo aceit\u00e1vel). Restaurei a configura\u00e7\u00e3o do FreePBX a partir do backup. Mais um fracasso. O resultado \u00e9 nulo!<\/p>\n

Desespero \u2014 a raz\u00e3o se ofusca, as decis\u00f5es se tornam ainda piores.<\/h3>\n

\nEstou caindo em desespero. Come\u00e7am a aparecer pensamentos bem ruins, penso: talvez o backup da configura\u00e7\u00e3o esteja corrompido (j\u00e1 passei por isso ap\u00f3s v\u00e1rias atualiza\u00e7\u00f5es, em que nada funcionava, e n\u00e3o consegui encontrar a causa), n\u00e3o resta nada: preciso recome\u00e7ar tudo do zero \u00e0 m\u00e3o. Que vergonha! O resultado \u00e9 estritamente nulo, e ainda perdi um monte de tempo!<\/p>\n

Aceita\u00e7\u00e3o - o caminho para a compreens\u00e3o<\/h3>\n

\nEm tentativas desesperadas de entender o que est\u00e1 acontecendo, come\u00e7o 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\u00e7o a pesquisar sobre o atraso na chamada, mas j\u00e1 especificando o atraso concreto. E encontro uma resposta que j\u00e1 havia encontrado, as pessoas dizem que o problema est\u00e1 no DNS, mas eu sei que n\u00e3o h\u00e1 problema, todos os endere\u00e7os s\u00e3o resolvidos!<\/p>\n

O \u00f3bvio - n\u00e3o o improv\u00e1vel<\/h3>\n

\nN\u00e3o tenho o que fazer, pego o nslookup e bingo (se eu tivesse feito isso logo de cara)! O DNS prim\u00e1rio est\u00e1 fora do ar (m\u00e1quina virtual com controlador), e eu nem percebi! Se houvesse apenas um DNS, haveria imediatamente um erro \ud83d\ude09<\/p>\n

Resultado<\/h3>\n

\nUm problema elementar, que poderia ter sido detectado pela monitoriza\u00e7\u00e3o (que deve ser configurada para todos os n\u00f3s), disfar\u00e7ado pela redund\u00e2ncia do DNS, resultou na perda de quase dois dias \u00fateis para resolver uma situa\u00e7\u00e3o est\u00fapida. A pregui\u00e7a traz dor de cabe\u00e7a, configurar a monitoriza\u00e7\u00e3o leva um minuto - procurar um problema onde n\u00e3o existe leva dois dias.<\/p>\n

Apenas usu\u00e1rios registrados podem participar da pesquisa. Entre<\/a><\/noindex>, por favor.<\/p>\n

J\u00e1 aconteceu algo parecido com voc\u00ea?<\/h2>\n