[Linux] Simpel monitor programma

[mphilipp]

Ik heb een Dell PowerEdge 1650 die straks een datacenter in gaat. Ik wil dat ding een beetje monitoren qua cpu en netwerkgebruik. Het serverprog dat erop draait wordt bewaakt (webmin) en als die crasht, start ie vanzelf opnieuw. Dat proces is op zich ook niet mijn zorg. Momenteel kijk ik regelmatig met top of htop om te zien of het cpu gebruik nog een beetje binnen de perken blijft. Ook heb ik ntop geïnstalleerd om het netwerkgebruik te kunnen bekijken. Waar ik alleen behoeft aan heb, is een systeem om de historie van die 2 zaken te bekijken, en trends te ontdekken.

Punt is dat ik alleen maar paketten als Nagios of Zenoss tegenkom. Volgens mij is dat weer een beetje overkill. Ik wil helemaal verder niets monitoren of alarmpjes. De schijf kan praktisch niet volraken, en het enige proces dat ertoe doet, is al gecovered door de monitor van Webmin. Ik ben denk ik langer bezig om alle overbodige shit in iets als Nagios uit te zetten, dan dat het me iets oplevert.

Zijn er pakketjes die alleen maar cpu en netwerkbandbreedte/doorvoer bijhouden en niet zo vreselijk uitgebreid zijn als Nagios enzo?

[woutertje]

