[RC5/OGR] alternatief voor ppstats

[Wortelsoep]

PowerCow: dat met inloggen heb ik ook. Beetje vreemd, maar niet kritisch.

[ramonp]

Ok, ik heb weer een aantal bugs / wensen aangepast

• Het probleem met het inlezen van 'pproxyogrYYYYMMDD.log' ipv 'pproxyogrYYYYMMDD.log'.
  Ik heb gewoon een extra veld in database gemaakt, zodat je voor ieder project zelf de bestandsnaam kan kiezen. Dit is aan te passen via de admin login.
• Het importeren van log-files.
  Ik heb een nieuw bestand gemaakt 'updatelog.php' en die importeerd logbestanden van de proxy vanaf de opgegeven datum tot gisteren (kan evt. worden aangepast). Het importeren gaat per project.
  Ik heb het getest met log-files van een aantal maanden in een LAN. Dat ging goed. Maar ik weet niet hoe het zit als er log-files van een aantal jaar zijn. I.v.m. time-outs.
  Daarom heb ik het zo gemaakt dat je de einddatum (standaard gisteren) kan aanpassen.

Ik zal ook nog even kijken naar dat 2x inloggen. Maar dat vind ik niet zo belangrijk

[Wortelsoep]

Staat het al online?

[ramonp]

wilko2 schreef op vrijdag 07 oktober 2005 @ 11:24:
Staat het al online?

jep, ik zet het eerst online voordat ik het hier post

[stappel_]

ramonp schreef op vrijdag 07 oktober 2005 @ 11:02:
• Het importeren van log-files.
Ik heb een nieuw bestand gemaakt 'updatelog.php' en die importeerd logbestanden van de proxy vanaf de opgegeven datum tot gisteren (kan evt. worden aangepast). Het importeren gaat per project.
Ik heb het getest met log-files van een aantal maanden in een LAN. Dat ging goed. Maar ik weet niet hoe het zit als er log-files van een aantal jaar zijn. I.v.m. time-outs.
Daarom heb ik het zo gemaakt dat je de einddatum (standaard gisteren) kan aanpassen.
[/list]

gewoon bovenin je updatelog.php file hetvolgende zetten

code:

set_time_limit(0);

en nooit meer last van een timeout

[ramonp]

stappel_ schreef op vrijdag 07 oktober 2005 @ 14:12:
[...]

gewoon bovenin je updatelog.php file hetvolgende zetten

code:

set_time_limit(0);

en nooit meer last van een timeout

Ik heb het er ingeplaatst, alleen kan ik het niet testen omdat ik maar van een paar maanden logs heb.

Ik heb ook nog het login probleem opgelost. Nu hoef je maar 1x in te loggen

[Wortelsoep]

Ik ben nu al een flinke tijd bezig met updatelog.php en het lijkt perfect te werken MySQL heeft het er alleen vrij zwaar mee, hij is nu al ruim een uur aan het draaien op full load maar dat is niet erg. Er staan nu ruim 22000 blokjes in, en hij zit pas in juni 2004. Dus hij moet nog wel even

Het dubbelcheck-probleem heb ik even heel banaal opgelost door gewoon geen primary key in de tabel te hebben. Of dat problemen oplevert merk ik later wel.

[Webgnome]

wilko2 schreef op vrijdag 07 oktober 2005 @ 14:52:
Ik ben nu al een flinke tijd bezig met updatelog.php en het lijkt perfect te werken MySQL heeft het er alleen vrij zwaar mee, hij is nu al ruim een uur aan het draaien op full load maar dat is niet erg. Er staan nu ruim 22000 blokjes in, en hij zit pas in juni 2004. Dus hij moet nog wel even

Het dubbelcheck-probleem heb ik even heel banaal opgelost door gewoon geen primary key in de tabel te hebben. Of dat problemen oplevert merk ik later wel.

Ik weet niet hoeveel blocks het toaal zijn maar ga er vanuit dat het we iets langer dan een uur kan duren Mysql is snel maar als er veel inserts moeten worden gedaan dat vind geen enkele dbase leuk (zeker niet als er ook nog eens een hoop indexen op hangen.. die vertragen het inserts en bji veel inserts ga je dat goed merken )

offtopic:
als ik poep praat hoor ik het wel

[ Voor 11% gewijzigd door Webgnome op 07-10-2005 18:52 ]

[Loco-Motiv]

wilko2 schreef op vrijdag 07 oktober 2005 @ 14:52:
Ik ben nu al een flinke tijd bezig met updatelog.php en het lijkt perfect te werken MySQL heeft het er alleen vrij zwaar mee, hij is nu al ruim een uur aan het draaien op full load maar dat is niet erg. Er staan nu ruim 22000 blokjes in, en hij zit pas in juni 2004. Dus hij moet nog wel even

Het dubbelcheck-probleem heb ik even heel banaal opgelost door gewoon geen primary key in de tabel te hebben. Of dat problemen oplevert merk ik later wel.

autocomit heb je uitstaan?
Zo ja, dan kan je bv om de 100 block comitten (check wel ff of je comit buffer groot genoeg is )

[MeneerKrab]

misschien nog handig om de link naar je downlaod in je signature te zetten Nu moet ik altijd ff een pagina terug browsen. Ga de nieuwe versieo ok ff proberen.

[ramonp]

PowerCow schreef op zaterdag 08 oktober 2005 @ 12:34:
misschien nog handig om de link naar je downlaod in je signature te zetten Nu moet ik altijd ff een pagina terug browsen. Ga de nieuwe versieo ok ff proberen.

done

[Witlof]

Wilde het vandaag even proberen maar volgens mij werkt het niet met PHP5 of wel

[Loco-Motiv]

Witlof schreef op zondag 09 oktober 2005 @ 22:30:
Wilde het vandaag even proberen maar volgens mij werkt het niet met PHP5 of wel

Ik heb een tijdje geleden de laatste versie van Mythor geprobeerd (0.175?) op PHP5, maar dat wilde bij mij niet lekker lopen.

Ben toen maar eens gaan kijken om zelf een systeempje te bouwen, maar dat idee is een beetje gestrand

[ramonp]

Staat ook op zijn website, dat het niet getest is met PHP5.

Zelf ben ik nog niet met PHP5 bezig, dus heb ik het ook niet getest.

[Witlof]

