🥇Non solo New Relic: uno sguardo a Datadog e Atatus

Nell'ambiente degli ingegneri SRE/DevOps, non sorprenderà nessuno che un giorno appaia un cliente (o un sistema di monitoraggio) e riferisca che "tutto è perduto": il sito non funziona, i pagamenti non vanno a buon fine, la vita sta decadendo ... Non importa quanto vorresti aiutare in una situazione del genere, può essere molto difficile farlo senza uno strumento semplice e comprensibile. Spesso il problema è nascosto nel codice stesso dell'applicazione; è sufficiente localizzarlo.

E nel dolore e nella gioia...

È successo così che ci siamo innamorati profondamente e a lungo di New Relic. Era e rimane uno strumento eccellente per monitorare le prestazioni delle applicazioni e consente inoltre di strumentare l'architettura dei microservizi (utilizzando il relativo agente) e molto altro ancora. E tutto sarebbe potuto andare alla grande se non fosse stato per i cambiamenti nella politica dei prezzi del servizio: esso costo con anni 2013 è cresciuto più di 3 volte. Inoltre, dallo scorso anno, per ottenere un account di prova è necessaria la comunicazione con un manager personale, il che rende difficile presentare il prodotto a un potenziale cliente.

La solita situazione: New Relic non è necessaria su base "permanente", se ne ricordano solo nel momento in cui iniziano i problemi. Ma è comunque necessario pagare regolarmente (140 USD per server al mese) e in un’infrastruttura cloud con scalabilità automatica le somme ammontano piuttosto grandi. Sebbene sia presente un'opzione Pay-As-You-Go, l'attivazione di New Relic richiederà il riavvio dell'applicazione, il che potrebbe portare alla perdita della situazione problematica per la quale tutto era stato avviato. Non molto tempo fa, New Relic ha introdotto un nuovo piano tariffario: Essenziali, - che a prima vista sembra una ragionevole alternativa a Professional... ma dopo un esame più attento si è scoperto che mancano alcune funzioni importanti (in particolare, non ha Transazioni chiave, Tracciamento di applicazioni incrociate, Tracciatura distribuita).

Di conseguenza, abbiamo iniziato a pensare di cercare un’alternativa più economica e la nostra scelta è caduta su due servizi: Datadog e Atatus. Perché su di loro?

A proposito di concorrenti

Dico subito che esistono altre soluzioni sul mercato. Abbiamo anche considerato le opzioni Open Source, ma non tutti i clienti hanno capacità libera per ospitare soluzioni self-hosted... - inoltre, richiederanno ulteriore manutenzione. La coppia che abbiamo scelto si è rivelata la più vicina i nostri bisogni:

