Nell'ambito degli ingegneri SRE e DevOps, non sorprende che a un certo punto un cliente (o un sistema di monitoraggio) possa segnalare che 'è tutto finito': il sito non funziona, i pagamenti non vengono elaborati, la vita è triste... Per quanto si desideri aiutare in una situazione simile, farlo senza uno strumento semplice e chiaro è spesso molto difficile. Spesso il problema si cela nel codice dell'applicazione stessa: è necessario solo localizzarlo.
Nella gioia e nel dolore...
È così che, da molto tempo, abbiamo sviluppato un grande affetto per New Relic. È uno strumento eccellente per monitorare le prestazioni delle applicazioni e consente anche di strumentare architetture a microservizi (attraverso il suo agente) e molto altro. Tutto potrebbe andare bene se non fosse per i cambiamenti nella politica dei prezzi del servizio: il suo costo è aumentato di oltre 3 volte. Inoltre, dall'anno scorso, per ottenere un account trial è necessario comunicare con un manager personale, il che rende difficile presentare il prodotto a potenziali clienti.
Situazione comune: New Relic non è necessario su base 'permanente'; si ricorda di lui solo quando sorgono problemi. Ma il pagamento è comunque necessario regolarmente (140 USD al mese per server), e in un'infrastruttura cloud auto-scalabile, le somme possono diventare significative. Anche se c'è la possibilità di 'Pay-As-You-Go', attivare New Relic richiederà un riavvio dell'applicazione, il che può portare alla perdita della situazione problematica per cui tutto è stato impostato. Recentemente, New Relic ha introdotto un nuovo piano tariffario — , — che a prima vista appare una ragionevole alternativa a Professional… ma con un'esaminazione più dettagliata, si è rivelato che alcune funzionalità importanti mancano (in particolare, non ha Key Transactions, Cross Application Tracing, Distributed Tracing).
Di conseguenza, abbiamo iniziato a cercare un'alternativa più economica, e la nostra scelta è caduta su due servizi: Datadog e Atatus. Perché proprio su di essi?
Sui concorrenti
Voglio precisare subito che sul mercato ci sono anche altre soluzioni. Abbiamo anche considerato opzioni Open Source, ma non tutti i clienti hanno sufficienti risorse per ospitare soluzioni di tipo self-hosted... inoltre, richiederanno ulteriore manutenzione. Le due soluzioni che abbiamo scelto si sono rivelate le più vicine a le nostre esigenze:
- un supporto integrato e sviluppato per le applicazioni PHP (il panorama dei nostri clienti è molto vario, ma questo è decisamente leader in termini di ricerca di alternative a New Relic);
- un costo accessibile (meno di 100 USD al mese per l'hosting);
- strumentazione automatica;
- integrazione con Kubernetes;
- somiglianza con l'interfaccia di New Relic — un chiaro vantaggio (poiché i nostri ingegneri vi sono abituati).
Pertanto, nella fase di selezione iniziale abbiamo escluso alcune altre soluzioni popolari, in particolare:
- Tideways, AppDynamics e Dynatrace — a causa del costo;
- Stackify — bloccato in RF e mostra troppe poche informazioni.
Il restante articolo è strutturato in modo che inizialmente verranno brevemente presentate le soluzioni analizzate, dopo di che racconterò del nostro tipico interazione con New Relic e delle esperienze/impressioni nell'esecuzione di operazioni simili in altri servizi.
Presentazione dei concorrenti selezionati
Riguardo , probabilmente l'hai sentito? Questo servizio ha iniziato a svilupparsi oltre 10 anni fa, nel 2008. Lo utilizziamo attivamente dal 2012 e non abbiamo mai riscontrato problemi nell'integrazione di un numero veramente elevato di applicazioni in linguaggi come PHP, Ruby e Python, e abbiamo anche esperienza con integrazioni in C# e Go. Gli autori del servizio offrono soluzioni per il monitoraggio delle applicazioni, dell'infrastruttura, la tracciabilità delle infrastrutture microservizi, hanno creato applicazioni facili da usare per i dispositivi degli utenti e molto altro.
Tuttavia, l'agente New Relic opera su protocolli proprietari e non supporta OpenTracing. Per un'implementazione avanzata è necessario apportare modifiche specifiche per New Relic. Infine, il supporto per Kubernetes è attualmente in fase sperimentale.
Sviluppato nel 2010 sembra decisamente più interessante di New Relic per quanto riguarda l'applicazione in ambienti Kubernetes. In particolare, supporta l'integrazione con NGINX Ingress, la raccolta di log, i protocolli statsd e OpenTracing, che consente di tracciare la richiesta dell'utente dal momento in cui si connette fino alla conclusione del lavoro, oltre a trovare i log relativi a quella richiesta (sia dal lato del server web che dal lato dei consumer).
Utilizzando Datadog, ci siamo trovati di fronte al problema che a volte costruiva erroneamente la mappa dei microservizi, oltre ad alcuni difetti tecnici. Ad esempio, identificava erroneamente il tipo di servizio (interpretando Django come un servizio di caching) e causava errori 500 nell'applicazione PHP che utilizzava la popolare libreria Predis.
è lo strumento più giovane; il servizio è stato lanciato nel 2014. Il suo budget di marketing è chiaramente inferiore a quello dei concorrenti menzionati, e i riferimenti sono notevolmente più rari. Tuttavia, lo strumento stesso è molto simile a New Relic, non solo nelle funzionalità (APM, monitoraggio del browser, ecc.), ma anche nell'aspetto.
Un notevole svantaggio è il supporto limitato a Node.js e PHP. D'altra parte, è implementato in modo significativamente migliore rispetto a Datadog. A differenza di quest'ultimo, Atatus non richiede modifiche alle applicazioni o l'aggiunta di etichette nel codice.
Come lavoriamo con New Relic
Ora vedremo come utilizziamo normalmente New Relic. Supponiamo di avere un problema che necessita di una soluzione:
Nel grafico è facile notare un picco — analizziamolo. In New Relic per l'applicazione web, sono immediatamente selezionate le transazioni web; nel grafico delle prestazioni sono presenti tutti i componenti, ci sono pannelli per il tasso di errore e il tasso di richiesta... Ciò che è fondamentale è che proprio da questi pannelli è possibile navigare tra le diverse parti dell'applicazione (per esempio, un clic su MySQL porterà alla sezione dei database).
Poiché nell'esempio in discussione vediamo un picco di attività PHP, clicchiamo su questo grafico e passeremo automaticamente a Transazioni:
L'elenco delle transazioni, che sono sostanzialmente i controllori del modello MVC, è già ordinato per Più tempo impegnativo, che è molto conveniente: vediamo subito cosa fa l'applicazione. Qui sono presenti esempi di richieste lunghe, che vengono raccolte automaticamente da New Relic. Cambiando l'ordinamento, è facile trovare:
- il controller dell'applicazione più sovraccarico;
- il controller più richiesto;
- il più lento tra i controller.
Inoltre, è possibile espandere ogni transazione e vedere cosa ha fatto l'applicazione durante l'esecuzione del codice:
Infine, nell'applicazione vengono memorizzati esempi di trace di richieste lunghe (che impiegano più di 2 secondi). Ecco il pannello per una transazione lunga:
È evidente che due metodi richiedono molto tempo, e insieme a questo viene mostrato anche il tempo in cui è stata eseguita la richiesta, il suo URI e il dominio. Questo aiuta spesso a trovare la richiesta nei log. Andando a Dettagli trace, è possibile vedere da dove vengono chiamati questi metodi:
E in Query del database concedere una valutazione delle query ai database che sono state eseguite al momento del funzionamento dell'applicazione:
Armati di queste conoscenze, possiamo valutare la causa del rallentamento dell'applicazione e, insieme allo sviluppatore, elaborare una strategia per risolvere il problema. In realtà, New Relic non offre sempre 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 insolitamente elevato ha portato a un ciclo annidato che verifica la presenza di 500 avatar nella memoria oggetti;
- e così via…
Può anche capitare che, invece di eseguire il codice nella schermata principale, cresca qualcosa legato a un'archiviazione esterna dei dati — e non importa cosa sia: Redis o PostgreSQL, — si nascondono tutti sotto la scheda Databases.
È possibile scegliere un database specifico per l'analisi e ordinare le query — analogamente a quanto avviene in Transactions. Inoltre, passando alla scheda delle query, è possibile vedere quante volte questa query viene chiamata in ciascun controller dell'applicazione e valutare con quale frequenza viene invocata. Questo è molto utile:
Dati simili sono forniti dalla scheda External Services, che nasconde richieste ai servizi HTTP esterni, come l'accesso a uno storage oggetti, l'invio di eventi a Sentry o simili. Contenutisticamente, la scheda è completamente analoga a Databases:
Concorrenti: possibilità e impressioni
Ora la parte interessante: confrontiamo le funzionalità di New Relic con quelle offerte dai concorrenti. Sfortunatamente, non siamo riusciti a testare tutti e tre gli strumenti su una versione dello stesso applicativo funzionante in produzione. Tuttavia, abbiamo cercato di confrontare situazioni/configurazioni il più identiche possibile.
1. Datadog
Datadog ci accoglie con un pannello e una bacheca di servizi:
Cerca di suddividere le applicazioni in componenti/microservizi, quindi nell'esempio dell'applicazione Django 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 arrivano le richieste degli utenti. Di solito, questo è facilitato da una mappa dei servizi:
A proposito, qualcosa di simile è presente anche in New Relic:
… e la loro mappa, a mio avviso, è più semplice e chiara: mostra solo i servizi o microservizi specifici, invece di rappresentare i componenti di un'unica 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 vediamo ciò che ci aspettavamo:
Sfortunatamente, di default non c'è un grafico Tempo di transazione web, simile a quello che vediamo sulla dashboard principale di New Relic. Tuttavia, è possibile configurarlo al posto del grafico % del tempo speso. Basta cambiarlo in Tempo medio per richiesta per tipo… ed ecco che il grafico familiare ci guarda!
Perché Datadog ha scelto un grafico diverso è un mistero per noi. Ci ha anche delusi il fatto che il sistema non ricordi la scelta dell'utente (a differenza di entrambi i concorrenti), e quindi – l'unica salvezza è creare dashboard personalizzate.
Tuttavia, ci ha soddisfatto la possibilità in Datadog di passare da questi grafici alle metriche dei server correlati, 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 si trovano le transazioni, del tutto simili a quelle di New Relic:
In Datadog, le transazioni vengono chiamate risorse. È possibile ordinare i controller in base al numero di richieste, al tempo medio di risposta o al massimo tempo impiegato nel periodo selezionato.
È possibile espandere la risorsa e vedere tutto ciò che abbiamo già osservato in New Relic:
Sono presenti sia statistiche sulla risorsa, sia un elenco riassuntivo delle chiamate interne e degli esempi di richieste, che possono essere ordinati in base al codice di risposta… A proposito, questa funzionalità di ordinamento è 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 impiegato per ciascun componente e un diagramma a cascata che mostra la sequenza delle chiamate. È anche disponibile la possibilità di passare a una visualizzazione ad albero del diagramma a cascata:
E la cosa più interessante è la visualizzazione del carico dell'host che ha eseguito la richiesta e la visualizzazione dei log della richiesta.
Ottima integrazione!
Potrebbe sorgere la domanda, dove sono le schede Databases e External Services, come in New Relic. Qui non ci sono: poiché Datadog suddivide l'applicazione in componenti, PostgreSQL sarà considerato come servizio separato, e invece di External Services si deve cercare aws.storage (lo stesso varrà per ogni altro servizio esterno a cui l'applicazione può connettersi).
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 consente di eseguire tracciamenti end-to-end dal momento in cui la richiesta arriva nel cluster, oltre a ricevere metriche statsd, raccogliere log e metriche degli host.
Un grande vantaggio di Datadog è che il suo prezzo è composto dal monitoraggio dell'infrastruttura, APM, gestione dei log e test Synthetics, quindi è possibile scegliere un piano in modo flessibile.
2. Atatus
Il team di Atatus afferma che il loro servizio è 'come New Relic, ma migliore'. Vediamo se è davvero così.
Il pannello principale sembra effettivamente simile, ma non sono riuscito a identificare i Redis e memcached utilizzati nell'applicazione.
APM seleziona tutte le transazioni di default, anche se, di solito, sono necessarie solo quelle web. Come in Datadog, non c'è la possibilità di passare al servizio necessario dalla pannello principale. Inoltre, le transazioni si trovano nell'elenco dopo gli errori, il che non sembra molto logico per un APM.
Nelle transazioni di Atatus, tutto assomiglia molto a New Relic. L'unico svantaggio è che non si può vedere immediatamente la dinamica per ciascun controller. Occorre cercarla nella tabella dei controller, ordinando per Tempo massimo consumato:
L'elenco dei controller a noi familiari è disponibile nella scheda Esplora:
Questa tabella ricorda in qualche modo Datadog, risultando preferibile rispetto a quella simile di New Relic.
Ogni transazione può essere espansa per vedere in cosa è stato impegnato l'applicativo:
Il pannello ricorda anch'esso Datadog: ci sono il numero di richieste e una panoramica generale delle chiamate. La parte superiore del pannello fornisce una scheda con gli errori Errori HTTP e esempi di richieste lente Tracce di sessione:
Se si passa alla transazione, si può visualizzare un esempio di traccia, ottenere l'elenco delle richieste al database e controllare le intestazioni della richiesta. Il tutto è simile a New Relic:
In generale, Atatus ha sorpreso con tracciamenti dettagliati — senza le tipiche unioni di chiamate in un blocco di promemoria come in New Relic:
Tuttavia, manca un filtro che, come in New Relic, escluda le richieste super rapide (<5 ms). D'altra parte, è piaciuta la visualizzazione della risposta finale della transazione (successo o errore).
Panello Databases aiuterà a studiare le richieste verso i database esterni fatte dall'applicazione. Ricordo che Atatus ha trovato solo PostgreSQL e MySQL, anche se nel progetto sono coinvolti Redis e memcached.
Le richieste sono organizzate secondo criteri familiari: frequenza di attivazione, tempo medio di risposta e così via. È particolarmente utile la scheda con le richieste più lente — è davvero comodo. Inoltre, i dati in questa scheda per PostgreSQL coincidono con quelli dell'estensione. — un ottimo risultato!
Scheda Richieste Esterne è completamente identica ai Database.
Conclusioni
Entrambi gli strumenti presentati hanno mostrato buone prestazioni come APM. Ognuno di essi può offrire il minimo necessario. In sintesi, possiamo riassumere le nostre impressioni come segue:
Datadog
Vantaggi:
- una tariffa conveniente (l'APM costa 31 USD per host);
- si è comportato ottimamente con Python;
- possibilità di integrazione con OpenTracing
- integrazione con Kubernetes;
- integrazione con NGINX Ingress.
Contro:
- il solo APM che ha causato l'inaccessibilità dell'applicazione a causa di un errore del modulo (predis);
- debole auto-strumentazione PHP;
- definizione dei servizi e dei loro scopi parzialmente strana.
Atatus
Vantaggi:
- strumentazione approfondita PHP;
- interfaccia utente simile a New Relic.
Contro:
- non funziona su vecchi sistemi operativi (Ubuntu 12.05, CentOS 5);
- debole auto-strumentazione;
- supporto per solo due linguaggi di programmazione (Node.js e PHP);
- lentezza dell'interfaccia.
Considerando il prezzo di Atatus a 69 USD al mese per server, preferiremmo utilizzare Datadog, che si integra perfettamente alle nostre esigenze (applicazioni web in K8s) e offre molte funzionalità utili.
P.S.
Leggete anche nel nostro blog:
- «»;
- «»;
- «».
Fonte: habr.com
