[FS / MySQL] Hoe logfiles het beste op te slaan?

[Verwijderd]

Ik zit eraan te denken om binnen het intranet bij ons op de zaak, logfiles aan te maken van wie wat doet, bijvoorbeeld:

code:

08-04-2008 19:23 [tweakerert] Deleted page id 211
08-04-2008 19:21 [don] Created user account for 'erica'
08-04-2008 19:17 [marcel] Uploaded picture foo.jpg
08-04-2008 19:17 [marcel] Uploaded picture bar.jpg
08-04-2008 19:17 [marcel] Uploaded picture baz.jpg
08-04-2008 19:10 [don] Suspended user account 'kees_p'

Dit, omdat er nogal eens oeverloze discussies zijn geweest onder sommige gebruikers over "wie wat fout heeft gedaan". Het aantal recordsets zal naar schatting enkele honderden per uur bedragen, eea afhankelijk van wat je allemaal precies wilt vastleggen.

Tot nu toe werden acties als wanneer iemand in- en uitlogt al in de (MySQL) database opgeslagen, maar ik vraag me af of het juist / nodig is om dit soort gegevens in een database op te slaan. Ze hebben immers geen relatie met andere database gegevens. Aan de andere kan is het wel makkelijker gegevens te doorzoeken ("alle delete acties van kees_p"). Wel ben ik bang voor het exponentieel uitdijen van de bewuste tabel; waardoor een enkele logfile, bv per week, weer beter lijkt. Het uitvoeren van zoekacties wordt dan echter weer lastiger.

Graag jullie inzicht hierover!

[RobIII]

Verwijderd schreef op woensdag 08 april 2009 @ 01:09:
Graag jullie inzicht hierover!

Gebruik een DB gewoon waar 'ie voor bedoeld is. Je hoeft niet lief/aardig voor 'm te zijn; van een paar duizend tot een paar (honderd)miljoen records loopt 'ie echt niet weg. Ranzige oplossingen als een tabel per week etc. zijn gewoon te ranzig. Mocht 't ooit echt een probleem worden dan kun je nog altijd alles ouder dan datum X verwijderen of iets in een archieftabel mikkeren (die dan rustig wel kan uitdijen).

Hou wel rekening met wat 'safeguards'; zo noem je bijvoorbeeld "alle delete^{insert/update} acties van kees_p" maar dat kan wel eens flink oplopen en dan een probleem gaan vormen in de GUI die opeens 3 miljoen records moet gaan displayen. Breid de selectie bijvoorbeeld standaard uit naar "afgelopen maand" ofzo, waarbij je dan nog altijd als gebruiker de periode kunt opgeven als 'ie (veel) verder terug wil zoeken.

Even ruim geteld: "naar schatting enkele honderden per uur bedragen":

8 uren per werkdag, enkele honderden ~ 1000. Dat is 8000 records, zeg 10.000 per dag. Dan zit je na een jaar op 3.5miljoen records (give or take). Boeie. Met een goeie index op (zeg) datum pik je er zo alle records van een bepaalde dag/week/maand uit. (Aangenomen dat je op een beetje fatsoenlijke hardware draait etc. natuurlijk).

Verwijderd schreef op woensdag 08 april 2009 @ 01:09:
Wel ben ik bang voor het exponentieel uitdijen van de bewuste tabel

Hoe zou dat exponentieel zijn? Hooguit een beetje "naar boven krommend lineair" als het door de loop van 't jaar steeds beter gaat met de business En met de recessie wordt 't dus waarschijnlijk alleen maar minder

[ Voor 55% gewijzigd door RobIII op 08-04-2009 02:12 ]

[ACM]

Verwijderd schreef op woensdag 08 april 2009 @ 01:09:
Wel ben ik bang voor het exponentieel uitdijen van de bewuste tabel; waardoor een enkele logfile, bv per week, weer beter lijkt. Het uitvoeren van zoekacties wordt dan echter weer lastiger.

Graag jullie inzicht hierover!

