Esta es una pequeña historia de la práctica real, donde un pequeño problema, bien enmascarado por la alta disponibilidad, se convierte en un dolor de cabeza.
Breve disposición:
Una pequeña sucursal, que tiene su propia PBX (Asterisk + FreePBX) en una máquina de escritorio y un pequeño 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ña y les es suficiente.
Todo comenzó con el monitoreo (debido a la falta de tiempo y pereza, no se monitorean todas las cosas), que reportó el sobrecalentamiento de uno servidores (con la PBX) en la sucursal. Mientras los locales resolvían el problema, el viejo se colgó y dañó un poco la base de datos de MySQL.
Mucho presagiaba el desastre, pero no esto...
No hay problema, la base de datos fue reparada, todo debería 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.
Pero el problema persiste, los locales aún se quejan, las llamadas no funcionan correctamente. Aparentemente, la llamada llega bien, pero cuando ellos llaman, o llaman entre sí, 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.
La desolación es el camino hacia la aceptación de malas decisiones:
Caigo en la desolación, horas de estar trabajando en la PBX no llevan a nada bueno, ya es tarde en la noche y el problema persiste.
Dejo el problema para la mañana, teniendo la esperanza de que un nuevo día traiga claridad. Por la mañana se toma otra decisión fallida: dado que el sistema se rompió (aunque el colapso no podía 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 éxito).
Tomo otra mala decisión: si la reparación parcial del S.O. (y de la base de datos desde la copia de seguridad) fue algo exitosa, y el núcleo del problema aún no está 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ón del proceso hace que esto ocurra en un tiempo razonable). Despliego la configuración de FreePBX desde una copia. Otro fracaso. ¡El resultado es nulo!
La desesperación nubla la razón, las decisiones se vuelven aún peores.
Caigo en la desesperación. Empiezo a tener pensamientos bastante negativos, me pregunto: ¿será que la configuración de respaldo está corrupta (me ha ocurrido después de algunas actualizaciones, donde no funcionaba y nunca encontré la causa)? No queda otra: tengo que reinstalar todo desde cero a mano. ¡Qué vergüenza! El resultado es estrictamente nulo, ¡y además he perdido un montón de tiempo!
La aceptación es el camino hacia la comprensión
En mis intentos desesperados por entender lo que está sucediendo, empiezo a estudiar detenidamente los logs. Noto una regularidad. La llamada a la Extensión ocurre exactamente a los 5 segundos, mientras que para un grupo de 3 Extensiones, ¡es a los 15! Empiezo a buscar en Google sobre el retraso de llamadas, pero ya apuntando a un retraso específico. Y me topo con una respuesta que ya había encontrado, la gente dice que el problema está en el DNS, pero yo sé que no hay problema, ¡todos los direcciones se resuelven!
Lo obvio no es lo probable
No hay nada que hacer, tomo nslookup y ¡bingo (debí haberlo hecho desde el principio)! El DNS primario está caído (la virtualización con el controlador), ¡y yo ni me di cuenta! Si hubiera sido un solo DNS, habría habido un error inmediatamente 😉
Summary
Un problema elemental, que podría haber visto el monitoreo (que se debe configurar para todos los nodos), camuflado por la tolerancia a fallos del DNS, llevó a la pérdida de casi dos días laborales en la resolución de esta situación estúpida. La pereza causa dolores de cabeza, configurar el monitoreo toma un minuto, buscar el problema donde no está toma dos días.
Solo los usuarios registrados pueden participar en la encuesta. , por favor.
¿Te ha pasado algo similar?
Sí, muy raramente
Sí, raramente
Sí, a menudo
Sí, muy a menudo
No, con cualquiera, ¡menos conmigo!
No, soy infalible.
Votaron 2 usuarios. Se abstuvo 1 usuario.
Fuente: habr.com
