Monitorozás és grafikon

Debian GNU/Linux

Olyan szoftvert keresek, ami egyetlen gépen tud mérni _mindent_ és szépen meg tudja jeleníteni egy belső weboldalon, illetve egyszerű limitek szerint riasztani is tud.

A minden tényleg minden: SMART, hardveres szenzorok, mindenféle IO sávszélesség, load, free, df, iptables számlálók, stb. Mindezt alapból kellene tudnia, nem 3rd party helyekről, fórumokról összevadászni az addonokat. Minél csili-vilibb grafikont tud, annál jobb, interaktív JS előnyben. Mindezeken felül hozzá akarok illeszteni majd egy időjárás állomást.

A lényeg, hogy nem akarok sokat foglalkozni az adminisztrálással, inkább gyűjtsön mindent alapból, amit csak lehet, és én majd kiválogatom, ami érdekel.

Tudom, hogy ezekről sokszor volt már szó itt, kerestem is, de ebben a formában még nem találtam meg a választ, és túl sokat kísérletezni se szeretnék.

  • 5856 megtekintés

( uid_15426 | 2017. 12. 24., v – 11:03 )

Prometheus + Grafana + exporterek.

InfluxDB-t én nem hasznalnek, a licenszelese egyre zurosebb. Graphite-ot szintén nem, haldokló technológia.

----------------------
while (!sleep) sheep++;

Most érek rá megint evvel foglalkozni. Lehet, hogy ez a Prometheus jobbnak tűnik, de az Influxdb is érdekesnek tűnik.

Mint írtam, egy gépes eset van, semmi szerverfarm vagy microservice-ek vagy VM-ek vagy ilyesmi. Úgy tűnik, hogy az Influxdb-s megoldások inkább skálázhatóságra vannak kihegyezve, a Prometheus meg inkább monolitikus.

Arról tudna-e valaki nyilatkozni, hogy maguk ezek a monitorozó szoftverek mennyi terhelést okoznak? Egy blogban láttam eddig, hogy az illető szerint az Influxdb nagyon sokat eszik, a Prometheus meg nem.

Fontos, hogy mindenről legyen adat, de azért nem kell nanoszekundumonként méregetni, mert nem akarom egy egyébként 95%-ban idle géppel a monitorozó szoftver miatt a szobát fűteni, és az se mutatna jól, ha a NAS tárhelye mérési adatokkal lenne tele.

Egy blogban láttam eddig, hogy az illető szerint az Influxdb nagyon sokat eszik

1 gepet akarsz monitorozni. Ez megis mennyi adatot jelent? Aligha olyan sokat. Foleg ugy nem, hogy be lehet allitani retention-t is, mert valoszinuleg nincs szukseged hosszu idore visszamenoleg az adatokra...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

( STP | 2018. 01. 15., h – 22:52 )

„A minden tényleg minden: SMART, hardveres szenzorok, mindenféle IO sávszélesség, load, free, df, iptables számlálók, stb. Mindezt alapból kellene tudnia.”
És ezt OOB, vagy egy kis integráció belefér?

De ha valóban mindent kell tudnia, akkor van egy sokkal jobb megoldás:
html body h1 42 /h1 /body /html

( peterson v | 2018. 01. 16., k – 07:08 )

Az hogy "mindent, de tényleg mindent, alapból kiegészítők nélkül tudjon", nem létezik. Bocs ha elszomorítalak.

A helyedben - mivel úgy tűnik igen célzott feladatra kell - két szempont mentén keresgetnék:
1. könnyű, és viszonylag egyszerű legyen bővíteni, célrahegyezni. Itt nem csak a megvalósításbeli egyszerűségre gondolok, hanem dokumentáltságra, támogatottságra, fórumokra, amik egyszerűbé teszik az egyébként bonyolult feladatot.
2. keveset kelljen belepiszkálni, legjobban közelítsen a céljaidhoz.

A két szempontnak talán semmi nem tud egyszerre megfelelni. Az elején kell meghozni egy stratégiai döntést, hogy mennyit vagy hajlandó dolgozni vele, és milyen kompromisszumokra vagy nyitott. E kettő fordítottan arányos.

"Felrakom oszt megy pont ahogy akarom": nem működik. ;)

---
"A megoldásra kell koncentrálni nem a problémára."

( tovis v | 2018. 01. 16., k – 21:18 )

Érdekel

* Én egy indián vagyok. Minden indián hazudik.

( joco01 v | 2018. 01. 20., szo – 11:45 )

Felelevenítem ezt egy kicsit. Ránéztem több megoldásra, ami fentebb volt javasolva (csak doksi/demo, nem tettem fel), és az a baj, hogy szerintem rengeteg pluszmunkát igényelnek. Elhiszem, hogy ez professzionális környezetben embert és szakértelmet kíván, de nekem se időm, se szakértelmem, és ez csak egy darab otthoni szerver, next-next-finish konfiguráció kellene, "jó lesz a default is" hozzáállással.

Amit én igazán szeretnék, az az, hogy felteszem, és alapból ott van 100 grafikon meg 100 bekonfigurált alert, amiket egyszer egy okos ember már összerakott, és én maximum elveszek belőle vagy hozzáadok 1-2-t. Ez kb. az, amit annak idején a Microsoft System Center Essentials tudott egy az egyben (abból az is SCOM). Csak nekem Linuxra kellene, lehetőleg open source.