Het zal van je beoogde zoekacties afhangen en de tijdsduur waarop je die terug wilt kunnen halen, grep/egrep zijn bijvoorbeeld hele complete tools voor specifieke zoekopdrachten, maar meer algemene "hoeveel acties deed kees per dag" zijn er wel lastig mee te bepalen. Je kan bijvoorbeeld ook een hybrideaanpak nemen. Alles sowieso in logfiles wegschrijven, die je netjes elke week "roteert" en dan gecomprimeerd opslaat, maar de laatste paar weken ook in je database bijhoudt.
Als je dan ook nog eens je files zo wegschrijft dat ze eenvoudig in de database in te lezen zijn, kan je eventueel uitgebreidere analyses on-demand nog uitvoeren. Het is in MySQL zelfs mogelijk om csv-files als tabel te benaderen, mocht dat later nuttig blijken. Kijk trouwens ook nog even naar de archive-engine, die slaat de boel lekker compact in een write-once formaat op.

Anderzijds heeft Rob wel gelijk dat 10k per dag niet per se heel veel is.

RobIII schreef op woensdag 08 april 2009 @ 02:01:
Gebruik een DB gewoon waar 'ie voor bedoeld is.

Loze data er in schrijven die eigenlijk prima in een flat-file aanpak kunnen is niet een van de basistaken van een database lijkt me zo Zodra je de data als niet-loos markeert en er in moet kunnen zoeken, buiten de simpele command line tools, dan wordt het een ander verhaal.

Ranzige oplossingen als een tabel per week etc. zijn gewoon te ranzig. Mocht 't ooit echt een probleem worden dan kun je nog altijd alles ouder dan datum X verwijderen of iets in een archieftabel mikkeren (die dan rustig wel kan uitdijen).

Hoe kom je erbij dat partitioneren ranzig is? Mits correct geimplementeerd is het juist een van de weinige manieren om efficient met hele grote hoeveelheden data te werken, juist met dit soort lineair ingevoerde data. En zeker als er op een gegeven moment alles van voor een bepaalde periode weer verwijderd moet worden (tabel/partitie droppen is een stuk efficienter dan een grote delete). Hierbij is het wel jammer dat het pas vanaf mysql 5.1 een beetje fatsoenlijk transparant te implementeren is.
De vraag hier is natuurlijk wel in hoeverre deze dataset al als "heel groot" te definieren valt.

8 uren per werkdag, enkele honderden ~ 1000. Dat is 8000 records, zeg 10.000 per dag. Dan zit je na een jaar op 3.5miljoen records (give or take). Boeie. Met een goeie index op (zeg) datum pik je er zo alle records van een bepaalde dag/week/maand uit. (Aangenomen dat je op een beetje fatsoenlijke hardware draait etc. natuurlijk).

Een paar miljoen records per jaar is inderdaad niet per se een probleem. Maar dat zegt nog niet dat je dan gelijk je database moet vullen, en dus je resources "verspillen", met log-data.

Een argument dat ik nog wel mis is overigens hoe eenvoudig het is om de boel in een centraal logsysteem weg te schrijven. Multithreaded/processed naar je database schrijven is triviaal, daar kan ie zelf al mee overweg, maar multithreaded/processed naar een of meerdere files schrijven is iets waar je wellicht nog expliciet rekening mee moet houden.
Daarnaast is het nog de vraag hoe eenvoudig je uberhaupt je logdata centraal kan krijgen. Als je meerdere clients hebt die ieder een eigen logfile gaan schrijven is dat niet erg handig en moet je dat weer samen zien te pakken.

[ Voor 3% gewijzigd door ACM op 08-04-2009 08:04 ]

[Kalentum]

Verwijderd schreef op woensdag 08 april 2009 @ 01:09:
Tot nu toe werden acties als wanneer iemand in- en uitlogt al in de (MySQL) database opgeslagen, maar ik vraag me af of het juist / nodig is om dit soort gegevens in een database op te slaan. Ze hebben immers geen relatie met andere database gegevens. Aan de andere kan is het wel makkelijker gegevens te doorzoeken ("alle delete acties van kees_p").

Ik denk dat dit soort loggegevens juist wel een relatie hebben met andere database gegevens. Ze zeggen iets over wie doet wat met welke gegevens, dus dat zegt iets over de data. Bovendien geef je aan dat gebruikers snel duidelijkheid willen over wie wat heeft gedaan en wanneer. Door het in de database te zetten kun je zonder een extra query te gebruiken (of extra code) de 'last modified' presenteren.