RĪKOTIES TAGAD! PIEDĀVĀJUMS IEROBEŽOTĀ LAIKĀ! OPERATORI GAIDĀ! Esmu gatavs nākamajam piedzīvojumam kā DevRel advokāts / tehniskais evaņģēlists / IT stāstu vērpējs. Ja tas izklausās pēc kaut kā jums nepieciešama, rakstiet man e-pastā vai LinkedIn
Esmu specializējies uzraudzībā un novērojamībā jau 27 gadus, un esmu redzējis, ka daudzi rīki un paņēmieni nāk un iet (RMon, kāds?); un vairāk nekā daži nāk un paliek (Baumas par SNMP nāvi ir bijušas un joprojām ir stipri pārspīlētas.). Pēdējā laikā esmu pētījis vienu no jaunākajiem šīs vietas uzlabojumiem — OpenTelemetry (ko atlikušajā šī emuāra daļā es nosaucu par “OTel”). Nesen rakstīju par savu lēmumu ienirt OTel .
Lielākoties es izbaudu braucienu. Taču jau kādu laiku pastāv problēma ar novērojamību, un OTel to nepalīdz. Šīs ziņas virsraksts norāda uz problēmu, bet es vēlos būt skaidrāks. Sāksim ar salīdzināšanas iepirkšanos.
Pirms apbēdinu katru pilsētas pārdevēju, vēlos skaidri pateikt, ka tie ir plaši, aptuveni un augsta līmeņa skaitļi. Ja vēlaties pārbaudīt detalizētu informāciju, esmu izveidojis saites uz cenu noteikšanas lapām, un es atzīstu, ka tālāk redzamais ne vienmēr norāda uz cenu, ko jūs faktiski varētu maksāt pēc cenas piedāvājuma saņemšanas reālā ražošanas vidē.
Jaunas relikvijas maksas
- 35 ¢ par GB par visiem jūsu nosūtītajiem datiem.
- …lai gan cenu lapā tas nav īpaši skaidrs
Datadog ir īsts iespēju saraksts, taču augstā līmenī tie iekasē :
15–34 USD par saimnieku
60 ¢ – 1,22 USD par miljonu neto plūsmas ierakstu
1,06–3,75 USD par miljonu žurnāla ierakstu
1,27–3,75 USD par miljonu
Dynatrace cenu lapā ir gandrīz tikpat garš saraksts kā Datadog, taču daži galvenie vienumi:
15 ¢ par 100,00 metrikām
- plus 0,07 ¢ par koncertu dienā par saglabāšanu
2¢ par koncertu baļķiem
- plus 0,07 ¢- par koncertu dienā, lai tos saglabātu
- plus 0,035 ¢ par vienu vaicāto koncertu
Notikumiem ir tāds pats rādītājs kā žurnāliem
0,014 ¢ par 1000 laidumiem
Grafana, kas – jāatzīmē – ir atvērtā koda avots un efektīvi sniedz visu bez maksas, ja vēlies veikt smagnējo instalēšanas un mitināšanas darbu. Bet to cenu var apkopot šādi :
- 8,00 USD par 1000 metriku (līdz 1 minūtē)
- 50 ¢ par koncertu par baļķiem un to izsekošanu ar 30 dienu saglabāšanu
Šis saraksts nav ne pilnīgs, ne pilnīgs. Esmu atstājis daudzus pārdevējus, nevis tāpēc, ka viņiem arī nav uz patēriņu balstītas cenas, bet gan tāpēc, ka tas būtu vairāk vienāds. Pat ar iepriekšminētajiem, informācija šeit nav pilnīga. Daži uzņēmumi iekasē maksu ne tikai par patēriņu (ievadīšanu), bet arī iekasē maksu par datu glabāšanu un vēlreiz iekasē maksu par datu vaicājumu (skatoties uz jums, New Relic). Daži uzņēmumi mudina jūs izvēlēties pakalpojuma līmeni, un, ja jūs to neizvēlaties, tie no jums iekasēs aptuveno likmi, kas balstīta uz 99. procentili mēnesī ( skatoties uz jums, Datadog ).
Nevienu nevajadzētu pārsteigt, ka tas, kas parādās viņu cenu lapā, nav pat pēdējais vārds. Daži no šiem uzņēmumiem pat tagad cenšas no jauna definēt savu “uz patēriņu balstītu cenu noteikšanas” jēdziena interpretāciju, kas varētu padarīt lietas vēl nepārskatāmākas (ATKAL skatoties uz jums, New Relic).
Pat ja tas viss ir teikts, es gribu teikt, ka katrs no šiem cenu punktiem ir tik zems, ka pat vārds “triviāls” ir pārāk liels.
Tas ir, līdz ražošanas slodzes atbilst cenu lapai. Tajā brīdī šie sīkie skaitļi ātri saskaita reālu naudu.
Anekdotes daudzskaitlis
Es uzdevu šo jautājumu dažiem draugiem, vaicājot, vai viņiem ir bijusi reāla pieredze ar uzlīmju šoku. Kā vienmēr, mani draugi nelika vilties.
“Pirms pāris gadiem es veicu detalizētu New Relic cenu salīdzinājumu ar Datadog, un Fargate kā galveno lietojumu. New Relic bija ievērojami lētāks, līdz sākāt sūtīt baļķus, un tad Datadog pēkšņi bija par 30-40% lētāks pat ar apm. [Bet] to izmaksas uz vienu saimniekdatoru arī ietekmē un padara APM diezgan nepievilcīgu, ja vien jūs neveicat kaut ko bez servera. Mēs vēlējāmies to izmantot kubernetes, taču tas bija tik dārgi, vadība atteicās ticēt Fargate pakalpojumu izmaksām, tāpēc es parasti rādīju savus numurus ik pēc 2–3 mēnešiem. ”__– Evelyn Osman, enmacc platformas vadītāja
“Viss, ko es atceros, ir finanšu direktora atmiņa, kad viņš ieraudzīja likumprojektu.”__ — kāds, kurš vēlas palikt anonīms, lai gan šis citāts ir satriecoši episks.
Un, protams, ir (tagad bēdīgi slavenais, novērojamības aprindās), kas ir 65 miljonu dolāru Datadog rēķina noslēpums.
Pirmais solis ir atzīt, ka jums ir problēma
Kādreiz (ar to es domāju 2000. gadu sākumu) izaicinājums ar uzraudzību (novērojamība vēl nebija mūsu lietots termins) bija, kā identificēt mums vajadzīgos datus un pēc tam panākt, lai sistēmas atsakās no šiem datiem, un pēc tam uzglabāt šos datus tā, lai tos būtu iespējams (nemaz nerunājot par efektīvu) izmantot vaicājumos, displejos, brīdinājumos un tamlīdzīgi.
Tur bija gandrīz visas izmaksas. Pašas sistēmas bija lokālas un, tiklīdz aparatūra tika nopirkta, faktiski “bezmaksas”. Rezultāts bija tāds, ka pieņemtā prakse bija savākt pēc iespējas vairāk un saglabāt to mūžīgi. Un, neskatoties uz izmaiņām tehnoloģijā, daudzu organizāciju argumentācija ir palikusi nemainīga.
Grafana Solutions arhitekts Alec Isaacson norāda, ka viņa sarunas ar klientiem dažreiz notiek šādi:
"Es savācu CDM metriku no savām vissvarīgākajām sistēmām ik pēc 5 sekundēm, jo reiz, ļoti sen, kāds uzsauca, kad sistēma darbojās lēni, un metrika nepaskaidroja, kāpēc."
Mūsdienās monitoringa un novērojamības datu vākšana (“telemetrija”) ir salīdzinoši vienkārša, taču – gan kā indivīdi, gan organizācijas – mēs neesam mainījuši problēmas formulējumu. Tāpēc mēs turpinām iegūt visus mums pieejamos datus. Mēs instrumentējam savu kodu ar katru tagu un diapazonu, ko varam iedomāties; ja ir žurnāla ziņojums, mēs to nosūtām; aparatūras rādītāji? Labāk paņemiet to, jo tas nodrošinās kontekstu; Ja ir tīkla telemetrija (NetFlow, VPC plūsmas žurnāli, straumēšanas telemetrija), mēs to arī ņemam vērā.
Bet mēs nekad neatvēlam laiku, lai domātu par to, ko mēs ar to darīsim. Osmanas kundzes pieredze ilustrē rezultātu:
“[Viņiem] nebija ne jausmas, ko viņi dara ar uzraudzību […] tika iespējota visa instrumentācija un reģistrēšana, tad “katram gadījumam” tika veikta ilgstoša saglabāšana. Tātad viņi vienkārši dedzināja smieklīgas naudas summas.
Lai to saistītu ar citu slikto uzvedību, no kuras esam (vairāk vai mazāk) pieļāvuši: “Paceliet un pārbīdām” (bieži vien precīzāk apraksta kā “paceliet un sūdos”) uz mākoni, mēs ne tikai pārvietojām lietojumprogrammas vairumtirdzniecībā; mēs to pārvietojām uz lielākajām platformas piedāvātajām sistēmām. Kāpēc? Tā kā vecajā lokālajā kontekstā serveri varējāt lūgt tikai vienu reizi, un tāpēc jūs prasījāt lielāko, ko varēja iegūt, lai nodrošinātu savu ieguldījumu nākotnē. Šis lēmums izrādījās ne tikai uzjautrinoši naivs, tas bija šausmīgi dārgs, un visiem bija vajadzīgi daži gadi, lai saprastu, kā darbojas “elastīgā aprēķins”, un pārveidotu savus lietojumprogrammas jaunajai paradigmai.
Tāpat ir pēdējais laiks apzināties un atzīt, ka mēs nevaram atļauties vākt visus mums pieejamos telemetrijas datus, un turklāt mums nav šo datu plāna, pat ja nauda nav objekts.
Atzīstiet: jūsu problēmai ir arī problēma
Ļaujiet man uz brīdi pāriet uz OTel. Viens no galvenajiem iemesliem — iespējams, GALVENAIS iemesls —, lai pārietu uz to, ir uz visiem laikiem un vienmēr novērst sāpes, ko rada pārdevēja bloķēšana. Tas ir kaut kas, ko es izpētīju savā pēdējā emuāra ierakstā, un nesen to atkārtoja mans draugs:
OTel patiešām atrisina daudzas problēmas saistībā ar “Ak, lieliski! tagad mēs esam iesprostoti ar pārdevēju x, un visa šī koda pārstrukturēšana mums izmaksās miljonus” pretstatā “Ak, mēs mainām pārdevējus? Forši, ļaujiet man vienkārši atjaunināt savu beigu punktu…” - Mets Makdonalds-Volss, risinājumu arhitekts, Grafana Labs
Lai būtu ļoti skaidrs, OTel veic pārsteidzošu darbu, risinot šo problēmu, kas pati par sevi ir neticama. BET… OTel ir mīnuss, ko cilvēki nepamana uzreiz, ja vispār to pamana. Šī problēma vēl vairāk pasliktina iepriekšējo problēmu.
OTel ņem visus jūsu datus (metriku, žurnālus, pēdas un pārējos), apkopo tos un nosūta tos, kur vien vēlaties. Taču OTel ne vienmēr to dara EFEKTĪVI.
1. piemērs: žurnāla ziņojumi
Ņemsim tālāk redzamo žurnāla ziņojumu, kas nāk tieši no syslog. Jā, vecais labais RFC 5424. Dzimis 80. gados, standartizēts 2009. gadā un neapstrīdams tīkla ziņojumu protokolu “pļāpātais kathy”. Esmu redzējis, ka neliela izmēra tīkli ģenerē vairāk nekā 4 miljonus sistēmas žurnāla ziņojumu stundā. Lielākā daļa no tā bija absolūti bezjēdzīga braukšana, ņemiet vērā. Bet šiem ziņojumiem bija kaut kur jānonāk un kādā sistēmā tie ir jāapstrādā (vai jāatmet). Tas ir viens no iemesliem, kāpēc es esmu ierosinājis syslog un lamatas "filtrēšanas sistēmu" būtībā uz visiem laikiem .
Ja nevēlaties izvēlēties ziņojumu apjomu, daži no šiem ziņojumiem dažkārt ir vērtīgi dažiem IT speciālistiem. Un tāpēc mums ir jāņem vērā (un jāapkopo) arī tie.
<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
Pats žurnāla ziņojums ir 228 baiti — gandrīz pat piliens telemetrijas datu spainī, ko apkopojat katru minūti, nemaz nerunājot par katru dienu. Bet saistībā ar to, ko es gatavojos darīt, es vēlos īstu ābolu un ābolu salīdzinājumu, tāpēc lūk, kā tas izskatītos, ja es to pārveidotu JSON formātā:
{ "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" }
Tas palielina lietderīgo slodzi līdz 336 baitiem bez atstarpēm vai 415 baitiem ar. Tagad salīdzinājumam šeit ir OTLP žurnāla ziņojuma paraugs:
{ "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" } }
Šī (vispārējā, minimālā) ziņojuma svars ir 420 baiti (bez atstarpes; tas ir 520 baiti, viss iekļauts). Tas joprojām ir niecīgs, taču pat tādā gadījumā OTel versija ar atstarpi ir par 25% lielāka nekā JSON formētais ziņojums (ar atstarpi) un vairāk nekā divas reizes lielāks par sākotnējo žurnāla ziņojumu.
Tiklīdz mēs sākam lietot reālās pasaules datus, lietas kļūst vēl lielākas. Mana doma ir šāda: ja OTel to dara ar katru žurnāla ziņojumu, šīs nelielās izmaksas ātri palielinās.
2. piemērs: Prometejs
Izrādās, ka mūsdienu metriskās pārvaldības metodes ir tikpat jutīgas pret inflāciju.
- Tipiska Prometheus metrika, kas formatēta JSON, ir 291 baits.
- Bet tā pati metrika, kas pārveidota OTLP metrikas formātā, sver 751 baitu.
Tā ir taisnība, OTLP ir pakešu funkcija, kas to mazina, taču tā palīdz tikai pārsūtīšanai pa vadu. Kad tas nonāk galamērķī, daudzi (ne visi, bet lielākā daļa) pārdevēju pirms uzglabāšanas izņem partiju, tāpēc tas atkal ir 2,5 reizes lielāks nekā sākotnējais ziņojums. Kā teica mans draugs Džošs Biglijs,
“Lai attaisnotu šīs izmaksas, ir 2,5 reižu metrika, ko labāk izstāstīt par kontekstu.”
Tas neesat jūs, OTel, tie esam mēs. (Bet tas esi arī tu)
Ja tas viss šķiet pārāk kritisks pret OTel, lūdzu, dodiet man iespēju paskaidrot. Es godīgi uzskatu, ka OTel ir pārsteidzošs sasniegums, un ikvienam, kas nopietni nodarbojas ar uzraudzību un novērojamību, tas ir jāpieņem kā standarts — tas attiecas gan uz lietotājiem, gan pārdevējiem. Iespēja izstarot baļķu, metriku, pēdu pinumu, vienlaikus saglabājot kontekstu neatkarīgi no galamērķa, ir nenovērtējama.
(Bet…) OTel izstrādāja programmatūras inženieri (un priekš tiem). Tas radās tajā aizgājušajā laikmetā (ar to es domāju “2016”), kad mūs joprojām vairāk uztrauca datu iegūšanas grūtības, nevis to pārvietošanas, apstrādes un uzglabāšanas izmaksas. OTel pēc konstrukcijas ir orientēts uz apjomu.
Neskatoties uz šīs sadaļas virsraksta joks, problēma patiešām nav OTel. Mēs tiešām esam vainīgi. Jo īpaši mūsu neveselīgās attiecības ar telemetriju. Ja mēs uzstājam uz katra atsevišķa datu punkta ievākšanu un pārsūtīšanu, mēs nevaram vainot nevienu, izņemot sevi, par augstajiem rēķiniem, ko saņemam mēneša beigās.
Vai šie dati jums sagādā prieku?
Ir viegli ļaut savam novērošanas risinājumam veikt smago celšanu un šuntēt katru datu baitu vienotā saskarnē. To ir viegli izdarīt, ja esat programmatūras inženieris, kuram (vismaz nomināli) pieder uzraudzības un novērojamības risinājumi.
Tas ir vēl vienkāršāk, ja esat tikai šo pakalpojumu patērētājs, nevainīgs skatītājs. Šajā kategorijā ietilpst cilvēki, kas ir cieši saistīti ar noteiktu tvertni (datu bāze, krātuve, tīkls utt.); vai palīdzības dienesta un NOC komandas, kas saņem biļetes un sniedz atbalstu, bet nav iesaistītas ne instrumentos, ne instrumentos, ar kuriem instruments ir savienots; vai komandas ar specializētākām vajadzībām, kas tomēr pārklājas ar uzraudzību un novērojamību, piemēram, informācijas drošību.
Bet būsim godīgi, ja esat drošības inženieris, kā jūs varat attaisnot divreiz dārgāku žurnālu vai metriku pārņemšanu salīdzinājumā ar pilnīgi labajiem standartiem, kas jau pastāv un ir labi kalpojuši gadiem ilgi? Vai tas nozīmē, ka jūs, iespējams, izmantojat vairāk nekā vienu rīku? Jā. Bet, kā jau esmu norādījis ( laiku un laiku , un laiku , un atkalun atkal), nav (un nekad nav bijis un nekad nebūs) viena risinājuma , kas derētu visiem. Un vairumā gadījumu nav pat vispiemērotākā risinājuma. Uzraudzība un novērojamība vienmēr ir bijusi saistīta ar neviendabīgu ieviešanu. Jo ātrāk jūs pieņemsit šo ideālu, jo ātrāk sāksit veidot novērojamības ekosistēmas, kas atbilst jūsu, jūsu komandas un jūsu uzņēmuma vajadzībām.
Šim nolūkam ir jāveic nopietna IA diskusija, pirms sākat izmantot OTel vai jebkuru novērojamības risinājumu.
<EOF> (pagaidām)
Mēs esam redzējuši pāreju no vienas vietas (vai interfeisa, vai šasijas vai CPU) cenu noteikšanas uz patēriņa modeli tirgū. Mēs esam arī redzējuši, ka tehnoloģijas ir atgriezušās atpakaļ (piemēram, veids, kā mobilais pakalpojums pārcēlās no minūtes vai teksta uz neierobežotiem datiem ar mēneša maksu). Man ir aizdomas, ka nākotnē mēs varam redzēt līdzīgu svārsta pagriezienu atpakaļ ar uzraudzību un novērojamību. Bet pagaidām mums ir jācīnās gan ar dominējošo cenu sistēmu, kāda tā pastāv šodien; un ar mūsu pašu piespiešanu, kas radusies citā monitoringa vēstures punktā, apkopot, pārsūtīt un saglabāt katru telemetrijas bitu (un baitu), kas iet zem mūsu deguna.
Protams, izmaksas nav vienīgais faktors. Jāņem vērā veiktspēja, risks (un daudz kas cits). Bet visa pamatā ir patiesa vajadzība sākt sev jautāt:
- Ko es darīšu ar šiem datiem?
- Kurš to izmantos?
- Cik ilgi man tas jāuzglabā?
Un, protams, kurš pie velna par to maksās?
