Dotaz: co monitorovat na linuxu

[chtel_bych_se_zeptat]

Dobry den, chtel bych se zeptat co monitorovat na linuxu. Nechci doporucit zadny konkretni tool. Zajimaji me metriky a stavy, ktere povazujete za uzitecne kontrolovat/sbirat. Melo by se jednat o virtualni stroje (smartmontools nejsou potreba).

Mam nejakou predstavu a uvitam jakykoliv konstruktivni nazor.

Nejaky zaklad: - Load - Memory (available, ne free) - Swap - CPU (celkove vyuziti, tak per jednotlive CPU, v pripade single-threaded aplikace) - Filesystemy - zaplneni, inody(?) - I/O (io-wait z top, coz jestli chapu dobre = saturace, %util z iotop?) - Propustnost site

Co dale? Nejaky max pocet procesu? Otevrenych file?

Predem diky.

---

---

Odpovědi

[Josef Kufner]

Hodí se teploty všeho možného (u fyzického serveru), load, využití disků a paměti (a swapu). Také se hodí sledovat I/O operace (jak počet, tak přenesené objemy dat).

Docela zajímavá metrika je rychlost růstu logů (stačí použít velikost souboru logu místo počítadla přenesených dat). Když se něco děje, tak je tam vidět nějaká anomálie.

Další hezká věc je ping na gateway (ať už defaultní, nebo nějaký nedaleký router). Hezky jsou na tom vidět potíže s připojením.

Ale reálně stačí mít akorát nastavené upozornění při docházejícím místu na disku a občas kouknout, jestli je dost paměti.

V případě virtuálních serverů, které poskytují nějakou konkrétní službu, bych se zaměřil také na tu službu samotnou. Ideálně, aby logovala, kolik tam je klientů, kolik toho dělají a jak dlouho trvá je odbavit. Však to je ten důvod, proč takový server běží.

[Max]

Osobně monitoruji u VM jen to nejnutnější, tj. :

• velikost volného místa na jednotlivých volume
• load serveru
• využití ram
• využítí swapu (mám jen pro jistotu, ale pomocí swappiness se snažím minimalizovat jeho použití)
• ping
• uptime (to aby bylo zřejmé, že došlo k otočení VM)
• počet procesů
• existence zombie procesů (= ukazatel, že je zde performance problém)

U VM pro win pak monitoruji ještě navíc to, zda běží nějaký proces, protože spousta idiotských aplikací, co vyžadují ruční spouštění atd.
Následně pokud je to nutné, tak monitoruji kritické app, co na té VM běží (typicky cca 10 hodnot u OracleDB apod.).
Monitorovat "nice to have" parametry považuji za zbytečné. Je mi vesměs k ničemu pozorovat průtok dat přes síťovku, sledovat I/O ve VM apod. Jsou to věci, které mi zbytečně zaplácnou volné režie pro monitorování opravdu důležitých věcí. Datové toky monitoruji na úrovni switchů. I/O na úrovni storage atd.
Osobně mám teď v monitoringu asi 250 hostů a přes 1250 služeb a jak jsem napsal, monitoruji opravdu jen to nejdůležitější. Kdybych chtěl monitorovat úplně všechno, asi by mi jeden monitorovací server nestačil a musel bych řešit rozkládání zátěže. Né, že by to byl problém, ale považuji to za zbytečné.
Zdar Max

[Andrej]

Já nejčastěji monitoruju, kdy je admin (tj. já) šíleně ožralý. To zatím způsobilo nejvíc problematických situací.

[Heron]

Já bych spíše poradil, co nemonitorovat. Dostanu se k tomu.

Monitorovat by se mělo především to, co ten server má dělat. Pokud je to webserver, tak by se mělo monitorovat to, zda odpovídá dostatečně rychle a zda je obsah určité stránky správný (tj třeba si tam vložit nějakou značku a kontrolovat její přítomnost). Některé projekty mají přímo speciální stránku pro health check.

Podobně u všech ostatních služeb, kontrolovat to, co mají skutečně dělat. IMAP server může odpovídat na portu, ale může tam být nějaký interní problém, takže třeba monitorovat i dosažitelnost nějaké zprávy.