supporto integrato e sviluppato per applicazioni PHP (lo stack dei nostri clienti è molto diversificato, ma questo è un chiaro leader nel contesto della ricerca di un'alternativa a New Relic);
costo accessibile (meno di 100 USD al mese per host);
strumentazione automatica;
integrazione con Kubernetes;
La somiglianza con l'interfaccia New Relic è un vantaggio notevole (perché i nostri ingegneri ci sono abituati).

Pertanto, nella fase di selezione iniziale, abbiamo eliminato diverse altre soluzioni popolari, e in particolare:

Tideways, AppDynamics e Dynatrace - a pagamento;
Stackify è bloccato nella Federazione Russa e mostra troppo pochi dati.

Il resto dell'articolo è strutturato in modo tale che verranno prima presentate brevemente le soluzioni in questione, dopodiché parlerò della nostra tipica interazione con New Relic e delle esperienze/impressioni derivanti dall'esecuzione di operazioni simili in altri servizi.

Presentazione dei concorrenti selezionati

Про New Relic, probabilmente tutti hanno sentito? Questo servizio ha iniziato il suo sviluppo più di 10 anni fa, nel 2008. Lo utilizziamo attivamente dal 2012 e non abbiamo avuto problemi a integrare un numero molto elevato di applicazioni in PHP, Ruby e Python, e abbiamo anche esperienza nell'integrazione con C# e Go. Gli autori del servizio dispongono di soluzioni per il monitoraggio di applicazioni, infrastrutture, tracciamento di infrastrutture di microservizi, creazione di applicazioni convenienti per i dispositivi degli utenti e molto altro.

Tuttavia, l'agente New Relic funziona su protocolli proprietari e non supporta OpenTracing. La strumentazione avanzata richiede modifiche specifiche per New Relic. Infine, il supporto di Kubernetes è ancora sperimentale.

Ha iniziato il suo sviluppo nel 2010 Datadog sembra notevolmente più interessante di New Relic proprio in termini di utilizzo negli ambienti Kubernetes. In particolare, supporta l'integrazione con i protocolli NGINX Ingress, log collection, statsd e OpenTracing, che consente di tracciare una richiesta dell'utente dal momento in cui viene connesso fino al completamento, nonché di trovare i log di tale richiesta (sia lato server web e sul consumatore).

Durante l'utilizzo di Datadog, abbiamo riscontrato che a volte creava la mappa dei microservizi in modo errato e presentava alcune carenze tecniche. Ad esempio, ha identificato erroneamente il tipo di servizio (confondendo Django con un servizio di caching) e ha causato 500 errori in un'applicazione PHP utilizzando la popolare libreria Predis.

Atato — lo strumento più giovane; il servizio è stato lanciato nel 2014. Il suo budget di marketing è chiaramente inferiore a quello dei concorrenti elencati, le menzioni sono molto meno frequenti. Tuttavia, lo strumento stesso è molto simile a New Relic, non solo nelle sue capacità (APM, monitoraggio del browser, ecc.), ma anche nell'aspetto.

Uno svantaggio significativo è che supporta solo Node.js e PHP. D'altro canto è implementato decisamente meglio di Datadog. A differenza di quest'ultimo, Atatus non richiede alle applicazioni di apportare modifiche o aggiungere ulteriori etichette al codice.

Come lavoriamo con New Relic

Ora vediamo come utilizziamo generalmente New Relic. Diciamo che abbiamo un problema che necessita di una soluzione:

È facile vederlo sul grafico всплеск - Analizziamolo. In New Relic, le transazioni web vengono immediatamente selezionate per un'applicazione web, tutti i componenti sono indicati nel grafico delle prestazioni, ci sono pannelli del tasso di errore, del tasso di richiesta... La cosa più importante è che direttamente da questi pannelli puoi spostarti tra diversi parti dell'applicazione (ad esempio, facendo clic su MySQL si accederà alla sezione del database).

Poiché nell'esempio in esame vediamo un aumento dell'attività PHP, fai clic su questo grafico e vai automaticamente a Le transazioni:

L'elenco delle transazioni, che sono essenzialmente controller del modello MVC, è già ordinato in base a La maggior parte del tempo richiesto, il che è molto comodo: vediamo subito cosa fa l'applicazione. Ecco alcuni esempi di query lunghe raccolte automaticamente da New Relic. Cambiando l'ordinamento, è facile trovare:

il controller dell'applicazione più caricato;
titolare del trattamento più frequentemente richiesto;
il più lento dei controllori.

Inoltre, puoi espandere ogni transazione e vedere cosa stava facendo l'applicazione nel momento in cui è stato eseguito il codice:

Infine, l'applicazione memorizza esempi di tracce di richieste lunghe (quelle che impiegano più di 2 secondi). Ecco il pannello per una transazione lunga:

Si può vedere che due metodi richiedono molto tempo e allo stesso tempo vengono visualizzati anche l'ora in cui è stata eseguita la richiesta, il suo URI e il dominio. Molto spesso questo aiuta a trovare la richiesta nei log. Andando a Traccia i dettagli, puoi vedere da dove vengono chiamati questi metodi:

E in Interrogazioni del database — valutare le query ai database eseguite durante l'esecuzione dell'applicazione:

Grazie a questa conoscenza, possiamo valutare il motivo per cui l'applicazione sta rallentando e collaborare con lo sviluppatore per elaborare una strategia per risolvere il problema. In realtà New Relic non sempre dà un quadro chiaro, ma aiuta a scegliere il vettore di indagine:

lungo PDO::Construct ci ha portato allo strano funzionamento di pgpoll;
instabilità nel tempo Memcache::Get ha suggerito che la macchina virtuale era configurata in modo errato;
un tempo sospettosamente aumentato per l'elaborazione dei modelli ha portato ad un ciclo annidato che controlla la presenza di 500 avatar nell'archivio degli oggetti;
e così via ...

Succede anche che invece di eseguire il codice, nella schermata principale cresca qualcosa relativo all'archiviazione di dati esterni - e non importa quale sarà: Redis o PostgreSQL - sono tutti nascosti nella scheda Database.

Puoi selezionare una base specifica per la ricerca e ordinare le query, in modo simile a come avviene in Transazioni. E andando alla scheda della richiesta, puoi vedere quante volte questa richiesta si verifica in ciascuno dei controller dell'applicazione e anche stimare la frequenza con cui viene chiamata. È molto comodo:

La scheda contiene dati simili Servizi esterni, che nasconde le richieste a servizi HTTP esterni, come l'accesso all'archiviazione di oggetti, l'invio di eventi a sentry o simili. Il contenuto della scheda è del tutto simile a Database:

Concorrenti: opportunità e impressioni

Ora la cosa più interessante è confrontare le capacità di New Relic con ciò che offrono i concorrenti. Sfortunatamente non siamo riusciti a testare tutti e tre gli strumenti su una versione di un'applicazione in esecuzione in produzione. Abbiamo comunque cercato di confrontare situazioni/configurazioni il più identiche possibile.

1.Datadog

Datadog ci accoglie con un pannello con un muro di servizi:

Cerca di suddividere le applicazioni in componenti/microservizi, quindi nell'applicazione Django di esempio vedremo 2 connessioni a PostgreSQL (defaultdb и postgres), nonché Sedano, Redis. Lavorare con Datadog richiede una conoscenza minima dei principi MVC: è necessario capire da dove generalmente provengono le richieste degli utenti. Questo di solito aiuta mappa dei servizi:

A proposito, c'è qualcosa di simile in New Relic:

... e la loro mappa, a mio avviso, è resa più semplice e chiara: non mostra i componenti di un'applicazione (il che la renderebbe eccessivamente dettagliata, come nel caso di Datadog), ma solo servizi o microservizi specifici.

Torniamo a Datadog: dalla mappa dei servizi possiamo vedere che le richieste degli utenti arrivano a Django. Andiamo al servizio Django e vediamo finalmente cosa ci aspettavamo:

Sfortunatamente, qui non è presente alcun grafico per impostazione predefinita Tempo di transazione web, simile a quello che vediamo nel pannello principale di New Relic. Tuttavia, può essere configurato al posto della pianificazione % del tempo trascorso. È sufficiente cambiarlo Tempo medio per richiesta per tipo... e ora il grafico familiare ci guarda!

Perché Datadog abbia scelto un grafico diverso per noi è un mistero. Un’altra cosa frustrante è che il sistema non ricorda la scelta dell’utente (a differenza di entrambi i concorrenti), e quindi l’unica soluzione è creare pannelli personalizzati.

Ma sono rimasto soddisfatto della capacità di Datadog di passare da questi grafici alle metriche dei server correlati, leggere i log e valutare il carico sui gestori dei server web (Gunicorn). Tutto è quasi uguale a New Relic... e anche qualcosa in più (log)!

Sotto i grafici ci sono transazioni del tutto simili a New Relic:

In Datadog vengono chiamate le transazioni le risorse. Puoi ordinare i controller in base al numero di richieste, al tempo medio di risposta e al tempo massimo impiegato per un periodo di tempo selezionato.

Puoi espandere la risorsa e vedere tutto ciò che abbiamo già osservato in New Relic:

Ci sono statistiche sulla risorsa, un elenco generalizzato di chiamate interne ed esempi di richieste che possono essere ordinate in base al codice di risposta... A proposito, ai nostri ingegneri è piaciuto molto questo ordinamento.

Qualsiasi risorsa di esempio in Datadog può essere aperta e studiata:

Vengono presentati i parametri della richiesta, un grafico riepilogativo del tempo impiegato su ciascun componente e un grafico a cascata che mostra la sequenza delle chiamate. Puoi anche passare alla visualizzazione ad albero del grafico a cascata:

E la cosa più interessante è visualizzare il carico dell'host su cui è stata eseguita la richiesta e visualizzare i log delle richieste.

Ottima integrazione!

Potresti chiederti dove sono le schede Database и Servizi esterni, come in Nuova Reliquia. Non ce ne sono qui: poiché Datadog scompone l'applicazione in componenti, verrà preso in considerazione PostgreSQL un servizio separato, e invece di Servizi esterni vale la pena cercarlo aws.storage (sarà simile per ogni altro servizio esterno a cui l'applicazione potrà accedere).

