Onderwerp: howto: MRTG + GBGRAPH

Origineel geplaatst door Hans
Nee voor stats van je eigen server heb je alleen snmpd en mrtg nodig. Maar snmpd moet wel op de juiste wijze geconfigureerd zijn:

snmpconf -g basic_setup

Verder niet zo heel erg thuis in snmpd, dus kan je niet zo best helpen daarmee.

Oke, weet iemand wat al die vragen inhouden va die setup want ik moet zo'n 4 accounts aanmkane en een hoop y/n vragen waarvan de helft in TE ingewikkelde uitleg.

Edit: google doet wonderen ...

Origineel geplaatst door NetRouting

*/5 * * * * root env LANG=C /usr/local/mrtg-2/bin/mrtg /usr/local/mrtg-2/mrtg.cfg \ --logging /var/log/mrtg.log (kan uiteraard ook onder een andere user gedraait worden dan root).

Oke, mrtg zou nu naar behoren dienen te draaien. Binnen 5 minuten zullen de eerste grafiekjes met data gegenereert worden.

Kan iemand me uitleggen hoe ik bijvoorbeeld een paar uur kan excluden? Bijvoorbeeld geen metingen tussen 3 en 4 uur s'nachts?

Origineel geplaatst door serverbilly


Kan iemand me uitleggen hoe ik bijvoorbeeld een paar uur kan excluden? Bijvoorbeeld geen metingen tussen 3 en 4 uur s'nachts?

ehh daar vraag je me wat... Buiten het feit dat ik niet zie wat het nut ervan is ben ik bang dat ik je het antwoord niet kan geven hierop, Hans misschien?

Origineel geplaatst door serverbilly


Kan iemand me uitleggen hoe ik bijvoorbeeld een paar uur kan excluden? Bijvoorbeeld geen metingen tussen 3 en 4 uur s'nachts?

Als je rrdtool based (cricket, nmis etc) traffic gegevens hebt kan je met onderstaand script tussen bepaalde tijden weg knippen.

Code:

#!/usr/bin/perl

# replace unwanted numeric data in an rrd file with NaN values
# from Ed Ravin, eravin@panix.com, May 2002.  License is GPL.

use strict;
use Date::Parse;

#################### user-configurable stuff
my $RRDTOOL=  "rrdtool";                 # location of rrdtool
my $TEMPFILE= "/tmp/rrdcut.$$.xml";
#################### end user-configurable stuff

my $usage= "Cut rows out of an RRD database based on date and time.  Usage:

rrdcut -starttime 'DATE' -endtime 'DATE' rrdfile [...]

'DATE' format is anything accepted by Date::Parse str2time()
All rows in all datasources dated BETWEEN the start and end times will be
replaced with NaN values.
";


my $starttime;
my $endtime;

die $usage unless @ARGV > 1;

while (1)
{
	die $usage unless @ARGV >= 1;

	if ($ARGV[0] =~ /^-?-(start|end)time$/)
	{
		my $whichend= $1 . "time";
		shift @ARGV;
		my $thetime= str2time($ARGV[0]) ||
			die "$0: unable to parse -$whichend option value\n";
		$starttime= $thetime if ($whichend eq "starttime");
		$endtime=   $thetime if ($whichend eq "endtime");
	}
	elsif ($ARGV[0] =~/^-/)
	{
		die "$0: unknown option $ARGV[0]\n";
	}
	elsif ($ARGV[0] !~ /^-/)
	{
		last;
	}
	shift @ARGV;
}

die $usage unless $starttime and $endtime;

# sample row
#  we want the ctime value:       vvvvvvvvvv
#  <!-- 2002-05-03 20:00:00 EDT / 1020470400 --> <row><v> 1.2338352416e+07 </v><v> 8.0156175954e+06 </v><v> 0.0000000000e+00 </v><v> 1.4221113929e+07 </v></row>