Ale rozhodně nemonitorujte souhrnné parametry typu load. To vám vůbec nic neřekne. Stejně jako zombie procesy (už někomu přišel warning na zombie?). Setkávám se s tím, že admini považují tyto veličiny za důležité a to především z toho důvodu, že každý tool pro monitorování je monitoruje by default. Jenže tyto veličiny tam jsou zejména proto, by ten výchozí template nebyl prázdný a aby se adminovi ukázaly nějaké grafy hned po nainstalování.

Takže load ne, zombie ne, swap si vypněte, ať jej nemusíte zbytečně monitorovat. FS je určitě dobré monitorovat, místo i inode. Dostupnost po síti a potom jednotlivé služby.

U těch služeb kontrolujte to, co jste schopen ovlivnit. Setkal jsem se s tím, že nějaký agent zjistil, že na stroji je DB a tak vesele monitorovat asi 60 interních hodnot. Admin jednak ani nevěděl, co ty hodnoty znamenají a řešil situace, které se řešit nemusejí jen na základě toho, že přišel warning. Takže monitorovat to, co jste schopen ovlivnit. Nedostatek místa na disku je jasná situace. Load vyšší než nějaké magické číslo není jasná situace.

Ještě je taky dobré si ujasnit, na co ten monitoring potřebujete. Já se na to dívám z pohledu admina a mě zajímá, zda webserver servíruje stránky dostatečně rychle. Proto nepotřebuju sledovat zátěž jednotlivých cpu. Pokud to někdo chce z důvodu optimalizace aplikace, tak je to úplně něco jiného. Tam budou jiné metriky podle toho, čeho chce dosáhnout. Někde jsem zaslechl krásný citát: optimalizuj pouze to, co jsi schopen změřit.

[Max]

Ano, zombie mi občas přijde, právě proto, že server je dost vytížen. Load monitoruji také. Vím, jaký je běžný provoz a vím, co není už ok a podle toho si load nastavím. Většinou v Linuxu monitoruji Load a ve Win CPU a oboje mi už pomohlo (přišel mi warning dřív, než se to začalo bít tak, že by se už začali ozývat i uživatelé). Load je podle mně dobrý ukazatel toho, kdy začne mít VM problém se zdroji, ale aplikace třeba ještě odpovídají dobře.
Zdar Max

[Max]

Jinak dodám, že počet procesů je na tom podobně jako load. Znám běžný stav, takže když počet procesů stoupne nad běžný stav, vím, že se něco děje. Setkal jsem se několikrát s tím, že nastala chyba sw, začala množit procesy (=neukončovala staré) a já se o tom díky tomuto dozvěděl ještě předtím, než by se začalo dít něco horšího.
Zdar Max

[Heron]

V tom případě je dobré monitorovat ty primární zdroje a nikoliv délku nějaké fronty přepočítané nějakým vzorcem a vyhlazené časem. Nedávno jsem viděl hezkou přednášku, mluví o tom od času 38:32.

K tomu dalšímu se mi snad ani nechce vyjadřovat. Pokud je ten server tak vytížen, tak by si zasloužil rozdělení na více strojů apod (podle toho, co to vlastně je). Stav, kdy sleduju nějaký ukazatel (protože si pamatuju, jaké jsou běžné a patologické hodnoty) na divném stroji a potom něco udělám, není podle mě dobrý. Stejně jako to, že tam musíš spouštět nějaké služby ručně.

[Josef Kufner]

Stav, kdy sleduju nějaký ukazatel (protože si pamatuju, jaké jsou běžné a patologické hodnoty) na divném stroji a potom něco udělám, není podle mě dobrý.

Pokud to je jediný ukazatel, který sleduju, tak to určitě dobré není. Pokud to je jako doplněk ke sledování toho podstatného, tak je celkem vysoká šance, že to upozorní na problémy, které explicitně nesleduji. Samozřejmě to neřekne, co přesně se děje, ale řekne to, že něco není úplně v pořádku a že bych se měl podívat důkladněji. Také už jsem se párkrát setkal s tím, kdy nějaké nepodstatné sledované ukazatele pomohly s lokalizací nejasných problémů a úzkých hrdel.

Osobně doporučuji mít dvě skupiny ukazatelů. Ty podstatné, které hlídají poskytované služby (odezvy démonů, health check) a celkový stav serveru (obsazená paměť, místo na disku, load). A pak ty nepodstatné, které se občas hodí a je levné je sbírat (IO operace, teploty, …).