Biztos összeszedte már valaki, hogy pl. a >90% softirq rossz. Kis ferdítéssel én azt se tudom, mi az, és miért kéne figyelni. Persze nekiállhatnék egyesével, hogy diszk terület figyelés, CPU terhelés figyelés, hőmérséklet figyelés, stb., eljutnék egy tucatig, rámenne a sok idő, de még mindig van 100 másik metrika, ami mutathat valamit.

- Netdata: Baromi jó, hogy kapok sok chartot alapból, ez eddig a legpozitívabb. De alertingről alig esik szó a doksikban. Pedig az pont olyan fontos, ha nem fontosabb, mint a grafikon. Nem kedvtelésből akarok grafikont nézegetni, hanem csak azt akarom látni, ha baj van. És az is baj, hogy nem perzisztál adatot, pedig én pl. akarnék olyat, hogy SMART érték tendenciák X évre visszamenőleg.
- Grafana: Csinos, de az a baj, hogy alapból üres, tőlem várja el, hogy rakjam össze egyesével a grafikonokat. Én meg pont nem azt akarom, hanem ő szedje elő az adatforrásból az összes létező metrikát, és tegye be kategóriák szerint pár menüpontba, hogy nekem már csak válogatni kelljen közülük.
- Prometheus: Szintén tetszik az alap ötlet, de ez egy üres héjat ad csak. Default alerting rule-okat nem láttam benne. A beépített grafikonja fényévekre van attól, amit én szeretnék.
- InfluxDB alapú megoldások: Itt az a baj, hogy N darab szoftverre van szétszedve a dolog. Ami általában jó, de az én céljaimra pont nem. Alapból nem tudja a bal kéz, mit csinál a jobb esete. Annyi rétegen megy át egy-egy metrika, hogy a végén már nem fogja tudni magától a rendszer, hogy abból milyen érték számít jónak vagy rossznak, tehát nekem kell konfigurálni rengeteg mindent.

Remélem, nem írtam hülyeséget.

Nem olyan nagy kérés. Mondanám, hogy a Zabbix jó neked, de nem vagyok biztos benne. Pedig alapból van benne többszáz grafikon, és riasztás.
De ammi neked kéne
"felteszem, és alapból ott van 100 grafikon meg 100 bekonfigurált alert"

Amíg nem tudjuk, hogy pontosan, és tételesen mi az a 100 grafikon, és milyen határértéket gondolsz a 100 alert-nek (ami nem biztos hogy 100%-ban fedi a 100 grafikont), addig nehéz is eltalálni a megfelelő monitoringot. A "tudjon mindent" kissé pongyola...
Az az érzésem kicsit, hogy te sem tudod pontosan mit akarsz.
Olyan software nem létezik, amivel nem kell dolgozni, nem kell gondolkodni, nem kell fizetni, és mindent tud még a nem világos elvárásokból is.

Fentebb már írtam:
határozd meg pontosan miket akarsz figyelni, döntsd el, mennyi időt/munkát szánsz rá, és miben/mennyire vagy kompromisszumkész.
Ezután keresd meg meg a megfelelő terméket.
Amennyiben a feltételeidet egyik termékkel sem tudod szinkronba hozni, úgy keress valakit, aki pénzért dolgozik vele, és meg csinálja olyanra amilyenre akarod. Véleményem szerint bármely monitoring rendszer képes mindenre amit vársz tőle, csak legyen aki rád szabja (nem én!). Itt jön a képbe a pénz...

---
"A megoldásra kell koncentrálni nem a problémára."

Az az érzésem kicsit, hogy te sem tudod pontosan mit akarsz.

nekem meg nagyon az. A 'mindent merni' ebben a kontextusban a nyilvanvalo fogalmatlansag jele...

Btw. nekem is volt valami hasonlo esetem, amikor az aramellato rendszert kellett monitorozni. Jon a facility manager, hogy itt a doksi, mit milyen snmp oid-dal lehet elerni (mar majdnem lexikon terjedelemben). Megkerdezem emberunket, hogy mit kene akkor merni? Mindent. (Jol van, hulye vagy). Rakerdezek meg1x, ugyanaz a valasz. Vegul ugy szereltem le a hulyet, hogy akkor irja mar le az osszes parameternel, hogy milyen threshold-ok atlepesenel szeretne riasztast. Talan ekkor felfogta, hogy mit is kert, es mivel elfoglalt volt, igy ejtettuk a projektet.

Szoval a kerdezo helyeben felvennek *par* altalanos metrikat (pl. cpu load, memory usage, disk utilization, homerseklet, stb.), azokra allitanek be riasztasi kuszobot, majd szunet. Aztan leulnek, es atgondolnam, milyen kritikus szolgaltatasok lesznek a gepen, hogyan lehet azokat monitorozni. Szunet. Aztan irnek szabalyokat a kevesbe fontos szolgaltatasokra / egyebekre, hogy minden valoban fontos dolog merve legyen, es amire kell, arra riasztas is legyen.

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Akkor pontosabban fogalmazok.

