Heb je iets aan mijn antwoord ? Een thumbs-up wordt zeker op prijs gesteld.
Misschien een overflow in de counter van de uptime?
Nu met Land Rover Series 3 en Defender 90
code:
En dan mag jij raden waarom hij net boven de 4000k naar 0 wrapt 1
2
3
| % calc 2**32 4294967296 % |
Sorry, maar op dit gebied ben ik waarschijnlijk helemaal een n00b. Ik heb geen idee waar je het over hebt.
Heb je iets aan mijn antwoord ? Een thumbs-up wordt zeker op prijs gesteld.
Hij bedoelt dat een 32-bit decimaal getal hetzelfde is als 4294967296 (2^32).
En als CentOS4 je idle time nu bewaart in een 32-bit integer, dan valt die weer naar 0 als 2^32 bereikt is.
En als CentOS4 je idle time nu bewaart in een 32-bit integer, dan valt die weer naar 0 als 2^32 bereikt is.
WebDAV in Vista is horribly broken. Ik wil het fixen, maar ben nog steeds op zoek naar de tarball met de source...
Als je die uptime nou in dagen laat weergeven dan zal et je niet meer overkomen.
Ik heb nu wel kunnen vinden hoe ik de werkelijke Idle tijd kan uitrekenen :
Maar hoe kan ik dit nu binnen MRTG implementeren zodat deze ook de tijd in dagen weergeeft i.p.v. sec ?
code:
1
| gawk "{print \$1/(3600 * 24.0)}" /proc/uptime |
Maar hoe kan ik dit nu binnen MRTG implementeren zodat deze ook de tijd in dagen weergeeft i.p.v. sec ?
Heb je iets aan mijn antwoord ? Een thumbs-up wordt zeker op prijs gesteld.
Je bepaalt zelf wat de input van MRTG is toch? Dus, zorgen dat de input in dagen is ipv seconden....delen door 60*60*24 zoals je hierboven al doet inderdaad?
Overigens wel gek dat de counter van het 'groene' vlak blijkbaar 64-bits is, die heeft het probleem namelijk niet...bugje in MRTG misschien
Overigens wel gek dat de counter van het 'groene' vlak blijkbaar 64-bits is, die heeft het probleem namelijk niet...bugje in MRTG misschien
Ik heb nu al een tijdje gezocht (ben ook geen MRTG held) maar ik kan niet vinden hoe ik de input in MRTG kan omzetten van sec. in dagen. Als iemand mij dit zou kunnen uitleggen ben ik hem/haar heel erkentelijk.
Heb je iets aan mijn antwoord ? Een thumbs-up wordt zeker op prijs gesteld.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| #!/usr/bin/perl use POSIX; use warnings; use strict; my $uptime; my $idle; $uptime = `cat /proc/uptime`; ($uptime, $idle) = split(/ /,$uptime,2); $uptime = floor($uptime/86400); $idle = floor($idle/86400); print "$uptime\n"; print "$idle\n"; print "unknown\n"; print "unknown\n"; |
en dan in je mrtg.cfg zoiets als dit als target regel.
code:
1
| Target[octopus_uptime]: `perl /path/to/uptime.pl` |
een mooi Tshirt met Pim. is de beste enzo
Dank je Oezie.
Ok, ik heb de bestanden aangepast en mij oude logfiles weg gegooid. Zoals je boven kan zien is de grafiek allweer netjes aan het lopen. Alleen via deze manier is mijn IDLE time nog steeds niet in orde.
Ok, ik heb de bestanden aangepast en mij oude logfiles weg gegooid. Zoals je boven kan zien is de grafiek allweer netjes aan het lopen. Alleen via deze manier is mijn IDLE time nog steeds niet in orde.
Heb je iets aan mijn antwoord ? Een thumbs-up wordt zeker op prijs gesteld.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| static int uptime_read_proc(char *page, char **start, off_t off,
int count, int *eof, void *data)
{
struct timespec uptime;
struct timespec idle;
int len;
cputime_t idletime = cputime_add(init_task.utime, init_task.stime);
do_posix_clock_monotonic_gettime(&uptime);
cputime_to_timespec(idletime, &idle);
len = sprintf(page,"%lu.%02lu %lu.%02lu\n",
(unsigned long) uptime.tv_sec,
(uptime.tv_nsec / (NSEC_PER_SEC / 100)),
(unsigned long) idle.tv_sec,
(idle.tv_nsec / (NSEC_PER_SEC / 100)));
return proc_calc_metrics(page, start, off, count, eof, len);
} |
uit proc_misc.c misschien dat er ipv cputime_t de 64bit variant gebruikt kan worden cputime64_t.
een mooi Tshirt met Pim. is de beste enzo
Pagina: 1