[Max]

Kdyby to byly služby, tak je to ok, ale jsou to jen win aplikace, které nedokážou běžet jako služby.
Ale to je přeci jasné, že musím vědět, jaké hodnoty jsou běžné a jaké patologické. Kdybych sledoval jen služby (jejich odezvy apod.), tak nepoznám, že se nějaký problém pomalu blíží a až se začnou zpomalovat odezvy monitorované aplikace, tak se dá říci, že už je pozdě. A pro mně je load v linuchu dobrým ukazatelem. Kdybych nesledoval load, sledoval bych samotné CPU, u kterého bych také musel vědět, jaké zatížení je běžné a jaké už ne.
Možná se ale bavíme v jiných rovinách. Já třeba musím monitorovat i věci, u kterých je běžné, že jsou v náhodných dobách off (a je to ok), chci vědět, kdy docházelo k malým výpadkům, ale chci být informován jen o těch větších atd.
Ty jsi třeba naproti tomu zvyklý provozovat HA věci, honit ms a tahat info o službách pomalu kontinuálně (jako např. netdata) a tak na to máme rozdílný pohled.
Zdar Max

[Heron]

Kdyby to byly služby, tak je to ok, ale jsou to jen win aplikace, které nedokážou běžet jako služby.

No comment Ale asi každý máme svoje peklo, které si udržujeme.

Ale to je přeci jasné, že musím vědět, jaké hodnoty jsou běžné a jaké patologické. Kdybych sledoval jen služby (jejich odezvy apod.), tak nepoznám, že se nějaký problém pomalu blíží a až se začnou zpomalovat odezvy monitorované aplikace, tak se dá říci, že už je pozdě.

Znalost systému a potřeb běžících služeb je klíčová, o tom nediskutuju. O tom, že člověk po určité době (obzvláště, když ten systém sám stavěl) pozná, že je něco špatně i z reakce terminálu po přihlášení se na ssh, taky nediskutuju. Takto jsem detekoval několik problémů ale po jejich odhalení je nutné monitorovat přímo ty zdroje, co to způsobily. A nespoléhat se na příznaky.

Možná se ale bavíme v jiných rovinách. Já třeba musím monitorovat i věci, u kterých je běžné, že jsou v náhodných dobách off (a je to ok), chci vědět, kdy docházelo k malým výpadkům, ale chci být informován jen o těch větších atd.

No spíš máme jiný přístup k věci. Já bych nebyl ochoten dělat polovinu věcí, o kterých ty píšeš a pokud už bych je dělal (což se občas stane), tak o tom určitě nebudu psát. Já si chci spravované služby vybírat a vybírám si ty, které jsou dostatečně příčetné.

[Max]

Tak já samozřejmě monitoruji, co je důležité, tedy i ty zdroje

Já si chci spravované služby vybírat a vybírám si ty, které jsou dostatečně příčetné.

V tom je ten rozdíl. Já si vybírat nemohu, resp. jen omezeně.
Zdar Max

[j]

Jenze velice casto nic jinyho nez ty priznaky nemas. Jak uz napsal MAX, primarne ti stroj muze v klidu odpovidat "dle ocekavani", vse funguje, ale ... trebas roste prave load, obsazenost ram, IO, atd atd. A protoze kdyz ten stroj nakou dobu bezi, tak vis jakej je normal, muzes sledovat nenormalni odchylky. Coz je presne ten indikator toho, ze se neco nenormalniho deje.

A kdyz zacnes nasledne zjistovat co, tak mas prevazne jeste nejakej ten cas, nez se to slozi uplne. Jasne, trebas zjistis, ze si reditel jen zrovna pustil nejaky to 8k porno, a proto mas 100x vyssi traffic nez je normal. Ale trebas taky zjistis, ze ti nekdo nebo neco luxuje obsah disku.

Prave hodnoty tehle "nezajimavych" velicin dost casto predikujou, ze jde neco do kopru. Jo, taky tu mam stroj, kde je load setrvale 20, i kdyz nedela vubec nic ... eto savetskaja technika ... (tahle do sdelali soudruzi v US).

[Heron]

trebas roste prave load, obsazenost ram, IO,

