KONAJTE HNEĎ! ČASOVO OBMEDZENÁ PONUKA! OPERÁTOROV ČAKÁ! Som pripravený na svoje ďalšie dobrodružstvo ako advokát DevRel / technický evanjelista / IT Talespinner. Ak to znie ako niečo, čo potrebujete, napíšte mi na e-mail alebo na LinkedIn
Špecializujem sa na monitorovanie a pozorovateľnosť už 27 rokov a videl som veľa nástrojov a techník, ktoré prichádzajú a odchádzajú (Mon, niekto?); a mnohí prichádzajú a zostávajú (Fámy o smrti SNMP boli – a naďalej sú – značne prehnané.). V poslednej dobe som skúmal jedno z najnovších vylepšení vo vesmíre – OpenTelemetry (ktorú pre zvyšok tohto blogu skracujem na „OTel“). O mojom rozhodnutí ponoriť sa do OTel som písal nedávno .
Väčšinou si cestu užívam. Ale je tu problém, ktorý už nejaký čas existuje s pozorovateľnosťou a je to niečo, čo OTel nepomáha. Názov tohto príspevku naznačuje problém, ale chcem byť explicitnejší. Začnime porovnávacími nákupmi.
Skôr než naštvem každého predajcu v meste, chcem mať jasno v tom, že ide o široké, hrubé čísla na vysokej úrovni. Ak chcete skontrolovať podrobnosti, prepojil som sa na stránky s cenami a uznávam, že to, čo vidíte nižšie, nemusí nevyhnutne znamenať cenu, ktorú by ste mohli skutočne zaplatiť po získaní cenovej ponuky v skutočnom produkčnom prostredí.
Poplatky New Relic
- 35 ¢ za GB za všetky údaje, ktoré im pošlete.
- …hoci na cenovej stránke to nie je príliš jasné
Datadog má skutočný zoznam možností prania, ale na vysokej úrovni účtujú :
15 – 34 USD na hostiteľa
60 ¢ – 1,22 USD za milión záznamov čistého toku
1,06 – 3,75 USD za milión záznamov denníka
1,27 – 3,75 USD za milión rozpätí
Cenová stránka Dynatrace obsahuje zoznam takmer rovnako dlhý ako Datadog, ale niektoré kľúčové položky:
15 ¢ za 100,00 metrík
- plus 0,07 ¢ za koncert a deň na uchovanie
2 ¢ za koncert pre denníky
- plus 0,07 ¢- za koncert a deň na ich uchovanie
- plus 0,035 ¢ za vyžiadaný koncert
Udalosti majú rovnakú frekvenciu ako denníky
0,014 ¢ na 1 000 rozpätí
Grafana, ktorá – treba poznamenať – je open source a efektívne vám dáva všetko zadarmo, ak ste ochotní robiť ťažké práce s inštaláciou a hostingom. Ich cena sa však dá zhrnúť takto :
- 8,00 USD za 1 000 metrík (až 1/minútu)
- 50 ¢ za koncert za záznamy a ich sledovanie s 30-dňovým uchovávaním
Tento zoznam nie je ani vyčerpávajúci, ani úplný. Vynechal som veľa predajcov, nie preto, že by tiež nemali ceny založené na spotrebe, ale preto, že by to bolo viac rovnaké. Ani v prípade vyššie uvedených podrobností tu nie sú úplné. Niektoré spoločnosti účtujú nielen spotrebu (príjem), ale účtujú aj uloženie údajov a znova účtujú za dopytovanie údajov (pri pohľade na vás, New Relic). Niektoré spoločnosti vás tlačia, aby ste si vybrali úroveň služieb, a ak tak neurobíte, budú vám účtovať odhadovanú sadzbu na základe 99. percentilu používania za mesiac ( pri pohľade na vás, Datadog ).
Nikoho by nemalo prekvapiť, že to, čo sa objaví na ich cenovej stránke, nie je ani posledné slovo. Niektoré z týchto spoločností sa dokonca aj teraz snažia predefinovať svoju interpretáciu konceptu „ceny založenej na spotrebe“, ktorá by mohla veci ešte viac znejasniť (znovu sa na vás pozerám, New Relic).
Napriek všetkému, čo už bolo povedané, idem do úzadia a pre záznam uvádzam, že každý z týchto cenových bodov je taký nízky, že aj slovo „triviálny“ je príliš veľké.
To znamená, kým výrobné úväzky nesplnia cenový list. V tom momente sa tieto maličké čísla pripočítavajú k skutočným peniazom a to rýchlo.
Množné číslo Anekdoty
Položil som túto otázku niekoľkým priateľom a opýtal som sa ich, či zažili skutočný šok z nálepky. Moji priatelia ako vždy nesklamali.
„Pred pár rokmi som urobil podrobné porovnanie cien New Relic s Datadogom s Fargate ako hlavným použitím. New Relic bol výrazne lacnejší, kým ste nezačali posielať protokoly a potom bol Datadog zrazu o 30-40% lacnejší aj s apm. [Ale] ich cena na hostiteľa tiež ovplyvňuje a robí APM dosť neatraktívnym, pokiaľ nerobíte niečo bez servera. Chceli sme to použiť na kubernetes, ale bolo to také drahé, že vedenie odmietlo uveriť nákladom na služby na Fargate, takže som zvyčajne ukazoval svoje čísla každé 2-3 mesiace.“__– Evelyn Osman, vedúca platformy v enmacc
"Všetko, čo mám, je spomienka na tvár finančného riaditeľa, keď videl účet." __– niekto, kto uprednostňuje zostať v anonymite, aj keď je ten citát strašidelný.
A samozrejme je tu (teraz neslávne známy v kruhoch pozorovateľnosti) záhadná záhada účtu Datadog vo výške 65 miliónov dolárov .
Prvým krokom je priznať, že máte problém
Kedysi (tým myslím začiatok roku 2000) bolo problémom s monitorovaním (pozorovateľnosť ešte nebol termín, ktorý sme používali), ako identifikovať údaje, ktoré sme potrebovali, a potom prinútiť systémy, aby sa týchto údajov vzdali, a potom tieto údaje uložiť spôsobom, ktorý umožnil (nehovoriac o efektívnosti) použitie v dopytoch, zobrazeniach, upozorneniach atď.
Tam spočívali takmer všetky náklady. Samotné systémy boli lokálne a po zakúpení hardvéru boli v skutočnosti „zadarmo“. Výsledkom bolo, že akceptovanou praxou bolo nazbierať čo najviac a uchovať si to navždy. A napriek zmenám v technológii, úvahy mnohých organizácií zostali rovnaké.
Architekt Grafana Solutions Alec Isaacson poukazuje na to, že jeho rozhovory so zákazníkmi niekedy prebiehajú takto:
"Zbieram metriky CDM z mojich najkritickejších systémov každých 5 sekúnd, pretože raz, veľmi dávno, niekto zakričal, keď bol systém pomalý a metriky mu nepovedali prečo."
Dnes je zber údajov z monitorovania a pozorovateľnosti („telemetria“) pomerne jednoduchý, ale – ako jednotlivci, tak aj organizácie – sme nezmenili náš rámec problému. Pokračujeme teda v získavaní všetkých údajov, ktoré máme k dispozícii. Náš kód inštruujeme každým tagom a rozsahom, na ktorý si spomenieme; ak existuje správa denníka, odošleme ju; hardvérové metriky? Je lepšie ho uchopiť, pretože poskytne kontext; Ak existuje sieťová telemetria (NetFlow, VPC Flow logs, Streaming Telemetry), nasávame to tiež.
Nikdy si však nedávame čas na to, aby sme si premysleli, čo s tým urobíme. Skúsenosti pani Osmanovej ilustrujú výsledok:
„[Nemali] ani potuchy, čo robia s monitorovaním […] všetky prístroje a protokolovanie boli povolené, potom došlo k zdĺhavému uchovávaniu „pre každý prípad“. Takže len pálili smiešne peniaze“
Aby sme to pripojili k ďalšiemu zlému správaniu, ktoré sme si (viac-menej) zlomili: V začiatkoch „zdvihnutia a posunu“ (často presnejšie opísaného ako „zdvihnutie a posranie“) do cloudu sme nielenže presunuli aplikácie veľkoobchodne; presunuli sme to na najväčšie systémy, ktoré platforma ponúkala. prečo? Pretože v starom on-prem kontexte ste mohli požiadať o server iba raz, a preto ste požiadali o najväčšiu vec, ktorú ste mohli dostať, aby ste zabezpečili svoju investíciu do budúcnosti. Toto rozhodnutie sa ukázalo nielen ako zábavne naivné, ale bolo aj strašne drahé a každému trvalo niekoľko rokov, kým pochopil, ako „elastický výpočet“ funguje, a upravil svoje aplikácie pre novú paradigmu.
Rovnako je najvyšší čas, aby sme si uvedomili a uznali, že si nemôžeme dovoliť zbierať každý kus telemetrických údajov, ktoré máme k dispozícii, a navyše, že na tieto údaje nemáme plán, aj keď peniaze neboli predmetom.
Priznajte sa: Váš problém má tiež problém
Dovoľte mi na chvíľu odbočiť k OTel. Jedným z kľúčových dôvodov – možno TEN KĽÚČOVÝ – prečo sa k nemu presťahovať, je navždy a navždy odstrániť bolesť spojenú s predajom. Toto je niečo, čo som preskúmal v mojom poslednom blogovom príspevku a nedávno to zopakoval môj priateľ:
OTel rieši veľa problémov okolo „Ó, skvelé! teraz sme uväznení s dodávateľom x a bude nás stáť milióny prerobenie celého tohto kódu“ na rozdiel od „Och, meníme dodávateľov? Skvelé, dovoľte mi aktualizovať môj koncový bod...“ – Matt Macdonald-Wallace, Solutions Architect, Grafana Labs
Aby bolo úplne jasné, OTel odvádza úžasnú prácu pri riešení tohto problému, ktorý je sám o sebe neuveriteľný. ALE... OTel má nevýhodu, ktorú si ľudia nevšimnú hneď, ak si to vôbec všimnú. Tento problém ešte viac zhoršuje predchádzajúci problém.
OTel vezme všetky vaše údaje (metriky, protokoly, stopy a ostatné), zhromažďuje ich a posiela, kam chcete. Ale OTel to nie vždy robí EFEKTÍVNE.
Príklad 1: správy denníka
Zoberme si správu protokolu nižšie, ktorá pochádza priamo zo syslogu. Áno, starý dobrý RFC 5424. Narodený v 80-tych rokoch, štandardizovaný v roku 2009 a nesporná „ukecaná kathy“ protokolov sieťových správ. Videl som, že siete skromnej veľkosti generujú viac ako 4 milióny správ syslog za hodinu. Väčšina z toho bola úplne zbytočná hlúposť, uvedomte si. Ale tie správy museli niekam ísť a počas cesty ich nejaký systém spracoval (alebo zahodil). Je to jeden z dôvodov, prečo som v podstate odjakživa navrhoval „filtračný systém“ syslog a pasce.
Ak neberieme do úvahy objem správ, niektoré z týchto správ majú hodnotu pre niektorých IT odborníkov. A tak ich musíme zvažovať (a zbierať) aj my.
<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
Ako taká má správa denníka 228 bajtov – čo je sotva kvapka v telemetrii, ktorú zbierate každú minútu, nieto ešte každý deň. Ale pre to, čo sa chystám urobiť, chcem skutočné porovnanie jabĺk s jablkami, takže takto by to vyzeralo, keby som to overil 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" }
To zvyšuje užitočné zaťaženie až na 336 bajtov bez medzier alebo 415 bajtov s. Teraz, na porovnanie, tu je vzorová správa protokolu 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" } }
Táto (všeobecná, minimálna) správa má hmotnosť 420 bajtov (bez medzier; je to 520 bajtov vrátane). Je to stále malé, ale aj tak je verzia OTel s medzerami o 25 % väčšia ako správa v JSON (s medzerami) a viac ako dvakrát väčšia ako pôvodná správa protokolu.
Keď začneme používať údaje z reálneho sveta, veci sa rozbehnú ešte viac. Ide mi o toto: Ak to OTel urobí s každou správou denníka, tieto malé náklady sa rýchlo sčítajú.
Príklad 2: Prometheus
Ukazuje sa, že moderné metódy riadenia metrických údajov sú rovnako náchylné na infláciu.
- Typická metrika prometheus, formátovaná v JSON, je 291 bajtov.
- Ale tá istá metrika prevedená do formátu metrík OTLP váži 751 bajtov.
Je pravda, že OTLP má funkciu dávkovania, ktorá to zmierňuje, ale pomáha len pri prenose cez drôt. Akonáhle dorazí na miesto určenia, mnohí (nie všetci, ale väčšina) predajcov odoberú dávku pred uložením, takže je 2,5-krát väčšia ako pôvodná správa. Ako povedal môj kamarát Josh Biggley,
„2,5-násobne lepšie prijímané metriky majú kurevsky úžasný príbeh o kontexte, ktorý ospravedlní tieto náklady.“
Nie ste to vy, OTel, to sme my. (Ale si to aj ty)
Ak sa toto všetko zdá byť pre OTel trochu hyperkritické, dajte mi prosím šancu to vysvetliť. Úprimne verím, že OTel je úžasný pokrok a každý, kto to myslí s monitorovaním a pozorovateľnosťou vážne, ho musí prijať ako štandard – to platí pre používateľov aj predajcov. Schopnosť vysielať vrkoč log, metrík, stôp pri zachovaní kontextu, bez ohľadu na miesto určenia, je neoceniteľná.
(Ale...) OTel bol navrhnutý (a pre) softvérovými inžiniermi. Vzniklo v tej minulej ére (myslím tým „2016“), keď sme sa stále viac zaujímali o ťažkosti pri získavaní údajov ako o náklady na ich presun, spracovanie a uloženie. OTel je dizajnovo orientovaný na objem.
Bez ohľadu na vtip názvu tejto sekcie, problém naozaj nie je OTel. Naozaj sme na vine. Konkrétne náš nezdravý vzťah k telemetrii. Ak trváme na zhromažďovaní a prenose každého jedného dátového bodu, nemôžeme viniť nikoho iného, iba seba za vysoké účty, ktoré dostávame na konci mesiaca.
Prinášajú vám tieto údaje radosť?
Je ľahké nechať svoje riešenie pozorovateľnosti robiť ťažkú prácu a presúvať každý bajt údajov do jednotného rozhrania. Je to jednoduché, ak ste softvérový inžinier, ktorý (aspoň nominálne) vlastní riešenia monitorovania a pozorovateľnosti.
Je to ešte jednoduchšie, ak ste iba konzumentom týchto služieb, nevinným okoloidúcim. Ľudia, ktorí spadajú do tejto kategórie, zahŕňajú tých, ktorí sú úzko spätí s konkrétnym zásobníkom (databáza, úložisko, sieť atď.); alebo tímy helpdesk a NOC, ktoré dostávajú lístky a poskytujú podporu, ale nie sú zapojené do prístrojového vybavenia ani do nástrojov, ku ktorým je prístrojové vybavenie pripojené; alebo tímy so špecializovanejšími potrebami, ktoré sa však prekrývajú s monitorovaním a pozorovateľnosťou, ako napríklad informačná bezpečnosť.
Ale povedzme si úprimne, ak ste bezpečnostný inžinier, ako môžete odôvodniť platenie dvojnásobných nákladov za príjem protokolov alebo metrík v porovnaní s úplne dobrými štandardmi, ktoré už existujú a dobre slúžia už roky? Znamená to, že možno používate viac ako jeden nástroj? áno. Ale ako som zdôraznil ( čas a čas a čas a znovaa znova) , neexistuje (a nikdy nebolo a nikdy nebude) univerzálne riešenie. A vo väčšine situácií ani neexistuje univerzálne riešenie. Monitorovanie a pozorovateľnosť boli vždy o heterogénnych implementáciách. Čím skôr tento ideál prijmete, tým skôr začnete budovať ekosystémy pozorovateľnosti, ktoré slúžia potrebám vás, vášho tímu a vášho podnikania.
Za týmto účelom je potrebné viesť serióznu diskusiu o návratnosti investícií predtým, ako sa pustíte do OTel alebo akéhokoľvek riešenia pozorovateľnosti.
<EOF> (zatiaľ)
V minulosti sme na trhu videli prechod od ceny za sedadlo (alebo rozhranie, šasi alebo CPU) k modelu spotreby. A tiež sme videli, ako sa technológie posunuli späť (napríklad spôsob, akým sa mobilné služby presunuli z minútovej alebo textovej na neobmedzené dáta s mesačným poplatkom). Mám podozrenie, že niekedy v budúcnosti by sme mohli vidieť podobné kývanie kyvadla späť s monitorovaním a pozorovateľnosťou. Nateraz však musíme zápasiť s prevládajúcim cenovým systémom, aký dnes existuje; a s naším vlastným nutkaním – zrodeným v inom bode histórie monitorovania – zhromažďovať, prenášať a ukladať každý bit (a bajt) telemetrie, ktorá nám prejde popod nos.
Samozrejme, cena nie je jediným faktorom. Je potrebné zvážiť výkon, riziko (a ďalšie). Ale v srdci toho všetkého je veľmi skutočná potreba, aby sme sa začali pýtať sami seba:
- Čo urobím s týmito údajmi?
- Kto to využije?
- Ako dlho ho musím skladovať?
A samozrejme, kto to do pekla zaplatí?
