Bekijk Volledige Versie : dataverkeer berekenen
Ik zit misschien met een probleem. Sinds kort gebruikt KDISS een
eigen script op dataverkeer te berekenen. Wij doen dit aan de hand
van octets die wij elke 5 minuten uit de switch halen. Naar mij weten
is deze berekening goed. Maar sommige klanten twijfelen hieraan. Nu
wil ik graag weten hoeveel dataverkeer jullie berekenen in Gigabyte
uit de onderstaande tabel en hoe jullie tot deze berekening komen.
Alvast bedankt!
ID DATE TIME INOCTETS OUTOCTETS
158 2005-08-03 21:45:06 313945418 4231385190
158 2005-08-03 21:50:05 353294562 4241456917
158 2005-08-03 21:55:06 395814694 4253693111
158 2005-08-03 22:00:06 426376665 4262348846
158 2005-08-03 22:05:06 463371128 4272694971
158 2005-08-03 22:10:06 500716321 4285784220
158 2005-08-03 22:15:06 536511047 3178451
158 2005-08-03 22:20:12 566992285 7953563
158 2005-08-03 22:25:09 600921772 17441469
158 2005-08-03 22:30:06 637640653 25302274
158 2005-08-03 22:35:07 693868884 1157359650
158 2005-08-03 22:40:06 729692190 1593113277
158 2005-08-03 22:45:06 774521902 1601748592
158 2005-08-03 22:50:06 807514440 1609971640
158 2005-08-03 22:55:06 831845113 1616150547
158 2005-08-03 23:00:06 852200796 1621773472
158 2005-08-03 23:05:10 872457172 1626487541
Origineel geplaatst door KDIS
Ik zit misschien met een probleem. Sinds kort gebruikt KDISS een
eigen script op dataverkeer te berekenen. Wij doen dit aan de hand
van octets die wij elke 5 minuten uit de switch halen. Naar mij weten
is deze berekening goed. Maar sommige klanten twijfelen hieraan. Nu
wil ik graag weten hoeveel dataverkeer jullie berekenen in Gigabyte
uit de onderstaande tabel en hoe jullie tot deze berekening komen.
Alvast bedankt!
ID DATE TIME INOCTETS OUTOCTETS
158 2005-08-03 21:45:06 313945418 4231385190
158 2005-08-03 21:50:05 353294562 4241456917
158 2005-08-03 21:55:06 395814694 4253693111
158 2005-08-03 22:00:06 426376665 4262348846
158 2005-08-03 22:05:06 463371128 4272694971
158 2005-08-03 22:10:06 500716321 4285784220
158 2005-08-03 22:15:06 536511047 3178451
158 2005-08-03 22:20:12 566992285 7953563
158 2005-08-03 22:25:09 600921772 17441469
158 2005-08-03 22:30:06 637640653 25302274
158 2005-08-03 22:35:07 693868884 1157359650
158 2005-08-03 22:40:06 729692190 1593113277
158 2005-08-03 22:45:06 774521902 1601748592
158 2005-08-03 22:50:06 807514440 1609971640
158 2005-08-03 22:55:06 831845113 1616150547
158 2005-08-03 23:00:06 852200796 1621773472
158 2005-08-03 23:05:10 872457172 1626487541
IN: 558511754 OUT: 1690069647
IN: 0.520154604688287 Gbyte
OUT: 1.57400001492351 Gbyte
Ik heb het perl script wat het voor me gebouwd heeft geattached.
Cliff hardstikke bedankt voor je tijd en uitleg. Ik heb dit gecontroleerd met onze eigen script en ik kon concluderen dat wij geen fouten in onze berekening gemaakt hebben. Ik weet het nu zeker dat het script goed is en dat de ik twijfel bij sommige klanten kan weg nemen. Nogmaals Bedankt! :W: :D
Waarschijnlijk gebruiken je klanten meting van directadmin, cpanel ed. hier kan je meestal wel een 25% bij optellen om tot het werkelijke gebruik te komen.
Installeer eens vnstat op enkele servers, die meet het verbruik van de server. Elk bitje wat door het lijntje gaat wordt gecheckt. Doen wij ook, en volgens mij komt het (de laatste keer dat ik keek), wel overeen met jullie berekeningen :).
Jochem
Er bestond bij enkele klanten twijfels, maar door deze topic worden de twijfels bij deze klanten weg gehaald. Daarnaast hebben net zoals je voorstelde Jochem deze waardes gecontroleerd met enkele klanten. Dit klopte! Wij weten nu dat wij 100% kunnen vertrouwen op onze eigen statistieken. MRTG en andere scripts vroegen te veel CPU tijd en wij konden te weinig met de waardes die MRTG opsloeg.
Je haalt de data gewoon op met SNMP in PHP oid?
Wij zitten namelijk met het probleem dat cacti nogal zwaar is.
Hoe doen jullie het met bijv 95%?
Dit gedeelte heb ik nog niet klaar, maar je kunt aan de hand van de octets berekenen wat de gemiddelde bandbreedte was voor elke 5 minuten omdat wij elke 5 minuten de waarde uit onze switches halen.
Je zou dus via die berekening de 95% moeten kunnen berekenen. Ik ga er binnen kort mee bezig, dan ga ik dit uitwerken. Misschien dat iemand anders op dit forum een voorbeeld script al heeft. Dit zou wel een hoop werk schelen. :D
Er klopt overgins ook iets niet op jullie website:
http://www.kdiss.com/content.php?site=1&lang=1&id=10
5u + 25 GB + none = 52 euro
Als je dan vervolgens volume 5000 selecteerd wordt het:
5u + 5000 GB + none = 732
Maar ga je dan weer terug naar 25 krijg je:
5u + 25 GB + none = 418
:o
Bovenstaande werkt ook in je voordeel bij (bijvoorbeeld) 2u ;)
Origineel geplaatst door KDIS
Dit gedeelte heb ik nog niet klaar, maar je kunt aan de hand van de octets berekenen wat de gemiddelde bandbreedte was voor elke 5 minuten omdat wij elke 5 minuten de waarde uit onze switches halen.
Je zou dus via die berekening de 95% moeten kunnen berekenen. Ik ga er binnen kort mee bezig, dan ga ik dit uitwerken. Misschien dat iemand anders op dit forum een voorbeeld script al heeft. Dit zou wel een hoop werk schelen. :D
95% in perl al werkend gekregen ?
Origineel geplaatst door Mikey
95% in perl al werkend gekregen ?
Dat is redelijk triviaal :)
Het geattachede perl script rukt 95% uit RRD files.
Als ik het goed heb kan de nieuwste RRD dit in 1 keer uitrekenen zonder dit soort scripts.
Origineel geplaatst door Merlijn
Als ik het goed heb kan de nieuwste RRD dit in 1 keer uitrekenen zonder dit soort scripts.
heb beetje zitten bladeren maar kan het alleen vinden als een oude TODO, voorderest niks op de change list.
Origineel geplaatst door Cliff
Dat is redelijk triviaal :)
Het geattachede perl script rukt 95% uit RRD files.
Heb de jouwe ietswat aangepast:
Usage:
95.pl -f <rrdFile> -t <timeSeconds>
Description:
-f rrd file to read in
-t Set count back time from now in seconds
Output:
Output is in 95th Percentile mbit/s
version:
0.02a
Kijk hier even naar (zoek op Percent). Doet als het goed is wat je wilt.
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/doc/rrdgraph_rpn.en.html
Origineel geplaatst door Merlijn
Kijk hier even naar (zoek op Percent). Doet als het goed is wat je wilt.
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/doc/rrdgraph_rpn.en.html
Hmmzz zal er eens mee gaan stoeien, heb nog een keer een wijziging aangebracht aan dat perl bestand en werkt nu met de volgende werking:
Usage:
95.pl -f <rrdFile> -s <startTimeSeconds> -e <endTimeSeconds>
Description:
-f rrd file to read in
-s Start timestamp
-e End timestamp
Output:
Output is in 95th Percentile mbit/s
version:
0.02a
Wij zijn aan het overstappen op RTG, dat werkt imho beter.
Wij draaien ook al een klein jaartje RTG. Een groot genot.
Dan kun je dit soort zaken gewoon met SQL queries doen, veel flexibeler.
Origineel geplaatst door Wido
Wij zijn aan het overstappen op RTG, dat werkt imho beter.
lekker onderbouwde mening :rolleyes:
Origineel geplaatst door Mikey
lekker onderbouwde mening :rolleyes: inderdaad.
Ik bedoel daarmee het volgende.
De data staat allemaal opgeslagen in een MySQL database, hierdoor kan je gemakkelijk met PHP/Perl data opvragen en berekeningen mee uitvoeren.
Tevens is RTG zeeer snel met pollen.
Origineel geplaatst door Wido
inderdaad.
Ik bedoel daarmee het volgende.
De data staat allemaal opgeslagen in een MySQL database, hierdoor kan je gemakkelijk met PHP/Perl data opvragen en berekeningen mee uitvoeren.
Tevens is RTG zeeer snel met pollen.
Je hebt zeker een punt met de combinatie mysql, maar vraag me af of jouw php parser sneller output geeft dan dat je dit door perl & rddtool laat doen. Daarentegen is cacti mocht je nie gebruik maken van cactid met veel hosts erg traag... Ik ben zelf aan het stoeien geweest icm php & perl & rrd files en het bevalt me prima. Ik laat cacti nog er langs draaien maar zal wel eruit gaan ivm. performance.
Origineel geplaatst door Mikey
Je hebt zeker een punt met de combinatie mysql, maar vraag me af of jouw php parser sneller output geeft dan dat je dit door perl & rddtool laat doen. Daarentegen is cacti mocht je nie gebruik maken van cactid met veel hosts erg traag... Ik ben zelf aan het stoeien geweest icm php & perl & rrd files en het bevalt me prima. Ik laat cacti nog er langs draaien maar zal wel eruit gaan ivm. performance.
Wij draaien nu inderdaad cacti en dat is zeer traag.
Vooral van RTG is dat we zeer gemakkelijk elke nacht een totaal sommetje van het aantal gb kunnen opslaan.
Grafieken kan je met RTG genereren via een bijgeleverd C++ programma.
Origineel geplaatst door Wido
Wij draaien nu inderdaad cacti en dat is zeer traag.
Vooral van RTG is dat we zeer gemakkelijk elke nacht een totaal sommetje van het aantal gb kunnen opslaan.
Grafieken kan je met RTG genereren via een bijgeleverd C++ programma.
Kijk in je PB, dan zie je dat je met rrd files ook sommetjes kunt maken ;)... Ik zal er zelf ook tzt eens mee gaan stoeien.
Origineel geplaatst door Mikey
Kijk in je PB, dan zie je dat je met rrd files ook sommetjes kunt maken ;)... Ik zal er zelf ook tzt eens mee gaan stoeien.
Ik zie het.
Meerdere wegen leiden naar Rome :)
Cliff: je moet wel ipv Average de MAXIMUM values pakken uit RRD. Anders komt je 95% te laag uit (vooral van belang als je 95-percentiles gaat uitrekenen over een periode van een maand bijv.)
Origineel geplaatst door Merlijn
Cliff: je moet wel ipv Average de MAXIMUM values pakken uit RRD. Anders komt je 95% te laag uit (vooral van belang als je 95-percentiles gaat uitrekenen over een periode van een maand bijv.)
Geen idee, ik gebruik dit script niet, het is enkel een voorbeeld script wat de methode om te rekenen laat zien. Uiteraard moet voor samengevatte data het maximum gepakt worden, alhoewel dat nog steeds niet correct 95% berekend. Ideaal zou een complete lijst van 5 minute averages zijn over een veel langere periode (dus niet die samengetrokken worden door RRD/MRTG na X periode).
Origineel geplaatst door Cliff
Geen idee, ik gebruik dit script niet, het is enkel een voorbeeld script wat de methode om te rekenen laat zien. Uiteraard moet voor samengevatte data het maximum gepakt worden, alhoewel dat nog steeds niet correct 95% berekend. Ideaal zou een complete lijst van 5 minute averages zijn over een veel langere periode (dus niet die samengetrokken worden door RRD/MRTG na X periode).
Script komt voor op de rrd-users mailing list.
@Merlijn
Misschien dat je eens probeert de waarde te verander van Average naar MAX, ik wil niet vervelend doen, maar mijn 95% waarde worden bijna allemaal verdubbeld of een x factor vergroot. Als je het perl script bekijkt zie je dat ze na alles geladen te hebben alles sorteren en dan pas de 5% cutten. Volgens mij geeft dit wel degelijk een correcte waarde.
MAX is toch echt correct. Gebruik het zelf en komt ook overeen bij onze transit partijen.
Een ruwe versie van wat ik vroeger heb gebruitk is attached.