Ecco un esempio con postgres:

In sostanza c'è tutto quello che volevamo:

Puoi vedere da quale “servizio” proviene la richiesta.

Non è fuori luogo ricordarti che Datadog si integra perfettamente con NGINX Ingress e consente di eseguire il tracciamento end-to-end dal momento in cui arriva una richiesta nel cluster, inoltre consente di ricevere metriche statsd, raccogliere log e metriche host .

Un grande vantaggio di Datadog è il suo prezzo sta prendendo forma dal monitoraggio dell'infrastruttura, APM, Log Management e test sintetici, ovvero Puoi scegliere il tuo piano in modo flessibile.

2.Atato

Il team di Atatus afferma che il loro servizio è “lo stesso di New Relic, ma migliore”. Vediamo se è davvero così.

Il pannello principale sembra simile, ma non è stato possibile determinare il Redis e il memcached utilizzati nell'applicazione.

APM seleziona tutte le transazioni per impostazione predefinita, anche se in genere sono necessarie solo le transazioni Web. Come Datadog, non è possibile accedere al servizio desiderato dal pannello principale. Inoltre, le transazioni vengono elencate dopo gli errori, il che non sembra molto logico per APM.

Nelle transazioni Atatus, tutto è il più simile possibile a New Relic. Lo svantaggio è che le dinamiche per ciascun controller non sono immediatamente visibili. Devi cercarlo nella tabella dei controller, ordinando per La maggior parte del tempo consumato:

