{"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\/es\/blog\/administrirovanie\/ishhem-problemu-ne-v-tom-meste","title":{"rendered":"Buscamos el problema en el lugar equivocado.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Esta es una peque\u00f1a historia de la pr\u00e1ctica real, donde un peque\u00f1o problema, bien enmascarado por la alta disponibilidad, se convierte en un dolor de cabeza.
\n<\/a><\/noindex><\/p>\n

Breve disposici\u00f3n:<\/h2>\n

\nUna peque\u00f1a sucursal, que tiene su propia PBX (Asterisk + FreePBX) en una m\u00e1quina de escritorio y un peque\u00f1o servidor local con 1C, un sistema de almacenamiento de archivos y un controlador de dominio virtual RO. Internet es proporcionado por Mikrotik. La sucursal es peque\u00f1a y les es suficiente.
\nTodo comenz\u00f3 con el monitoreo (debido a la falta de tiempo y pereza, no se monitorean todas las cosas), que report\u00f3 el sobrecalentamiento de uno servidores<\/a> (con la PBX) en la sucursal. Mientras los locales resolv\u00edan el problema, el viejo se colg\u00f3 y da\u00f1\u00f3 un poco la base de datos de MySQL.<\/p>\n

Mucho presagiaba problemas, pero no esto\u2026<\/h3>\n

\nNo hay problema, la base de datos fue reparada, todo deber\u00eda funcionar. Pero los locales se quejan, las llamadas se cortan. Bueno, problemas en FreePBX pueden ocurrir, tomo una copia de seguridad, la despliego, todo bien.
\nPero el problema persiste, los locales a\u00fan se quejan, las llamadas no funcionan correctamente. Aparentemente, la llamada llega bien, pero cuando ellos llaman, o llaman entre s\u00ed, hay un retraso de varios segundos. Empiezo a examinar los extensos e incomprensibles registros de Asterisk y FreePBX, y no logro detectar el problema. Recuerdo que hubo un problema con STUN e ICE que causaba un retraso similar. Desactivo todo por completo, el resultado es nulo.<\/p>\n

La desolaci\u00f3n es el camino hacia la aceptaci\u00f3n de malas decisiones:<\/h3>\n

\nCaigo en la desolaci\u00f3n, horas de estar trabajando en la PBX no llevan a nada bueno, ya es tarde en la noche y el problema persiste.
\nDejo el problema para la ma\u00f1ana, teniendo la esperanza de que un nuevo d\u00eda traiga claridad. Por la ma\u00f1ana se toma otra decisi\u00f3n fallida: dado que el sistema se rompi\u00f3 (aunque el colapso no pod\u00eda ser tan destructivo), intento arreglar el sistema reinstalando todos los paquetes. El resultado es un poco mejor que cero, se ha reducido el retraso (no de forma significativa, pero sigue siendo un \u00e9xito).
\nTomo otra mala decisi\u00f3n: si la reparaci\u00f3n parcial del S.O. (y de la base de datos desde la copia de seguridad) fue algo exitosa, y el n\u00facleo del problema a\u00fan no est\u00e1 claro, y ya se ha gastado mucho tiempo buscando la causa, decido actuar radicalmente: borramos el S.O. y comenzamos desde cero (afortunadamente, la automatizaci\u00f3n del proceso hace que esto ocurra en un tiempo razonable). Despliego la configuraci\u00f3n de FreePBX desde una copia. Otro fracaso. \u00a1El resultado es nulo!<\/p>\n

La desesperaci\u00f3n nubla la raz\u00f3n, las decisiones se vuelven a\u00fan peores.<\/h3>\n

\nCaigo en la desesperaci\u00f3n. Empiezo a tener pensamientos bastante negativos, me pregunto: \u00bfser\u00e1 que la configuraci\u00f3n de respaldo est\u00e1 corrupta (me ha ocurrido despu\u00e9s de algunas actualizaciones, donde no funcionaba y nunca encontr\u00e9 la causa)? No queda otra: tengo que reinstalar todo desde cero a mano. \u00a1Qu\u00e9 verg\u00fcenza! El resultado es estrictamente nulo, \u00a1y adem\u00e1s he perdido un mont\u00f3n de tiempo!<\/p>\n

La aceptaci\u00f3n es el camino hacia la comprensi\u00f3n<\/h3>\n

\nEn mis intentos desesperados por entender lo que est\u00e1 sucediendo, empiezo a estudiar detenidamente los logs. Noto una regularidad. La llamada a la Extensi\u00f3n ocurre exactamente a los 5 segundos, mientras que para un grupo de 3 Extensiones, \u00a1es a los 15! Empiezo a buscar en Google sobre el retraso de llamadas, pero ya apuntando a un retraso espec\u00edfico. Y me topo con una respuesta que ya hab\u00eda encontrado, la gente dice que el problema est\u00e1 en el DNS, pero yo s\u00e9 que no hay problema, \u00a1todos los direcciones se resuelven!<\/p>\n

Lo obvio no es lo probable<\/h3>\n

\nNo hay nada que hacer, tomo nslookup y \u00a1bingo (deb\u00ed haberlo hecho desde el principio)! El DNS primario est\u00e1 ca\u00eddo (la virtualizaci\u00f3n con el controlador), \u00a1y yo ni me di cuenta! Si hubiera sido un solo DNS, habr\u00eda habido un error inmediatamente \ud83d\ude09<\/p>\n

Summary<\/h3>\n

\nUn problema elemental, que podr\u00eda haber visto el monitoreo (que se debe configurar para todos los nodos), camuflado por la tolerancia a fallos del DNS, llev\u00f3 a la p\u00e9rdida de casi dos d\u00edas laborales en la resoluci\u00f3n de esta situaci\u00f3n est\u00fapida. La pereza causa dolores de cabeza, configurar el monitoreo toma un minuto, buscar el problema donde no est\u00e1 toma dos d\u00edas.<\/p>\n

Solo los usuarios registrados pueden participar en la encuesta. Inicie sesi\u00f3n<\/a><\/noindex>, por favor.<\/p>\n

\u00bfTe ha pasado algo similar?<\/h2>\n