Sja, maar er zit een verschil tussen niet getest hebben en niet werken

[Witlof]

Heb er nog niet echt naar gekeken maar op de gehoste server staan de stats nu en werken. Nu heb ik alleen een vraagje. Is het mogelijk om in te stellen dat de OGR logs in een andere dir staan dan de rc5 logs? Heb namelijk aparte directory's aangemaakt voor het overzicht en daarin staan de logfiles met de datum als naam.

Uhm, als ik nu een IP-adres aan een user koppel en dan de update weer laat lopen staan er 2x zoveel blokjes onder de IP-adressen check. Heb er 1200 geflushed op het ene adres en er staan er 2400

Zag ook de error maar dat moet op te lossen zijn door de logs te laten verwijzen naar de hoofddir van de proxy en dan bij rc5 en ogr een toevoeging maken van iets als ogrp2/ en bij rc5 iets van rc572/ denk ik.

Oh, en hoe zat het met die error van OGR? Die datum klopt niet echt

File error: The log file: /home/proxy/ogrp2/20050924.log does not exist.

rc572
Processed lines: 0
New filepointer: 132725
Stats update: 0.0022158622741699
Email claims: 0.00018310546875
IP claims: 0.012564897537231
Plot all gfx: 0.067373037338257
Total parce time: 0.079977989196777

En waar komt die [...] vandaan bovenaan de stats achter de teamnaam

En als laatste vraag Waarom kan ik het password niet aanpassen via de website?

[ Voor 74% gewijzigd door Witlof op 11-10-2005 17:23 ]

[ramonp]

Witlof schreef op dinsdag 11 oktober 2005 @ 16:33:
Heb er nog niet echt naar gekeken maar op de gehoste server staan de stats nu en werken. Nu heb ik alleen een vraagje. Is het mogelijk om in te stellen dat de OGR logs in een andere dir staan dan de rc5 logs? Heb namelijk aparte directory's aangemaakt voor het overzicht en daarin staan de logfiles met de datum als naam.

Uhm, als ik nu een IP-adres aan een user koppel en dan de update weer laat lopen staan er 2x zoveel blokjes onder de IP-adressen check. Heb er 1200 geflushed op het ene adres en er staan er 2400

Zag ook de error maar dat moet op te lossen zijn door de logs te laten verwijzen naar de hoofddir van de proxy en dan bij rc5 en ogr een toevoeging maken van iets als ogrp2/ en bij rc5 iets van rc572/ denk ik.

Oh, en hoe zat het met die error van OGR? Die datum klopt niet echt

[...]


En waar komt die [...] vandaan bovenaan de stats achter de teamnaam

En als laatste vraag Waarom kan ik het password niet aanpassen via de website?

Dat van die verschillende mappen voor OGR en RC5 is op zich wel makkelijk te maken.

Dat verhaal van dat IP adres, zou ik even moeten testen.

Die error met OGR is op te lossen door de update nog een keer te doen,
dan wordt er namelijk naar de logfile van een dag erna gekeken.
Maar dat werkt bij jou versie nog niet goed, omdat ie na bv 30-09-2005 naar 31-09-2005 ipv 01-10-2005 gaat.
Dat heb ik inmiddels opgelost, maar die versie staat nog niet online.

Die [...] is in mijn laatste versie vervangen door het projectnaam, OGR-25 of RC5-72.
Dus je krijgt dan Teamnaam [OGR-25]

Naar dat password moet ik even kijken.

Ik zal morgen mijn laatste versie even online zetten, dan kan je weer even voorruit.

[Witlof]

OK! Snelle reactie trouwens

[MeneerKrab]

hij is echt snel.

Nog even iets. Ik heb nooit zin om scheduled tasks te maken kan er iets inkomen een knopje van update ofzo? zodat de bezoeker zelf een update kan regelen en daarna direct weer up 2 date stats heeft. misschien iets met een timer erin? bij mij thuis doet hij al een seconde over een 100wu's, maar op een teamproxy misschien langer, zodat niet verschillende updates door elkaar gaan lopen.

[ Voor 30% gewijzigd door MeneerKrab op 11-10-2005 22:12 ]

[Loco-Motiv]

PowerCow schreef op dinsdag 11 oktober 2005 @ 22:12:
hij is echt snel.

Nog even iets. Ik heb nooit zin om scheduled tasks te maken kan er iets inkomen een knopje van update ofzo? zodat de bezoeker zelf een update kan regelen en daarna direct weer up 2 date stats heeft. misschien iets met een timer erin? bij mij thuis doet hij al een seconde over een 100wu's, maar op een teamproxy misschien langer, zodat niet verschillende updates door elkaar gaan lopen.

Gewoon altijd de update draaien bij het openen van de hoofdpagina
(heb je (bijna) altijd wel up2date stats)

En hoe vaker je de update doet, hoe minder hij hoeft te verwerken als het goed is
(hij loopt toch niet elke keer alles af zoals ppstats??)

[Witlof]

Dat van die verschillende mappen voor OGR en RC5 is op zich wel makkelijk te maken.

Heb het al opgelost door er <mapnaam>/ voor te zetten. Werkt perfect

Dat verhaal van dat IP adres, zou ik even moeten testen.

Het leek 'opeens' opgelost te zijn Wat nu nog wel prettig is om een IP-adres van een member te kunnen verwijderen en onder een andere naam neer te zetten zodat alle blokjes ook daarbij komen te staan. Dus dat de blokjes weer 'vrij komen' onder de naam unknown. Had nu iets te snel IP-adressen toegevoegd waardoor er 1 onder admin kwam te staan. Na veel pielen is dat IP-adres onder admin weg en onder de juiste member gezet. Echter blijven de blokjes in de stats onder admin staan doordat deze 'geclaimed' zijn

Die error met OGR is op te lossen door de update nog een keer te doen,
dan wordt er namelijk naar de logfile van een dag erna gekeken.
Maar dat werkt bij jou versie nog niet goed, omdat ie na bv 30-09-2005 naar 31-09-2005 ipv 01-10-2005 gaat.
Dat heb ik inmiddels opgelost, maar die versie staat nog niet online.

Hoe zit het met de 'error' dat er geen logfile beschikbaar is? Daardoor wordt niets geupdate. Ook niet als je dus IP-adressen aan members koppelt en de stats update.