Il consueto elenco dei controller è disponibile nella scheda Esplora:

In un certo senso, questa tabella ricorda Datadog e mi piace di più di quella simile in New Relic.

Puoi espandere ogni transazione e vedere cosa stava facendo l'applicazione:

Anche il pannello ricorda più Datadog: c'è una serie di richieste, un quadro generale delle chiamate. Il pannello superiore fornisce una scheda di errore Errori HTTP ed esempi di query lente Tracce della sessione:

Se vai a una transazione, puoi vedere un esempio di traccia, puoi ottenere un elenco di richieste al database e guardare le intestazioni delle richieste. Tutto è simile a New Relic:

In generale, Atatus è soddisfatto delle tracce dettagliate, senza il tipico incollaggio delle chiamate di New Relic in un blocco promemoria:

Tuttavia, manca un filtro che (come New Relic) interrompa le richieste ultraveloci (<5ms). D'altra parte, mi è piaciuta la visualizzazione della risposta finale della transazione (successo o errore).

Панель Database ti aiuterà a studiare le richieste ai database esterni effettuate dall'applicazione. Permettetemi di ricordarvi che Atatus ha trovato solo PostgreSQL e MySQL, sebbene nel progetto siano coinvolti anche Redis e memcached.

Le richieste vengono ordinate secondo i consueti criteri: frequenza di risposta, tempo medio di risposta e così via. Vorrei anche menzionare la scheda con le query più lente: è molto comoda. Inoltre, i dati in questa scheda per PostgreSQL coincidono con i dati dell'estensione pg_stat_statements - risultato eccellente!

Inserire Richieste esterne completamente identico ai database.

risultati

Entrambi gli strumenti presentati hanno funzionato bene nel ruolo di APM. Ognuno di loro può offrire il minimo richiesto. Le nostre impressioni possono essere brevemente riassunte come segue:

Datadog

pro:

tariffa conveniente (APM costa 31 USD per host);
ha funzionato bene con Python;
Possibilità di integrazione con OpenTracing
integrazione con Kubernetes;
integrazione con NGINX Ingress.

contro:

l'unico APM che ha reso l'applicazione non disponibile a causa di un errore del modulo (predis);
debole strumentazione automatica PHP;
definizione in parte strana dei servizi e del loro scopo.

Atato