{"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\/it\/blog\/administrirovanie\/ishhem-problemu-ne-v-tom-meste","title":{"rendered":"Cerchiamo il problema non in quel punto","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Questa \u00e8 una piccola storia di una pratica reale, in cui un piccolo problema, ben mascherato dalla tolleranza ai guasti, si trasforma in un mal di testa.
\n<\/a><\/noindex><\/p>\n

Una piccola disposizione:<\/h2>\n

\nUn piccolo filiale, con il suo centrale telefonico (Asterisk + FreePBX) basato su hardware desktop e un piccolo server locale con 1C, un deposito di file e un controller di dominio virtuale RO. L'Internet \u00e8 fornito da Mikrotik. Il filiale \u00e8 piccolo, questo basta per loro.
\nTutto \u00e8 iniziato con il monitoraggio (a causa della mancanza di tempo e pigrizia non si monitora tutto), che ha segnalato un surriscaldamento di uno server<\/a> (con il centrale telefonico) nella filiale. Mentre i locali cercavano di risolvere il problema, il vecchietto si \u00e8 bloccato e ha danneggiato leggermente il database MySQL.<\/p>\n

Molte cose presagivano un disastro, ma non questo\u2026<\/h3>\n

\nNon \u00e8 un problema, hanno riparato il database, tutto dovrebbe funzionare. Ma i locali si lamentano, le chiamate si interrompono. Va bene \u2014 i problemi con FreePBX capitano, prendo un backup, lo ripristino, tutto ok.
\nMa il problema \u00e8 ancora presente, i locali continuano a lamentarsi, le chiamate non vanno bene. La chiamata sembra passare normalmente, ma quando cercano di chiamarsi a vicenda, c'\u00e8 un ritardo di qualche secondo. Comincio a esaminare i log Asterisk e FreePBX, voluminosi e incomprensibili, ma non riesco a scorgere il problema. Ricordo che c'era stato un problema con STUN e ICE, che causava un ritardo simile. Disattivo tutto e il risultato \u00e8 nullo.<\/p>\n

La disperazione \u00e8 la strada per prendere decisioni sbagliate:<\/h3>\n

\nCadendo nella disperazione, ore di frustrazione con il centrale telefonico non portano a nulla di buono, \u00e8 gi\u00e0 notte fonda e il problema non si risolve.
\nHo lasciato il problema fino al mattino, sperando in una mente fresca. Al mattino \u00e8 stata presa una nuova decisione sbagliata: dato che il sistema si era rotto (anche se il blocco non poteva essere cos\u00ec distruttivo), cerco di riparare il sistema reinstallando tutti i pacchetti. Il risultato \u00e8 leggermente migliore di zero, il ritardo \u00e8 diminuito (non sostanzialmente, ma \u00e8 comunque un successo).
\nPrendo un'altra decisione sbagliata: se la riparazione parziale del sistema operativo (e del database dal backup) ha avuto un certo successo, e se la radice del problema \u00e8 ancora poco chiara, ed \u00e8 gi\u00e0 stato speso molto tempo nella ricerca della causa, decido di agire in modo radicale: cancello il sistema operativo e reinstallo tutto da capo (per fortuna l'automazione del processo lo rende possibile in tempi accettabili). Ripristino la configurazione di FreePBX dal backup. Un altro fallimento. Risultato nullo!<\/p>\n

La disperazione oscura la mente, le decisioni diventano ancora peggiori.<\/h3>\n

\nMi sento disperato. Comincio a ricevere pensieri davvero brutti, penso: forse la conferenza nel backup \u00e8 difettosa (mi era capitato dopo alcuni aggiornamenti, e non sono mai riuscito a trovare la causa), non resta che ricominciare tutto da capo a mano. Che vergogna! Il risultato \u00e8 assolutamente nullo, e ho anche sprecato un sacco di tempo!<\/p>\n

Accettazione - la via verso la consapevolezza<\/h3>\n

\nNei miei disperati tentativi di comprendere quanto sta accadendo, inizio a esaminare attentamente i log. Notando una regolarit\u00e0. La chiamata all'Extension avviene esattamente dopo 5 secondi, mentre per un gruppo di 3 chiamate all'Extension ci vogliono 15! Comincio a cercare su Google riguardo ai ritardi nelle chiamate, ma gi\u00e0 specificando un ritardo concreto. E mi imbatto nella risposta che avevo gi\u00e0 trovato: la gente dice che il problema \u00e8 nel DNS, ma io so per certo che non c'\u00e8 problema, tutti gli indirizzi vengono risolti!<\/p>\n

L'ovvio - non il probabile<\/h3>\n

\nNon ho nulla da fare, prendo in mano nslookup e bingo (ma perch\u00e9 non l'ho fatto subito)! Il DNS primario \u00e8 gi\u00f9 (una macchina virtuale con il controller), e io non me ne sono neanche accorto! Se ci fosse un solo DNS, ci sarebbe stato subito un errore \ud83d\ude09<\/p>\n

Risultato<\/h3>\n

\nUn problema elementare, che il monitoraggio (che andrebbe configurato per tutti i nodi) avrebbe potuto vedere, mascherato dalla resilienza del DNS, mi ha fatto perdere quasi due giorni lavorativi per risolvere una situazione stupida. La pigrizia \u00e8 una seccatura, impostare un monitoraggio richiede un minuto - cercare problemi dove non ci sono - due giorni.<\/p>\n

Solo gli utenti registrati possono partecipare al sondaggio. Accedi<\/a><\/noindex>, per favore.<\/p>\n

Vi \u00e8 mai capitato qualcosa del genere?<\/h2>\n