CPU load, memory usage, disk utilizatiom, hőmérséklet, stb. annyira alap, hogy még egy majom is tudja. Ha ezeket a riasztásokat, grafikonokat kézzel kell *létrehozni* is, már rossz. Legyen benne alapból. Én maximum a thresholdot reszelem, de legyen benne valami általános alap határérték azért (nem olyan nehéz pár konzervatív számot előre beírni, pl. diszk=0 már tuti riaszt, hőmérséklet=100°C már tuti riaszt, stb.). Ez volna a minimum elvárás. De ezek olyan alap dolgok, hogy magam is meg tudnám csinálni, de akkor minek is van rá kész szoftver?

A még ideálisabb eset, a "mindent mérjünk": mérjen olyan dolgokat, ami nekem nem jutna eszembe, a fent említett körön kívül van. Nézd meg ezt: https://london.my-netdata.io/default.html . Itt van kb. 200 (!) grafikon. Ha ilyet akarok, nekem 2 akadály is van: tényleg nem jutna eszembe egy csomó dologról, hogy mérni lehetne, illetve kézzel beállítani rengeteg idő egy ekkora dashboardot, ha az adott szoftver semmit nem ad alapból. Miért van erre szükség, ha ez nem is kritikus szerver? Egyrészt érdekesség, és tanulni akarok belőle, másrészt ha egyszer valami HW/SW hiba beüt, akkor simán lehet, hogy a fenti minimum körből létrehozott mérések nem mutatják ki, és kellene a többi is. Hogy itt mire lehetne riasztani: egyrészt itt is sok esetben meg lehet adni konzervatív határértékeket, másrészt anomáliákra lehet automatikusan riasztani szinte bármilyen adatforrásnál annak valódi ismerete nélkül is.

Tehát megállja a helyét az, hogy nem tudom pontosan, mit akarok, de csak azért, mert léteznek ennek a szakmának számomra ismeretlen mélységei. De azt fenntartom, hogy az a tudás, amit keresek, az valahol létezik, mert sokan mások megoldották már ezt remélhetőleg általánosítható módon. Az áramellátós példádra: igenis lehetne mindent mérni, véges számú mérőeszköz van, amiket nem viccből raktak oda, az egy másik dolog, hogy az illető nem tudta, melyik mit jelent, így valóban nehéz, de ha lett volna szakértő, aki tudja, akkor ez egy megoldható feladat.

Velem már sokszor előfordult munka közben, hogy beütött a krach, és debug közben derült ki, hogy ezt meg azt már eleve mértük, mert okos emberek régen kitalálták, hogy jól jön az még, és csak meg kellett keresni az adott dashboardot, és ott volt a válasz. (https://www.youtube.com/watch?v=LlvJdK1xsl4) Ugyebár a másik eset az, hogy beüt a krach, és rájössz, hogy mit kellett *volna* mérni, aztán beállítod, hogy legközelebb ne forduljon elő.

Zabbixban vannak template-ek, ami adott esdzköztipusra ad alapból n+1 mért értéket. A Zabbix filozófiája olyan, hogy amit mérünk, abból esz/lehet grafikon, garfikonokból meg screen, illetve a dashboard-ra is felrakhatsz n+1 különböző dolgot (eseménykonzol, riasztások, satöbbi).
Ha egy template bővül, onnantól kezdve az azt használó (abból származó) hostra vonatkozóan is elkezdi mérni/gyűjteni az adott információkat - és ha a kapcsolódó screen-re is felrakod, akkor a grafikon is ott fog figyelni. Ha jól emlékszem, de szerintem tényleg próbáld ki.

megneztem. Oszinten megmondom, mindegyik mert parametert hasznosnak tartom, mert lehet olyan gebasz, ahol pont pl. az ipv4.tcpconnaborts segit neked megerteni, hogy mi a gubanc.

és tanulni akarok belőle

ha ez igy van, akkor nem picsogni kene, hogy semmi se jo, hanem kivalasztani 1-et, aztan megcsinalni. Ha next-next-finish-sel felteszel valamit, abbol mit fogsz tanulni?

Tehát megállja a helyét az, hogy nem tudom pontosan, mit akarok, de csak azért, mert léteznek ennek a szakmának számomra ismeretlen mélységei.

igen, ezt nehez nem eszrevenni.

Az áramellátós példádra: igenis lehetne mindent mérni,

nem eszkozbol volt sok, hanem parameterbol. Es tovabbra is fenntartom, hogy teljesen folosleges mindet merni. De majd te megmondod, hogy egy menedzser szamara tenyleg kell az a tobb szaz, ha nem tudja megmondani, melyik mikor riasszon? Ez a konkret eset annyiban specialis volt, hogy nem volt olyan monitorozo eszkoz (kifejezetten) hozza, amiben esszeru default-ok lettek volna. Igy a kicsi kezemmel kellett volna bepotyogni az oid-okat, meg kitalalni hozza riasztast, ami ha nem jo, akkor szinten kezzel faragni rajtuk.

az egy másik dolog, hogy az illető nem tudta, melyik mit jelent, így valóban nehéz, de ha lett volna szakértő, aki tudja, akkor ez egy megoldható feladat.

valoszinuleg tudta, mert (a maga teruleten) szakmabeli volt. De abban igazad van, hogy ez egy megoldhato feladat: csak nem ugy, ahogy azt te vagy o elkepzeltetek. De ezt betudhatjuk annak, hogy vannak szamodra is, szamara meg foleg 'ismeretlen melysegek' is. Mondjuk kinek nincsenek...

A google monitorozasat meg sulyos felreertes idekeverni. A te otthoni projekted aligha ugyanaz a kategoria. De lehet, inkabb ott belul kene dumalnod valakivel, hogy vegyek be a te geped is a halmazba, aztan kesz vagy.

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

"A google monitorozasat meg sulyos felreertes idekeverni."

Nyilván fényévek vannak a kettő dolog mérete között, de az elv ugyanaz lenne: 100 dolgot mérünk a háttérben, de csak 10-re van kézzel összerakott dashboard, amit lehet szúrópróbaszerűen nézegetni, viszont ha debuggolni kell, elő tudjuk venni a 100-at is időutazás nélkül.

A Google vagy bármelyik hasonló léptékű gép és szolgáltatás halmaz monitoringja jó eséllyel egyedi fejlesztésű célszoftver vagy erősen testre szabott valami. Ott valóban működni fog, hogy néhány géptípus és néhány role lesz, sőt valszin adott géptípus adott role-t is jelent egyben és aki a végeredményt telepíti (bocsánat, deployment, meg enrollment...) csak klikkel kettőt. Ez viszont nem egy félórás tervezés és apt-get/yum install munin/zabbix/etc, hanem soksok ezer mérnökóra csúszott ebbe bele és biztos vagyok benne, hogy volt sok homlokra csapás, mert valami kimaradt vagy máshogy mérték, mint azt a való élet megkívánta.

Én személy munin párti vagyok monitoringban, de nem 100%-os megoldás. Megvannak a nyűgjei és korlátai, de ugyanakkor nagyon hasznos és amit tud azt jól tudja.

Azt kell megértened, hogy a monitoring, az nem egy kész eszköz, nem végtermék, mint a kalapács, hogy ottvan, használod oszt jónapot.

A monitoring egy alrendszer, amit meg kell tervezni, fel kell építeni, és üzemeltetni kell. Valamint az idő haladtával fejleszteni.

Minden monitoringnak vannak beépített dolgai alapértelmezésekkel ami neked vagy jó, vagy nem.

Még egyszer: találd ki mit akarsz. Keresd meg az ehhez legközelebb álló terméket. Teszteld! Módosítsd úgy hogy neked jó legyen. Üzemeltesd.

Két út van:
1: gondolkodsz, és dolgozol
2: fizetsz
A döntés a tiéd :)

