Nel mondo degli ingegneri SRE/DevOps, non sorprende che un giorno appaia un cliente (o un sistema di monitoraggio) e segnali che "è tutto finito": il sito non funziona, i pagamenti non passano, la vita è vana... Per quanto si voglia aiutare in una situazione del genere, farlo senza uno strumento semplice e comprensibile può essere molto difficile. Spesso il problema è nascosto nel codice dell'applicazione stessa: bisogna solo localizzarlo.
Nella gioia e nel dolore…
Dopo tutto questo tempo, abbiamo sviluppato un grande amore per New Relic. È stato e rimane un ottimo strumento per il monitoraggio delle prestazioni delle applicazioni e consente anche di strumentare un'architettura a microservizi (tramite il suo agente) e molto, molto altro. E tutto sarebbe stato meraviglioso, se non fosse stato per i cambiamenti nella politica dei prezzi del servizio: esso costo . Inoltre, dall'anno scorso, per ottenere un account di prova è necessario comunicare con un manager personale, il che complica la presentazione del prodotto ai potenziali clienti.Situazione tipica: New Relic non è necessario in "modo continuativo", viene ricordato solo quando iniziano i problemi. Ma si deve comunque pagare regolarmente (140 USD per server al mese), e in un'infrastruttura cloud che si scala automaticamente, le somme si accumulano. Anche se c'è la possibilità di "Pay-As-You-Go", per attivare New Relic è necessario riavviare l'applicazione, il che può portare alla perdita della situazione problematica per cui tutto è stato avviato. Non molto tempo fa, New Relic ha introdotto un nuovo piano tariffario —
Essentials Key Transactions Cross Application Tracing, Distributed Tracing, Di conseguenza, abbiamo iniziato a cercare un'alternativa più economica, e la nostra scelta è ricaduta su due servizi: Datadog e Atatus. Perché proprio su di loro?).
Sui concorrenti
Vorrei chiarire che sul mercato ci sono altre soluzioni. Abbiamo persino considerato opzioni Open Source, ma non tutti i clienti hanno capacità disponibili per l'implementazione di soluzioni della categoria self-hosted… — inoltre, richiederanno ulteriore manutenzione. La coppia che abbiamo scelto si è rivelata la più vicina a
le nostre esigenze nostre esigenze:
- supporto PHP integrato e avanzato (il nostro stack è molto vario, ma questo è indubbiamente un leader nel contesto della ricerca di alternative a New Relic);
- costo accessibile (meno di 100 USD al mese per l'hosting);
- strumentazione automatica;
- integrazione con Kubernetes;
- similitudine con l'interfaccia di New Relic — un vantaggio notevole (perché i nostri ingegneri ci sono abituati).
Pertanto, nella fase di selezione iniziale, abbiamo escluso diverse altre soluzioni popolari, in particolare:
- Tideways, AppDynamics e Dynatrace — per il costo;
- Stackify — bloccato in RF e mostra troppo pochi dati.
L'articolo seguente è strutturato in modo tale che inizialmente verranno brevemente presentate le soluzioni considerate, dopodiché parlerò del nostro interazione tipica con New Relic e delle esperienze/impressioni nell'eseguire operazioni simili in altri servizi.
Presentazione dei concorrenti selezionati
Su , probabilmente, l'ha sentito ognuno? Questo servizio ha iniziato il suo sviluppo oltre 10 anni fa, nel 2008. Lo utilizziamo attivamente dal 2012 e non abbiamo mai riscontrato problemi nell'integrare un numero veramente elevato di applicazioni in PHP, Ruby e Python, e abbiamo anche avuto esperienza di integrazione con C# e Go. Gli autori del servizio hanno soluzioni per il monitoraggio delle applicazioni, infrastrutture, tracciamento delle infrastrutture microservizi, sono state create applicazioni convenienti per i dispositivi degli utenti e molto altro.
Tuttavia, l'agente di New Relic funziona con protocolli proprietari, non supporta OpenTracing. Per una strumentazione avanzata, è necessario apportare modifiche specifiche per New Relic. Infine, il supporto per Kubernetes ha attualmente uno status sperimentale.
Avviato nel 2010 si presenta decisamente più interessante di New Relic proprio in termini di applicazione negli ambienti Kubernetes. In particolare, supporta integrazioni con NGINX Ingress, raccolta di log, protocolli statsd e OpenTracing, che consente di tracciare la richiesta dell'utente dall'istante della connessione fino al completamento dell'operazione, oltre a trovare i log relativi a questa richiesta (sia dal lato del server web che dal lato dei consumer).
Utilizzando Datadog, abbiamo riscontrato che a volte costruiva in modo errato la mappa dei microservizi e presentava alcuni difetti tecnici. Ad esempio, identificava erroneamente il tipo di servizio (ha scambiato Django per un servizio di caching) e causava errori 500 in un'applicazione PHP che utilizzava la popolare libreria Predis.
— il più giovane strumento; il servizio è stato lanciato nel 2014. Il suo budget di marketing è chiaramente inferiore a quello dei competitor elencati, e le menzioni sono significativamente più rare. Tuttavia, lo strumento in sé è molto simile a New Relic, non solo nelle funzionalità (APM, Browser monitoring, ecc.), ma anche nell'aspetto.
Un notevole svantaggio è il supporto limitato a Node.js e PHP. D'altra parte, è implementato in modo notevolmente migliore rispetto a Datadog. A differenza dell'ultimo, Atatus non richiede modifiche alle applicazioni o l'aggiunta di etichette extra nel codice.
Come lavoriamo con New Relic
Ora facciamo chiarezza su come utilizziamo generalmente New Relic. Supponiamo di avere un problema che necessita di soluzione:
Nel grafico è facile notare un picco — analizziamolo. In New Relic per l'applicazione web sono selezionate immediatamente le transazioni web, nel grafico delle performance sono indicati tutti i componenti, ci sono i pannelli error-rate, request-rate... La cosa importante è che da questi pannelli si può navigare tra le varie parti dell'applicazione (per esempio, un clic su MySQL porterà alla sezione dei database).
Poiché nell'esempio considerato vediamo un picco di attività PHP, facciamo clic su questo grafico e passeremo automaticamente a Transazioni:
L'elenco delle transazioni, che sono fondamentalmente controller del modello MVC, è già ordinato per Le più dispendiose in termini di tempo, il che è molto comodo: vediamo subito cosa sta facendo l'applicazione. Qui ci sono anche esempi di richieste lunghe, che vengono raccolte automaticamente da New Relic. Cambiando l'ordinamento, è facile trovare:
- il controller dell'applicazione più sollecitato;
- il controller più frequentemente richiesto;
- il più lento dei controller.
Inoltre, è possibile espandere ogni transazione e vedere cosa stava facendo l'applicazione al momento dell'esecuzione del codice:
Infine, nell'applicazione vengono salvati esempi dei trace delle richieste lunghe (che richiedono più di 2 secondi). Ecco il pannello per una lunga transazione:
È evidente che due metodi richiedono molto tempo, e viene mostrato anche il tempo in cui è stata eseguita la richiesta, il suo URI e il dominio. Questo aiuta molto a trovare la richiesta nei log. Passando a Dettagli del Trace, è possibile vedere da dove vengono chiamati questi metodi:
E a Query del database — valutare le richieste ai database che sono state eseguite durante il funzionamento dell'applicazione:
Armati di queste conoscenze, possiamo valutare la causa del rallentamento dell'applicazione e collaborare con lo sviluppatore per elaborare una strategia di risoluzione del problema. In realtà, New Relic non sempre fornisce un quadro chiaro, ma aiuta a scegliere la direzione dell'indagine:
- lungo
PDO::Constructci ha portato a un funzionamento strano di pgpoll; - instabilità nel tempo
Memcache::Getha suggerito una configurazione errata della macchina virtuale; - un tempo di elaborazione del modello sospettosamente aumentato ha portato a un ciclo nidificato che controlla la presenza di 500 avatar nello storage degli oggetti;
- e così via…
Può anche accadere che, invece di eseguire codice sullo schermo principale, emerga qualcosa legato a storage esterno — e non importa se sia Redis o PostgreSQL, — tutti si nascondono nella scheda Database.
È possibile selezionare un database specifico per l'analisi e ordinare le query — in modo simile a come si fa in Transactions. Passando alla scheda delle query, è possibile vedere quante volte appare questa query in ciascuno dei controller dell'applicazione e anche valutare quanto spesso viene chiamata. È molto comodo:
Dati simili sono disponibili nella scheda Servizi Esterni, che contiene le richieste verso i servizi HTTP esterni, come accessi allo storage degli oggetti, invio di eventi a sentry o simili. Il contenuto della scheda è completamente analogo a Databases:
Competitor: funzionalità e impressioni
Ora arriva il momento interessante: confrontiamo le funzionalità di New Relic con quelle offerte dai competitor. Purtroppo, non siamo riusciti a testare tutti e tre gli strumenti sulla stessa versione di un'applicazione funzionante in produzione. Tuttavia, abbiamo cercato di confrontare situazioni/configurazioni il più identiche possibile.
1. Datadog
Datadog ci accoglie con un pannello e una wall dei servizi:
Cerca di suddividere le applicazioni in componenti/microservizi, quindi nell'applicazione Django fornita come esempio vedremo 2 connessioni a PostgreSQL (defaultdb e postgres), e anche Celery, Redis. Lavorare con Datadog richiede da parte vostra conoscenze minime dei principi MVC: è necessario capire dove vanno a finire le richieste degli utenti. Di solito, questo è facilitato da una mappa dei servizi:
A proposito, qualcosa di simile è disponibile anche in New Relic:
… e la loro mappa, a mio avviso, è fatta in modo più semplice e chiaro: mostra solo specifici servizi o microservizi, invece dei componenti di un'applicazione (il che la renderebbe eccessivamente dettagliata, come nel caso di Datadog).
Torniamo a Datadog: dalla mappa dei servizi si vede che le richieste degli utenti arrivano a Django. Passiamo al servizio Django e finalmente vedremo ciò che ci aspettavamo:
Sfortunatamente, qui non c'è un grafico per impostazione predefinita. Tempo di transazione web, simile a quello che vediamo nella dashboard principale di New Relic. Tuttavia, può essere configurato al posto del grafico. % del tempo speso. È sufficiente commutarlo in Tempo medio per richiesta per tipo… e voilà, il grafico familiare ci guarda!
Perché in Datadog è stato scelto un grafico diverso è un mistero per noi. Ci ha anche deluso che il sistema non memorizza la scelta dell'utente (a differenza di entrambi i concorrenti), quindi l'unica soluzione è creare pannelli personalizzati.
Tuttavia, abbiamo apprezzato la possibilità in Datadog di passare da questi grafici alle metriche dei server associati, leggere i log e valutare il carico dei gestori del server web (Gunicorn). È tutto quasi come in New Relic… e anche un po' di più (i log)!
Sotto i grafici ci sono le transazioni, del tutto analoghe a New Relic:
In Datadog le transazioni sono chiamate risorse. È possibile ordinare i controller in base al numero di richieste, al tempo medio di risposta e al tempo massimo speso in un intervallo di tempo selezionato.
La risorsa può essere espansa per vedere tutto ciò che abbiamo già osservato in New Relic:
Sono disponibili statistiche sulla risorsa, un elenco riassuntivo delle chiamate interne e esempi di richieste che possono essere ordinate per codice di risposta… Questa ordinazione è piaciuta molto ai nostri ingegneri.
Qualsiasi esempio di risorsa in Datadog può essere aperto e studiato:
Sono presentati i parametri della richiesta, un diagramma riassuntivo del tempo speso per ciascun componente e un diagramma a cascata che mostra la sequenza delle chiamate. È anche disponibile il passaggio a una visualizzazione ad albero del diagramma a cascata:
E la cosa più interessante è la visualizzazione del carico dell'host su cui è stata eseguita la richiesta e la visualizzazione dei log della richiesta.
Ottima integrazione!
Può sorgere la domanda, dove sono le schede Database e Servizi Esterni, come in New Relic. Qui non ci sono: poiché Datadog analizza l'applicazione in componenti, PostgreSQL sarà considerato un servizio separato, mentre invece dei servizi esterni si dovranno cercare aws.storage (analogamente sarà per ogni altro servizio esterno a cui l'applicazione può fare riferimento).
Ecco un esempio con postgres:
In sostanza, c'è tutto ciò che volevamo:
È evidente da quale 'servizio' è arrivata la richiesta.
Non è superfluo ricordare che Datadog si integra perfettamente con NGINX Ingress e permette di eseguire un tracciamento end-to-end dal momento in cui la richiesta entra nel cluster, oltre a raccogliere metriche statsd, log e metriche degli host.
Un grande vantaggio di Datadog è che il suo prezzo è composto da monitoraggio dell'infrastruttura, APM, Log Management e Synthetics test, ovvero è possibile scegliere un piano flessibile.
2. Atatus
Il team di Atatus sostiene che il loro servizio è 'come New Relic, ma migliore'. Vediamo se è davvero così.
La dashboard sembra effettivamente simile, ma non siamo riusciti a identificare Redis e memcached utilizzati nell'applicazione.
APM seleziona per impostazione predefinita tutte le transazioni, anche se di solito servono solo quelle Web. Come in Datadog, non c'è la possibilità di passare al servizio desiderato direttamente dalla dashboard principale. Inoltre, le transazioni si trovano nell'elenco dopo gli errori, il che per APM non appare molto logico.
Nelle transazioni, Atatus è molto simile a New Relic. Un contro è che non si vedono immediatamente le dinamiche di ciascun controller. Bisogna cercarle nella tabella dei controller, ordinando per Most Time Consumed:
L’elenco dei controllori a noi familiare è disponibile nella scheda Esplora:
Questa tabella ricorda in qualche modo Datadog e risulta più piacevole rispetto a quella simile di New Relic.
Ogni transazione può essere espansa per vedere cosa ha fatto l'applicazione:
La dashboard ricorda piuttosto Datadog: mostra il numero di richieste e un quadro generale delle chiamate. La parte superiore della dashboard fornisce una scheda con gli errori HTTP Failures e esempi di richieste lente Session Traces:
Se si passa a una transazione, si vede un esempio di trace, è possibile ottenere un elenco delle richieste al database e vedere gli header della richiesta. È completamente analogo a New Relic:
In generale, Atatus ha impressionato con trace dettagliati, senza le tipiche unificazioni di chiamate in un blocco di promemoria di New Relic:
Tuttavia, manca un filtro che (come in New Relic) escluda le richieste ultra-veloci (<5ms). D'altro canto, mi è piaciuta la visualizzazione della risposta finale della transazione (successo o errore).
Pannello Database aiuterà a esaminare le richieste ai database esterni fatte dall'applicazione. Ricordo che Atatus ha trovato solo PostgreSQL e MySQL, anche se nel progetto sono coinvolti anche Redis e memcached.
Le query vengono ordinate secondo criteri familiari: frequenza di attivazione, tempo medio di risposta e così via. È particolarmente utile notare la scheda con le query più lente: è molto comodo. Inoltre, i dati in questa scheda per PostgreSQL sono coincisi con i dati dell'estensione — ottimo risultato!
Scheda Richieste esterne è completamente identica a Databases.
Conclusioni
Entrambi gli strumenti presentati hanno mostrato buone prestazioni come APM. Ognuno di essi può offrire il minimo necessario. Possiamo riassumere le nostre impressioni in questo modo:
Datadog
Pro:
- griglia tariffaria comoda (l'APM costa 31 USD per host);
- ha funzionato eccellentemente con Python;
- possibilità di integrazione con OpenTracing
- integrazione con Kubernetes;
- integrazione con NGINX Ingress.
Contro:
- l'unico APM che ha causato l'indisponibilità dell'applicazione a causa di un errore del modulo (predis);
- debole auto-instrumentazione PHP;
- in parte strano nella definizione dei servizi e dei loro scopi.
Atatus
Pro:
- profonda strumentazione PHP;
- interfaccia utente simile a New Relic.
Contro:
- non funziona su sistemi operativi datati (Ubuntu 12.05, CentOS 5);
- debole auto-instrumentazione;
- supporto per soli due linguaggi di programmazione (Node.js e PHP);
- lentezza nell'interfaccia.
Considerando il prezzo di Atatus di 69 USD al mese per server, utilizzeremmo piuttosto Datadog, che si integra ottimamente con le nostre esigenze (applicazioni web in K8s) e offre molte funzionalità utili.
P.S.
Leggi anche nel nostro blog:
- «»;
- «»;
- «».
Fonte: habr.com
