AGISCI ORA! OFFERTA A TEMPO LIMITATO! GLI OPERATORI SONO IN ATTESA! Sono pronto per la mia prossima avventura come sostenitore DevRel / Evangelista tecnico / IT Talespinner. Se ti sembra qualcosa di cui hai bisogno, scrivimi una riga via e-mail o su LinkedIn
Sono specializzato in monitoraggio e osservabilità da 27 anni ormai e ho visto molti strumenti e tecniche andare e venire (RMon, qualcuno?); e più di qualcuno andare e restare (le voci sulla morte di SNMP sono state - e continuano a essere - notevolmente esagerate). Ultimamente ho esplorato uno dei più recenti miglioramenti nello spazio: OpenTelemetry (che abbreviarò in "OTel" per il resto di questo blog). Ho scritto della mia decisione di immergermi in OTel di recente .
Per la maggior parte, mi sto godendo il viaggio. Ma c'è un problema con l'osservabilità che esiste da un po' di tempo ormai, ed è qualcosa che OTel non sta aiutando. Il titolo di questo post accenna al problema, ma voglio essere più esplicito. Cominciamo con un po' di comparazione dei prezzi.
Prima di far incazzare tutti i venditori in città, voglio essere chiaro sul fatto che questi sono numeri generali, approssimativi e di alto livello. Ho linkato le pagine dei prezzi se vuoi controllare i dettagli e riconosco che ciò che vedi di seguito non è necessariamente indicativo del prezzo che potresti effettivamente pagare dopo aver ottenuto un preventivo su un ambiente di produzione reale.
Nuove accuse di Relic
- 35 centesimi per GB per tutti i dati che invii.
- …anche se la pagina dei prezzi non lo rende particolarmente chiaro
Datadog ha una vera e propria lista di opzioni, ma a un livello elevato, fa pagare :
$ 15-$ 34 per host
60¢ – $ 1,22 per milione di record di flusso netto
$ 1,06-$ 3,75 per milione di record di registro
$ 1,27-$ 3,75 per milione di campate
La pagina dei prezzi di Dynatrace presenta un elenco quasi lungo quanto quello di Datadog, ma con alcuni elementi chiave:
15 centesimi per 100,00 metriche
- più 0,07 centesimi per Gig al giorno per la fidelizzazione
2 centesimi per giga per i registri
- più 0,07 centesimi al giorno per tenerli
- più 0,035¢ per giga richiesto
Gli eventi hanno la stessa frequenza dei registri
0,014¢ per 1.000 campate
Grafana, che – bisogna dirlo – è open source e di fatto ti dà tutto gratis se sei disposto a fare il grosso del lavoro di installazione e hosting. Ma i suoi prezzi possono essere riassunti come :
- $ 8,00 per 1k metriche (fino a 1/minuto)
- 50 centesimi a giga per i log e le relative tracce, con conservazione per 30 giorni
Questo elenco non è né esaustivo né completo. Ho tralasciato molti venditori, non perché non abbiano prezzi basati sul consumo, ma perché sarebbe stato più o meno lo stesso. Anche con quelli di cui sopra, i dettagli qui non sono completi. Alcune aziende non solo addebitano il consumo (ingest), ma addebitano anche l'archiviazione dei dati e addebitano di nuovo l'interrogazione dei dati (sto parlando con te, New Relic). Alcune aziende ti spingono a scegliere un livello di servizio e, se non lo fai, ti addebiteranno una tariffa stimata basata sul 99° percentile di utilizzo per il mese ( sto parlando con te, Datadog ).
Non dovrebbe sorprendere nessuno che ciò che appare sulla loro pagina dei prezzi non sia nemmeno la parola finale. Alcune di queste aziende stanno, anche adesso, cercando di ridefinire la loro interpretazione del concetto di "prezzo basato sul consumo", il che potrebbe rendere le cose ancora più opache (ti sto guardando ANCORA, New Relic).
Detto questo, mi sbilancio e affermo esplicitamente che ognuno di quei prezzi è così basso che persino la parola "banale" è troppo grande.
Cioè, finché i carichi di lavoro di produzione non soddisfano il listino prezzi. A quel punto, quei numeri minuscoli si sommano in denaro reale, e in fretta.
Il plurale di aneddoto
Ho posto questa domanda ad alcuni amici, chiedendo se avessero avuto esperienze reali di shock da adesivi. Come sempre, i miei amici non mi hanno deluso.
"Ho fatto un confronto dettagliato dei prezzi di New Relic con Datadog un paio di anni fa con Fargate come utilizzo principale. New Relic era significativamente più economico finché non hai iniziato a spedire i log e poi Datadog è diventato improvvisamente più economico del 30-40% anche con apm. [Ma] il loro costo per host è un fattore e rende APM piuttosto poco attraente a meno che tu non stia facendo qualcosa senza server. Volevamo usarlo su kubernetes ma era così costoso che la direzione si rifiutava di credere ai costi con i servizi su Fargate, quindi di solito mostravo i miei numeri ogni 2-3 mesi".__– Evelyn Osman, responsabile della piattaforma presso enmacc
"Tutto quello che ho è il ricordo della faccia del CFO quando ha visto la bolletta."__– qualcuno che preferisce rimanere anonimo, anche se questa citazione è incredibilmente epica.
E poi c'è il mistero (ormai tristemente noto nei circoli dell'osservabilità) della fattura Datadog da 65 milioni di dollari .
Il primo passo è ammettere di avere un problema
Una volta (e con questo intendo i primi anni del 2000), la sfida con il monitoraggio (osservabilità non era ancora un termine che usavamo) era come identificare i dati di cui avevamo bisogno, quindi fare in modo che i sistemi fornissero tali dati e poi memorizzarli in un modo che rendesse possibile (per non dire efficiente) il loro utilizzo in query, visualizzazioni, avvisi e così via.
Era lì che ricadeva quasi tutto il costo. I sistemi stessi erano on-premise e, una volta acquistato l'hardware, di fatto "gratuiti". Il risultato era che la prassi accettata era quella di raccogliere il più possibile e conservarlo per sempre. E nonostante il cambiamento nella tecnologia, il ragionamento di molte organizzazioni è rimasto lo stesso.
Alec Isaacson, architetto di Grafana Solutions, sottolinea che a volte le sue conversazioni con i clienti si svolgono in questo modo:
"Raccolgo le metriche CDM dai miei sistemi più critici ogni 5 secondi perché una volta, tanto tempo fa, qualcuno venne sgridato perché il sistema era lento e le metriche non gliene spiegavano il motivo".
Oggi, raccogliere dati di monitoraggio e osservabilità ("telemetria") è relativamente facile, ma - sia come individui che come organizzazioni - non abbiamo cambiato il nostro inquadramento del problema. Quindi continuiamo ad acquisire ogni pezzo di dati a nostra disposizione. Strumentiamo il nostro codice con ogni tag e span che ci viene in mente; se c'è un messaggio di log, lo spediamo; metriche hardware? Meglio acquisirle perché forniranno contesto; se c'è telemetria di rete (NetFlow, log VPC Flow, Streaming Telemetry) assorbiamo anche quella.
Ma non ci prendiamo mai il tempo di pensare a cosa ne faremo. L'esperienza della Sig.ra Osman illustra il risultato:
“[Loro] non avevano idea di cosa stessero facendo con il monitoraggio […] tutta la strumentazione e la registrazione erano abilitate, poi c’era una lunga conservazione “per ogni evenienza”. Quindi stavano solo bruciando quantità ridicole di denaro”
Per collegarlo a un altro cattivo comportamento da cui (più o meno) ci siamo liberati: ai primi tempi del "lift and shift" (spesso più correttamente descritto come "lift and shit") sul cloud, non solo spostavamo le applicazioni all'ingrosso; le spostavamo sui sistemi più grandi offerti dalla piattaforma. Perché? Perché nel vecchio contesto on-prem si poteva chiedere un server solo una volta, e quindi si chiedeva la cosa più grande che si potesse ottenere, per rendere il proprio investimento a prova di futuro. Questa decisione si è rivelata non solo divertentemente ingenua, ma anche orribilmente costosa e ci sono voluti alcuni anni a tutti per capire come funzionava il "calcolo elastico" e per riorganizzare le proprie applicazioni per il nuovo paradigma.
Allo stesso modo, è giunto il momento di riconoscere e ammettere che non possiamo permetterci di raccogliere ogni singolo dato di telemetria a nostra disposizione e, inoltre, che non abbiamo un piano per tali dati, anche se i soldi non fossero un problema.
Ammettilo: il tuo problema ha anche un problema
Lasciatemi passare per un attimo a OTel. Una delle ragioni principali, forse LA ragione principale, per passare a questo è quella di eliminare, per sempre e sempre, il dolore del vendor lock-in. È qualcosa che ho esplorato nel mio ultimo post del blog e che è stato ripreso di recente da un mio amico:
OTel risolve molti dei problemi del tipo "Oh, fantastico! Ora siamo intrappolati con il fornitore x e ci costerà milioni rifare tutto questo codice" invece di "Oh, stiamo cambiando fornitore? Fantastico, lasciami solo aggiornare il mio endpoint..." – Matt Macdonald-Wallace, Solutions Architect, Grafana Labs
Per essere molto chiari, OTel fa un lavoro incredibile nel risolvere questo problema, il che è incredibile di per sé. MA... c'è un lato negativo di OTel che le persone non notano subito, se mai lo notano. Quel problema rende il problema precedente ancora peggiore.
OTel prende tutti i tuoi dati (metriche, log, tracce e il resto), li raccoglie e li invia ovunque tu voglia. Ma OTel non sempre lo fa in MODO EFFICIENTE.
Esempio 1: messaggi di registro
Prendiamo il messaggio di log qui sotto, che proviene direttamente da syslog. Sì, il caro vecchio RFC 5424. Nato negli anni '80, standardizzato nel 2009 e l'indiscusso "chatty kathy" dei protocolli di messaggi di rete. Ho visto reti di dimensioni modeste generare più di 4 milioni di messaggi syslog all'ora. La maggior parte di essi erano assolutamente inutili sciocchezze, badate bene. Ma quei messaggi dovevano andare da qualche parte ed essere elaborati (o eliminati) da qualche sistema lungo il percorso. È uno dei motivi per cui ho suggerito un "sistema di filtraggio" syslog e trap praticamente da sempre .
A parte il pignolo sul volume dei messaggi, c'è valore in alcuni di quei messaggi, per alcuni professionisti IT, a volte. E quindi dobbiamo considerarli (e raccoglierli) anche noi.
<134>1 2018-12-13T14:17:40.000Z myserver myapp 10 - [http_method="GET"; http_uri="/example"; http_version="1.1"; http_status="200"; client_addr="127.0.0.1"; http_user_agent="my.service/1.0.0"] HTTP request processed successfully
Così com'è, quel messaggio di log è di 228 byte, appena una goccia nel mare di telemetria che raccogli ogni minuto, figuriamoci ogni giorno. Ma per quello che sto per fare, voglio un vero confronto tra pari, quindi ecco come apparirebbe se lo convertissi in JSON:
{ "pri": 134, "version": 1, "timestamp": "2018-12-13T14:17:40.000Z", "hostname": "myserver", "appname": "myapp", "procid": 10, "msgid": "-", "structuredData": { "http_method": "GET", "http_uri": "/example", "http_version": "1.1", "http_status": "200", "client_addr": "127.0.0.1", "http_user_agent": "my.service/1.0.0" }, "message": "HTTP request processed successfully" }
Ciò aumenta il payload fino a 336 byte senza spazi vuoti, o 415 byte con. Ora, per fare un confronto, ecco un esempio di messaggio di log OTLP:
{ "resource": { "service.name": "myapp", "service.instance.id": "10", "host.name": "myserver" }, "instrumentationLibrary": { "name": "myapp", "version": "1.0.0" }, "severityText": "INFO", "timestamp": "2018-12-13T14:17:40.000Z", "body": { "text": "HTTP request processed successfully" }, "attributes": { "http_method": "GET", "http_uri": "/example", "http_version": "1.1", "http_status": "200", "client_addr": "127.0.0.1", "http_user_agent": "my.service/1.0.0" } }
Quel messaggio (generico, minimo) pesa 420 byte (senza spazi; sono 520 byte tutto incluso). È ancora minuscolo, ma anche così la versione OTel con spazi è più grande del 25% rispetto al messaggio JSON-ificato (con spazi) e più del doppio del messaggio di log originale.
Una volta che iniziamo ad applicare dati del mondo reale, le cose si gonfiano ancora di più. Il mio punto qui è questo: se OTel fa questo a ogni messaggio di log, questi piccoli costi si sommano rapidamente.
Esempio 2: Prometeo
A quanto pare, anche i moderni metodi di gestione metrica sono altrettanto sensibili all'inflazione.
- Una tipica metrica Prometheus, formattata in JSON, è di 291 byte.
- Ma la stessa metrica convertita nel formato OTLP pesa 751 byte.
È vero, OTLP ha una funzione di batching che mitiga questo problema, ma aiuta solo con il trasferimento via cavo. Una volta arrivato a destinazione, molti (non tutti, ma la maggior parte) dei venditori de-batchano prima di archiviarlo, quindi torna a essere 2,5 volte più grande del messaggio originale. Come ha detto il mio amico Josh Biggley,
"Le metriche 2,5x devono avere una storia fantastica da raccontare sul contesto per giustificare quel costo."
Non sei tu, OTel, siamo noi. (Ma sei anche tu)
Se tutto questo vi sembra un po' ipercritico nei confronti di OTel, allora vi prego di darmi la possibilità di spiegarvelo. Credo sinceramente che OTel sia un progresso incredibile e chiunque sia seriamente interessato al monitoraggio e all'osservabilità deve adottarlo come standard, e questo vale sia per gli utenti che per i vendor. La capacità di emettere la treccia di log, metriche, tracce mantenendone il contesto, indipendentemente dalla destinazione, è inestimabile.
(Ma...) OTel è stato progettato da (e per) ingegneri informatici. Ha avuto origine in quell'epoca passata (e con ciò intendo "2016") in cui eravamo ancora più preoccupati della difficoltà di ottenere i dati che del costo di spostarli, elaborarli e archiviarli. OTel è, per progettazione, orientato al volume.
Nonostante la battuta del titolo di questa sezione, il problema non è davvero OTel. Siamo noi in realtà in colpa. In particolare, del nostro rapporto malsano con la telemetria. Se insistiamo nel raccogliere e trasmettere ogni singolo punto dati, non abbiamo nessuno da incolpare se non noi stessi per le bollette alle stelle che riceviamo a fine mese.
Questi dati ti danno gioia?
È facile lasciare che la tua soluzione di osservabilità faccia il grosso del lavoro e smista ogni byte di dati in un'interfaccia unificata. È facile da fare se sei un ingegnere informatico che (almeno nominalmente) possiede le soluzioni di monitoraggio e osservabilità.
È ancora più facile se sei un semplice consumatore di quei servizi, un innocente spettatore. Le persone che rientrano in questa categoria includono coloro che sono strettamente legati a un particolare silo (database, storage, rete, ecc.); o team di helpdesk e NOC che ricevono i ticket e forniscono supporto ma non sono coinvolti nella strumentazione né negli strumenti a cui è collegata la strumentazione; o team con esigenze più specializzate che tuttavia si sovrappongono al monitoraggio e all'osservabilità, come la sicurezza delle informazioni.
Ma siamo onesti, se sei un ingegnere della sicurezza, come puoi giustificare il pagamento del doppio del costo per l'acquisizione di log o metriche, rispetto agli standard perfettamente validi che già esistono e che hanno funzionato bene per anni? Ciò significa che potresti utilizzare più di uno strumento? Sì. Ma come ho sottolineato ( più e più volte e più volte epiù volte) non esiste (e non c'è mai stata, e non ci sarà mai) una soluzione adatta a tutti. E nella maggior parte delle situazioni non esiste nemmeno una soluzione adatta alla MAGGIOR PARTE. Il monitoraggio e l'osservabilità hanno sempre riguardato implementazioni eterogenee. Prima abbraccerai questo ideale, prima inizierai a creare ecosistemi di osservabilità che soddisfano le tue esigenze, quelle del tuo team e della tua attività.
A tal fine, è necessario discutere seriamente del ROI prima di puntare tutto su OTel o su qualsiasi soluzione di osservabilità.
<EOF> (per ora)
Abbiamo assistito in passato al passaggio da un prezzo per posto (o interfaccia, o chassis, o CPU) a un modello di consumo sul mercato. E abbiamo anche visto le tecnologie tornare indietro (come il modo in cui il servizio cellulare è passato da al minuto o per testo a dati illimitati con un costo mensile). Sospetto che potremmo assistere a un simile pendolo tornare indietro con il monitoraggio e l'osservabilità in un momento futuro. Ma per ora, dobbiamo fare i conti sia con il sistema di prezzi prevalente così come esiste oggi; sia con la nostra stessa compulsione, nata in un momento diverso nella storia del monitoraggio, a raccogliere, trasmettere e archiviare ogni bit (e byte) di telemetria che passa sotto il nostro naso.
Naturalmente, il costo non è l'unico fattore. Bisogna considerare anche le prestazioni, il rischio (e altro). Ma al centro di tutto c'è la necessità molto reale di iniziare a chiederci:
- Cosa farò con questi dati?
- Chi lo utilizzerà?
- Per quanto tempo devo conservarlo?
E naturalmente, chi diavolo pagherà per questo?