---
"A megoldásra kell koncentrálni nem a problémára."

"Minden monitoringnak vannak beépített dolgai alapértelmezésekkel ami neked vagy jó, vagy nem."

De hát én mondtam, hogy evvel nincs baj, egy lusta embernek ez jár, világos. A bajom ott van, ha egy adott monitoringnak semmi defaultja nincs.

"1: gondolkodsz, és dolgozol
2: fizetsz"

3: egy kellően sok embert érintő use case esetén valakik megcsinálják, felteszik a githubra, és a többi ember élvezi ingyen. A félreértés ott lehet, hogy amire én azt gondolom, triviális és bárkinek jól jöhet, arra más nem azt gondolja. Ezt jelenleg csak úgy tudnám bebizonyítani, ha én lennék az az ember, aki megcsinálja, és felteszi a githubra, vagy mutatok 10^N darab másik embert, akinek kell ugyanez :).

Amúgy nem annyira elrugaszkodott dolog ez, mert fizetősben létezik, ld. általam írt MS SCOM és mások által írt Datadog. Ha ingyenesben nincs ilyen, akkor majd eldöntöm, hogy reszelek egy hasonlót, vagy megveszem.

Amúgy nem annyira elrugaszkodott dolog ez, mert fizetősben létezik, ld. általam írt MS SCOM és mások által írt Datadog.

De, pont annyira elrugaszkodott. A kettővel fentebbivel sem értek egyet, a fizetés sem helyettesíti a gondolkodást, mert ha nem tudod hogy mit, hogyan, mikor, mivel és miért mérsz, akkor megette az egészet a fene. Mert eredményként lesz egy marha nagy halom számod, amiről nem tudod, hogy mit jelent.

Ezt jelenleg csak úgy tudnám bebizonyítani, ha én lennék az az ember, aki megcsinálja, és felteszi a githubra

Kérlek, adj egy értelmes default-ot:
* default load-ra
* swap használat mértékére
* memória használat mértékére
* conntrack tábla telítettségének mértékére
* forward/input/output lánc packet szám/csomagméret mértékére
* SMART Pending Sectors count megfelelő mértékére

