Vineri ma plictisisem de prostituat pe la birou si m-am bagat si eu in seama intr-o discutie dintre niste programatori PHP-isti si Ops. In seama in sensul ca ascultam ca poate mai aflu chestii depsre una-alta.
La un moment dat s-au apucat sa vorbreasca despre scos metrice din aplicatii PHP si despre cum ar fi complicat ca alea ruleaza pe multe pod-uri in Kubernetes si ca php-fpm iti omoara procese si ai multe procese si alte cele.
In momentul ala mi-a scaparat o idee ca se pot scoate metrici super usor, trebuie doar sa le tii undeva :))
Eu sunt asa super fan Redis ca mi se pare ca e genul ala de software scris cum trebuie (adica in C) si cu grija (adica merge repede).
M-am gandit eu vineri ca pot scrie din PHP in Redis si dupa aia sa le iau de acolo si sa le pune undeva de unde le poata lua Prometheus.
Problema asta fiind rezolvata, am ajuns la cum fac sa nu trebuiasca sa populez inainte Redis-ul cu informatii si dupa aia sa scrie aplicatia chestii pe acolo. Am zis ca’s fan Redis? E, Redix are SETNX, prin care setezi o cheie la o anumita valoare doar daca cheia aia nu exista. Si asta inseamna ca poti sa spawnezi ‘jde aplicatii care prima oara fac SETNX si dupa aia incrementeaza pe acolo contoare. Mi-am dat un self-highfive si m-am apucat de scris.
M-am apucat de scris azi, ca peste weekend am avut altele de facut, da mi-a mers acolo ganditul in background si azi stiui ce sa scriu.
Cam asta e povestea lui Enigmatique. Ca e enigmatic asa sa nu stii cate metrici o sa ai si nici Prometheus cand face scrape n-o sa stie :))
Am scris asta din doua motive mari asa:
- Stiu ca vocile nu’s reale, dar cateodata au idei bune. Asta fu’ unu’ din cazuri.
- Sa mai fac ceva practica cu programatul, ca nu se stie cand mai au vocile idei.
Si ii facui si logo, ca nu se stie cand e nevoie de-un logo. Sa traiasca Shopify ca are aplicatie de facut logo-uri :))
Cred ca sint deja o multime de biblioteci care pot impinge metrici in prometheus pushgateway. Also “merge repede si e in C” e aproape o prostie in ziua de azi ;)
Asta e o alta abordare si pe deasupra te scapa de un catch in pushgateway: poti sa nu exporti metrice mai mult de 5 min si prometheus n-o sa zica ca nu mai exista metrica.
Legat de C, fiecare cu opiniile lui si evident cred ca gresesti pentru ca orice nu e C e un pic mai prost decat daca ar fi fost scris in C :)
Mai era unu’ acum citiva ani pentru care orice software care nu era scris in assembler era mai lent, mai prost, mai naspa.
In fine, parerea mea ca pentru cele dooj’ de pehaspeuri despre care vorbesti, pushgateway este ceea ce iti trebuia de fapt (daca vei citi doacele de prometheus vei vedea ca pentru asta a fost si facut).
Sint niste limitari legate de pushgw, dar nu in situatia ta.
IMHO nu ai facut decit sa fii pehaspist si in loc sa refolosesti o solutie facuta (si testata) pentru problema ta, te-ai apucat sa o rescrii from scratch ca stii tu mai bine.
In ce priveste metricile, astea-s niste animalute la care pierderea citorva pe drum nu ar trebui sa conteze pentru ca de fapt orice decizie asupra lor ar trebui sa o iei asupra unor agregate, nu asupra unor datapointuri individuale(daca te uiti la datapointuri individuale, nu metrici cauti ci altceva).
Nici nu o sa ma apuc sa compar din nou cele dooj de pehaspeuri cu infrastructurile pe care lumea pune de obicei statsd fara sa il satureze din cauza de udp asa cum sugerezi tu. Adica sigur, daca vrei sa reinventezi roata si sa o faci ovala, o faci pe timpul tau :)
Nu’s asa jihadist cu ASM, mi-a trecut acu vreo 15 ani :) Bine, apreciez cod prin care mai vad inline assembler ‘for old times sake’.
Am citit documentatia de la pushgateway si mi s-a parut un pic limitat la treaba cu expirarea metricilor (in loc sa puna 0 de la el pentru ce nu mai primeste informatii).
Nu apreciez atitudinea asta condescendenta cu ‘pentru dooj de scripturi’. Poate pentru alea 5 scripturi ale tale de le pui in ‘infrastructuri unde nu se satureaza statsd’ e ok sa folosesti statsd :))
As apecia mai mult un “ai un bug la linia 15” sau “poti sa optimizezi X si Y in felul Z” decat treaba asta cu “exista deja ceva facut, de ce sa mai faci si tu”.
Nu inteleg care e de fapt problema ta, da’ ce-are daca trimiti pe protocolul de statsd (adica via udp, adica cu impact minimal asupra aplicatiei) chestii in prometheus fara sa chinui un redis? Exista si gateway gata facut: https://github.com/prometheus/statsd_exporter
In primul rand nu prea mai sunt aplicatii fara Redis (sau MemCache ca e oarecum similar) in care se tin informatii pentru cache/stare, si daca mai pui cateva chei nu se intampla nimic. “Sa stresezi Redis” ar inseamna sa bag nu stiu… 50 de milioane e metrici ca sa aiba multe chei de sortat sau ceva si asta probabil ar insemna un overhead de inca 10msec in plus la citire. In al doilea rand, fiind UDP, StatsD poate la fel de bine sa nu mearga sau sa nu primeasca metrici si inseamna sa pui monitorizare suplimentara pe el sa vezi daca vin metrici si care e rate-ul minim de metrici primite astfel incat sa stii ca merge sau nu. Plus de adaugat inca o biblioteca in aplicatie :)