ACTIE NU! BEPERKTE TIJD AANBIEDING! OPERATORS STAAN KLAAR! Ik ben klaar voor mijn volgende avontuur als DevRel advocate / Technical Evangelist / IT Talespinner. Als dat klinkt als iets wat je nodig hebt, stuur me dan een berichtje via e-mail of op LinkedIn
Ik ben nu 27 jaar gespecialiseerd in monitoring en observability en ik heb veel tools en technieken zien komen en gaan (RMon, iemand?); en meer dan een paar zien komen en blijven (geruchten over de dood van SNMP zijn – en blijven – enorm overdreven.). De laatste tijd heb ik een van de meest recente verbeteringen in de ruimte onderzocht – OpenTelemetry (die ik voor de rest van deze blog afkort tot “OTel”). Ik schreef onlangs over mijn besluit om me in OTel te verdiepen .
Ik geniet over het algemeen van de reis. Maar er is een probleem dat al een tijdje bestaat met observability, en dat is iets waar OTel niet aan bijdraagt. De titel van dit bericht geeft al aan dat het om een probleem gaat, maar ik wil het wat explicieter maken. Laten we beginnen met wat vergelijken.
Voordat ik alle verkopers in de stad boos maak, wil ik duidelijk maken dat dit brede, ruwe, hoge getallen zijn. Ik heb een link naar de prijspagina's geplaatst als u de details wilt bekijken, en ik erken dat wat u hieronder ziet niet per se een indicatie is van de prijs die u daadwerkelijk betaalt na het ontvangen van een offerte voor een echte productieomgeving.
Nieuwe Relikwie -ladingen
- 35¢ per GB voor alle data die u hen stuurt.
- …hoewel de prijspagina dit niet bepaald duidelijk maakt
Datadog heeft een hele waslijst aan opties, maar als je het over het algemeen bekijkt, betaal je:
$15-$34 per gastheer
60¢ – $1,22 per miljoen nettostroomrecords
$1,06-$3,75 per miljoen logrecords
$1,27-$3,75 per miljoen overspanningen
De prijspagina van Dynatrace bevat een lijst die bijna net zo lang is als die van Datadog, maar bevat wel een aantal belangrijke items:
15¢ per 100.000 metrische gegevens
- plus 0,07¢ per Gig per dag voor retentie
2¢ per gig voor logs
- plus 0,07¢- per gig per dag om ze te behouden
- plus 0,035¢ per opgevraagde gig
Gebeurtenissen hebben dezelfde snelheid als logs
.014¢ per 1.000 overspanningen
Grafana, dat – dat moet gezegd worden – open source is en je in feite alles gratis geeft als je bereid bent om het zware werk van installeren en hosten te doen. Maar hun prijzen kunnen als volgt worden samengevat :
- $ 8,00 voor 1k-metriek (tot 1/minuut)
- 50¢ per gig voor logs en traces, met een bewaartermijn van 30 dagen
Deze lijst is noch uitputtend noch compleet. Ik heb veel leveranciers weggelaten, niet omdat ze ook geen consumptiegebaseerde prijzen hebben, maar omdat het gewoon meer van hetzelfde zou zijn. Zelfs met de bovenstaande zijn de details hier niet compleet. Sommige bedrijven rekenen niet alleen voor consumptie (ingest), ze rekenen ook voor het opslaan van de data en rekenen opnieuw voor het opvragen van de data (ik kijk naar jou, New Relic). Sommige bedrijven pushen je om een serviceniveau te kiezen en als je dat niet doet, rekenen ze je een geschat tarief op basis van het 99e percentiel van het gebruik voor de maand ( ik kijk naar jou, Datadog ).
Het zou niemand moeten verbazen dat wat er op hun prijspagina staat niet eens het laatste woord is. Sommige van deze bedrijven zijn, zelfs nu, bezig met het herdefiniëren van hun interpretatie van het concept "consumptiegebaseerde prijsstelling", wat de zaken nog ondoorzichtiger zou kunnen maken (ik kijk WEER naar jou, New Relic).
Maar ondanks alles durf ik toch te stellen dat elk van die prijspunten zo laag is dat zelfs het woord ‘triviaal’ te groot is.
Dat wil zeggen, totdat de productiewerklasten voldoen aan de prijslijst. Op dat punt tellen die piepkleine bedragen snel op tot echt geld.
Het meervoud van anekdote
Ik stelde deze vraag aan een paar vrienden, om te vragen of zij echte sticker-shock ervaringen hadden. Zoals altijd stelden mijn vrienden niet teleur.
“Ik heb een paar jaar geleden een gedetailleerde prijsvergelijking gemaakt van New Relic met Datadog, met Fargate als hoofdgebruik. New Relic was aanzienlijk goedkoper totdat je logs ging verzenden en toen was Datadog plotseling 30-40% goedkoper, zelfs met apm. [Maar] hun kosten per host spelen ook een rol en maken APM nogal onaantrekkelijk, tenzij je iets serverloos doet. We wilden het gebruiken op Kubernetes, maar het was zo duur dat het management weigerde de kosten te geloven met services op Fargate, dus ik liet mijn cijfers meestal elke 2-3 maanden zien.”__– Evelyn Osman, Head of Platform bij enmacc
"Het enige wat ik nog heb is de herinnering aan het gezicht van de CFO toen hij de rekening zag."__ – iemand die liever anoniem blijft, ook al is dat citaat echt episch.
En dan is er natuurlijk nog het (inmiddels beruchte, in observatorische kringen) whodunit-mysterie van de 65 miljoen dollar kostende Datadog-rekening .
De eerste stap is toegeven dat je een probleem hebt
Vroeger (ik bedoel begin jaren 2000) was de uitdaging bij monitoring (observeerbaarheid was een term die we toen nog niet gebruikten) hoe we de benodigde gegevens konden identificeren en hoe we de systemen die gegevens konden laten vrijgeven. Vervolgens moesten we de gegevens op een manier opslaan die het mogelijk (en zeker efficiënt) maakte om ze te gebruiken in query's, weergaven, waarschuwingen en dergelijke.
Dat was waar bijna alle kosten lagen. De systemen zelf waren on-premises en, zodra de hardware was gekocht, effectief "gratis". Het resultaat was dat de geaccepteerde praktijk was om zoveel mogelijk te verzamelen en het voor altijd te bewaren. En ondanks de verandering in technologie, is de redenering van veel organisaties hetzelfde gebleven.
Grafana Solutions Architect Alec Isaacson geeft aan dat zijn gesprekken met klanten soms als volgt verlopen:
“Ik verzamel elke 5 seconden CDM-statistieken van mijn meest kritische systemen, omdat er ooit, lang geleden, tegen iemand werd geschreeuwd toen het systeem traag was en de statistieken niet aangaven waarom.”
Tegenwoordig is het verzamelen van monitoring- en observatiegegevens ("telemetrie") relatief eenvoudig, maar - zowel als individu als organisatie - hebben we onze framing van het probleem niet veranderd. Dus blijven we elk stukje data verzamelen dat voor ons beschikbaar is. We instrumenteren onze code met elke tag en span die we kunnen bedenken; als er een logbericht is, verzenden we het; hardware-statistieken? Pak het maar beter, want het biedt context; als er netwerktelemetrie is (NetFlow, VPC Flow-logs, streaming-telemetrie) zuigen we dat ook op.
Maar we nemen nooit de tijd om na te denken over wat we ermee gaan doen. De ervaring van mevr. Osman illustreert het resultaat:
“[Ze] hadden geen idee wat ze deden met het monitoren […] alle instrumentatie en logging was ingeschakeld en toen was er een lange retentie ‘voor het geval dat’. Dus ze verbrandden gewoon belachelijke bedragen”
Om het te koppelen aan een ander slecht gedrag waar we (min of meer) vanaf zijn: in de begindagen van "lift and shift" (vaak beter omschreven als "lift and shit") naar de cloud, verhuisden we applicaties niet alleen in zijn geheel; we verhuisden ze naar de grootste systemen die het platform bood. Waarom? Omdat je in de oude on-prem context maar één keer om een server kon vragen, en daarom vroeg je om het grootste wat je kon krijgen, om je investering toekomstbestendig te maken. Deze beslissing bleek niet alleen grappig naïef, het was ook verschrikkelijk duur en het duurde een paar jaar voordat iedereen begreep hoe "elastische computing" werkte en hun applicaties opnieuw inrichtte voor het nieuwe paradigma.
Het is ook de hoogste tijd dat we erkennen en erkennen dat we het ons niet kunnen veroorloven om alle beschikbare telemetriegegevens te verzamelen en dat we bovendien geen plan hebben voor die gegevens, zelfs als geld geen rol zou spelen.
Geef het toe: uw probleem heeft ook een probleem
Laat me even overschakelen naar OTel. Een van de belangrijkste redenen – mogelijk DE belangrijkste reden – om hiernaartoe te gaan, is om voor altijd en eeuwig de pijn van vendor lock-in weg te nemen. Dit is iets dat ik in mijn laatste blogpost heb onderzocht en dat onlangs werd herhaald door een vriend van mij:
OTel lost veel problemen op rondom "Oh geweldig! nu zitten we vast bij leverancier x en het gaat ons miljoenen kosten om al deze code te refactoren" in tegenstelling tot "Oh, we wisselen van leverancier? Cool, laat me gewoon mijn eindpunt updaten..." – Matt Macdonald-Wallace, Solutions Architect, Grafana Labs
Om het heel duidelijk te maken, OTel doet geweldig werk om dit probleem op te lossen, wat op zichzelf al ongelooflijk is. MAAR… er is een keerzijde aan OTel die mensen niet meteen opmerken, als ze het al opmerken. Dat probleem maakt het vorige probleem nog erger.
OTel neemt al uw gegevens (metrieken, logs, traces en de rest), verzamelt ze en stuurt ze naar waar u ze wilt hebben. Maar OTel doet dat niet altijd EFFICIËNT.
Voorbeeld 1: logberichten
Laten we het logbericht hieronder nemen, dat rechtstreeks uit syslog komt. Ja, de goede oude RFC 5424. Geboren in de jaren 80, gestandaardiseerd in 2009, en de onbetwiste "chatty kathy" van netwerkberichtenprotocollen. Ik heb netwerken van bescheiden omvang meer dan 4 miljoen syslogberichten per uur zien genereren. Het meeste daarvan was absoluut nutteloze onzin, let wel. Maar die berichten moesten ergens naartoe en onderweg door een systeem worden verwerkt (of verwijderd). Het is een van de redenen waarom ik al sinds mensenheugenis een syslog en trap "filtratiesysteem" heb voorgesteld.
Afgezien van muggenzifterij over het volume van berichten, zijn sommige van die berichten waardevol, voor sommige IT-professionals, soms. En dus moeten we ze ook overwegen (en verzamelen).
<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
Zoals het is, is dat logbericht 228 bytes – nauwelijks een druppel op een gloeiende plaat van de telemetrie die je elke minuut verzamelt, laat staan elke dag. Maar voor wat ik ga doen, wil ik een echte vergelijking van appels met appels, dus dit is hoe het eruit zou zien als ik het JSON-ifieerde:
{ "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" }
Dat verhoogt de payload naar 336 bytes zonder witruimte, of 415 bytes met. Ter vergelijking, hier is een voorbeeld van een OTLP Log-bericht:
{ "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" } }
Dat (generieke, minimale) bericht weegt 420 bytes (zonder witruimte; het is 520 bytes all-inclusive). Het is nog steeds klein, maar zelfs dan is de OTel-versie met witruimte 25% groter dan het JSON-ified bericht (met witruimte), en meer dan twee keer zo groot als het originele logbericht.
Zodra we echte data gaan toepassen, worden de zaken nog groter. Mijn punt hier is dit: als OTel dat met elk logbericht doet, lopen deze kleine kosten snel op.
Voorbeeld 2: Prometheus
Het blijkt dat moderne methoden van metrisch beheer net zo vatbaar zijn voor inflatie.
- Een typische Prometheus-metriek, geformatteerd in JSON, is 291 bytes groot.
- Maar dezelfde metriek, omgezet naar OTLP-metriekformaat, weegt 751 bytes.
Het is waar, OTLP heeft een batchingfunctie die dit verzacht, maar dat helpt alleen bij overdracht via de kabel. Zodra het op de bestemming aankomt, halen veel (niet alle, maar de meeste) leveranciers de batch eruit voordat ze het opslaan, dus het wordt weer 2,5x groter dan het oorspronkelijke bericht. Zoals mijn maatje Josh Biggley zei:
“2,5x-metrieken moeten een geweldig verhaal over de context vertellen om die kosten te rechtvaardigen.”
Het ligt niet aan jou, OTel, het ligt aan ons. (Maar het ligt ook aan jou)
Als dit allemaal een beetje hyperkritisch over OTel voelt, geef me dan alsjeblieft de kans om het uit te leggen. Ik geloof oprecht dat OTel een geweldige vooruitgang is en dat iedereen die serieus is over monitoring en observatie het als standaard moet aannemen – dat geldt voor zowel gebruikers als leveranciers. Het vermogen om de vlecht van logs, metrics, traces uit te zenden terwijl de context behouden blijft, ongeacht de bestemming, is van onschatbare waarde.
(Maar…) OTel is ontworpen door (en voor) software engineers. Het ontstond in dat vervlogen tijdperk (waarmee ik bedoel “2016”) toen we ons nog meer zorgen maakten over de moeilijkheid om de data te verkrijgen dan over de kosten van het verplaatsen, verwerken en opslaan ervan. OTel is, per ontwerp, gericht op volume.
Ondanks de grap van de titel van dit gedeelte, is het probleem niet echt OTel. Wij zijn echt de schuldige. Met name onze ongezonde relatie met telemetrie. Als we erop staan om elk afzonderlijk datapunt te verzamelen en te verzenden, hebben we niemand anders dan onszelf de schuld te geven van de torenhoge rekeningen die we aan het einde van de maand ontvangen.
Maakt deze data u blij?
Het is makkelijk om uw observability-oplossing het zware werk te laten doen en elke byte aan data naar een uniforme interface te shunten. Het is makkelijk om te doen als u een software-engineer bent die (nominaal tenminste) eigenaar is van de monitoring- en observability-oplossingen.
Het is nog makkelijker als je een simpele consument van die services bent, een onschuldige omstander. Mensen die in deze categorie vallen, zijn onder andere degenen die nauw verbonden zijn met een bepaalde silo (database, opslag, netwerk, etc.); of helpdesk- en NOC-teams die de tickets ontvangen en ondersteuning bieden, maar niet betrokken zijn bij de instrumentatie of de tools waarmee de instrumentatie is verbonden; of teams met meer gespecialiseerde behoeften die desondanks overlappen met monitoring en observeerbaarheid, zoals informatiebeveiliging.
Maar laten we eerlijk zijn, als je een security engineer bent, hoe kun je dan rechtvaardigen dat je twee keer zoveel betaalt om logs of metrics te verwerken, in vergelijking met de perfect goede standaarden die al bestaan en al jaren goed werken? Betekent dit dat je misschien meer dan één tool gebruikt? Ja. Maar zoals ik heb aangegeven ( keer op keer op keer op keer op keer opkeer ) is er geen (en is er nooit geweest, en zal er nooit zijn) een one-size-fits-all oplossing. En in de meeste situaties is er niet eens een one-size-fits-MOST oplossing. Monitoring en observability gingen altijd over heterogene implementaties. Hoe eerder je dat ideaal omarmt, hoe eerder je begint met het bouwen van observability ecosystemen die voldoen aan de behoeften van jou, je team en je bedrijf.
Daarom is het belangrijk om een serieuze ROI-discussie te voeren voordat u volledig voor OTel of een andere observatieoplossing kiest.
<EOF> (voor nu)
We hebben in het verleden de overstap gezien van prijsstelling per stoel (of interface, of chassis, of CPU) naar een consumptiemodel in de markt. En we hebben ook gezien dat technologieën teruggingen (zoals de manier waarop mobiele service van per minuut of per tekst naar onbeperkte data met een tarief per maand ging). Ik vermoed dat we in de toekomst een soortgelijke slinger terug zullen zien met monitoring en observeerbaarheid. Maar voor nu moeten we het doen met zowel het heersende prijssysteem zoals dat nu bestaat; als met onze eigen dwang – geboren op een ander punt in de geschiedenis van monitoring – om elk stukje (en byte) telemetrie dat onder onze neus passeert te verzamelen, verzenden en opslaan.
Natuurlijk zijn kosten niet de enige factor. Prestaties, risico's (en meer) moeten worden overwogen. Maar de kern van dit alles is de zeer reële noodzaak dat we onszelf de vraag gaan stellen:
- Wat ga ik met deze gegevens doen?
- Wie gaat het gebruiken?
- Hoe lang moet ik het bewaren?
En natuurlijk, wie gaat dat in godsnaam betalen?