A loadot fentebb már írták, hogy géptől és felhasználástól függően bárhol lehet. Swap használat szintén géptől és felhasználástól függően lehet, hogy >0-ra már jelezni kell, lehet, hogy >50% kell csak jelezni. Memóriahasználatnál egy desktop-on a 80% memória használat még belefér, egy VM-ekkel telített host-on lehet, hogy nem szerencsés. Egy routernek használt gépen a forward láncra eső forgalmat akarhatod monitorozni, lesz belőle szép grafikonod (nincs limit) - egy tisztán szervernél ha valami beesett oda, akkor valaki valamiért feléd route-olt egy csomagot, ami lehet, hogy baj (>0 és riasszon). Egy olyan rendszeren, amin a diskek csak local cache-ként működnek egy hálózati storage előtt, nem gond, ha van egy pending sector. Ha egy 0-24-ben futtatandó gépen van ugyanez, akkor a pending sector miatt lehet, hogy el kell indítanod a coldspare HDD cseréjének a beszerzését.

És ezek _tényleg_ csak a legegyszerűbb dolgok voltak.

Tudnod kell, hogy mit miérsz, azt, hogy az mit jelent és a saját környezetedre kell mondanod megfelelő határértékeket.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A példáid többnyire jók, akkor lehessen mondjuk 10-20-féle role közül választani. De még mindig jobb pl. pending sector>0 esetén inkább default riasztani, és ha olyan gépen jön elő, ahol leszarod (ami mondjuk az esetek 0.1%-a?), akkor silence. Illetve ahogy már írtam, nem csak határérték alapú riasztás van, hanem pl. https://anomaly.io/anomaly-detection-normal-distribution/ .

Pont ez írtam a muninra, hogy a saját heti/havi/éves átlaghoz képesti adott eltérésre vagy az alapján nem tud riasztani. A legegyszerűbb példa a gép fogyasztása lenne, ahol a pillanatnyi érték roppantmód ingadozik, ezért kénytelen vagy nagy határértéket belőni. Sokkal jobban örülnék, ha mondjuk a heti átlag vagy az aktuális félórás átlagból jönne a riasztás, mert egy jóval simább grafikon. Másnál biztosan mással lesz valamilyen probléma és mégis muninozik, mert egyébként nincs kapacitás belemenni ebbe.

A 10-20 féle role ráhúzható bármelyik monitoring cuccra, csak a konfigfile-okat kell ez alapján feltölteni. Szerintem a muninforge-on (ha még úgy hívják) várják már a scripted. :)

Pedig a mindent mérjünk tényleg nem jó ötlet. Egyrészt a mindent monitorozó el fog önteni egy hatalmas információtengerrel, nem fogod tudni áttekinteni, felét nem fogod érteni micsoda, másik fele meg csak nem lesz hasznos, és egy kisebb résznek hasznát vennéd, de munkás lesz megtalálni benne. Plusz a mindent monitorozás a célgépre is nagyobb terhet ró, ha mindenféle felesleges adatot kell küldeni.

Értem, hogy lusta vagy, default kéne minden, de szánd rá az időt, állítgasd te be a figyelnivalókat, meg szedd össze a plugineket. Egyszer rászántad az időt, utána hosszabb távon időt, munkát takarít meg neked, azaz megtérül sokszorosan.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Tud alertelni, de azt, hogy mikor, milyen feltételek teljesülésekor alerteljen, azt neked kell megmondani. Default-ok vannak nagyjából mindenütt, de a monitorozás/riasztás/előrejelzés olyan dolog, aminél a testreszabást nem úszod meg.
Van, ahol a "mit és hogyan mérünk" is a testreszabás/konfigurálás része, van, ahol a grafikonokkal, alert szabályokkal, dashboardokkal bezárólag vannak kész template-ek - de ezeket is célszerű, vagy épp kifejezetten szükséges testre szabni. Zabbixban pl. az a jó, hogy rengeteg alapbeállításod van, ami általában jó - viszont valamennyit felülbírálhatod, akár több szinten is, összeköthetsz több paraméterre vonatkozó figyelést egy alertbe, satöbbi. Ezt _is_ tervezni kell, ad-hoc ugyanis csak katyvasz lesz belőle, amit később nehezen fogsz tudni kireszelni.

Munin... 1-2 órát kell a konfigra szánni aztán megy. Gondolom sejted, hogy bármelyik megoldásnál mindenképp kell mókolni.

Meg lehet nézni a fizetős online megoldásokat, ahol snmp vagy egyéb beépülő megoldással gyűjtik az adatot. Ezeknél is fennállhat az, hogy 1-2 órát rá kell szánni a konfigra.

Megfelelő környezetben ezek egyszer vannak beállítva és utána minimális extrameló vagy esetleg script konfigol.

1-2 óra belefér. De biztos van egy rakat olyan metrika, amire kb univerzális alert szabályokat lehet írni, ezt nem akarom egyesével konfigolni (pl 0% diszk hely vagy vég nélkül növekvő cpu load és hőmérséklet sose jó) és megtanulni (softirq és a Linux egyéb mélységei), legyen benne alapból.

Meg egy rakat olyan is van, ahol nincs általános rule. Honnan fogja tudni bármi, hogy mondjuk neked egy 20TB-os partición a 3% vagy a 10% közel tele állapot? Ugyanez vonatkozik emailezésre is. IPMI-nél általában kiolvashatóak a warning/critical értékek, de ritkán élnek vele sajnos, illetve ezektől függetlenül neked kellhet kisebb érték vagy egyáltalán szükséges, lásd fogyasztás figyelés.

