Bekijk Volledige Versie : snmp traffic monitoring
Beste Forum leden,
Momenteel ben ik bezig met een traffic meter om mrtg te vervangen.
om te kijken of me programma klopt heb ik zowel mrtg + cacti + eigen creatie draaien.
Mrtg draait gewoon op z'n eigen log files, cacti draait op een RRD database en mijn eigen creatie ook RRD.
Het vreemde nu is dat ik bij alle 3 andere getallen krijg :huh:
Al zijn de verschillen vrij klein vind ik het toch best vreemd.
mrtg
- in: 31.1 kb/s
- out: 46.5 kb/s
cacti
- in: 31.73 kb/s
- out: 43.97 kb/s
eigen
- in: 31.09 kb/s
- out: 45.04 kb/s
aangezien ze alle 3 om de 5 minuten lopen is de enigste reden die ik kan verzinnen is dat ze alle 3 niet precies op het zelfde moment een bepaalde poort meten waardoor je wel enigsins wat verschil krijgt. Maar nu is dus voor mij de vraag, kloppen de getallen van mijn eigen systeem nou wel of niet :)
Misschien dat iemand een andere verklaring heeft of een oplossing of misschien klopt het gewoon?
p.s. mijn systeem is gebouwd met php + rrdtool.
Bij dit soort tools is het zo dat ze natuurlijk niet allemaal op exact hetzelfde moment draaien, al zou je dit instellen, ze draaien dus iets na elkaar...
Ik weet niet op wat voor server dat is, maar als ik deze situatie op een gemiddelde server zou draaien zou er bij een halve seconde al zo'n resultaat kunnen zijn.
Mocht het dat niet zijn, zou ik het eerlijk gezegd ook niet echt weten, komen alle gegevens beschikbaar via snmpd ?
edit: De enige manier om zeker te zijn is denk ik om op exact hetzelfde moment ook een switch poort verkeers uitlezing te doen :D
ik lees met alle 3 een switch uit.
de server waar ik het momenteel op draai is een P3, 1Ghz ( die verder zo goed als nix doet )
// edit
in de crontab draaien ze op deze volgorde:
- cacti
- mrtg
- eigen
Vaxon Networks
23/02/04, 11:16
verander die volgorde eens dan :)
Origineel geplaatst door Wolvie
verander die volgorde eens dan :)
Heeft ook veel zin:p Dan weet ik toch nog niet of het wel of niet klopt? :)
Ziet er prima uit (deze ene meting), ik zou het ook nog even vergelijken bij piekbelasting.
@Skydancer,
voor zo ver ik heb kunnen zien ( draait nu sins vrijdag ) zijn er steeds van die kleine verschillen. met piek belastig ( veel traffic ) zijn de verschillen wel iets groter.
@ everybody
Afgezien van de tijd dat het uitgevoerd word. zou er dan nog iets verkeerd kunnen zijn? ( voor zo ver ik heb kunnen zien nml niet . )
tuurlijk krijg je verschillen als je ze niet op het zelfde moment laat uitlezen. Als je een belasting meet van 50 kbsec en meter 1 heeft 5 min. 50 kbsec en meter 2 heeft 4min 30 50 kbsec en daarna aflopend, kun je er toch niet vanuit gaan dat deze metingen hetzelfde zijn. Welliswaar moet dat in het maand totaal niks uitmaken, die marge moet nihil zijn.
MRTG haalt de info van een interface uit je switch op het moment dat je hem aanroept (geen gemiddelde dus, zoals veel mensen denken!). Het gaat je niet lukken om 3 verschillende programma's op exact hetzelfde moment te laten uit lezen waarschijnlijk.
bedankt allemaal :D
ik ga er dan maar vanuit dat de getallen kloppen, dan kan ik in elk geval door met de rest van het programma :)
Origineel geplaatst door ProServe
MRTG haalt de info van een interface uit je switch op het moment dat je hem aanroept (geen gemiddelde dus, zoals veel mensen denken!). Het gaat je niet lukken om 3 verschillende programma's op exact hetzelfde moment te laten uit lezen waarschijnlijk.
toch is dat niet helemaal waar. Anders zou je elke isp voor de gek kunnen houden. Dan doe ik lekker 50 mbit erover heen, 30 seconden voor de polling schroef je hem terug naar 100kb. Op die manier zou je mooi dataverkeer kunnen sprokkelen. Mrtg haalt nl de hoeveelheid data op van de switch en niet de snelheid, hieraan berekent mrtg wat het gemiddelde is.
Origineel geplaatst door Mikey
toch is dat niet helemaal waar. Anders zou je elke isp voor de gek kunnen houden. Dan doe ik lekker 50 mbit erover heen, 30 seconden voor de polling schroef je hem terug naar 100kb. Op die manier zou je mooi dataverkeer kunnen sprokkelen.
Dat klopt, daar heb je helemaal gelijk in. En dat is wel waar. Probleem is alleen dat je nooit weet wanneer een ISP de counters uitleest.
Mrtg haalt nl de hoeveelheid data op van de switch en niet de snelheid, hieraan berekent mrtg wat het gemiddelde is.
Nee hoor, MRTG haalt netjes de current waardes van een bepaalde interface uit een switch/router. Stel je voor dat een router of switch ook nog eens het dataverkeer bij moest gaan houden. En hoe zou MRTG die data counter moeten resetten via een read only SNMP community?
MRTG heeft netjes een file per interface waar een tijd in staat, en de waarde op dat moment. Niets geen gemiddelde of wat dan ook.
( hmm, heb een leuke discussie gestart zo :p )
een switch blijft gewoon optellen wat er aan traffic door gaat.
mrtg logt dat en zet per tijd steeds die traffic bij en rekent dan zelf het verschil uit :)
Origineel geplaatst door electric
een switch blijft gewoon optellen wat er aan traffic door gaat.
Als je me verhaal goed gelezen hebt, doet een switch dat dus niet.
Origineel geplaatst door ProServe
Als je me verhaal goed gelezen hebt, doet een switch dat dus niet.
ik heb bij 2 switches ( hp & cisco ) iig niet gezien dat zodra ie uit gelezen is de counters weer op 0 zet hoor :)
Origineel geplaatst door electric
ik heb bij 2 switches ( hp & cisco ) iig niet gezien dat zodra ie uit gelezen is de counters weer op 0 zet hoor :)
idd, 3com idem
Port: 3 Port Speed: 100Mbps HD Auto
Received Stats Transmit Stats
-------------- --------------
Unicast Packets: 666820 Unicast Packets: 310023324
Non Unicast Packets: 5195 Non Unicast Packets: 193225472
Octets: 168970208 Octets: 12639283
Fragments: 20476 Collisions: 20445
Errors
------
Undersize: 20414 Oversize: 0
CRC Error: 0 Jabbers: 0
Packet Size Analysis
--------------------
64 Octets: 294709265 256 to 511 Octets: 3298020
65 to 127 Octets: 195591208 512 to 1023 Octets: 1661045
128 to 255 Octets: 4603478 1024 to 1518 Octets: 4037381
Origineel geplaatst door electric
ik heb bij 2 switches ( hp & cisco ) iig niet gezien dat zodra ie uit gelezen is de counters weer op 0 zet hoor :)
Dat klopt, want ze lezen de huidige waarde uit. Dan hoeft er niets gereset te worden. (zie andere posting)
Origineel geplaatst door ProServe
Dat klopt, want ze lezen de huidige waarde uit. Dan hoeft er niets gereset te worden. (zie andere posting)
mrtg leest inderdaad de huidige waarde af, maar de switch zelf blijft gewoon door tellen :)
Dat zijn dan andere counters, die niets met de counters te maken hebben die MRTG uitleest.
Origineel geplaatst door ProServe
Dat zijn dan andere counters, die niets met de counters te maken hebben die MRTG uitleest.
stug volhouden :D , laat maar zien dan :)
ik zal ff iets aanhalen van de mrtg site "MRTG consists of a Perl script which uses SNMP to read the traffic counters of your routers"
zal het maar in nederlands onder zetten voordat we daar weer gebakelij over krijgen, hij leest de verkeers tellers uit ! en dus niet de snelheid.
Origineel geplaatst door ProServe
Dat klopt, daar heb je helemaal gelijk in. En dat is wel waar. Probleem is alleen dat je nooit weet wanneer een ISP de counters uitleest.
lang leve de mrtg index file :) , daarin staat de laatste poll tijd, met beetje f5 drukken kun je aardig recht schatten. + meer mogelijke mogelijkheden om erachter te komen
Origineel geplaatst door Mikey
lang leve de mrtg index file :) , daarin staat de laatste poll tijd, met beetje f5 drukken kun je aardig recht schatten. + meer mogelijke mogelijkheden om erachter te komen
Dan moet je alleen nog even de tijd van je server gelijkzetten met die van je hoster. Als je zover wilt gaan om onder je traffic kosten uit te komen, ben je een beetje verkeerd bezig naar mijn idee.
Origineel geplaatst door Mikey
stug volhouden :D , laat maar zien dan :)
Mij maakt het niet zoveel uit hoor, wat je gelooft. Ik heb genoeg ervaring om te weten dat dit zo is :) Bewijs het tegendeel maar.
Uhm... het leek mij ook duidelijk dat MRTG steeds momentopnames van SNMPD pakt.
Naar mijn mening is dit bewijs genoeg
Overigens in MRTG ook zo in te stellen om elke 30minuten te controleren via een CRONJOB. Je zult andere averages zien als je om de 5 minuten controleert dan om de 60 minuten.
Dit heeft ermee te maken dat hij niet de averages van de hele dag neemt, maar van wat hij heeft gecontroleerd.
Ook weet MRTG helemaal niet hoe vaak hij zelf wordt uitgevoerd.
Origineel geplaatst door ProServe
Mij maakt het niet zoveel uit hoor, wat je gelooft. Ik heb genoeg ervaring om te weten dat dit zo is :) Bewijs het tegendeel maar.
http://www.webhostingtalk.nl/showthread.php?s=&postid=316492#post316492
http://people.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg.html
ik vind het een beetje vreemd dat je zelf absoluut met geen hard feit komt. Graag wil ik en denk andere ook wel weten hoe het nu precies zit, en mocht ik er langs zitten zou ik zeker niet verlegen zijn omdat toe te geven.
mocht het kloppen, dan zijn tevens ook de rekening die je krijgt van je isp ongeldig. Want als hij mrtg alleen pieken meet is de waarde niet kloppend. Dan is mrtg gewoon geen correct meet tool, en niet eens goed genoeg om een schatting te geven.
Origineel geplaatst door Mikey
mocht het kloppen, dan zijn tevens ook de rekening die je krijgt van je isp ongeldig. Want als hij mrtg alleen pieken meet is de waarde niet kloppend. Dan is mrtg gewoon geen correct meet tool, en niet eens goed genoeg om een schatting te geven.
Goed, dan mag jij elke isp/carrier in de wereld gaan vertellen dat ze wat anders mogen gaan verzinnen. De meeste van onze klanten worden trouwens afgerekend op echt verbruikt verkeer, afleesbaar per ip.
Origineel geplaatst door Mikey
http://www.webhostingtalk.nl/showthread.php?s=&postid=316492#post316492
http://people.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg.html
ik vind het een beetje vreemd dat je zelf absoluut met geen hard feit komt. Graag wil ik en denk andere ook wel weten hoe het nu precies zit, en mocht ik er langs zitten zou ik zeker niet verlegen zijn omdat toe te geven.
Wat zie jij als verkeers tellers en snelheid tellers?
Als je bewijs wilt hoe het werk, mail de maker van MRTG, of check de source. Waar denk je dat de cuin en cuout variabele voor staat? Misschien current in en current out?
Origineel geplaatst door ProServe
Wat zie jij als verkeers tellers en snelheid tellers?
Als je bewijs wilt hoe het werk, mail de maker van MRTG, of check de source. Waar denk je dat de cuin en cuout variabele voor staat? Misschien current in en current out?
wanneer kom je nou eens met een concreet stukje text van het net ofzo ?
Volgens mij leest MRTG de gemiddelden waardes uit.
5 minuten 100 Mbit
5 minuten 10 Mbit
Dan geeft MRTG aan:
100+100+100+100+100+10+10+10+10+10 = 550 : 10 = 55 MBit.
MRTG gaat per 5 minuten en daar het gemiddelde bits/secs
Greets
Desmond
Wat desmond hierbboven beschrijft ben ik het compleet mee eens.
dit houd in:
4min 80 mbit
1 min 30 mbit
zou dan gem. moeten zijn : 80 + 80 + 80 + 80 + 30 /5 = 70mbit.
En niet zoals eerder beschreven werd dat als mrtg zijn data verzameld en er op dat moment 80 mbit over de lijn gaat dat er dan ook gem 80mbit overheen gaat. Terwijl er maar 4 min 80 mbit is en de rest minder.
Maar we wachten op een concreet antwoord van ProServe, die weet namelijk hoe het zit
therealchrizz
24/02/04, 20:36
How MRTG Works
http://www.nwc.com/1406/1406ws1.html
MRTG and Load Balancers
http://vegan.net/MRTG/countergauge.php
Eerste geeft redelijk wat uitleg over de methode die MRTG gebruikt. Zoals jullie weten haalt MRTG, Cacti of whatever de gegevens op op RRDTOOL en zet deze om naar een graph; die methode wordt hier nader besproken.
Wellicht dat dit meer duidelijkheid kan bieden..
Origineel geplaatst door therealchrizz
How MRTG Works
http://www.nwc.com/1406/1406ws1.html
@ ProServe
"Here's how MRTG works: It periodically collects two values using SNMP and displays them over time via an HTML page and PNG images. It does this by using SNMP GETs to retrieve SNMP counters--ifInOctets (OID 1.3.6.1.2.1.2.2.1.10) and ifOutOctets (1.3.6.1.2.1.2.2.1.16)--that record the number of bytes coming into (ifInOctetes) and out of (ifOutOctets) a single interface.
Toch jammer dat de persoon die hier het tegendeel beweerde hier niet meer op reageerd. Ik denk dat inmiddels wel meerdere mensen willen weten hoe zij hun dataverkeer dan meten. Heb desbetreffende een PB gestuurd of hij nog wil reageren, maar ben bang dat dat er niet meer in zit :(