Die [...] is in mijn laatste versie vervangen door het projectnaam, OGR-25 of RC5-72.
Dus je krijgt dan Teamnaam [OGR-25]

OK, dat is dan duidelijk

Naar dat password moet ik even kijken.

Mooi, anders komt er straks iemand langs die leuk denkt te zijn en alles weggooid, aanpast of gewoon vern**kt

Ik zal morgen mijn laatste versie even online zetten, dan kan je weer even voorruit.

En waar staat die

[MeneerKrab]

Witlof schreef op woensdag 12 oktober 2005 @ 15:54:
en waar staat die

geduld. Hij heeft hem nog niet online gezet iig. De dag duurt nog langer dan deze 16uur en 20min.

[stappel_]

ik heb nog wat aanpassingen voor hem. Ik heb ze verzamelt in de volgende file
http://susreport.perot.nl/phpstatnotes.txt

[Witlof]

PowerCow schreef op woensdag 12 oktober 2005 @ 16:20:
[...]

geduld. Hij heeft hem nog niet online gezet iig. De dag duurt nog langer dan deze 16uur en 20min.

Sja, je moet wat als je niets te doen hebt

stappel_ schreef op woensdag 12 oktober 2005 @ 16:38:
ik heb nog wat aanpassingen voor hem. Ik heb ze verzamelt in de volgende file
http://susreport.perot.nl/phpstatnotes.txt

[MeneerKrab]

wat ik me ook afvraag is waarom onder de current stats nog wat van die grijze balken zitten en daar staat history... Deze doet verder niets bij mij.

[stappel_]

PowerCow schreef op woensdag 12 oktober 2005 @ 18:14:
wat ik me ook afvraag is waarom onder de current stats nog wat van die grijze balken zitten en daar staat history... Deze doet verder niets bij mij.

Dat is de plek waar normaal een plaatje staat (team-rc572.png). Echter is deze functie stuk en komt er dan een lege .png te staan in de output directory. Firefox laat dan niks zien, in IE zie je een rood kruisje.

[MeneerKrab]

stappel_ schreef op woensdag 12 oktober 2005 @ 18:34:
[...]

Dat is de plek waar normaal een plaatje staat (team-rc572.png). Echter is deze functie stuk en komt er dan een lege .png te staan in de output directory. Firefox laat dan niks zien, in IE zie je een rood kruisje.

oke. Dat verklaart waarom ik op het werk wel een kruisje zag en thuis dus weer niet.
Dat is de gnuplot functie zie ik.

[Witlof]

Jep, de persoon die de server beheert bij ons zei al dat het een beetje brakke coding was en heeft het verholpen. Hoe weet ik niet maar wij hebben wel grafiekjes zie: http://proxy.divisionbrabant.nl

Zal eens vragen of hij kan zeggen waar het mis ging

[ Voor 23% gewijzigd door Witlof op 12-10-2005 19:12 ]

[ramonp]

stappel_ schreef op woensdag 12 oktober 2005 @ 16:38:
ik heb nog wat aanpassingen voor hem. Ik heb ze verzamelt in de volgende file
http://susreport.perot.nl/phpstatnotes.txt

Bovenstaande aanpassingen heb ik nog niet aangebracht,
maar wel wat andere dingen. Ik zal morgen wel even naar bovenstaande kijken.

Ik heb ook het e.e.a. op m'n website aangepast, zodat je kan zien wat er veranderd is t.o.v. de vorige versie.

Maar goed, de nieuwe versie staat online (zie ondertitel)

Dit is er in veranderd:
- Mogelijk om password te wijzigen.
- Proxystatus bij Serverinfo werkt nu goed.
- Update (suball.php) werkt nu goed wanneer er een log-file ontbreekt.
- Mogelijk om het hele path van de log-files op te geven.
- [...] vervangen door projectnaam
- Menuitem Total by hour toegevoegd, zodat te zien is op welke uren men flusht.
- Html aangepast, zoveel mogelijk Valid HTML 4.01 gemaakt.
- E.e.a. aangepast bij Stats stats.

Edit:
De gnuplot functie werkt gewoon. Maar onder Windows moet je dat met de hand doen, onder Linux (als het goed geïnstalleerd is) werk het gewoon goed.

[ Voor 8% gewijzigd door ramonp op 12-10-2005 19:17 ]

[stappel_]

ramonp schreef op woensdag 12 oktober 2005 @ 19:15:
Edit:
De gnuplot functie werkt gewoon. Maar onder Windows moet je dat met de hand doen, onder Linux (als het goed geïnstalleerd is) werk het gewoon goed.

niet helemaal, hij zeurt vaak over een lege xrange en maakt dan een lege output file aan. (ja onder Linux)

[ Voor 3% gewijzigd door stappel_ op 12-10-2005 19:52 ]

[MeneerKrab]

ik ga morgen de laatste versie van je installeren. Momenteel ziek dus kan wel wat leuks doen.
top dat je deze stats aanpast.

[ramonp]

stappel_ schreef op woensdag 12 oktober 2005 @ 19:51:
[...]
niet helemaal, hij zeurt vaak over een lege xrange en maakt dan een lege output file aan. (ja onder Linux)

Oh, oke, ik zal er naar kijken. Ik ben het zelf nog niet tegen gekomen.

[MeneerKrab]

wat ik ook niet snap is waarom de stats de console log niet kan uitlezen vanuit windows. Ik zal ppstats er eens bij pakken en kijken hoe het daarin is opgelost.

[ramonp]

PowerCow schreef op donderdag 13 oktober 2005 @ 09:30:
wat ik ook niet snap is waarom de stats de console log niet kan uitlezen vanuit windows. Ik zal ppstats er eens bij pakken en kijken hoe het daarin is opgelost.

Ik gebruik zelf geen Windows, dus dat test ik ook niet.

Maar goed het is toch gewoon die console log uitlezen en dat weg schrijven in de database.

[Witlof]

Is het misschien zo dat je console logfile ook voorzien wordt van een datum? Daar is namelijk geen rekening mee gehouden. De stats kijken maar naar 1 bepaalde file zonder datum (clog.log oid en dus niet clog20051013.log). Je moet dus logfilerotation gebruiken of in iedergeval geen datum aan de logfile laten koppelen.

[MeneerKrab]