Ha én írnék egy ilyen szoftvert, beállítanám, hogy pl. 10G vagy 5% alatt szóljon. Ha ez valakinek nem jó, kikapcsolja vagy átállítja a küszöbértéket.

A lényeg, hogy a szoftver írója gondoljon rá (ne a végfelhasználónak kelljen, mert olyan sokféle metrika van, nincs az az ember, akinek egyedül eszébe jut mind), rakja össze a rule-t (ne nekem kelljen az egész szintaxist nulláról megtanulni, jobb az, ha van egy sablon), legyen alkalmazva alapból (ha beteszek egy új diszket, simán lehet, hogy elfelejtem bekapcsolni rá), és akkor a végfelhasználónak jó eséllyel jó egy az egyben, vagy maximum egy kicsit reszel rajta.

A konkrét számértéket leszámítva ez csupa olyan dolog, ami a világ több száz millió szerverénél ugyanúgy előjön újra meg újra, és pont az ilyen dolgokra szoktak szoftvereket írni.

Közösségi alapon főleg tök jó lenne a világ össze metrikájára összeszedni a know-how-t, hogy mi számít jó vagy rossz értéknek. Ha most én itt random kiválasztom a Prometheus által gyűjtött 243 metrikából a 197-ediket, ami a /sys vagy /proc alól valami egzotikus helyről elővesz egy számot, állítom, hogy itt a népek mondjuk 1-10%-a fogja csak fejből tudni, hogy milyen küszöbérték lenne jó rá.

Mondok még valamit, ami már konkrétan a munkám során előjött. Tegyük fel, hogy hirtelen belassul egy szolgáltatás. Van monitoring a válaszidőre, jön riasztás, oké. Hogyan tovább?
A. Elkezdek tippelgetni, hogy vajon mitől lehet. Előbb tapasztalatból a szokásos dolgokat nézem, aztán egyre mélyebben, aztán egyesével szúrópróbaszerűen az egzotikusabb helyeken is kutakodok. Kézzel rakok össze lekérdezéseket, ad-hoc grafikonokat, stb. Nagyon sokáig is el tud tartani.
B. Van egy monitoring oldal, ahol adott szolgáltatással kapcsolatban ott van a szemem előtt egyszerre az összes metrika. Van mindegyiken ugyanott egy függőleges vonal, ahol az alert előjött. Végiggörgetem, és rögtön látszódni fog valahol egy outlier. Rögtön tudom, hogy merre kell nézelődni. Akkor is, ha egyébként eszembe se jutott volna pont azt az egy grafikont elővenni.

Ezért gondolom azt, hogy sokkal jobb egy kézzel összeválogatott halmaz helyett minden létező adatot gyűjteni, és ha baj van, mindet egyszerre prezentálni. Itt bukik el a Grafana, ahol nem láttam olyat, hogy na akkor erre az oldalra tedd ki a Prometheus összes metrikáját, viszont ezt tudja a Netdata (csak az máson vérzik el).

Egy jó rendszerben eleve úgy van definiálva minden metrika, hogy van mellette magyarázat, mértékegység, stb. Ezek után triviális teljesen automatikusan az összes létező metrikából grafikont gyártani. Ha ehhez hozzájön, hogy a metrika definíciójában vannak küszöbértékek, amit egy okos ember egyszer már kitalált, akkor máris van generikus alerting is, zéró konfigurációval. Plusz egy monitorozó rendszertől az sem nagy elvárás már manapság, hogy anomáliákat jelezzen (pl. egy adott RPC szolgáltatás válaszidejére tényleg nehéz jó értéket állítani gyárilag, viszont meg lehet tanulni, hogy ez általában 10-15 ms alatt válaszol, akkor 50 ms fölött riasztunk, egy másik meg 200-500 ms alatt, akkor riasztunk 2 s fölött, vagy 50 ms alatt).

Valahogy sokszor járok így, hogy DIY, pedig szerintem meg elég triviális use case (a megvalósítás persze nem az).

Most gondolj bele, jelen pillanatban is biztos 100 különböző mérnök gondolkozik azon a világban, milyen alerting szabályokat írjon, pedig elég lenne, ha 5-en összedugnák a fejüket pár napra, feltennék a Githubra, és mindenki más tudná azt használni, nem?

Oké, a fentiekből is össze lehet rakni, és valamit össze is fogok. Csak nem lesz ideális.

"Ha én írnék egy ilyen szoftvert, beállítanám, hogy pl. 10G vagy 5% alatt szóljon. Ha ez valakinek nem jó, kikapcsolja vagy átállítja a küszöbértéket."

Nohát írtak neked sokféle szoftvert, azt valahogy egyikben sem volt jó neked pont. Épp erre próbáltam utalni, hogy ugyan mindíg lehet finomítani a gyári határértékeket, figyelendőeket, de mindig találsz majd olyat, ami neked pont úgy nem jó. Hiába jó úgy ötmillió gépen, ha nálad épp nem és persze fordítva is lesz, hogy van ami nálad pontjó és közben meg másnál nem. Pont a diszk hely a muninban iirc 90% warning és 95% critical. Ez néhány 100GB-ig, talán néhány TB-ig egészen jó, de utána már kevésbé, sőt tuti lesz aki már 75%-nál akar warningot és a 85% már übercriticalvilágvégepirosgomb fokozat.