Misschien kun je wat met MRTG (draait bij mij op http://xen.wouter-web.nl/mrtg). Vrij simpel programma
en genoeg over te vinden.

[lvh]

rrdtool.

[maleadt]

woutertje schreef op dinsdag 27 januari 2009 @ 11:03:
Misschien kun je wat met MRTG (draait bij mij op http://xen.wouter-web.nl/mrtg). Vrij simpel programma
en genoeg over te vinden.

Of cacti, doet het ook heel goed en is heel uitbreidbaar (zelf even een data source plugin schrijven is niet zo veel werk). Ondersteund ook remote servers, dus je kan cacti perfect op een andere bak hosten.

racoontje schreef op dinsdag 27 januari 2009 @ 11:03:
rrdtool.

RRDtool is natuurlijk wel de onderliggende machinerie van al deze tooltjes, maar ik zou het niet zelf beginnen gebruiken. Moet je al zelf scripts beginnen schrijven en zo, allemaal niet nodig: er bestaan al genoeg pakketten die je dit werk uit handen nemen.

[Verwijderd]

Voor deze doeleinden is munin een aanrader: http://munin.projects.linpro.no/

Hier een simple howto om munin op te zetten:

http://www.howtoforge.com/server_monitoring_monit_munin

[Boudewijn]

Munin is hier inderdaad erg geschikt voor.

Veel meer een no-brainer dan cacti om op te zetten, en gebruikt onder de motorkap rrd .

[mboy]

Eventueel is collectd ook een optie. Collectd gebruikt ook rrd onder de motorkap en is daarnaast volledig modulair en simpel op te zetten.

http://collectd.org/

[Verwijderd]

Ik ben zelf groot fan van Zabbix, maar dat is niet echt een 'simpel' monitoring programma. Kijk zelf maar eens op http://www.zabbix.org

[jpm.lensen]

Als je tevreden bent met je top/ ntop output, misschien kun je dit dmv een optie ook naar disk schrijven? Vaak zit die optie er al in. Dan moet je misschien alleen nog zelf deze bestanden in excel/ oid importeren voor trends etc.?

[Noxious]

Je hebt al keuzes genoeg in ieder geval

Munin is idd leuk

[mphilipp]

Dank allemaal voor de suggesties. Ik ga denk ik voor MRTG. Die kende ik eigenlijk al, maar ik dacht dat ie alleen voor routers was en niet geschikt voor mijn doel, maar nu blijkt dat ie precies doet wat ik wil. Ik wil gewoon kunnen kijken hoe cpu en geheugengebruik zich ontwikkelt en de bandbreedte in de gaten houden. Een programma met alarmpjes enzo is niet nodig, en teveel toeters en bellen ook niet. Grafiekjes zijn zat.

[Boudewijn]

Maar zoiets als munin bevat standaard alle scriptjes al om die grafieken te maken, mrtg is volgens mij puur de graphing software. Ga je dan zelf de scripts nog schrijven?

[Oezie Woezie]

http://www.google.nl/sear...&btnG=Google+zoeken&meta=

speciaal voor boudewijn dan:
http://konijn.oezie.org/rrd2/cpu.pl
geeft iets als:
http://konijn.oezie.org/rrd2/cpu/haas.html

[ Voor 43% gewijzigd door Oezie Woezie op 28-01-2009 16:31 ]

[Verwijderd]

Boudewijn schreef op woensdag 28 januari 2009 @ 14:12:
Maar zoiets als munin bevat standaard alle scriptjes al om die grafieken te maken, mrtg is volgens mij puur de graphing software. Ga je dan zelf de scripts nog schrijven?

Helemaal met je eens Boudewijn

@mphilipp kies gewoon voor munin en klaar ben je

[Boudewijn]

Oezie Woezie schreef op woensdag 28 januari 2009 @ 14:34:
http://www.google.nl/sear...&btnG=Google+zoeken&meta=

Wat is dit nou voor post? Verkapte UTFS ofzo?


Even voor de rest: hij vraagt simpel! Hij wil gewoon een stel grafiekjes hebben zonder zelf 3 weken te hoeven klooien met allerlei code. Niet meer, niet minder. .


@TS: Bevalt het?

[mboy]

MRTG maakt gebruik van rrdtool en is voor zover ik weet niet meer dan een verzameling wrappertjes om rrdtool heen. Verzamelde gegevens worden gewoon opgeslagen in rrd's, die vervolgens met rrdtool's graph utility worden uitgelezen om grafiekjes te bakken.

[TommyGun]

mboy schreef op donderdag 29 januari 2009 @ 13:28:
MRTG maakt gebruik van rrdtool en is voor zover ik weet niet meer dan een verzameling wrappertjes om rrdtool heen. Verzamelde gegevens worden gewoon opgeslagen in rrd's, die vervolgens met rrdtool's graph utility worden uitgelezen om grafiekjes te bakken.

Dat dus. Kortom; ga voor MRTG

[Boudewijn]

TommyGun schreef op donderdag 29 januari 2009 @ 13:30:
[...]


Dat dus. Kortom; ga voor MRTG

+1 genuanceerd .

Maar waarom is het dan beter qua usability dan munin? Dat gebruikt net zo goed rrd.
Echter heeft munin (mi!) meer standaard scriptjes voor standaard dingen (die de ts wil) zoals CPU , disk etc.

Heb net de proef op de som genomen en apt-get install munin munin-node gedaan.
Had in 60 seconden een complete monitoring op mijn debian server . Mijn ervaring met mrtg is dat je vaak zelf toch nog wat views enzo in elkaar moet klooien. Kan allemaal prima, maar kost meer tijd.


Verder kan munin ook met losse nodes werken en 1 centrale server. Weet niet of mrtg dat out of the box ook kan (zonder veel instelwerk).

[berties]

Om het verhaal van Boudewijn nog even te onderstrepen,

Ten eerste is mrtg ≠ rddtool.
Het zijn beide pakketten om data om te zetten in grafieken. Persoonlijk zie ik rddtool wel als de verbeterde opvolger van mrtg. Mrtg is eenvoudiger qua opzet en rddtool heeft meer functies en maakt mooiere grafieken. Toch gaat rddtool beter om mijn zijn resources dan mrtg en daarbij heeft rddtool dus in alle, behalve één, opzichten de voorkeur boven mrtg.
Dat ene opzicht is dan misschien de moelijkheidsgraad. Aan het verzamelen en verwerken van data ten behoeve van rddtool worden meer eisen gesteld dan mrtg, dit maakt mrtg dus eenvoudiger. Ik heb jaren (denk een jaar of 6) gewerkt met allerlei omslachtige (gedeeltelijk) zelfgemaakte scripts om aan mrtg te voeren.
Tot ik munin tegen kwam en die naast het gehele rddtool pakket ook allerlei extra's installeerd, waaronder 75% van de standaardscripts die je nodig hebt om je grafiekjes te maken. Zoals Boudewijn al zegt ben je in een aantal seconden zover dat het merendeel van je benodigde grafieken out-of-the-box werkt. Voor die paar extra maak je op basis van de voorhanden zijnde voorbeelden en bestaande grafieken super simpel een eigen grafiek die automatisch wordt meegenomen.

Dus als je toch voor mrtg gaat, veel succes. Ik verwacht dat je dan echter bij het gebruik van munin (of vergelijkbaar pakket natuurlijk (Cacti)) tot de conclusie komt dat je veel werk bespaard kon zijn gebleven.

I rest my case..

[Boudewijn]

offtopic:
Tobi oetiker (geen idee of ik het goed schrijf), de maker van mrtg en rrd, heeft rrd als replacement geschreven voor mrtg. Het is dus een complete vervangende herimplementatie van dezelfde functionaliteit (en meer uiteindelijk).

[mboy]

berties heeft gelijk, ik heb te snel gesproken. MRTG is wel degelijk meer dan rrdtool met wat wrappertjes. rrdtool kan evt. gebruikt worden i.s.m. rrdtool, maar MRTG maakt out-of-the-box van logfiles die slim worden geconsolideerd.

[Boudewijn]

Dat is leuk, maar ook de logfiles moeten nog gegenereerd worden. Bij zoiets als een webserver is dat goed te doen, maar memory en CPU vereist wat scriptwerk . Interrupts en eth-errors ook.

[berties]

"[offtopic]" van toepassing maar dan werkt "[quote]" niet meer...

Ik moet toch even reageren omdat ik enkele stukken tekst niet helemaal snap.

MRTG is wel degelijk meer dan rrdtool met wat wrappertjes.

Boudewijn;

Tobi oetiker (geen idee of ik het goed schrijf), de maker van mrtg en rrd, heeft rrd als replacement geschreven voor mrtg. Het is dus een complete vervangende herimplementatie van dezelfde functionaliteit (en meer uiteindelijk).

rrdtool kan evt. gebruikt worden i.s.m. rrdtool.

????

maar MRTG maakt out-of-the-box van logfiles die slim worden geconsolideerd.

????

[mboy]

Boudewijn en ik spreken elkaar inderdaad tegen Ik baseer mijn uitspraken op wat ik lees op de volgende pagina: http://oss.oetiker.ch/mrtg/doc/mrtg-rrd.en.html. Misschien dat Boudewijn een andere bron heeft of het anders interpreteerd dan ik of misschien dat ik iets over het hoofd gezien heb of whatever.

Daarnaast heb ik MRTG of Munin nooit aangeprezen als de oplossing voor de TS. Ik dacht alleen een interessante opmerking te maken, die bij nader inzien toch niet zo interessant was

[Oezie Woezie]

Boudewijn schreef op donderdag 29 januari 2009 @ 15:02:
Dat is leuk, maar ook de logfiles moeten nog gegenereerd worden. Bij zoiets als een webserver is dat goed te doen, maar memory en CPU vereist wat scriptwerk . Interrupts en eth-errors ook.

logfile parsen is toch ook script werk? en in de meeste gevallen is het ook via SNMPd uit te lezen, en dan is het gewoon een kwestie van een standaard rrdtool script pakken en de OID's veranderen.

[Boudewijn]

Oezie Woezie schreef op donderdag 29 januari 2009 @ 15:54:
[...]


logfile parsen is toch ook script werk? en in de meeste gevallen is het ook via SNMPd uit te lezen, en dan is het gewoon een kwestie van een standaard rrdtool script pakken en de OID's veranderen.

Verschillende ranges, laten refreshen, alarmpjes evt.
En meerdere nodes.

Doe je niet in 2 minuutjes, althans ik niet.

[berties]

mboy schreef op donderdag 29 januari 2009 @ 15:41:
Boudewijn en ik spreken elkaar inderdaad tegen Ik baseer mijn uitspraken op wat ik lees op de volgende pagina: http://oss.oetiker.ch/mrtg/doc/mrtg-rrd.en.html. Misschien dat Boudewijn een andere bron heeft of het anders interpreteerd dan ik of misschien dat ik iets over het hoofd gezien heb of whatever.

Ik denk dat die verwarring eigenlijk wel begrijpelijk is.
Je hebt naast mrtg en de verbeterde en herschreven vorm daarvan; rddtool ook een een compatibiliteitsmogelijkheid om de mrtg data door rddtool te laten verwerken, daarmee heb je dus eigenlijk mrtg en rddtool gecombineerd.

[mphilipp]

berties schreef op donderdag 29 januari 2009 @ 14:18:
Dus als je toch voor mrtg gaat, veel succes. Ik verwacht dat je dan echter bij het gebruik van munin (of vergelijkbaar pakket natuurlijk (Cacti)) tot de conclusie komt dat je veel werk bespaard kon zijn gebleven.

I rest my case..

Als je er van uit gaat dat iedereen die MRTG gaat gebruiken het wiel opnieuw uitvindt heb je misschien gelijk. Maar dat is niet nodig. Ik heb hier voor me een guide om MRTG precies voor datgene te gebruiken dat ik wil, en die guide is niet langer of korter dan de guide om Munin aan de praat te krijgen. Want Munin is geenszins plug & play. Dus voor mijn doeleinden is MRTG prima. Alleen CPU/network history, meer niet. Out of the box doet MRTG je netwerk al, ik moet alleen een pietluttig skrippie copy/pasten en klaar ben ik.

Maar even in het algemeen: geen enkel pakket is 'beter' dan een ander pakket. Dat hangt altijd af van wat je precies wilt doen, je eigen kennisnivo en nog wat factoren. Er is zat te vinden op het web, maar 80% van de 'guides' zijn (blijkbaar) verouderd, onvolledig, of het hele pakketje werkt toch niet zoals het zou moeten. Wat dat betreft is het af en toe een ware slijtageslag.

Evengoed lijkt het met MRTG prima te lukken.

[Boudewijn]

mphilipp schreef op donderdag 29 januari 2009 @ 16:27:
[...]
Want Munin is geenszins plug & play.

Ik ben het verder helemaal eens met je post , maar waarom dat statement? Op mijn dozen (debian, freebsd en ubuntu) draait het prima out of the box .

[pennywiser]

mphilipp schreef op donderdag 29 januari 2009 @ 16:27:
[...]
Ik heb hier voor me een guide om MRTG precies voor datgene te gebruiken dat ik wil,

Wil je die howto wellicht hier even posten?

[berties]

mphilipp schreef op donderdag 29 januari 2009 @ 16:27:
[...]

Als je er van uit gaat dat iedereen die MRTG gaat gebruiken het wiel opnieuw uitvindt heb je misschien gelijk. Maar dat is niet nodig. Ik heb hier voor me een guide om MRTG precies voor datgene te gebruiken dat ik wil, en die guide is niet langer of korter dan de guide om Munin aan de praat te krijgen. Want Munin is geenszins plug & play. Dus voor mijn doeleinden is MRTG prima. Alleen CPU/network history, meer niet. Out of the box doet MRTG je netwerk al, ik moet alleen een pietluttig skrippie copy/pasten en klaar ben ik.

Maar even in het algemeen: geen enkel pakket is 'beter' dan een ander pakket. Dat hangt altijd af van wat je precies wilt doen, je eigen kennisnivo en nog wat factoren. Er is zat te vinden op het web, maar 80% van de 'guides' zijn (blijkbaar) verouderd, onvolledig, of het hele pakketje werkt toch niet zoals het zou moeten. Wat dat betreft is het af en toe een ware slijtageslag.

Evengoed lijkt het met MRTG prima te lukken.

Ik ben het helemaal met je eens dat je nooit kunt stellen dat het ene pakket in alle situaties beter is dan het andere. Dat heb ik ook niet willen veronderstellen.
Toch denk ik dat er maar weinig situaties zijn waarin mrtg de voorkeur heeft boven munin. Op basis van mijn persoonlijke ervaring (kijk daar zit de crux; persoonlijke ervaring ) kan ik stellen dat voor het genereren van enkel cpu/netwerk grafieken mijn voorkeur uitgaat naar munin. Op mijn Debian box is dat een apt-get en daarna de symlinks in de plugins directory verwijderen van die 10 pakketen die je niet nodig hebt en de rest laten staan. Dat is alles. Als je voor mrtg gaat zul je nog steeds moeten kijken hoe de mrtg.cfg is opgebouwd en een heel eenvoudig script moeten maken die de data aan mrtg voert. Dit is ook niet veel werkt maar persoonlijk geef ik in dit geval de voorkeur aan munin...

..gelukkig is er open source en is iedereen vrij te gebruiken wat ie wil en kun je het altijd aanpassen als je het anders wil. Iedereen tevreden

[berties]

pennywiser schreef op donderdag 29 januari 2009 @ 16:33:
[...]


Wil je die howto wellicht hier even posten?

Op de site van Tobi staat een grote verzamelijk links naar howto's.

[mphilipp]

pennywiser schreef op donderdag 29 januari 2009 @ 16:33:
[...]
Wil je die howto wellicht hier even posten?

Deze

Wat Munin betreft: als ik deze guide aan hou, is het niet zomaar klaar na apt-get. Het zal wel de verkeerde guide zijn, maar het werkte toch (weer) niet zoals geadverteerd. Soms lijkt het wel of ze zo'n guide uit het hoofd hebben ingetikt ofzo.

Anyway...mrtg is - zoals ik al aangaf - prima. Hij doet wat ie doen moet, niets meer en niets minder. Ik heb geen behoefte aan fancy toestanden en de cpu belasting per proces is voor mij ook totaal niet interessant. Er draait, naast de dingen waar je niets aan kunt doen, alleen mijn ding op, en ik wil graag zien of er iets geks gebeurt. Als dat zo is, ga ik zelf wel weer verder graven.

[Boudewijn]

Hmm hier werkte het op etch na apt-get wel . Echt niets aangepast, en ik heb redelijk wat info.
Het kan beter , qua informatie.

Echter heb ik niets anders gedaan dan apt-get install munin. En een webserver installen uiteraard.

Info die ik heb:

o Disk
+ Filesystem usage (in %)
+ Inode usage (in %)
+ IOstat
o Exim
+ Exim Mailqueue
+ Exim mail throughput
o Network
+ eth0 errors
+ eth1 errors
+ eth0 traffic
+ eth1 traffic
+ Netstat
o Processes
+ Fork rate
+ Number of Processes
+ VMstat
o System
+ CPU usage
+ Available entropy
+ Interrupts & context switches
+ Individual interrupts
+ Load average
+ Memory usage
+ File table usage
+ Inode table usage
+ Swap in/out

Alle counters lijken ook gewoon te werken trouwens.

In die guide van jou staat heel veel aan optioneel spul. Ook remote logging dmv nodes... en tsja dat dat niet out of the box werkt is vrij logisch .

[berties]

Ik heb dezelfde ervaring als Boudewijn, apt-get was voldoende en werkte perfect.

De howto die je gevonden had is inderdaad wel wat meer dan alleen een apt-get. Ik kan me voorstellen dat mrtg er dan eenvoudiger uit ziet.

Ik heb in basis ook al die extra dingen niet nodig maar redeneer wel omgekeerd. Als er iets mis is, dan wil ik dat er op dat moment werd gelogd en liever een proces te veel dan een te weinig, waardoor het achterhalen van de problemen moeilijker wordt. Het wordt lastig om dan met terugwerkende kracht alsnog uitvoerig grafisch te loggen en er achter te komen dat je toch te weinig logt om de uitschieters vast te stellen. Dan wordt het toch echt cat sed awk en grep werk en ik heb nu net munin om in één oogopslag te zien waar de uitschieters zitten. Dan kan ik altijd nog gaan cat sed awk en greppen...

[Verwijderd]

Munin is inderdaad eigenlijk alleen maar een kwestie van apt-get install. Zie bijv. deze howto:

http://www.howtoforge.com/server_monitoring_monit_munin

[Bertus]

Kan je met munin ook een extern systeem loggen?

[Verwijderd]

Bertus schreef op dinsdag 03 februari 2009 @ 16:13:
Kan je met munin ook een extern systeem loggen?

Ja.

[Boudewijn]

Bertus schreef op dinsdag 03 februari 2009 @ 16:13:
Kan je met munin ook een extern systeem loggen?

Ja je hebt munin ,de 'master', waar je dan een aantal munin-nodes aan kunt knopen.
Master maakt er netjes een html page oid van, die je weer serveert.

Zo doe ik het iig op mijn vm-clustertje. Slechts 1 doos draait munin (en munin-node), de rest draait enkel munin.

[sparks]

Wat is er mis aan het oude sar commando?

[Confusion]

sparks schreef op dinsdag 03 februari 2009 @ 19:31:
Wat is er mis aan het oude sar commando?

Dat je daar dan zelf nog een wrapper omheen moet schrijven om de gegevens over de laatste 5 min, 30 min, etc. uit te rekenen en overzichtelijk weer te geven?

[Boudewijn]

En je het dan ook nog slim remote moet doen....
En volgens mij kun je ook niet alles met sar opvragen.

[Verwijderd]

En verder geven grafieken een betere trend weer dan wat getallen.

[Boudewijn]

Alleen getallen geven uberhaupt geen trend weer (zonder historie dan). En alerts zijn ook wel handig.

[ Voor 18% gewijzigd door Boudewijn op 03-02-2009 21:49 ]