Witlof schreef op donderdag 13 oktober 2005 @ 10:05:
Is het misschien zo dat je console logfile ook voorzien wordt van een datum? Daar is namelijk geen rekening mee gehouden. De stats kijken maar naar 1 bepaalde file zonder datum (clog.log oid en dus niet clog20051013.log). Je moet dus logfilerotation gebruiken of in iedergeval geen datum aan de logfile laten koppelen.

dat is het ja. Mijn console log is daily en krijgt dus een datum. Ga het gelijk ff proberen. Verder heb ik met je laatste versie dat ik niet meer in kan loggen als admin / admin terwijl ik het nog niet veranderd had.

[ramonp]

PHPstats gaan er vanuit dat het console log er zo clog20050727.log uitziet.

Probeer als wachtwoord eens 'pino' en heb het even moeten testen en ben het vergeten terug te zetten, toen ik de database heb geexporteerd

[MeneerKrab]

ramonp schreef op donderdag 13 oktober 2005 @ 10:36:
PHPstats gaan er vanuit dat het console log er zo clog20050727.log uitziet.

Probeer als wachtwoord eens 'pino' en heb het even moeten testen en ben het vergeten terug te zetten, toen ik de database heb geexporteerd

ik heb de console log zo staan.
Wachtwoord had ik ondertussen zelf al ff veranderd.

[Witlof]

PowerCow schreef op donderdag 13 oktober 2005 @ 10:39:
[...]

ik heb de console log zo staan.
Wachtwoord had ik ondertussen zelf al ff veranderd.

Als je de console log zo hebt staan werkt het wel? Of niet?

[MeneerKrab]

Witlof schreef op donderdag 13 oktober 2005 @ 10:45:
[...]

Als je de console log zo hebt staan werkt het wel? Of niet?

niet

[ramonp]

Mijn console log files bevatten ook een datum en dit werkt gewoon.

Oh wacht, ik heb het al gezien. Hij probeert de datum uit de database te halen uit een veld dan niet bestaat

@stappel_

Ik heb de wijzigingen die je heb aangedragen bijna allemaal doorgevoerd.
Maar onderstaande niet, omdat er $plot al wel bestaat.
Eerder in het script (in een andere functie) staat $plot="";

code:

============================== modules/gnuplot.php ===============
vervang:
    $plot.="set size 
door
    $plot="set size 
De eerste keer bestaat $plot nog niet dus mag je geen .= gebruiken

[stappel_]

ramonp schreef op donderdag 13 oktober 2005 @ 11:09:
Eerder in het script (in een andere functie) staat $plot="";

dat klopt, maar in de functie zelf bestaat hij niet, of je moet het als global in die functie definieren.

[ramonp]

stappel_ schreef op donderdag 13 oktober 2005 @ 12:01:
[...]
dat klopt, maar in de functie zelf bestaat hij niet, of je moet het als global in die functie definieren.

Ik zal het aanpassen, je hebt me overtuigd

[Witlof]

Kun je misschien ook de volgende versie 0.177 noemen ipv 0.176a? Zeker met die rp erachter is het niet echt duidelijk. Dacht namelijk nog altijd dat de oude versie er stond maar blijkt dus al een nieuwe te zijn.

[MeneerKrab]

Ik heb nu even wat ogr gedaan en ik krijg hetzelfde probleem als Wilko2
Hij kan dus iets van een regel niet goed wegschrijven naar de database.

[ramonp]

Met die updates van stappel_ is dat opgelost.

Ik zal het straks even online zetten onder versie nummer 0.177

Het staat online (zie ondertitel)

[ Voor 17% gewijzigd door ramonp op 13-10-2005 14:22 ]

[MeneerKrab]

Ziet er top uit.

Ondertussen heb ik gnuplot ook draaien op de windows machine.

code:

//// Enable GNUplot (wont work on MS OS'es)
$gnuplot = 1;
$gnuplotLocation = "c:/gnuplot/wgnuplot.exe";

Resultaten op http://rc5.biesterbosch.nl

[ Voor 14% gewijzigd door MeneerKrab op 13-10-2005 14:39 ]

[ramonp]

PowerCow schreef op donderdag 13 oktober 2005 @ 14:38:
Ziet er top uit.

Ondertussen heb ik gnuplot ook draaien op de windows machine.

code:

//// Enable GNUplot (wont work on MS OS'es)
$gnuplot = 1;
$gnuplotLocation = "c:/gnuplot/wgnuplot.exe";

Resultaten op http://rc5.biesterbosch.nl

Ziet er idd goed uit.

Ik zie alleen dat Server status nog niet helemaal goed werkt, maar dat kan misschien aan een instelling van je console log file liggen.

[Gijsh]

Hallo, ik ben ook aan het klooien met die phpstats. Ik kom er echter alleen niet helemaal uit. Op dit moment kom ik tot deze foutmelding (als ik index.php open.):

code:

Database Error: Could not Parce Stats Querie
Select claimed,SUM(blocks) AS blocks,UNIX_TIMESTAMP(MAX(date)) as date FROM stats where date > '20051013000000' and date < 20051013235959 GROUP BY claimed ORDER BY blocks DESC

Heeft iemand hier misschien een idee waar dit aan ligt? Ik ben niet bekend met Mysql en php dus het zegt me niet zo vrij veel allemaal.

[stappel_]

RamonP:
In de functie InsertData staat nog :
$SQL = "INSERT INTO ". $db ." VALUES ('".$logdata[0]."',

dat moet zijn:
$SQL = "INSERT INTO ". $db ." VALUES ('".$datetime[0]." ".$datetime[1]."',

omdat niet overal de datum als 2000-10-13 staat, soms staat het als 10/13/05. Dit lost dat probleem ook op.

(het staat bij ogrp2 en rc572)

[MeneerKrab]

ramonp schreef op donderdag 13 oktober 2005 @ 16:48:
[...]


Ziet er idd goed uit.

Ik zie alleen dat Server status nog niet helemaal goed werkt, maar dat kan misschien aan een instelling van je console log file liggen.

[console]
logfileconsole=c:/proxy/logs/console/clog
logfileconsolerotation=daily
consoleverbosity="general stats keyblock server client buffers timestamp attention errlow errsevere"
timestampflags=130

Ook ben ik er achter dat het grafiekje door mezelf gemaakt is. Ik had gnuplot een keer geopend en zo'n ini ingeladen. Dit maakte dat er een grafiekje uit kwam. Klopt niet helemaal volgens mij want er staat op de x 10-2005 en dat wel een paar keer.

