Share
Un'applicazione in esecuzione non è solo un mucchio di codice, il codice deve anche essere eseguito da qualche parte. Sto parlando dei tuoi server di produzione. Altrettanto importante è assicurarsi che le scatole di produzione si comportino da sole, così come assicurarsi che il codice dell'applicazione sia performante. È possibile configurare sistemi come Nagios per aiutarti in questo, ma questi possono essere estremamente complessi con cui lavorare, richiedono un'infrastruttura significativa e possono essere overkill totali (a meno che le tue esigenze di infrastruttura siano estremamente complesse). New Relic offre un'alternativa meno completa ma molto semplice quando si tratta di monitoraggio dell'infrastruttura.
Se hai letto alcuni dei nostri articoli precedenti su New Relic, dovresti essere a casa con il funzionamento dei cruscotti New Relic. I dashboard di monitoraggio dei server utilizzano gli stessi concetti. Se stai già utilizzando New Relic, puoi iniziare a ricevere i dati sulle prestazioni del tuo server molto rapidamente. Anche se non hai precedentemente configurato New Relic, potrebbe valerne la pena utilizzarlo solo per il monitoraggio dei server. Le sei o più dashboard fornite da New Relic possono ritardare in modo significativo (o addirittura rimuovere completamente) la necessità di una soluzione di monitoraggio dell'infrastruttura più completa.
A seconda delle esigenze della tua applicazione, potresti avere un componente web, database, cache, ricerca, bilanciamento del carico, ecc. Alcuni di questi potrebbero condividere la stessa casella. Ma, una volta che la tua applicazione supera una determinata dimensione, inizierai a metterne alcuni in una scatola. Quando hai un solo server di produzione, le cose sono facili. Si SSH in quella scatola, eseguire alcuni comandi della shell e ottenere un'idea abbastanza buona per quanto riguarda l'integrità di quel server. Con la crescita del numero di scatole, questo può diventare un po 'complicato. Sarebbe utile se potessi avere un modo per scoprire subito lo stato di salute di tutte le tue scatole. Questo è esattamente il problema che i cruscotti dei server di New Relic risolvono. Si ottiene immediatamente un'istantanea dello stato di tutti i server di produzione.
Naturalmente, controllare manualmente lo stato di tutti i server non è la cosa più efficiente da fare. Quando le cose vanno male, vuoi scoprirlo non appena succede, non la prossima volta che decidi di controllare. La maggior parte dei sistemi di monitoraggio dell'infrastruttura è in grado di inviare avvisi quando parti specifiche dei server monitorati non funzionano (ad es., Disco pieno, utilizzo di troppa RAM, ecc.). La nuova reliquia non è diversa. È possibile utilizzare l'infrastruttura dei criteri di avviso molto flessibile per inviare notifiche di errore nel modo desiderato, come e-mail, web hook ecc.
Infine, spesso i problemi infrastrutturali non appaiono improvvisamente, il contesto storico è importante. La RAM verrà lentamente consumata per ore prima che la scatola inizi a fallire, il disco si riempirà per giorni prima che le cose vadano alla testa. La verifica spot dei server non ti offre il contesto storico necessario per evitare che si verifichino problemi. Se ti capita di controllare l'utilizzo del disco quando è pieno, puoi fare qualcosa al riguardo. Altrimenti, imparerai solo il problema quando le tue scatole muoiono. New Relic raccoglie dati e li rimanda continuamente ai loro server, quindi i dashboard sono tutti relativi al contesto storico. Questo rende molto facile anticipare alcune classi di problemi.
Lascia che ti racconti un paio di storie. Utilizziamo New Relic in Tuts + per il monitoraggio delle prestazioni delle applicazioni e il monitoraggio dei server. Qualche mese fa ero in servizio, quando le nostre scatole iniziarono a comportarsi male ogni pochi minuti. Non stavano cadendo abbastanza, ma l'applicazione si sarebbe comportata molto male per brevi periodi di tempo. Ho effettuato l'accesso alle caselle e ho scoperto che l'utilizzo della memoria era molto alto. Così ho riavviato i server uno per uno e le cose sembravano andare bene per un po '. Ma poche ore dopo tutto ha ripreso a succedere. Questo puzzava di perdita di memoria.
Così ho effettuato l'accesso a New Relic per dare un'occhiata ai grafici. Abbastanza sicuro, uno dei deploy che abbiamo fatto in precedenza aveva introdotto una perdita di memoria nell'applicazione. Ci vorrebbero alcune ore perché tutta l'memoria venga consumata dall'applicazione, a quel punto si finirebbe in una disperata frenesia della raccolta dei rifiuti, causando ogni sorta di problemi divertenti. Guardando i grafici della memoria su tutte le scatole è stato subito evidente cosa stava succedendo. Al momento non avevamo impostato alcun avviso (lo facciamo ora), quindi non ci siamo resi conto del problema fino a quando non si sono manifestati altri problemi. Ma, essendo in grado di confrontare tutte le caselle l'una con l'altra, oltre ad avere il contesto storico, mi consente di diagnosticare facilmente il problema, di eseguire una correzione e di addormentarmi in orario quella notte.
Ecco un altro. Recentemente si è verificata un'interruzione nel datacenter AWS in cui è ospitato Tuts +. Quando finalmente le cose si sono calmate, abbiamo riavviato tutte le caselle per assicurarci che non ci fossero problemi di insoddisfazione. Ma quando le scatole sono tornate, l'applicazione restituirebbe a intermittenza 500 risposte o funzionerebbe molto male per un po 'di tempo. Questo era probabilmente un problema con uno o più server, il che è molto fastidioso da diagnosticare quando si hanno molte scatole. Ancora una volta, guardando New Relic ci ha permesso di far emergere il problema molto rapidamente. Una delle nostre scatole è tornata con un processo anomalo che stava consumando un sacco di CPU, facendo sì che l'app su quella casella si comportasse male. Un'altra casella è stata influenzata da una sorta di problema tecnico di AWS che ha causato il 100% dell'utilizzo IO del disco di quella casella. Abbiamo tolto questa scatola dal nostro sistema di bilanciamento del carico, ci siamo sbarazzati del processo anomalo sull'altro e l'applicazione ha iniziato a funzionare di nuovo bene.
I grafici di New Relic sono veramente utili e non vorrei farne a meno, quindi mostrami come ottenere il monitoraggio del server attivo e funzionante.
In pratica, tutto si riduce all'accesso al server e all'installazione del daemon di monitoraggio del server New Relic (nrsysmond). Se hai letto l'articolo New Relic per PHP, la procedura è quasi identica. Come al solito, supponiamo di essere su Ubuntu.
La prima cosa da fare è importare la chiave del repository New Relic:
wget -O - https://download.newrelic.com/548C16BF.gpg | sudo apt-key add -
Ora aggiungiamo il repository New Relic al sistema:
sudo sh -c 'echo "deb http://apt.newrelic.com/debian/ newrelic non-libero"> /etc/apt/sources.list.d/newrelic.list'
Ora usiamo solo adatto:
sudo apt-get update sudo apt-get install newrelic-sysmond
Dopo aver terminato l'installazione, riceverai un bel messaggio come questo:
************************************************** ******************* ******************************* ************************************** *** *** Impossibile avviare la nuova reliquia Server Monitor fino a quando non si inserisce una chiave di licenza valida nel seguente file: *** *** /etc/newrelic/nrsysmond.cfg *** *** È possibile farlo eseguendo il seguente comando come root: * ** *** nrsysmond-config --set license_key =*** *** Nessun dato verrà segnalato fino all'avvio del monitor del server. *** Puoi ottenere la nuova chiave Relic dalla sezione 'Configurazione' *** del menu 'Supporto' del tuo account New Relic (accessibile da *** https://rpm.newrelic.com). *** *********************************************** ********************** **************************** *****************************************
Facciamo quello che dice. Innanzitutto, passiamo alle impostazioni del nostro account Relic nuovo per cercare la nostra chiave di licenza (sarà sulla destra):
Ora eseguiamo il comando:
nrsysmond-config --set license_key =
Se controlli ora il file di configurazione: /etc/newrelic/nrsysmond.cfg. Vedrai la tua chiave di licenza lì. Siamo pronti per avviare l'agente:
/etc/init.d/newrelic-sysmond start
Ora puoi controllare la lista dei processi per assicurarti che sia in esecuzione:
ps -ef | grep nrsys newrelic 10087 1 0 09:25? 00:00:00 / usr / sbin / nrsysmond -c /etc/newrelic/nrsysmond.cfg -p /var/run/newrelic/nrsysmond.pid newrelic 10089 10087 0 09:25? 00:00:00 / usr / sbin / nrsysmond -c /etc/newrelic/nrsysmond.cfg -p /var/run/newrelic/nrsysmond.pid ubuntu 10100 9734 0 09:25 pts / 1 00:00:00 grep - -color = auto nrsys
Come per l'agente PHP, ci sono due processi. Uno è un processo di monitoraggio e il secondo è l'operatore. Il lavoratore fa effettivamente il lavoro di comunicazione con i server New Relic, il processo di monitoraggio semplicemente guarda il lavoratore e se il lavoratore muore, per qualsiasi motivo, ne genera uno nuovo.
Possiamo anche controllare i log per accertarci che non ci siano errori all'avvio:
cat /var/log/newrelic/nrsysmond.log 2014-05-25 09:25:02 [10089 / main] sempre: nuova Relic Server Monitor versione 1.4.0.471/C+IA avviata - pid = 10089 background = true SSL = true ca_bundle =ca_path = host = ip-10-196-10-195 2014-05-25 09:25:03 [10089 / main] informazioni: reindirizzamento RPM: collector-102.newrelic.com (50.31.164.202) porta 0 (0 significa porta predefinita )
Tutto sembra a posto e ora dovresti iniziare a vedere i dati visualizzati nell'interfaccia utente di New Relic.
Nella maggior parte dei casi non è necessario configurare altro oltre la chiave di licenza, ma se è necessario aumentare il livello di log o configurare un proxy, è sicuramente possibile. Tutto vive in /etc/newrelic/nrsysmond.cfg. Il file è molto ben commentato e abbastanza auto-esplicativo. Se cambi qualcosa, ricordati di ricomincia il demone:
/etc/init.d/newrelic-sysmond restart
C'è solo una cosa sottile quando si configura il monitoraggio del server e questo è il nome del server, come verrà visto nei dashboard di New Relic. Per impostazione predefinita, New Relic prenderà il nome host della casella e creerà il nome del server nei dashboard (ad esempio, l'output del hostname comando). Ti raccomando di tenerlo così. Se stai utilizzando New Relic anche per il monitoraggio delle applicazioni, mantenendo il nome host, come output da hostname comando, poiché il nome del server garantirà che New Relic possa calcolare correttamente quali applicazioni sono in esecuzione su quali caselle e collegare tutto correttamente nell'interfaccia utente.
Se proprio devi, puoi cambiare il nome del server così come apparirà nell'interfaccia utente impostando il hostname = parametro nel file di configurazione: /etc/newrelic/nrsysmond.cfg. Dovrai riavviare il demone affinché questo abbia effetto. È inoltre possibile modificare il nome del server direttamente nell'interfaccia utente che non influirà sul daemon.
La prima cosa che vedi quando clicchi server il collegamento a sinistra è un'istantanea di tutti i tuoi server e le metriche chiave per tutti loro (CPU, disco, memoria, IO).
Questa pagina può farti vedere se una o più delle tue scatole sono ovviamente inadatte. Qui puoi anche rinominare un server o aggiungere tag ad esso, se necessario.
Se clicchiamo su uno dei server, arriviamo al dashboard del server principale:
Ci sono sei metriche principali qui:
Questo ti darà una veloce panoramica di un particolare server. È possibile eseguire il drill down in ciascuno dei grafici per ottenere ulteriori informazioni. Ad esempio, è possibile eseguire il drill down nel grafico della CPU per vedere quali processi stanno utilizzando la CPU:
Oppure puoi approfondire il grafico del disco per vedere la tua velocità di I / O, una suddivisione di letture e scritture, oltre a ottenere una stima di quanto tempo ci vorrà prima che il tuo disco sia pieno.
La parte migliore è che puoi utilizzare le stesse operazioni su tutti questi grafici come puoi nei grafici a livello di applicazione. Quindi, puoi ingrandire una finestra di cinque minuti per osservare il picco dell'utilizzo della CPU più da vicino, oppure puoi dare un'occhiata a un trend di sette giorni nell'utilizzo della memoria.
La parte migliore è che i grafici sono semplici da capire, non sei sopraffatto dalle metriche e puoi confrontare caselle simili tra loro. Questo può aiutarti a diagnosticare il 99% dei problemi comuni che potresti incontrare con la tua infrastruttura.
New Relic ha recentemente lavorato molto per migliorare le loro capacità di alerting. Le politiche di avviso sono ciò che hanno scoperto in tutto il loro sistema (ad esempio, esistono criteri di avviso dell'applicazione per i criteri di avviso dell'applicazione e del server per le caselle). All'inizio potrebbe essere un po 'confuso, ma è piuttosto semplice una volta capito. Ci sono due concetti, politiche e canali principali. In termini di avvisi del server, funziona in questo modo:
Impostiamo una politica e assegniamo alcuni server ad essa:
Crei anche un canale (ad esempio email, webhook) a cui inviare gli avvisi:
Quindi si assegna un canale a una politica. Da quel momento in poi, a seconda delle impostazioni del canale (ad esempio, primo evento critico, tutti gli eventi critici, solo tempi di inattività). Riceverai le notifiche su quel canale.
L'unico bit di confusione sulle politiche di avviso è dove trovarle. Vivono sotto Strumenti-> politiche di avviso:
È quindi necessario fare clic su server nel menu in alto, per trovare le politiche di avviso del server.
Se stai già utilizzando una soluzione di monitoraggio dell'infrastruttura come Nagios e sta funzionando bene per te, allora potresti non ottenere troppi extra dal monitoraggio dei server di New Relic (sebbene i grafici e le tendenze storiche siano piuttosto eccellenti). Tuttavia, se non stai monitorando la tua infrastruttura o se la tua attuale soluzione non funziona, sicuramente provi New Relic. Per me, è diventato il primo strumento a cui mi rivolgo quando sospetto che qualcosa non va nei miei server. E abbastanza spesso mi farà sapere che il problema si sta preparando prima che la situazione diventi critica. Come sviluppatori, questo è il tipo di strumenti che vogliamo tutti nel nostro arsenale.
Accentsconagua