Vegyünk inkább a loadot, az jóval inkább gépfüggő, hogy mi a jó. Volt szerverem, amin az 50-estől egészen a 80-as loadig normális volt, aztán ahol 2-4 közötti és még sorolhatnám. Szóval még kevés gépnél is annyira felhasználás függőek ezek, hogy nem tudsz ökölszabályt dobni, amikoris csak felpattint bárki egy gepfigyelo.exe-t majd eljön a kánaán.

Vajon az éri meg jobban, hogy úgy általában vannak általában jó határértékek vagy pedig ezerszámra mennek a mérnökórák a mindenféle esetekre és alesetekre és azokon belül még néhány körülményre?

"Nohát írtak neked sokféle szoftvert, azt valahogy egyikben sem volt jó neked pont."

Én úgy láttam, hogy a fent említett szoftverekben nincsenek előre beállított gyári határértékek. Ha benéztem, elnézést. Van ilyen mégis?

"Hiába jó úgy ötmillió gépen, ha nálad épp nem és persze fordítva is lesz, hogy van ami nálad pontjó és közben meg másnál nem."

Ez nem baj! Nekem pont olyan kellene, ami már bizonyított ötmillió gépen. Ha jön alert, majd elolvasom, miért jött, és vagy örülök, hogy elkapott valami igazi hibát, vagy átállítom.

Az a lényeg, hogy legyen kiindulási alap, ne a 0-ról kelljen összeszedni. Könnyű eljutni onnan, hogy "azt akarom, hogy szóljon, ha kevés a diszk" odáig, hogy manual olvasása alapján össze tudok rakni egy query-t vagy beleírok 3 sort egy config fájlba. Ez is sok idő tud lenni, akár még favágó szintűen unalmas is lehet egyesével mindenen végigmenni, de oké.

A nehezebb rész az, hogy honnan jön maga az ötlet, hogy ezt vagy azt a metrikát kellene nézni? Érdemes nézni a softirq %-ot? Érdemes nézni a HDD-k IO latenciáját és az 1, 2, X hónappal ezelőttihez hasonlítani? Érdemes-e nézni a /sys/kernel/irq/130/per_cpu_count értékét és mi számít túl soknak vagy túl kevésnek? Stb. stb. stb... Akár egyesével mindegyikkel el lehet tölteni egy-egy napot Guglizással meg mittudomén, hogy megtanuljam.

"Vegyünk inkább a loadot, az jóval inkább gépfüggő, hogy mi a jó."

Tudtommal a load normális értéke CPU-szám függő, tehát avval leosztva már nem fog nagy határok között mozogni. És igenis lehet rá általános alertet íri. Egyrészt szerintem létezik abnormális érték (ha mondjuk 0..1/CPU szokott lenni jó esetben, akkor 10/CPU fölött szólunk). Vagy ha adott gépen megszokott értékhez képest hirtelen felugrik, vagy elkezd lassan növekedni (ld. https://anomaly.io/anomaly-detection-normal-distribution/).

A munin pluginekben általában van alapból megadott alert, de sokban csak opció.

A load értéke a processzorra várakozó folyamatok számától függ. 16 magos gépen voltaz említett 50-80-as érték és mégis pörgős volt, máshol pedig 12 maggal volt a normális a 2 és 4 között load. Az első esetben 5, a másodikban 0,3333...-at a load/cpucount hányados. :) Ráadásul a load "ugrálós", ahhoz képest, hogy 5 alapból 5 percenként kukkant rá a munin. Ha mondjuk 39 adott időben és utána 5 perccel 80, akkor 200%-os a növekedés, miközben ez a gépen normális.

Sajnos a munin azt valóban nem tudja, hogy mondjuk az átlagos értékhez képesti ugrás alapján szóljon, ez hiányzik belőle nekem is több esetben.

Hogy mit kell nézni, az onnan jön, hogy az adott gépnek mi a feladata és azon belül a konkrét terhelés/használat mit mutat.

"
Én úgy láttam, hogy a fent említett szoftverekben nincsenek előre beállított gyári határértékek"

Tévedés. Mindben van. Ha már megnézel egy ilyet, kéretik mélyebbre nézn két screenshot-nál.

Már írtam: a munkát, és gondolkodást nem tudod kikerülni.
Tessék gondolkodni! Utána már dolgozni nem nehéz ;)
---
"A megoldásra kell koncentrálni nem a problémára."

Eddig kettőt néztem meg jobban, a többi javaslatot majd ezután, ahogy időm engedi. Attól, hogy itt válaszolgatok a kommentekre, még tesztelni is fogok.

"Tévedés. Mindben van."

Prometheus-ban csak móricka példák vannak dokumentációs célból: https://pastebin.com/tVRWBJVb

Netdatában vannak defaultok, de kevés, még annál is kevesebb, mint amire magamtól rájönnék (nincs SMART a diszkekre, ZFS-re csak memory egy memory throttle és semmi más).

Szerintem nem áll olyan távol a valóságtól, amit mondtam.