[ramonp]

PowerCow schreef op donderdag 13 oktober 2005 @ 18:37:
[...]


[console]
logfileconsole=c:/proxy/logs/console/clog
logfileconsolerotation=daily
consoleverbosity="general stats keyblock server client buffers timestamp attention errlow errsevere"
timestampflags=130

Ook ben ik er achter dat het grafiekje door mezelf gemaakt is. Ik had gnuplot een keer geopend en zo'n ini ingeladen. Dit maakte dat er een grafiekje uit kwam. Klopt niet helemaal volgens mij want er staat op de x 10-2005 en dat wel een paar keer.

Die console instellingen zouden goed moeten zijn.

Bij de settings van phpstats moet je dan het volgende invullen.
Console log file path: c:/proxy/logs/console/
Console log file name: clog
Console log file sufix: .log

Dan zou het moeten werken.

@stappel_

Daar heb ik helemaal overheen gekeken. Ik zal het meteen aanpassen.


Van het weekend zal ik phpstats eens op een Windows machine installeren, kijken wat ik dan nog voor problemen / beperkingen tegenkom.

edit: Nieuwe versie staat online

[ Voor 3% gewijzigd door ramonp op 14-10-2005 09:46 ]

[Witlof]

Zal eens mailen dat 0.178 eens geïnstalleerd moet worden. Staan er nog dingen te gebeuren de komende dagen? Zijn er nog plannen mbt de stats?

[ramonp]

Witlof schreef op dinsdag 18 oktober 2005 @ 09:22:
Zal eens mailen dat 0.178 eens geïnstalleerd moet worden. Staan er nog dingen te gebeuren de komende dagen? Zijn er nog plannen mbt de stats?

Ik heb er de komende dagen niet veel tijd voor.
Dus deze versie blijft voorlopig nog wel even zo.

Tenzij er natuulijk een kritieke fout inzit ofzo.

[Witlof]

Maar wat zijn de plannen als de tijd er wel is?

[ramonp]

Witlof schreef op dinsdag 18 oktober 2005 @ 13:46:
Maar wat zijn de plannen als de tijd er wel is?

Er schijnt nog een probleem te zijn met 'Total by week' en dan met de week nummers 53 en 01.
Dat moet ik nog even uitzoeken.

Daarnaast wil ik het menu in een database stoppen.

En er zijn nog wat klein dingen die opgelost moeten worden.

[stappel_]

ramonp schreef op dinsdag 18 oktober 2005 @ 15:22:
Er schijnt nog een probleem te zijn met 'Total by week' en dan met de week nummers 53 en 01.
Dat moet ik nog even uitzoeken.

Klopt, ik zag het ook.
Hij vraagt alleen het weeknummer aan mysql. 1-jan-2005 meldt hij dan als week 53. wat correct is. In je script zet je er dan zelf het huidige jaar voor. wat dus fout is want het is week 53 van 2004.

[ramonp]

stappel_ schreef op dinsdag 18 oktober 2005 @ 16:29:
[...]

Klopt, ik zag het ook.
Hij vraagt alleen het weeknummer aan mysql. 1-jan-2005 meldt hij dan als week 53. wat correct is. In je script zet je er dan zelf het huidige jaar voor. wat dus fout is want het is week 53 van 2004.

Dat is handig om te weten. Ik wist namelijk nog niet wat precies het probleem was.
Ik heb even snel gekeken, maar ik denk dat php het moet gaan laten oplossen ipv mysql.

[ramonp]

En we hebben weer een nieuwe versie PHPStats

Deze lost de volgende problemen op:

• Gnuplot aangepast, zodat de gemiddelden per user goed berekent worden.
• Probleem bij 'Total by week' is opgelost. Week 53 wordt nu goed weergegeven met het juiste jaartal.

Er zijn wederom geen database aanpassingen gemaakt, dus alleen de bestanden vervangen is voldoende.

Download: zie ondertitel.

[Witlof]

Ik zat net even te kijken en zag dat de optie tot een overzicht van 'dupes' ontbrak. Is dat doordat deze versie dit helemaal niet ondersteund of gewoon nog niet naar gekeken is? Voor een voorbeeld, zie de stats van DSmarty

[ramonp]

Witlof schreef op vrijdag 21 oktober 2005 @ 14:21:
Ik zat net even te kijken en zag dat de optie tot een overzicht van 'dupes' ontbrak. Is dat doordat deze versie dit helemaal niet ondersteund of gewoon nog niet naar gekeken is? Voor een voorbeeld, zie de stats van DSmarty

Dat is misschien wel te maken, maar wat heeft het overzicht voor meerwaarde?

Ik zie trouwens dat op de stats van DSmarty ook de week 53 fout gaat.

[stappel_]

Witlof schreef op vrijdag 21 oktober 2005 @ 14:21:
Ik zat net even te kijken en zag dat de optie tot een overzicht van 'dupes' ontbrak. Is dat doordat deze versie dit helemaal niet ondersteund of gewoon nog niet naar gekeken is? Voor een voorbeeld, zie de stats van DSmarty

dupes kan niet zonder database wijziging, reparsen alle log en code aanpassingen. er worden momenteel geen sub id's of block id's opgeslagen in de database.

[Witlof]

ramonp schreef op vrijdag 21 oktober 2005 @ 14:40:
[...]


Dat is misschien wel te maken, maar wat heeft het overzicht voor meerwaarde?

Ik zie trouwens dat op de stats van DSmarty ook de week 53 fout gaat.

Makkelijk een overzicht als je meer geflushed hebt volgens de proxy dan dnet weergeeft wie hiervoor eventueel verantwoordelijk is? Als iemand bv nog niet weet hoe het precies werkt met offline PC's en verkeerd te werk gaat of iemand bewust loopt te kloten kun je dat makkelijk terug vinden.

Stats worden dan eerlijk opgebouwd en members kunnen aangesproken worden als het mis gaat.

stappel_ schreef op vrijdag 21 oktober 2005 @ 14:48:
[...]

dupes kan niet zonder database wijziging, reparsen alle log en code aanpassingen. er worden momenteel geen sub id's of block id's opgeslagen in de database.

Ahaa, dus dat is nogal wat werk begrijp ik hieruit

