FSF konferencia 2018

Utana Tomka Gergely megosztott par sztorit hadoop klaszterekrol, meg tulkepzett security csapatokrol, ill. arrol, hogy legyen mentesed!

Aztan jott egy eloadas, amiben kivaltottuk a microsoft SBS-et Uninvention corporate szervererrel + kopano-val (ami egy zarafa fork). Tetszik benne, hogy van hozza egy store, amibol osszelegozhatja az ember, hogy mi kell neki. Bar az ilyen cuccok kapcsan mindig van egy olyan felsz bennem, hogy akkor mit csinal az egyszeri rendszergazda, ha olyan dologra van szuksege, amit a gui (vagy meg a cli sem) nem tud: pl. email archivalas beallitasa.

Vegul jott atya az adatbazisok teljesitmenyhangolasaval kapcsolatban. Sajnos nem ert a mondanivaloja vegere, de kivancsian varom a slide-jait, mert erdekel a vege is :-) Azzal viszont vitatkoznek, hogy az optimalizaciot [lehetoleg] a kod modositasa nelkul kelljen megoldani. Szerintem leginkabb az ugyetlen alkalmazasok (es itt most nem a posgresql-re gondolok, hanem arra a kodra, ami azt [is] hasznalja) fixalasaval lehet a legnagyobb sebessegjavulast elerni.

Volt egy sztorim egy hazai, bizonyos mobiltelefon tartozekokat arulo webshoprol:
- Birni fogja a vm a fekete penteket?
- Azt en honnan tudjam?
- Hat, aggodunk, hogy nem fogja
- [itt adtam par altalanos tippet, miket kene megnezni a php-s cuccban, sql, indexek, cache-eles, egy kis teszteles, etc, mert hogy ha mar mindezeken tul vannak, akkor van ertelme hw-t boviteni]
- Hmm-hmm, akkor kerunk meg ennyi memoriat es cpu-t...

Ebben az ertelemben atya mondanivalojat huztak ala, miszerint a fejleszto (ideje) draga, foglalkozzon massal. De szerintem meg ez a kicsi, magyar rogvalosag, ahol az atlagbela webshop tulaj 1x fizet php pistinek, aki kepessegei szerinti megoldast szallit, aztan soha tobbe nem foglalkozik vele (ami ebbol a szempontbol zsak a foltjat, ha nem kap zset a support-ert).

Itt meg nem volt vege, csak nekem mennem kellett, mert eleg huzos volt az utobbi par nap. Btw. amilyen eros volt a mezony, jo esellyel nem en lettem a legjobb eloado. Pedig igyekeztem nem hadarni :-)

Ja, a vegen kaptam par kerdest (amiket meg elo tudok hivni), amikre az alabbi valaszt adom (most, hogy van idom egy kicsit gondolkozni is :-)):

- az influxdb egy celszerszam, altalanos sql kivaltasara nem jo. Ha ossze kell kotni az abban ill. egy sql szerverben tarolt adatokat, akkor ehhez a logikat leginkabb magunknak kell osszerakni, hiszen mi tudjuk, hogy mit akarunk :-)

- a TICK es az ELK nem pont ugyanazt tudjak, mert egyreszt az ELK-ba jobbara logokat kuld az ember (es nem metrikakat), mig a Telegraf gyakorlatilag barmilyen metrikat kepes influxdb-be (vagy eppen elasticsearch-be, stb. tolni). Azonkivul a Kibana GUI-ja sem ugyanazt tudja, mint a Chronograf (vagy epp a Grafana). Szoval a TICK es az ELK mas feladatra lonek.

- az rrdtool-rol azert nem volt szo a benchmark reszben, mert egyreszt ilyen eredmenyeket nem talaltam, masreszt (szigoruan szubjektiv maganvelemenyem) elavultnak tartom azt ezt hasznalo eszkozoket, pl. mrtg, cacti, munin, etc. Nem azt mondom, hogy ezek rosszak, de a TICK (vagy epp a TIG) stack-hez kepest dinoszauruszok, ill. az RRD nem tamogat semmilyen muveletet, transzformaciot az adatokon, ami szukseges lehet egy uzleti dontes megtamogatasahoz. Bar magad is megirhatod a szukseges fuggvenyeket, de sokkal egyszerubbnek tartom egy kesz megoldas hasznalatat, ami mindezt beepitve tudja. Vegul a Grafana megjelenitesi kepessegei is joval felulmuljak az RRD-re epulo gui-s cuccoket.

- zabbix-ban nem trivialis osszerakni egy olyan alertet, ami egy komplex feltetel teljesulese eseten szol. Bevallom nem probalkoztam ilyennel a kapacitor hasznalatakor.

- ha a telegraf nem tudja (pl. halozati gubanc miatt) elkuldeni az adatokat, akkor probalkozik parszor ujra, de (imho) nem fogja bufferelni huzamosabb ideig az adatokat, hogy kesobb egy nagyobb batch-et elkuldjon. Ha van lokalisan kafka, es oda ir a telegraf, ugy esetleg megoldhato, hogy onnan a kozponti influxdb (vagy valami mas) megkapja az adatokat. Bar, ha ilyen esetre kell felkeszulni, akkor inkabb egy file-ba iratnam az adatokat a telegraf-fal, es egy periodikusan futo cucc tolna a tavoli influxdb-be az adatokat

- a nyilt forrasu valtozat nem tamogat influxdb klasztereket, az a fizetos verzioban van csak

- MIT licenszet hasznal az influxdb

Vegeztul par szo a catering-rol: nekem bejott a svedasztalos megoldas (tortilla, salatak, hidegtalak, whatever). A 3 fele retes kozul az almas volt a legjobb.

Majd a kovetokiadvanyba beleirom a kimaradt twitteres bitcoin sztorit is, ugyhogy rettegjetek :-)