CPU SNMP monitoring in Linux

[MPAnnihilator]

Ik zit momenteel wat verveeld met CPU monitoring van een aantal Checkpoint firewalls. Wij monitoren die hier met PRTG , één van de bekendere commerciele SNMP monitoring pakketten denk ik.

Checkpoint heeft wel zijn eigen MIB uitbreidingen , maar voor die CPU monitoring hoeven we daar geen gebruik van te maken. In feite is mijn vraag dus algemener dan enkel voor onze Checkpoint monitoring.


Ik wens 2 zaken uit te lezen van die CPU , de idle time in % , en de 1 minute load in %
Dit zijn zowat de standaard mogelijkheden/OID's , diegene in het vet , die gebruik ik :

CPU Statistics

Load
1 minute Load: .1.3.6.1.4.1.2021.10.1.3.1
5 minute Load: .1.3.6.1.4.1.2021.10.1.3.2
15 minute Load: .1.3.6.1.4.1.2021.10.1.3.3

CPU
percentage of user CPU time: .1.3.6.1.4.1.2021.11.9.0
raw user cpu time: .1.3.6.1.4.1.2021.11.50.0
percentages of system CPU time: .1.3.6.1.4.1.2021.11.10.0
raw system cpu time: .1.3.6.1.4.1.2021.11.52.0
percentages of idle CPU time: .1.3.6.1.4.1.2021.11.11.0
raw idle cpu time: .1.3.6.1.4.1.2021.11.53.0
raw nice cpu time: .1.3.6.1.4.1.2021.11.51.0


Nu het probleem :

- Voor de 1 minute load ( .1.3.6.1.4.1.2021.10.1.3.1 ) : hier krijgen we extreen lage waardes , bijna allemaal 0,x waardes. Het leek mij dan logisch dat ik de uitgelezen waarde per definitie maal 10 doe , om de effectieve load te zien. Dat komt dan neer op belasting tussen de 3-5% ( wat met TOP op het toestel zelf bevestigd wordt ).
Het enige probleem is dat ik af en toe ook een waarde 11,x en dergelijke uitlees. Als ik deze maal 10 doe , kom ik uiteraard aan een load percentage van meer dan 100 %. Is dit dan gewoon het samentellen van 2 cores tot 200% , die dan 110% belast zijn , is dit dan 1 core 100% belast , en de 2 de core 10 procent ? Indien ja , dan hoef ik me geen zorgen te maken. Indien niet , dan snap ik niet wat ik nu juist uitlees , die OID voor 1 minute idle time moest toch iets héél algemeen zijn in de Linux wereld ?

- 2 de probleem is de Idle time in % ( .1.3.6.1.4.1.2021.11.11.0 ) : Deze lezen op sommige systemen 78% continu , andere systemen 98% continu. Zo'n 'flatline' voor CPU idle time lijkt me toch helemaal niet te kloppen

Graag enig advies , wat ik in TOP zie snap ik allemaal wel , maar wat ik nu met SNMP uitlees slaat voorlopig nergens op

[ Voor 0% gewijzigd door MPAnnihilator op 26-10-2012 11:43 . Reden: opmaak ]

[CAPSLOCK2000]

Load is niet hetzelfde als CPU-belasting. Het is een beetje ingewikkeld onderwerp, maar load kun je zien als de wachtrij van processen die actief willen zijn. Te weinig CPU kan een reden zijn om in de wachtrij te komen maar er zijn ook andere redenen.

Load wordt niet in procenten uitgedrukt. Er zit geen maximum aan de wachtrij.

Ik denk dat de getallen die je ziet kloppen.

[MPAnnihilator]

Als load niet in procenten werkt , met wat dan wel , vanaf welke waardes kan je dan best alarm slaan ?
Die waardes van load kloppen dan mogelijks wel , maar die van Idle time , die slaat nergens op , toch ? Dat kan toch geen flat line zijn

[blaataaps]

https://bugzilla.redhat.com/show_bug.cgi?id=473824 gelezen, over die OID's?
En wat zegt top over de idle-tijd? Wat zeggen de andere counters? Waarom heb je deze counters gekozen? De waarde en betekenis van de load-avg is genoeg over te vinden, misschien is het handig dat eerst te lezen voor je willekeurige getallen gaat vermenigvuldigen met andere willekeurige getallen

[MPAnnihilator]

Willekeurig is het zeker niet , in PRTG kan je je devices laten scannen op beschikbare sensoren. PRTG kiest dan zelf welke de meest gebruikte OID's/ sensoren zijn voor jouw OS/Hardware.

CPU idle en load avarage zijn zaken die hij bij elke Linux flavor standaard activeert/uitleest. Ik had dus geen reden om voor dat soort basic monitoring andere OID's te gaan zoeken , als die er al waren. Checkpoint heeft wel een custom MIB , maar dat gaat over funtionele zaken van de firewall software , zoals het uitlezen van het aantal gedropte pakketten , aantal vpn sessies , cluster status enz enz...

Die standaard mib tree lijkt me vrij universeel tussen alle Linuxen , alleen snap ik niet deze merkwaardige outputs... Bij nader inzicht blijkt het een fenomeen te zijn dat ook optreed bij Ubuntu machines en bij CentOS machines , ik denk niet dat het de 'schuld' is van een bepaalde Linux flavor. Ik heb gewoon geen ervaring met de waardes die uit die snmp walks komen en kan ze ook niet goed interpreteren.

[CyBeR]

MPAnnihilator schreef op vrijdag 26 oktober 2012 @ 13:25:
Als load niet in procenten werkt , met wat dan wel , vanaf welke waardes kan je dan best alarm slaan ?
Die waardes van load kloppen dan mogelijks wel , maar die van Idle time , die slaat nergens op , toch ? Dat kan toch geen flat line zijn

Ok. Ten eerste, voor een komma of ander leesteken zetten we in het Nederlands (en trouwens in geen enkele taal waar ik van weet) geen spatie.

Vervolgens: dat is het gemiddelde aantal processen in de run queue van de kernel's scheduler gedurende die tijd. Dus een waarde van 0.5 betekent dat er de helft van de tijd gemiddeld een proces in de run queue stond. Een waarde van 1 betekent dat de hele tijd er één proces in de queue stond. Enzovoort. Processen kunnen om meerdere redenen in die queue staan, dus je kunt er géén CPU usage aan aflezen. Een proces kan namelijk in de queue staan (en een load van 1.00 veroorzaken) omdat 'ie 100% van de cpu gebruikt, of omdat 'ie bijvoorbeeld op disk I/O zit te wachten. In dat laatste geval gebruikt 'ie 0% cpu maar staat 'ie wel constant in de queue.

Wat wij linux admins gewoonlijk aannemen als zijnde 'niet goed' is een load getal groter dan het aantal CPU cores. Dus, een quad core doos met overmatig vaak een load van > 4 = slechte zaak.