[server] logs, hoe ermee omgaan
Alles wat er op de server gebeurt, wordt gelogd. Van de ene kant natuurlijk handig, maar van de andere kant zorgt het ook voor een hoop 'zooi'. Als ik bijv. kijk hoeveel pogingen er worden gedaan om in te breken op de server ... daar loopt je log op een gegeven moment aardig vol van. (Hoe groot mag een log eigenlijk worden?)
Maar wat moet je daar nu eigenlijk mee vraag ik me af. Moet je zo'n log na een tijdje handmatig leegmaken? Of laat je 'm gewoon 'groeien'? En hoe moet je überhaupt omgaan met logs vraag ik me af. Moet je die iedere week doornemen? Of kijk je er hooguit 1 of 2 keer per jaar naar? Of kijk je er pas naar op het moment dat er iets fout gaat?
En hoe kun je logs nu eigenlijk het beste beschouwen ... zijn het tools die je telkens in de gaten moet houden om te controleren of het systeem nog goed werkt OF zijn het simpelweg bestandjes die je kunt raadplegen als er een keer iets fout gaat? Hoe moet je dat zien?
Mijn logs kijk ik alleen maar door als er dingen fout gaan. PHP-errors stuur ik naar mijn eigen log tor die zich niet roteert. Hoe minder errors, hoe beter.
Gewijzigd op 10/05/2016 07:39:13 door - Ariën -
Omdat ik mijn serverlogs ook gebruik voor technische SEO-analyse, schoon ik de boel pas na 18 maanden op: dat maakt jaar-op-jaar-vergelijkingen mogelijk.
PHP- en MySQL-fouten log ik naar een apart bestand waar ik alleen induik als er eens wat fout gaat (dus vooral in een testomgeving). Gaat een site of een kritieke service down, dan laat ik een 503-pagina een waarschuwing naar mijn Gmail-account mailen, zodat ik gelijk kan ingrijpen.
Logbestanden op een server kan je het beste wegschrijven op een aparte partitie (met een quotum) waardoor er genoeg ruimte blijft voor het besturingssysteem om te functioneren.
Dan is "logs" een nogal brede noemer. Wat voor logs zijn dit? Ik zou deze op zijn minst splitsen in errorlogs en accesslogs. Errorlogs zou ik bij tijd en wijlen doornemen en vaak terugkerende fouten oplossen. Dit is ook nodig om door de bomen het bos te kunnen (blijven) zien. Wanneer je errorlog ramvol zit met meldingen van undefined indexes zie je wellicht dringender zaken over het hoofd.
Een log bevat meestal een beknopte historie en is daarmee een naslagwerk welke je inzage kan geven in wat er mis kan (of is ge)gaan in het gebruik (de uitvoering) van code. Het verschaft je dus mogelijk "getuigen" van een "ongeval". Het maakt je ook vaak attent op dingen die je zelf hebt gemist bij ontwikkeling of randgevallen waar je geen rekening mee hield en ontstaan bij (intensief) gebruik.
De eerste vraag die je jezelf kunt/moet stellen als er "iets is misgegaan" is "wat zeggen de errorlogs?". Deze vraag zou je ook standaard op kunnen nemen in een checklist die iemand nagaat voordat 'ie hier (in het algemeen) zijn/haar vraag dumpt. Net zoals het inschakelen van het melden en weergeven van fouten. Vaak kun je de vraag dan al oplossen voordat je deze stelt :). (error)logs are your friend.
Gewijzigd op 10/05/2016 13:24:09 door Thomas van den Heuvel
https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md#5-psrlogloglevel
Hiermee heb je in je eigen PHP-applicaties een prima instrument om zelf te bepalen wat je wel/niet logt en om een onderscheid te maken tussen onschuldige akkefietjes en kwalijke zaken. Een logger inbouwen brengt wat overhead met zich mee — en daar houdt Ozzie niet zo van ;-) — maar je kunt beter te veel dan te weinig loggen.
In grotere organisaties horen logs actief in de gaten gehouden te worden. Niet alleen om te kijken of een product functioneert, maar ook of er oneigenlijk gebruik van gemaakt wordt. Van inlogpogingen vanaf obscure IP-adressen, tot complete audit trails om te zien of een gebruiker wel recht had om iets in te zien.
Omdat logs zo veelzijdig kunnen zijn (je kunt er vanalles inzetten) zijn er allerlei tools te vinden om logs te analyseren, je kunt er triggers opzetten om vreemd gedrag van gebruikers in de gaten te houden, etc. Maar dan moeten logbestanden dus wel onderdeel zijn van een proces dat altijd door mensen bediend wordt.
Een ander soort logbestand is dat wat je aanzet als een programma of programma-keten niet goed functioneert, een debug log. Of nog gedetailleerder: een trace log. Deze categorie logbestanden hebben doorgaans een dusdanig negatieve impact op de prestaties van een programma dat het pas aangezet wordt als er een probleem is waarvan de oorzaak niet bekend is, men hoopt dan op deze manier aan meer informatie te komen. In een debug log wordt doorgaans gedragingen van een programma opgenomen, waar in een trace log ook nog eens communicatie tussen verschillende onderdelen wordt bijgehouden.
Het gaat echt om de logs van de server zelf. Dat zijn er nogal wat. Je hebt een secure log, je hebt messages, je hebt een maillog enz. Allemaal van de server dus. Als er een paar klojo's proberen te connecten met je mailservers, zorgt dat per aanval voor tientallen log-regels. En als je dan een aantal keren per dag zo'n aanval hebt, loopt een bestandje gauw vol. Hetzelfde geldt voor aanvallen op poort 80. Dat zorgt ook voor een hoop bagger.
Ik ga nog wel Fail2Ban installeren, dus dat zal wel wat gaan schelen, maar het is en blijft vervelend. Dat roteren van logs moet ik nog even uitzoeken. Wellicht doet Plesk dat al, maar dat weet ik nog niet.
>> Een logger inbouwen brengt wat overhead met zich mee — en daar houdt Ozzie niet zo van ;-)
Dat klopt ... maar het hangt er vooral vanaf of zo'n log zichzelf weer opruimt. Dát er gelogd wordt, vind ik niet erg. Maar als dat straks ineens bestanden worden van tientallen of honderden mb's wordt het een ander, en vervelend, verhaal.