[ Voor 20% gewijzigd door Witlof op 21-10-2005 14:57 ]

[ramonp]

Ok nu weet ik wat 'dupes' inhoud.

Het is wel te realiseren, maar zoals stappel_ zegt is het nogal wat werk.
Ik zal er eens over nadenken, of het simpel op te lossen is.

[Witlof]

Sja, in het verleden was het te doen met een dupechecker om te kijken of de blokjes dubbel waren en wie deze flushte. In een overzicht wat dagelijks meerdere malen geupdate wordt is het sneller terug te zien en kun je sneller handelen. Opzich zou ik het wel een prettige feature vinden als die erin zat maar als het niet zo is kijk ik wel bij DSmarty want daar flushen we naar toe. Moet ik nog wel kijken wie er verantwoordelijk voor is via mijn eigen logs.

[Webgnome]

Ramonp wat wordt er opgeslagen in 'blocks' in je sql? Als dat het id van het blokje is , dan is een simpele nieuwe tabel ( dupes ) en een aantal nieuwe queries toch voldoende?

[Webgnome]

Ramonp wat wordt er opgeslagen in 'blocks' in je sql? Als dat het id van het blokje is , dan is een simpele nieuwe tabel ( dupes ) en een aantal nieuwe queries toch voldoende?

.... een opnieuw inladen van de logs ontkom je dan inderdaad niet aan tenzij je natuurlijk alle blokcs in je block tabel laad. Dus ook als er dubbele instaan. dan volstaat het een simpele insert query met een select op de blocks tabel al om de dubes tabel te vullen

[ Voor 31% gewijzigd door Webgnome op 21-10-2005 18:48 ]

[ramonp]

Bij 'blocks' worden het aantal blocks opgeslagen in de database.

Als je alle blockid's gaat opslaan betekent het dat er voor iedere regel uit de logfile een record wordt gemaakt.
Nu is het zo dat de blocks met dezelfde datum, tijd en ip bij elkaar worden opgeteld en die wordt als één record weggeschreven in de database.

Het scheel een hoop ruimte om op te slaan, maar heeft als nadeel dat je geen dupes kan controleren.

[MeneerKrab]

er staat in de init.php dat gnuplot nu ook werkt op MS OSSEN, maar datis nog niet zo.
Op een vage manier heb ik toen zelf een grafiekje uit gnuplot weten te toveren door de rc572.ini in te laden en dat gaf me ook nog een verneukt grafiekje.

De plaatjes werken ook niet meer.
$baseurl = "/"; < zo staat mijn baseurl. Nu kan ik hem bekijken van intern en extern.

[ Voor 21% gewijzigd door MeneerKrab op 25-10-2005 17:54 ]

[Webgnome]

ramonp schreef op zaterdag 22 oktober 2005 @ 14:07:
Bij 'blocks' worden het aantal blocks opgeslagen in de database.

Als je alle blockid's gaat opslaan betekent het dat er voor iedere regel uit de logfile een record wordt gemaakt.
Nu is het zo dat de blocks met dezelfde datum, tijd en ip bij elkaar worden opgeteld en die wordt als één record weggeschreven in de database.

Het scheel een hoop ruimte om op te slaan, maar heeft als nadeel dat je geen dupes kan controleren.

dus je houd helemaal niet bij welk block id er is geflusht? nee dan is het inderdaad neit mogelijk om dupes te controleren.

[_reboot_]

@Ramonp:
Is het geen idee om de weekstats volledig via MySQL de laten gaan dan ben je ook van het wekenprobleem verlost? Volgens mij worden de weekstats (en misschien de rest ook wel) geparsed door PHP. Is het niet gemakkelijk om dit gelijk door MySQL te laten doen? Hoe meer je vanuit de database al doet, hoe sneller het meestal gaat.

Check bijvoorbeeld: http://dev.mysql.com/doc/...e-and-time-functions.html

[ramonp]

_reboot_ schreef op vrijdag 28 oktober 2005 @ 16:49:
@Ramonp:
Is het geen idee om de weekstats volledig via MySQL de laten gaan dan ben je ook van het wekenprobleem verlost? Volgens mij worden de weekstats (en misschien de rest ook wel) geparsed door PHP. Is het niet gemakkelijk om dit gelijk door MySQL te laten doen? Hoe meer je vanuit de database al doet, hoe sneller het meestal gaat.

Check bijvoorbeeld: http://dev.mysql.com/doc/...e-and-time-functions.html

Ik heb het probleem uiteindelijk toch maar via MySQL opgelost, in de laatste versie (v0.179).
Er werd in de query een verkeerde 'jaar' variable gebruikt. Het was %Y terwijl het i.c.m. weken %x moest zijn. (Dat staat ook op de link die je hebt gegeven.)

[ramonp]

Ik heb even het één en ander getest om dupes te controleren.

Er zit één groot nadeel aan, de tabel groeit enorm.

Als voorbeeld heb ik even mijn eigen database bekeken.

De tabel rc572 heeft nu 557 records en is 60 kb groot.
De tabel rc572 waar ook de blockid's worden opgeslagen heeft ruim 17.500 records en is 1,5 mb groot.

* ramonp vraagt zich dan ook af of dit de moeite waard is.

[Verwijderd]

Niet voor het een of het ander, maar 17.500 records is niets voor een database. En anderhalve megabyte is ook niets. Dat kan bijna op een floppy

Zowat anderhalf jaar geleden had ik nog een ECC2-109 proxy draaien, die ook een dupe checker had. De database daarachter (een simpel MySQL geval) had aan het einde van het project ruim een half miljoen records en een tiental tables. En die draaide prima op m'n oude getrouwe 486DX2-66 met amper 32MB geheugen! Ik geef toe dat je af en toe wel een handvol seconden moest wachten om stats te laten genereren als meerdere mensen gelijk stats gingen bekijken, maar dat was dan ook meer mijn schuld dan die van de database (slecht design met verschillende complexe queries die met een paar honderdduizend records gingen spelen), maar dat boeide uiteindelijk niet zoveel. Toen ik de database op het einde op m'n oude Athlon 750 ging draaien merkte je niet eens dat die draaide op wat geheugengebruik na, zelfs met het slechte design van de stats...