Pozor, já jsem explicitně uvedl právě ten load a důvody jsem napsal. Schválně si pusť odkazovanou přednášku, tam je to vysvětleno ještě z jiného úhlu pohledu. (Je teda fakt, že on pro přesné řízení zdrojů a pro PID opravdu potřebuje mít čistou veličinu, protože jakákoliv přepočtová funkce mu z toho PID udělá něco zcela jiného.)

Obsazenost ram a io zátěž jsou jistě správné veličiny k monitorování.

K tomu loadu, s absurdně vysokými hodnotami loadu (stovky) se setkávám, pokud procesy čekají na IO. Jsou ve stavu D, čekají třeba na již neexistující NFS server a nic nedělají. Load stoupá (protože load je zprůměrovaná délka fronty čekajících procesů), počet procesů stoupá, ale jinak se nic neděje.

Zajímavé je, že většina monitovacích software má / měla default check pro zombie (já jsem fakt za 15 let praxe neviděl, že by kernel nestíhat zabíjet zombíky) ale nikde jsem se nesetkal s checkem pro D (uninterruptible sleep).

Takže správný postup je monitorovat ten NFS mount, druhá správná možnost je monitorovat procesy ve všech patologických stavech (monitoruje se pouze Z). Ne, místo toho se měří load.

[Heron]

Ještě mě napadla další věc. Spousta lidí si myslí, že monitorováním loadu si ušetří práci. Prostě když je load vysoký, tak se něco děje a začne se vyšetřovat. To je jako mít jednu červenou kontrolku, která se rozsvítí, když je něco špatně. Sice špatně může být asi tisíc věcí, ale vy máte jen jedno červené světlo.

To ale žádný čas neušetří, protože potom musíte vyšetřovat co se kde stalo. Když jsou testy na každém rohu, tak přesně víte, které selhaly. Ještě nevíte proč, ale víte přesně které.

[Max]

Stejně tak jako tak jdu na server a podívám se, co se děje. Sice mohu monitorovat 20x víc věcí, ale stejně se na ten server nakonec podívám.
Další věcí je udržitelnost. Pokud člověk nepoužívá nějaké automatizační nástroje na monitoring (nějaký agent, co ti začne na serveru měřit vše, co najde a udělá ti v tom pěkný bordel), které osobně moc nemusím, tak při jakékoli změně musím dbát změny i na monitoring serveru. Čím míň věcí monitoruji, tím menší údržbu na monitoringu musím dělat.
Chápu, že tobě se load nelíbí, ok, mně naopak pro mé potřeby vyhovuje a plně dostačuje a nestydím se za to.
Zdar Max

[Heron]

Chjo, tohle není nic na úrovni stydět se. Pokud ti to tak vyhovuje, tak si to tak dělej. Já jsem chtěl jen poradit.

tak při jakékoli změně musím dbát změny i na monitoring serveru

No to by mělo být součástí práce. Stejně jako dokumentace. Práce není hotová, dokud nejsou testy a není to zdokumentováno. (Opět je to moje vidění, které nikomu necpu.)

tobě se load nelíbí

To není o líbí / nelíbí. Taky jsem se v minulosti spálil monitorováním nesprávných metrik (které byly sledované nikoliv proto, že to daná situace vyžadovala, ale proto, "že se to tak dělá").

[Josef Kufner]

Ty bereš load jako něco všemocného, co nahradí všechny další metriky, ale ono to je jen souhrnný ukazatel. Ta jedna červená kontrolka se hodí, abych věděl, že se něco děje. Neřekne mi co přesně se děje, ale řekne mi, ať se na to kouknu. Pak přijdou na řadu ty další ukazatele.

[Heron]

Ty bereš load jako něco všemocného

Seš si jistej, že reaguješ na správný komentář? Od počátku píšu load nebrat a ty mě na to napíšeš, že to beru jako něco všemocného

[Josef Kufner]

Jo, ale to slovo asi nebylo úplně to správné … „příliš obecný a všezahrnující, než aby byl užitečný“? Prostě, přijde mi, že load zatracuješ, protože máš od něj přehnaná očekávání, která samozřejmě nenaplní, neboť je to jen souhrnný a nekonkrétní indikátor.

[Heron]

Prostě, přijde mi, že load zatracuješ, protože máš od něj přehnaná očekávání