foreach my $file (@ARGV)
{
	open(RRDXML, "$RRDTOOL dump $file|") ||
		die "$0: cannot rrddump $file: $!\n";
	open(TEMP, ">$TEMPFILE") ||
		die "$0: cannot open temp file $TEMPFILE for output: $!\n";
	while(<RRDXML>)
	{
		if (m@^\s* <!-- \s* \d\d\d\d-\d\d-\d\d \s* \d\d:\d\d:\d\d \s* [^/]*  \s* / \s* (\d+) \s* --> \s* <row>@ix )
		{
			my $rowtime= $1;
			if ($starttime <= $rowtime and $rowtime <= $endtime)
			{
				s@<v> \s* \S+ \s* </v>@<v> NaN </v>@ixg;
			}
		}
		print TEMP $_;
	}
	close TEMP || die "$0: failure closing temp file $TEMPFILE: $!\n";
	rename ($file, "$file.old") || die "$0: failure renaming $file: $!\n";
	my $rc= system "$RRDTOOL restore $TEMPFILE $file";
	warn "$0: WARNING: rrdrestore fails, status $rc.  $file may be corrupt.\n"
		if $rc;
}

unlink $TEMPFILE unless
	exists($ENV{"RRDCUT_DEBUG"}) and $ENV{"RRDCUT_DEBUG"} eq "YES";

Origineel geplaatst door NetRouting



ehh daar vraag je me wat... Buiten het feit dat ik niet zie wat het nut ervan is

Als je backups scheduled op een bepaald tijdstip wordt het backup verkeer niet mee gerekend.

Origineel geplaatst door kilobit


Als je backups scheduled op een bepaald tijdstip wordt het backup verkeer niet mee gerekend.

Kan, maar dan weet die klant dat ook. en dan kan ie in princiepe op dat moment super veel traffic maken zonder dat 't berekent word.

Origineel geplaatst door electric


Kan, maar dan weet die klant dat ook. en dan kan ie in princiepe op dat moment super veel traffic maken zonder dat 't berekent word.

my point exactly.

Kwam iemand anders ook al met een berichtje over backups. Maar er kan altijd verkeer zijn op dat uur, misschien wel pieken heb die je aan het einde van de maand wel op je factuur mag zien .

Hoe zouden jullie dit dan aanpakken?

Origineel geplaatst door serverbilly
Hoe zouden jullie dit dan aanpakken?

De port op de switch van je provider monitoren of laten monitoren door je provider. Intern verkeer zul je daar niet op zien.

Klopt, maar er hangen meerdere servers aan en dan kan ik dat dus niet opsplitsen per server...

Origineel geplaatst door electric


Kan, maar dan weet die klant dat ook. en dan kan ie in princiepe op dat moment super veel traffic maken zonder dat 't berekent word.

Ben benieuwd hoeveel bezoekers van websites het volgende zinnetje lezen en volgen:

"Beste bezoeker, De volgende url is gelinkt naar een zeer groot bestand, gelieve wakker blijven tot 5 uur 's ochtends en dan pas de url klikken. BVD webmaster"

Of je bewaart 1 instantie van traffic gegevens voor controle en 1 om te billen.

Als je als klant misbruik gaat maken van je providers goodwill ben je niet goed bezig.

Origineel geplaatst door serverbilly
Klopt, maar er hangen meerdere servers aan en dan kan ik dat dus niet opsplitsen per server...

snmp draaien op de servers zelf, en dan de NICs pollen.

Gewoon door blijven meten, de backup server grafieken vergelijken met de grafieken van de (web)servers, mocht dat niet overeen komen ga je op d`n duur gewoon kijken wat er rond die tijd over de uplinks gaat, uiteindelijk is er maar 1 of 2 die een uitschieter maakt, (maken) naar de je uplinks toe. Port trunking toepassen van te voren en met je tweede nic in de server gewoon snifferen. Het is maar hoeveel moeite je ervoor wilt doen.

Andere oplossing zou zijn om het transfer verkeer van de backup server per account bij te houden, en dit aan het einde van de maand eraf te halen van het totale gemiddelde.

Er zijn genoeg manieren die je kunt bedenken om dit goed in controlle te houden.

Zelf zou ik kiezen voor een apart backup netwerkje en in de server een 2e nic plaatsen. is wel wat meer moeite en wat omslachtiger maar werkt beter lijkt me.

Origineel geplaatst door electric
Zelf zou ik kiezen voor een apart backup netwerkje en in de server een 2e nic plaatsen. is wel wat meer moeite en wat omslachtiger maar werkt beter lijkt me.

mja zoiets zou ik ook het liefst doen, maar in een 1u server met een remote managemnt kaart erin heb je weinig ruimte voor een 2de nic