En zelfs dat is nog niets. Doet me denken aan dit bericht wat ik een tijdje geleden tegen kwam. Een database van 600GB met 3600 tables en 2 miljard records waar iedere 2 uur zowat 4 miljoen inserts worden gedaan. En dat zelfs met MySQL. Jij komt nog lang niet in de buurt van de limieten van je database denk ik

Zelfs de DPC topteams hebben nog maar een paar miljoen blokjes. Laat ons uitgaan van 100 miljoen blokjes, dan zijn dat honderd miljoen records met een ID. Een ID kun je in 40 bits opslaan. Laat ons nog zeggen dat je er 64 bit voor neemt, of 8 bytes. Da's een database van niet eens een gigabyte. Dat zie je niet eens staan op een moderne harddisk. Volgens mij wordt het meer een kunst om bijvoorbeeld een dupe check snel te laten verlopen met 100 miljoen andere IDs in de database...

Dus ik denk dat je je geen zorgen moet maken voor een paar duizend records en een paar megabyte data Gewoon een dupe check toelaten als optie. Wie het wil gebruiken zet het aan, de anderen laten het afstaan.

[Webgnome]

ramonp schreef op maandag 31 oktober 2005 @ 10:55:
Ik heb even het één en ander getest om dupes te controleren.

Er zit één groot nadeel aan, de tabel groeit enorm.

Als voorbeeld heb ik even mijn eigen database bekeken.

De tabel rc572 heeft nu 557 records en is 60 kb groot.
De tabel rc572 waar ook de blockid's worden opgeslagen heeft ruim 17.500 records en is 1,5 mb groot.

* ramonp vraagt zich dan ook af of dit de moeite waard is.

De database groeit inderdaad enorm maar wat daar tegenovestaat is wel de moeite waard. Dupechecking. Op dit moment heeft het stats systeem van [BVD]South in de main table +/- 1.307.570 (maal 8 kolommen ) records waarvan er in de dupetable 21.813 ( maal 4 kolommen ) geregistreerd staan.

In de blocks tabel worden de gegevens opgeslagen van de blocks op het momentd at ze binnen komen. Mocht er een dupe worden gegenereerd dan wordt deze in de blocks tabel opgeschreven. hiervan wordt alleen het ID opgeschreven van het zlefde block in de blockt table en de datum waarop het wordt geduped en het ip waarmee het is verzonden. Dat dit mischien niet de meest goede manier is ben ik wel met jullie eens

En om nou te zeggen dat de stats langzaam zijn?

grazestats nou nee met andere woorden waarom is het niet de moeite waard. Je moet pas gaan denken hieraan als door dit 'grapje' de tabel grensen worden bereikt en dat is voor mysql meen ik 4 miljoen records (waar ik dat vandaan heb ik weet ik ook niet ).

[ Voor 32% gewijzigd door Webgnome op 31-10-2005 17:28 ]

[Verwijderd]

Webgnome schreef op maandag 31 oktober 2005 @ 17:20:
Je moet pas gaan denken hieraan als door dit 'grapje' de tabel grensen worden bereikt en dat is voor mysql meen ik 4 miljoen records (waar ik dat vandaan heb ik weet ik ook niet ).

Dat zou bijzonder lomp zijn en kan ik me haast niet voorstellen. Ik zou verwachten dat het het ruim 4 miljard was ('4 billion'), toch voor een 32 bit systeem (2^32 is ruim 4 miljard). Uiteraard moet je dan nog wel rekening houden met de beperkingen van je file system. En voor 64 bit systemen zou ik zelfs nog een veel hogere limiet verwachten...

[ Voor 9% gewijzigd door Verwijderd op 31-10-2005 20:17 ]

[ramonp]

Nou goed. Ik zal het eens verder uitwerken.

Kijken of het een beetje gaat werken.

[Webgnome]

ramonp schreef op dinsdag 01 november 2005 @ 08:40:
Nou goed. Ik zal het eens verder uitwerken.

Kijken of het een beetje gaat werken.

als er iets niet lukt dan ben ik wel bereid om je te helpen

[ramonp]

Het is op zich wel gelukt, maar ik weet niet of ik voor de snelste methode heb gekozen.

Ik heb een extra tabel aangemaakt dupes_rc572 wat een exacte kopie is van rc572.

Daarna heb ik de update query aangepast. Bij het inlezen van de log file wordt eerst gekeken of het blockid voorkomt in rc572. Zo niet dan wordt ie in de tabel rc572 bijgeschreven. Komt ie al wel voor dan wordt ie in de tabel dupes_rc572 weggeschreven.

Hetzelfde geldt natuurlijk voor ogr.

Het gaat allemaal wel goed, alleen gaat het updaten wat langzamer.

[Webgnome]

Zo heb ik het ook gedaan bij mijn stats system. Ik ben de laatste dagen mezelf ook aan het afvragen of dit niet beter kan ( met een of andere subquery ).

[ParaNoiMia]

