Questa settimana, stavo vedendo un calo in media back-end delle prestazioni sul lavoro, abbiamo avuto un calo medio in termini di prestazioni di caricamento della pagina da ~ 250 ms a circa 500ms. Questo sembrava essere un problema intermittente e abbiamo cercato attraverso i grafici a NewRelic senza colpevole chiaro. Poi abbiamo iniziato a guardare al nostro interno collettore profiling MediaWiki, e alcuni degli strumenti di aggregazione diversi che ho messo insieme. Dopo pochi minuti è diventato chiaro che il tempo di connessione su uno dei nostri database sono aumentate 1000 volte. Dopo aver recentemente cambiato la configurazione spanning-tree e lo spostamento di alcuni dei nostri cross connect a 10Gb / s, ho sospettato questo potrebbe essere stato un problema di spanning tree. Si scopre il nostro demone Ganglia (gmond) su tale host aveva consumato memoria sufficiente a causa di una perdita di memoria per performance negativa del sistema affetto. Purtroppo questo era un modo piuttosto inefficiente per trovare il problema, e mi ha ricordato di alcuni inquilini di base del monitoraggio.
Monitor Latenza
Un semplice test MySQL può solo dire se il server è su o giù. Gli avvisi, probabilmente nemmeno timeout, ma in strumento di monitoraggio più ho visto questi sono misurati in secondi, non millisecondi. Il tuo dovrebbe avere il vostro avviso configurato per dirvi quando il servizio che state monitorando è andato a un livello inaccettabile, e forse effettuare le prestazioni del sito. Così, il semplice controllo di MySQL dovrebbero timeout in 3 secondi, ma avvisare l'utente se preso più di 100 ms per stabilire una connessione. Ricordate, se la latenza è abbastanza alto il vostro servizio sia effettivamente basso.
Monitoraggio del monitoraggio
A volte il monitoraggio può uscire whack. Potreste scoprire che vi mette alla prova consumano risorse talmente tanti che sono negativamente che effettuano le prestazioni. È necessario definire i parametri accettabili per queste applicazioni, e assicurarsi che il suo fare quello che vi aspettate.
Impostare tuoi avvisi Inferiore You Need
Gli avvisi devono andare via prima che i servizi sono rotti. Idealmente questo dovrebbe essere fatto con segnalazioni di avvertimenti, ma per un buon numero di avvertimento persone sono troppo rumorosi. Se stai solo andando a avvisare in caso di errori, impostare la soglia ben al di sotto del livello di servizio si prevede di fornire. Ad esempio, se si dispone di un servizio HTTP, che si prevede di rispondere entro 100 ms, e in genere le risposte all'interno di 25ms, le avvertenze dovrebbe essere fissato a qualcosa di simile a 70ms e gli errori a 80ms. In allarme precoce, la prevenzione di una chiamata da un cliente, o di un boss arrabbiato.
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.