Ne, já vím přesně, co je load. Časem zprůměrovaná délka fronty procesů s nějakým exponenciálním úbytkem. Nic víc od něj neočekávám. A toto stanovisko je u mě roky stejné.

A ty roky potkávám právě lidi, kteří load považují za bůh ví co. Když jsem nedávno dělal graf renderingu v 80 threadech, měl jsem load 80. Když se mi někde sekne NFS, je load klidně 500. Jen protože procesy čekají ve frontě. V prvním případě jsou to cpu bound procesy, ale vše ostatní funguje (když se tomu rendereru dá nízká priorita) v nezměněném tempu. U těch procesů zaseknutých v D je už potom vliv zcela nulový (ok, dobře, žerou paměť). Tj load 30 znamená jen tolik, že průměrně za 1 / 5 / 15 minut bylo ve stavu runnable 30 procesů. No to jsem se toho dozvěděl. Navíc ta hodnota není nezávislá. Load 30 na 4jádru může přestavovat problém, load 30 na 64jádru je flákárna.

[chtel_bych_se_zeptat]

K tem zombikum... Ja jsem taky myslel ze se o ne kernel postara, ale tady nejak ne.

[root@server ~]# top | grep zombie
Tasks: 168 total,   1 running, 163 sleeping,   0 stopped,   4 zombie


[root@server ~]# ps aux | awk '$8~/Z/ {print}'
pentaho  22169  0.0  0.0      0     0 ?        Z    Jul24   0:00 [sh] defunct
pentaho  24656  0.0  0.0      0     0 ?        Z    Jul27   0:00 [sh] defunct
pentaho  29982  0.0  0.0      0     0 ?        Z    Jul27   0:00 [sh] defunct
pentaho  30895  0.0  0.0      0     0 ?        Z    Jul27   0:00 [sh] defunct

[Josef Kufner]

Jen technický detail: O zombíky se nestará kernel, ale init. Pokud rodičovský proces ještě žije a zombíky nesbírá, tak tam zombíkují a init je posbírá, až když rodičovský proces skončí (a init se automaticky stane jejich rodičem). Celá pointa zombíků je v tom, že rodičovský proces si musí vyzvednout návratový kód procesu (ten int, který vrací main()). Po ukončení procesu se uvolní všechny zdroje, které měl proces alokované a zůstane jen zombík, tedy záznam v tabulce procesů, který obsahuje ten návratový kód.

[Peter Golis]

A má to byť monitorovanie desktopu (pracovného/herného), alebo servera? Lebo v obidvoch prípadoch má prioritu monitorovania niečo iné.

[chtel_bych_se_zeptat]

Server.

[Peter Golis]

Tak pri serveri vie správca čo je preň kritické. Nejaký domáci NAS na tom bude asi inak, ako bezdiskový výpočtový nod clustra, alebo databázový server na ktorý pristupuje paralelne 100 000 užívateľov.

Všeobecne sa dá poradiť aby na začiatok človek zapol mointoring úplne všetkého, a postupom času si vytvoril pohľad v ktorom sa mu zobrazia najkritickejšie aspekty.

[sulin]

Všeobecne sa dá poradiť aby na začiatok človek zapol mointoring úplne všetkého, a postupom času si vytvoril pohľad v ktorom sa mu zobrazia najkritickejšie aspekty.

Asi tak

[q.]

da se rict ze souhlasim s tim co tu zatim zaznelo (+load urcite a presne jak popsal Max, ve chvili kdy se neco deje, je dobre omrknout jestli a jak moc je tam zvyseny celkovy load apod, mnohem jednodussi nez vesteni z vrcholu hodnot cpu vytizeni [a to obzvlast zaznam pro kazde jadro, celkove je naopak dost neuzitecny])

urcite bych u vm rekl monitorovat u cpu i steal hodnotu (viz 'st' v top), protoze muzes mit pretizene cpu ale nedela to tve vm ale jine ci host system (asi ne u vsech druhu virtualizaci/prirazeni cpu, pokud chces minimum mereni tak otestovat)

stejne tak u disku read/write bandwidth a latency (u vm dulezitost muze zaviset na zvolenem zpusobu kesovani diskovych pozadavku virtualizaci) + prip. iops