Alakul. Tehát kellenek smart adatok. Ez már konkrét igény!
Én zabbixhoz csináltam smart template-et. Csak SAS HDD és SAS SSD-hez jó, és nem tettem githubra. Ha kell átadom. Nekem jó arra amire kell. Neked nem biztos. :)

A smart adat pont nem alapértelmezés jellemzően. De ha tudod mire van szükséged, és meg is mondod, akkor lesz megoldás.

A "tudjon mindent", és a "nem akarok dolgozni vele" továbbra sem működik.

---
"A megoldásra kell koncentrálni nem a problémára."

check_mk nagyjából lefedi az igényed.
viszonylag egyszerű feltelepíteni (vannak csomagok) és elindítani,utána már csak webes felületen kell hozzányúlni.
alapból localhost-on már van egy csomó ellenőrzést. új host-okhoz csak letöltöd az előre generált binárist (ha nincs kedved fordítani forrásból), feltelepíted, hozzáadod a listához és kész.
tud snmp-t is alapból, van rengeteg előre definiált check.

de 1-2 órát azért erre is rá kell szánni az elején.

( Vamp | 2018. 01. 20., szo – 20:24 )

Netdata+InfluxDB+Grafana

Pont a minap raktam ossze egy ilyen pakkot ket szerver megfigyelesehez. A konfigjaval el lehet molyolni, mire olyan lesz, mint ahogy te akarod, de utana szuper!
https://hup.hu/node/157435

Illetve a fentiekhez:

Jo monitoringhoz ra kell szanni az idot... Ez nem megy ugy, h letoltod, felrakod es pont olyan, amit te szeretnel.

A fontebb emlitett szoftverek nem azert nincsenek elore beallitva, mert a fejlesztoik ezt nem tudnak, hanem pont azert, hogy mindenki a sajat igenyere szabja a rendszert.

En a helyedben, (valahol fontebb olvastam h penzt is szannal ra) folfogadnek valakit, aki beallitja neked megfeleloen a fonti szofverek valamelyiket.

Vagy ugye ott a Spiceworks... De az nekem nagyon fapad... Viszont abszolut next..next..finish! :)

https://www.spiceworks.com/network-monitor/windows-linux-server-monitor…

"Netdata+InfluxDB+Grafana"

Jól tudom, hogy a netadata alapból kirakja neked a 100+ grafikonját, ami pl. a demókon is látszik? Azt is olvastam, hogy nem ment diszkre adatot, hanem pl. InfluxDB-be menti. Ezután Grafanábal kézzel kell újra felvenni ugyanezeket a grafikonokat? Mert ha igen, akkor elborul az agyam. Olyan nincs, hogy a Netdata saját felületén látom az aktuális és historikus adatokat is? A backendbe csak ír, de nem olvas vissza onnan?

"A fontebb emlitett szoftverek nem azert nincsenek elore beallitva, mert a fejlesztoik ezt nem tudnak, hanem pont azert, hogy mindenki a sajat igenyere szabja a rendszert."

Akkor itt van a kutya elásva. Szerintem létezik egy olyan baseline, ami a hülyéknek/lustáknak elmegy, és lenne rá igény. Nem szeret mindenki állítgatni, tekergeti, mert nem ért hozzá, nem az a munkája, nincs rá ideje, stb.

"En a helyedben, (valahol fontebb olvastam h penzt is szannal ra) folfogadnek valakit, aki beallitja neked megfeleloen a fonti szofverek valamelyiket."

Az nekem is menne. Infós vagyok, gyorsan megtanulok bármit, de már most látom, hogy amit én szeretnék, az annyi idő, amit nem biztos, hogy szívesen rászánnék. De még mindig inkább az, mint hogy egy embert fizessek azért, hogy egy (relatíve jelentéktelen) pinceszervert állítgasson. Pénz alatt fizetős szoftverre gondoltam (amit már írtak is fentebb).

A netdata csak real time monitoroz. Igen, InfluxDB-re ment, minden adatot. Alapbol folvesz minden grafikont, azokat kell hozzadni kezzel, amik plusz konfigot igenyelnek. (pl mysql, ahol be kell allitani az adatbazosban, h a netdata hozzaferjen)

InfluxDB-bol pl a Grafana tud kivenni adatot. Nem, nem kell mindent kezzel folvenni, erre vannak az elore elkeszitett dashboard-ok. https://grafana.com/dashboards?dataSource=influxdb&search=netdata

Azert en megneznem a Spiceworks-ot hatha eleg infot ad neked.

( render_elek v | 2018. 02. 04., v – 08:04 )

Nagios-t miért nem írta senki?

Ahja... Zabbix is ilyen szerintem... :)

Valahogy az az érzésem, hogy két fél monitoring eszköz van:
- a fapados, amelyik tud valamit, azt jól tudja, de kínszenvedés a paradigmáján kívüli dologra megtanítani és alapvetően ronda is
- a pilótavizsgás, amelyik mindent tud, különféle minőségben, de kínszenvedés rendesen beállítani, ha viszont sikerül, akkor apáról fiúra száll a telepítés.

Köztes dolgokkal nem nagyon találkoztam... :/

+1, én is csak ezért nem javasoltam (meg a mindent out-of-the-box tudjon sem igazán illik rá, bár még localhostban egész sok plug-in feldobható a legtöbb disztrón csomagból)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)