Ik heb dat op een andere manier opgelost met een klein undupe proggie. Als je een unieke key maakt op het block in je tabel en je doet insert query, dan ontstaat er een fout, omdat de key niet uniek is. Met foutafhandeling kan je dat block daarna alsnog in de dupetabel inserten. Werkt sneller dan een select (zeker met de miljoenen wu's die NC in de DB zou krijgen )

[ramonp]

Het is idd sneller, maar echt een mooie oplossing vind ik het niet.

[ParaNoiMia]

ramonp schreef op woensdag 02 november 2005 @ 14:13:
Het is idd sneller, maar echt een mooie oplossing vind ik het niet.

Ik zie niet wat er mis mee is ? Sterker nog, je maakt gebruik van errorhandling en de controle wordt door je DB afgehandeld en niet programmatisch

[ Voor 12% gewijzigd door ParaNoiMia op 02-11-2005 15:48 ]

[ramonp]

ParaNoiMia schreef op woensdag 02 november 2005 @ 15:48:
[...]


Ik zie niet wat er mis mee is ? Sterker nog, je maakt gebruik van errorhandling en de controle wordt door je DB afgehandeld en niet programmatisch

Ik heb het even heel simpel gedaan, dus er word niet gekeken wat er fout gaat.

PHP:

$sql = "insert in de tabel";
if (!mysql_query($sql)){
  $sql = "insert in de dupes tabel";
  mysql_query($sql);
}

[ge-flopt]

Heeft iemand de zelf gemaakte updates al gebundeld en opnieuw uitgebracht?

[ramonp]

ge-flopt schreef op maandag 07 november 2005 @ 10:20:
Heeft iemand de zelf gemaakte updates al gebundeld en opnieuw uitgebracht?

Welke updates bedoel je?

Het 'dupes' gebeuren moet eerst even goed worden uitgewerkt en worden getest.
Voor de rest zijn er geen nieuwe updates meer sinds de laatste versie.

Maar momenteel heb ik andere problemen, de harddisk uit m'n Linux machine staat op het punt om dood te gaan
Dus ik ben nu bezig om alles te backuppen en daarna moet ik alles opnieuw installeren.

[ramonp]

Zo een nieuwe Linux machine is up-and-running
Dus weer tijd om het e.a. te doen.

Goed er is wederom een nieuwe versie uit v.0.180, er zijn een aantal kleine dingen aangepast.

• Geen database wijzigingen, dus alleen de bestanden moeten worden vervangen.
• Gnuplot aangepast, zodat het (nu wel) goed onder Windows werkt.
• E.a. aangepast m.b.t. de update
• Updatelog.php aangepast, zodat deze goed werkt met deze versie.
• Serverinfo aangepast, zodat er geen eventuele lege velden kunnen ontstaan wanneer de proxy niet draait.

Het dupes gedeelte ben ik nog mee bezig, maar is nog niet klaar. Komt waarschijnlijk in de volgende versie.

[luie-steffie]

Is er nog work in progress op een van de 2 stats ?
Die van Madman81, of die van Ramonp ?

[ramonp]

luie-steffie schreef op maandag 27 februari 2006 @ 23:19:
Is er nog work in progress op een van de 2 stats ?
Die van Madman81, of die van Ramonp ?

Ik heb er momenteel niet veel tijd voor, dus blijft het een beetje liggen.

[Brede P]

luie-steffie schreef op maandag 27 februari 2006 @ 23:19:
Is er nog work in progress op een van de 2 stats ?
Die van Madman81, of die van Ramonp ?

Voor zover ik weet, zijn die van Madman81 volledig up and running (kijk maar op de statspagina van www.dsmarty.com ).

[ge-flopt]

KICK!!! (Zie het topic gaan als een raket omhoog)

Weer eens aan het stoeien geweest met stats. Uiteindelijk PHPstats er maar opgezet. Nu kom ik alleen bij 1 probleem. Ik kan niet ingelogd komen met het admin account. Ik heb geprobeerd om met admin, Admin ed in te loggen en het standaard wachtwoord password . Maar helaas. Ook nog een ander account aangemaakt, maar helaas. Krijg constant de melding: Login failed .

het geheel draait op Mysql 5, Apache 2 en PHP 5. Iemand een idee?

[radial]

ge-flopt schreef op vrijdag 09 juni 2006 @ 14:47:
KICK!!! (Zie het topic gaan als een raket omhoog)

Weer eens aan het stoeien geweest met stats. Uiteindelijk PHPstats er maar opgezet. Nu kom ik alleen bij 1 probleem. Ik kan niet ingelogd komen met het admin account. Ik heb geprobeerd om met admin, Admin ed in te loggen en het standaard wachtwoord password . Maar helaas. Ook nog een ander account aangemaakt, maar helaas. Krijg constant de melding: Login failed .

het geheel draait op Mysql 5, Apache 2 en PHP 5. Iemand een idee?

Probeer eens met admin/admin ? er staat me iets van bij dat het best wel simpel was

[ge-flopt]

Ik heb getest door het originele wachtwoord met md5 te bewerken en dan krijg ik de zelfde hash string terug als in de database staat.

UPDATE extra info:
Wat ik overigens wel vreemd is dat in de 0.175 zip file de aq directory niet gevuld is. Ik heb dus uit de 0.175 Beta zip deze dir overgenomen.

[ Voor 39% gewijzigd door ge-flopt op 10-06-2006 18:08 ]

[ge-flopt]

Kick, anyone?

[MeneerKrab]

ik kreeg het niet werkende onder windows. Toen ik linux probeerde draaide hij als een zonnetje. misschien dat het daar aan ligt.

[ge-flopt]

Ik draai het ook onder linux

[Wortelsoep]

Werkt phpstats eigenlijk ook goed voor OGR? Ik meen dat ik het ooit eens had geprobeerd maar dat ik er niet echt wijs uit werd..
Het ziet er namelijk wel erg mooi uit allemaal. ppstats wordt nu toch wel echt oud.

[ge-flopt]

Kan inmiddels inloggen. Ben wat aan het spitten geweest, en heb wat aangepast. Denk dat het een groot verschil maakt of je phpstats op php4 en/of php5 draait.

[ge-flopt]

Heb uiteindelijk ook besloten omdat ik op wat dingetjes uit kwam die ik niet prettig vond, om eens te kijken of ik zelf iets kan bouwen. U hoort nog van me

[D2DM]

ip samenvoeg vraagje; ppstats 7.2.0c (debian)

(Alle clients .ini bestand hebben hetzelfde e-mail adres/domein.)
Er staan een aantal inactieve ip's in m'n host lijst, hoe voeg ik deze toe aan actieve ip's.
Bijv. inactief ip: 10.0.0.157 samenvoegen met actief ip 10.0.0.159, zonder .158.

Ranges zijn hiervoor ongeschikt
http://www.dutchpowercows.org/doc.php?id=61
Je kunt met rc5-ip.cons instellen dat ip ranges als 1 'host' vermeld moeten worden.

en uit: Config in "Hulp nodig met mijn stats pagina"
# Consolidate numbers in hosts? ie, host12.myisp.com -> host?.isp.com
# See rc5-ip.cons for a list of ip addresses you wish to manual consolidate.

--
Stripcache?
Striplog, de downloadlinks die ik tegenkom werken niet. Waar is dit te halen?
http://users.belgacom.net/pinball/ + doorverwijzing werkt niet.
--
Voor evt. volgende versie:
- hitparade day, month, alltimehigh pakt rc5.flags wijziging (NL op .com) goed op.
hitparade week en By domain niet.
- Serversysteem specs optioneel weergeven. Zoals onderaan op deze page: http://www.dsmarty.com/stats-rc5.html
- Executive Team Summary Total CPU vervangen door Total CPU Types

[ Voor 36% gewijzigd door D2DM op 06-10-2006 15:03 ]