a jak tu taky nekdo psal, urcite se zamyslet a zamerit na monitorovani samotne sluzby a dostani podstatnych hodnot primo od ni (nebo aspon z logu) to by snad krome primeho nedostatku disku/pameti mel byt primarni indikator ze je neco spatne (a mozna pak je treba studovat ostatni hodnoty)

[chtel_bych_se_zeptat]

Chtel vych se zeptat blize na io. Kterou metriku by jste osobne sledovali.

Byla by to io-wait z topu? (Jestli tomu dobre rozumim, tak kdyz tohle roste, tak se jedna o saturaci, takze i hodna 15% je v tomto pripade spatne.)

Nebo %util z iotop? (Kde se jedna o vytizeni a 80% muze byt klidne v pohode.)

Vety v zavorkach jsou spise moje domenky, jak chapu tyto hodnoty ja. Jestli se pletu, rad se necham poucit.

Predem moc diky

[NN]

Pokud to neni tajne, muzeme se konecne dozvedet co to bude cele zac? Co je to za server a k cemu bude slouzit?

[chtel_bych_se_zeptat]

Neni to tajne. Prevazne webove a databazove servery. Nasadil jsem NRPE, ale zjistil jsem, ze skripty v balicku nagios-plugins jsou pomerne zastarale. Pisi si ted sve vlastni. Je to dobry trening a clovek se neco priuci. Aktualne to delam tak jak tady bylo nekolikrat zmineno - nasadim obecne checky na vsechny servery a pak zvlast checky podle toho o jaky server se jedna. Nechci sbirat tech metrik moc.

[KOLEGA]

Nic si nepis a sahni po Icinga. Taky jsme to v praci resili a jsme moc spokojeni. Nagios veci si preneses a zbytek pozbiras, komunita je mimoradne vstricna.

Metrik tolik nesbirame, jenom bezne lifecycle ukazatale a pak nejake hardware veci pres SNMP. Takze jak pises se mi to zda moudre.

[chtel_bych_se_zeptat]

Dobre, ale neco Vam musi data do Icingy posilat. Pouzivate nejakeho agenta? Jinak odpoved "nic si nepis" neni zrovna to co potrebuji :) ja v tom opravdu vidim dobry trenink. :)

[alkoholik]

Zrovna SNMP na vetsinu veci bohate staci.

[Max]

Já používám zásadně nrpe (jak na linuxu, tak na win). Nevím, jak nyní, ale dřív se snmp chovalo rozdílně i v rámci distribucí. Nrpe naproti tomu se všude chová stejně (+ samozřejmě mnohem lepší možnosti kontrol).
Zdar Max

[chtel_bych_se_zeptat]

A jak resis scripty, ktere NRPE spousti?

[Max]

Jak to myslíš? Jako nebezpečí děravosti nrpe povoleného s argumentama? Nebo myslíš distribuci skriptů na jednotlivé servery?
Zdar Max

[chtel_bych_se_zeptat]

No prosel jsem nekolik navodu na instalaci NRPE a skoro vsude je uvedeno "nainstaluj balik nagios-plugins (nagios-plugins-basic)". Tohle dotahne skripty/binarkt, ktere pak NRPE spousti jako jednotlive checky. Ale me vadi ze to je takova smeska, casto s obosolete kodem.

Takze jak delas ty checky. Pouzivas pro to balik nagios-plugins a nebo mas jiny zdroj?

Predem diky

[Max]

Používám standardní balík "nagios-plugins" + mám vlastní plugin na paměť + většinu ostatních kontrol pak dělám z dálky.
Bezpečnost řeším tak, že :

• povolená komunikace jen pro centreon server
• na firewallu povoleno navázat spojení jen pro centreon server
• nyní mám ještě nasazen flowmon na odhalení podezřelé komunikace na síti (ADS)

Zdar Max

[OldFrog {Ondra Nemecek}]

Názorů tu padlo mnoho. Jen doplním, že podle mě má smysl monitorovat oboje skupiny parametrů:

1. odezvy a funkčnost služeb - to je to co jedině nakonec zajímá uživatele
2. ostatní systémové parametry - protože pomohou předvídat anebo odhlalit příčinu, proč služba uvedená v bodě 1 neběží

[chtel_bych_se_zeptat]

Myslim, ze vse podstatne k me prvni otazce bylo zodpovezeno. Poprosim admina o oznaceni za vyreseno. Dekuji vsem. :)