Hab ich doch endlich mal mein Apache-Logging-Auswertungs-Skript-Sammelsurium fertig gestellt. Infos dazu gibt es ab [hier].
Kickern war heute auch wieder erfolgreich. Hab mit dem Abteilungs-Super-Kicker-Typ zusammengespielt. Hab heute auch mal kein Eigentor geschossen wodurch es in zwei von drei Spielen zum Sieg reichte.
Chaos
Der Praktikant der die Erweiterungen zu bereits erwähntem Newsletter-Tool programmiert hat, hat mir das ganze Packet heute mal zugeschickt für nen ersten Test. Wohlgemerkt, sie wollten damit in 4 Tagen live gehen.
Nun, was soll ich sagen. Der Server läuft... Das war's dann aber auch schon.
Dafür habe ich mein Skript-Sammelsurium für die Webserver fertiggestellt um endlich die Logs sämtlicher virtual Hosts auszuwerten. Dazu die kommenden Tage mehr - will euch das ja nicht vorenthalten.
Nun, was soll ich sagen. Der Server läuft... Das war's dann aber auch schon.
Dafür habe ich mein Skript-Sammelsurium für die Webserver fertiggestellt um endlich die Logs sämtlicher virtual Hosts auszuwerten. Dazu die kommenden Tage mehr - will euch das ja nicht vorenthalten.
Kommunikationsschwierigkeiten
Ende letzten Jahres hat mich Frau X angerufen zwecks Testumgebung für ein Newsletter-Tool. Kollege richtete dafür eine virtuelle Maschine ein und Frau X konnte darauf nach Herzenslust tun lassen.
Heute ruft mich ein Praktikant an, dass er mit mir noch abstimmen wolle, wie die Skripte auf mein Webservercluster in der DMZ kommen und wer mir es einrichtet die dort erzeugten Dateien regelmäßig mit intern zu synchronisieren.
Gaaanz großes Kino. Die wollen nächsten Montag (also noch zwei Werktage Zeit) damit doch glatt produktiv gehen. Mit dieser lächerlichen virtuellen Kiste *lol*. Ohne Abstimmung bezüglich irgendwelcher Webserver, Sync-Vorgänge zwischen DMZ und Intranet ganz zu schweigen vom Mailrouting von ein paar 10.000 Newslettern.
Der Hardware-verantwortliche und meine Wenigkeit bekommen zum Glück Rückendeckung vom Chef, wenn wir jetzt erst mal die Notbremse ziehen...
Kicker in der Mittagspause war dafür mal wieder recht entspannend. Kollege hats mitm Ball fast bis zur Decke rauf geschafft...
Heute ruft mich ein Praktikant an, dass er mit mir noch abstimmen wolle, wie die Skripte auf mein Webservercluster in der DMZ kommen und wer mir es einrichtet die dort erzeugten Dateien regelmäßig mit intern zu synchronisieren.
Gaaanz großes Kino. Die wollen nächsten Montag (also noch zwei Werktage Zeit) damit doch glatt produktiv gehen. Mit dieser lächerlichen virtuellen Kiste *lol*. Ohne Abstimmung bezüglich irgendwelcher Webserver, Sync-Vorgänge zwischen DMZ und Intranet ganz zu schweigen vom Mailrouting von ein paar 10.000 Newslettern.
Der Hardware-verantwortliche und meine Wenigkeit bekommen zum Glück Rückendeckung vom Chef, wenn wir jetzt erst mal die Notbremse ziehen...
Kicker in der Mittagspause war dafür mal wieder recht entspannend. Kollege hats mitm Ball fast bis zur Decke rauf geschafft...
ungeduldig
Die erste Nacht nach Eröffnung hier... Google Analytics sagt 0,0 Besucher. *grummel*
Zum Ausgleich werde ich wohl mal wieder am AntiSpam-System raussuchen, wer welche Newsletter abonniert hat.
Eine Mitarbeiterin hatte mal einen eines Erotik-Versandhauses bestellt und sich bei mir beschwert, dass der ständig als Spam erkannt werden würde. Pff, Anfängerin!
Zum Ausgleich werde ich wohl mal wieder am AntiSpam-System raussuchen, wer welche Newsletter abonniert hat.
Eine Mitarbeiterin hatte mal einen eines Erotik-Versandhauses bestellt und sich bei mir beschwert, dass der ständig als Spam erkannt werden würde. Pff, Anfängerin!
Mittagspäuschen
Den Kicker mal wieder fleißig bemüht.
Währendessen hat mir doch glatt jemand in dem einen Browsergame meine ganze Flotte weg geschossen.
Zum Ausgleich muss ich mal wieder die Quarantäne des Virenscanners nach Videos durchsuchen. Teilweise krasses Zeug dabei...
Währendessen hat mir doch glatt jemand in dem einen Browsergame meine ganze Flotte weg geschossen.
Zum Ausgleich muss ich mal wieder die Quarantäne des Virenscanners nach Videos durchsuchen. Teilweise krasses Zeug dabei...
Russisches Spamproblem
Unser FirstLevel-Support aus Russland hat mal wieder eine Mail geschickt. Mein persönlicher Lieblingsrusse.
Da sitzt irgendein User in unserer Zweigstelle in Moskau und hat einen Kunden der eine Adresse bei mail.ru hat. Dies alleine ist schon Grund genug für unseren FirstLevel-Support-Mitarbeiter mich darum zu beten die Domain auf die Whitelist zu setzen. Es könnte ja eine Mail im Spamfiler hängen bleiben.
Meine Reaktion war wieder die selbe wie die letzten 50 mal:
Antwort
Please whitelist *@mail.ruGenau. Ausschlaggebend für diese Mail war mal wieder das selbe wie für die anderen 50 Mails von denen mich täglich von dieser Person eine erreicht: Zero-Kompetenz.
Da sitzt irgendein User in unserer Zweigstelle in Moskau und hat einen Kunden der eine Adresse bei mail.ru hat. Dies alleine ist schon Grund genug für unseren FirstLevel-Support-Mitarbeiter mich darum zu beten die Domain auf die Whitelist zu setzen. Es könnte ja eine Mail im Spamfiler hängen bleiben.
Meine Reaktion war wieder die selbe wie die letzten 50 mal:
Antwort
Yes, for sure!und die Mail löschen.
Start
Tatsächlich, dachte ich werde nie dazu gehören. Nun habe aber auch ich einen Blog. Will euch nicht vorenthalten, was ich hier als Admin in einem mittelgroßen RZ eigentlich alles so erlebe. Zum einen, weil die meisten User (bei uns zumindest) garnicht wissen, was hier eigentlich bei einem Admin alles abgeht, zum anderen, weil ich mir selbst die Geschichten garnicht alle merken kann.
Mal schauen, wie lange ich es durchhalte hier regelmäßig zu posten...
Mal schauen, wie lange ich es durchhalte hier regelmäßig zu posten...
LogProcessing - Part 1
How to analyze Apache access logs from multiple machines
oder
Wie zum Teufel kriege ich das alles unter einen Hut?
Die Problemstellung:
Wir haben in der DMZ drei Webserver. Über einen LoadBalancer bedienen alle drei sozusagen parallel sämtliche virtual Hosts. Ziel soll sein sämtliche Logs eines jeden einzelnen virtual Hosts über alle drei Webserver hinweg auf einem zentralen System im Intranet auszuwerten.
Unsere Webserver laufen (aus politischen Gründen) alle unter Windows. Aber ich denke ein fleißiger Admin da draußen kann das sicherlich auch auf Linux übertragen.
Die Lösung:
Vom Prinzip her ist es eigentlich ganz einfach. Die vier Schritte:
sämtliche Logs einsammeln, die Logs pro Domain/virtual Host aufbereiten, Logs auswerten und dann die Statistiken aggregieren.
Da beginnen jedoch die Probleme. Wie kriege ich Logs alle eingesammelt? Wie kann ich diese chronologisch sauber auswerten? Und wie aggregiere ich diese Daten?
Weiter mit Schritt 1 (Apache Logging & Logs einsammeln)...
Ablaufplan & Übersicht
oder gleich zu Schritt 2 (Logs aufbereiten)
oder Schritt 3 (Logs auswerten und eine schicke Übersicht ausgeben)
oder
Wie zum Teufel kriege ich das alles unter einen Hut?
Die Problemstellung:
Wir haben in der DMZ drei Webserver. Über einen LoadBalancer bedienen alle drei sozusagen parallel sämtliche virtual Hosts. Ziel soll sein sämtliche Logs eines jeden einzelnen virtual Hosts über alle drei Webserver hinweg auf einem zentralen System im Intranet auszuwerten.
Unsere Webserver laufen (aus politischen Gründen) alle unter Windows. Aber ich denke ein fleißiger Admin da draußen kann das sicherlich auch auf Linux übertragen.
Die Lösung:
Vom Prinzip her ist es eigentlich ganz einfach. Die vier Schritte:
sämtliche Logs einsammeln, die Logs pro Domain/virtual Host aufbereiten, Logs auswerten und dann die Statistiken aggregieren.
Da beginnen jedoch die Probleme. Wie kriege ich Logs alle eingesammelt? Wie kann ich diese chronologisch sauber auswerten? Und wie aggregiere ich diese Daten?
Weiter mit Schritt 1 (Apache Logging & Logs einsammeln)...
Ablaufplan & Übersicht
oder gleich zu Schritt 2 (Logs aufbereiten)
oder Schritt 3 (Logs auswerten und eine schicke Übersicht ausgeben)
LogProcessing - Part 2
1.) Apache Logging & Logs einsammeln
(Nochmal zurück zum Intro)
Ausgangspunkt des ganzen sind die Logs. Diese braucht man schon mal in einem Format mit dem man leicht weiter arbeiten kann.
Um das ganze ohne Probleme auswerten zu können habe ich mich für das "Combined Log Format" entschieden - die erweiterte Form des "Common Log Format".
Dies muss für unsere Zwecke jedoch noch um den "virtual Host" erweitert werden, sprich, jede Zeile beginnt nicht wie üblich mit der Client IP, sondern mit dem Host Header des virtual Host. Im Apache sieht das wie folgt aus:
Durch die zusätzliche Aufführung des Hosts (%v) spare ich mir schon einmal für jeden Host ein eigenes Log anzulegen. Das macht das ganze an den Präsentationservern draußen etwas übersichtlicher und ich habe im Prinzip nur "ein" Log. Die Anführungszeichen deshalb, da ich natürlich durch Logrotation mehrere habe. Logrotation generell ist eine tolle Sache. Ich kann die Logs alle etwas kleiner halten und kann die schon mal grob pro Tag aufteilen.
Bei uns rotieren die Logs nicht nach Zeit, sondern bei 10MB. Das ist die Größe wo ein Zugriff auf ein Log nicht ewig dauert, wir aber noch nicht zu viele Logs haben. Diese Größe sollte vielleicht je nach Belieben angepasst werden. Bei uns sieht der Eintrag für CustomLog also wie folgt aus:
Der Pfad unseres Vertrauens wohin die Logs geschrieben werden ist, wie ihr sehen könnt, "E:\logs\". Dies ist natürlich den eigenen Vorstellungen anzupassen.
"[server]" sollte natürlich entsprechend angepasst werden, selbstverständlich durch den Namen des Webservers himself - nicht irgendeiner Domain.
Diesen Eintrag macht man auch nur einmal zentral in der httpd.conf - dieser ersetzt die "CustomLog"-Direktive eines jeden einzelnen virtual Hosts!
Ein Standard virtual Host sieht bei uns übrigens so aus:
An dieser Stelle haben wir jetzt schon mal an jedem Server einen Ordner, in den maximal 10MB große Logs liegen. Sämtliche virtual Hosts loggen zusammen in dieses eine Ziel.
Der Rest ist wieder ganz einfach:
Nächtlich ein Script am kleinen Server im Intranet laufen lassen, welches aus diesen Ordnern die Logs einsammelt.
Aber Vorsicht: keine Logs im Zugriff einfach weg ziehen! Entweder kurz vorher am Webserver draußen ein Maintenancescript laufen lassen, welches den Apache restartet und Logs vom Vortag weg verschiebt, oder Rotatelog zeitlich so steuern, dass die Logs tageweise angelegt werden. Letzteres erfordert jedoch wieder Logik beim Copyscript, welches die Logsfiles einsammelt. Ich habe mich ganz billig für erstere Methode entschieden. Um 01:00 Uhr wird draußen der Apache gestoppt, die Logs in einen Copy-Ordner geschoben und Apache dann wieder gestartet. 5 Minuten danach das selbe auf dem zweiten Server und 5 Minuten danach auf dem dritten Server.
Die ganzen Logs landen dabei dann in dem Ordner "E:\logs\move" von wo sie vom zentralen Server dann alle um 05:00 Uhr abgeholt werden.
Nun sind wir also an dem Punkt, dass unser Server auf dem die Logs weiter ausgewertet werden sollen nun von sämtlichen Webservern draußen die Logs lokal hat, fein säuberlich in 10MB-Häppchen wo wild jeder virtual Host rein geloggt hat.
In Schritt 2 werden wir nun die Logs aufbereiten.
Ablaufplan & Übersicht
(Nochmal zurück zum Intro)
Ausgangspunkt des ganzen sind die Logs. Diese braucht man schon mal in einem Format mit dem man leicht weiter arbeiten kann.
Um das ganze ohne Probleme auswerten zu können habe ich mich für das "Combined Log Format" entschieden - die erweiterte Form des "Common Log Format".
Dies muss für unsere Zwecke jedoch noch um den "virtual Host" erweitert werden, sprich, jede Zeile beginnt nicht wie üblich mit der Client IP, sondern mit dem Host Header des virtual Host. Im Apache sieht das wie folgt aus:
LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" comb_vHost(Natürlich ohne Zeilenumbruch, sollte es bei euch nicht in eine Zeile passen...)
Durch die zusätzliche Aufführung des Hosts (%v) spare ich mir schon einmal für jeden Host ein eigenes Log anzulegen. Das macht das ganze an den Präsentationservern draußen etwas übersichtlicher und ich habe im Prinzip nur "ein" Log. Die Anführungszeichen deshalb, da ich natürlich durch Logrotation mehrere habe. Logrotation generell ist eine tolle Sache. Ich kann die Logs alle etwas kleiner halten und kann die schon mal grob pro Tag aufteilen.
Bei uns rotieren die Logs nicht nach Zeit, sondern bei 10MB. Das ist die Größe wo ein Zugriff auf ein Log nicht ewig dauert, wir aber noch nicht zu viele Logs haben. Diese Größe sollte vielleicht je nach Belieben angepasst werden. Bei uns sieht der Eintrag für CustomLog also wie folgt aus:
CustomLog "|bin/rotatelogs.exe E:/logs/apache_access_[server]_%Y.%m.%d_%H.%M.log 10M" comb_vHost
Der Pfad unseres Vertrauens wohin die Logs geschrieben werden ist, wie ihr sehen könnt, "E:\logs\". Dies ist natürlich den eigenen Vorstellungen anzupassen.
"[server]" sollte natürlich entsprechend angepasst werden, selbstverständlich durch den Namen des Webservers himself - nicht irgendeiner Domain.
Diesen Eintrag macht man auch nur einmal zentral in der httpd.conf - dieser ersetzt die "CustomLog"-Direktive eines jeden einzelnen virtual Hosts!
Ein Standard virtual Host sieht bei uns übrigens so aus:
<VirtualHost *:80>
ServerName [domain]
DocumentRoot E:\www\[domain]
ScriptAlias /cgi-bin/ "E:/cgi-bin/[domain]/"
RewriteEngine On
RewriteOptions Inherit
</VirtualHost>
An dieser Stelle haben wir jetzt schon mal an jedem Server einen Ordner, in den maximal 10MB große Logs liegen. Sämtliche virtual Hosts loggen zusammen in dieses eine Ziel.
Der Rest ist wieder ganz einfach:
Nächtlich ein Script am kleinen Server im Intranet laufen lassen, welches aus diesen Ordnern die Logs einsammelt.
Aber Vorsicht: keine Logs im Zugriff einfach weg ziehen! Entweder kurz vorher am Webserver draußen ein Maintenancescript laufen lassen, welches den Apache restartet und Logs vom Vortag weg verschiebt, oder Rotatelog zeitlich so steuern, dass die Logs tageweise angelegt werden. Letzteres erfordert jedoch wieder Logik beim Copyscript, welches die Logsfiles einsammelt. Ich habe mich ganz billig für erstere Methode entschieden. Um 01:00 Uhr wird draußen der Apache gestoppt, die Logs in einen Copy-Ordner geschoben und Apache dann wieder gestartet. 5 Minuten danach das selbe auf dem zweiten Server und 5 Minuten danach auf dem dritten Server.
Die ganzen Logs landen dabei dann in dem Ordner "E:\logs\move" von wo sie vom zentralen Server dann alle um 05:00 Uhr abgeholt werden.
Nun sind wir also an dem Punkt, dass unser Server auf dem die Logs weiter ausgewertet werden sollen nun von sämtlichen Webservern draußen die Logs lokal hat, fein säuberlich in 10MB-Häppchen wo wild jeder virtual Host rein geloggt hat.
In Schritt 2 werden wir nun die Logs aufbereiten.
Ablaufplan & Übersicht
LogProcessing - Part 3
2.) Logs aufbereiten
(Nochmal zurück zum Intro)
(Nochmal zum schritt 1)
Im ersten Schritt haben wir die Logs zentral gesammelt. Wir haben die netten 10MB-Häppchen von allen Servern in einem Verzeichnis. Vor jeder Logzeile im "combined" Format steht die bediente URL. So weit so gut.
Jetzt wollen wir das irgendwie auswerten. Ich habe mich an dieser Stelle für Webalizer entschieden, zum einen, weil ich mit dem Tool schon einmal gearbeitet habe und die config kenne, zum anderen weil man bei den anderen üblichen Verdächtigen das ganze nicht so komfortabel in mein Szenario pressen kann.
Um die Logs mit Webalizer auszuwerten müssen sie noch aufbereitet werden. Webalizer hat die Eigenschaft nur Einträge aufzunehmen die neuer sind wie bereits in der History berücksichtigte. Wenn wir nun die Logs so wie sie vorliegen analysieren würden hätten wir das Problem, dass erst von einem Server die Logs von Beispielsweise 10:00 - 11:00 Uhr dran kämen und dann aus dem selben Zeitraum die von den anderen beiden Servern. Nachdem wir aber den Zeitraum 10:00 - 11:00 schon vom ersten Server ausgewertet haben, würden Eintrage für Server 2 von beispielsweise 10:42 nicht mehr dazugezählt werden.
Also müssen wir erst einmal die ganzen Logs zu einem Log zusammenfassen, welches chronologisch richtig sortiert ist. Dazu bediene ich mich eines Perl-Skriptes aus der AWStats-Sammlung: "logresolvemerge.pl" aus den Tools zu AWStats.
In meinem Batchfile wird das ganze so aufgerufen:
%BATCHDIR% ist das Verzeichnis in dem meine ganzen Skripte liegen
%WORKDIR% ist das Verzeichnis in dem die ganzen logs temporär zwischengelagert werden
%MONSTERLOG% ist das Logfile, in welches die Ausgabe von logresolvemerge.pl landet (unser aggregiertes, chronologisch sortiertes Logfile)
Nachdem Webalizer 1.) mit dem virtual Host Eintrag am Anfang der Logzeile nicht viel Anfangen kann und 2.) wir sowieso alles pro Domain erst einmal auswerten wollen muss dieses Monsterlog nun aufgesplittet werden. Ich habe mir dazu ein kleines VBScript geschrieben. Aufgerufen wird das ganze so:
Übergeben wird der Pfad zu unserem Monsterlog, welches aufgeteilt werden soll und das aktuelle Arbeitsvereichnis, wohin die ganzen Logs pro Host geschrieben werden sollen.
Die kleinen Logs werden nach dem Schema "tmp_[domain]_access.log" benannt. Dabei werden auch gleichzeitig bei den ganzen Logeinträgen die virtual Hosts am Anfang abgeschnitten.
Wir haben nun also für jeden von den Webservern draußen bedienten virtual Host ein eigenes kleines, chronologisch richtig sortiertes Logfile, welches komfortabel ausgewertet werden kann.
Wenn man nur vier, fünf virtual Hosts hat könnte man auch an dieser Stelle abbrechen und die Logs wie üblich auswerten. Nachdem wir hier aber über 50 haben, habe ich keine Lust 50 Webalizer-Konfigurationen zu pflegen und den ganzen Mist anzupassen.
Weiter geht es mit Schritt 3...
Ablaufplan & Übersicht
(Nochmal zurück zum Intro)
(Nochmal zum schritt 1)
Im ersten Schritt haben wir die Logs zentral gesammelt. Wir haben die netten 10MB-Häppchen von allen Servern in einem Verzeichnis. Vor jeder Logzeile im "combined" Format steht die bediente URL. So weit so gut.
Jetzt wollen wir das irgendwie auswerten. Ich habe mich an dieser Stelle für Webalizer entschieden, zum einen, weil ich mit dem Tool schon einmal gearbeitet habe und die config kenne, zum anderen weil man bei den anderen üblichen Verdächtigen das ganze nicht so komfortabel in mein Szenario pressen kann.
Um die Logs mit Webalizer auszuwerten müssen sie noch aufbereitet werden. Webalizer hat die Eigenschaft nur Einträge aufzunehmen die neuer sind wie bereits in der History berücksichtigte. Wenn wir nun die Logs so wie sie vorliegen analysieren würden hätten wir das Problem, dass erst von einem Server die Logs von Beispielsweise 10:00 - 11:00 Uhr dran kämen und dann aus dem selben Zeitraum die von den anderen beiden Servern. Nachdem wir aber den Zeitraum 10:00 - 11:00 schon vom ersten Server ausgewertet haben, würden Eintrage für Server 2 von beispielsweise 10:42 nicht mehr dazugezählt werden.
Also müssen wir erst einmal die ganzen Logs zu einem Log zusammenfassen, welches chronologisch richtig sortiert ist. Dazu bediene ich mich eines Perl-Skriptes aus der AWStats-Sammlung: "logresolvemerge.pl" aus den Tools zu AWStats.
In meinem Batchfile wird das ganze so aufgerufen:
perl %BATCHDIR%\logresolvemerge.pl %WORKDIR%\apache_access_*.log >%MONSTERLOG%Ich arbeite in meinen Batchfiles immer mit Variablen um sie leichter anzupassen.
%BATCHDIR% ist das Verzeichnis in dem meine ganzen Skripte liegen
%WORKDIR% ist das Verzeichnis in dem die ganzen logs temporär zwischengelagert werden
%MONSTERLOG% ist das Logfile, in welches die Ausgabe von logresolvemerge.pl landet (unser aggregiertes, chronologisch sortiertes Logfile)
Nachdem Webalizer 1.) mit dem virtual Host Eintrag am Anfang der Logzeile nicht viel Anfangen kann und 2.) wir sowieso alles pro Domain erst einmal auswerten wollen muss dieses Monsterlog nun aufgesplittet werden. Ich habe mir dazu ein kleines VBScript geschrieben. Aufgerufen wird das ganze so:
CScript %BATCHDIR%\split-logfile.vbs //B %MONSTERLOG% %WORKDIR%Und hier das Skript: [klick mich]
Übergeben wird der Pfad zu unserem Monsterlog, welches aufgeteilt werden soll und das aktuelle Arbeitsvereichnis, wohin die ganzen Logs pro Host geschrieben werden sollen.
Die kleinen Logs werden nach dem Schema "tmp_[domain]_access.log" benannt. Dabei werden auch gleichzeitig bei den ganzen Logeinträgen die virtual Hosts am Anfang abgeschnitten.
Wir haben nun also für jeden von den Webservern draußen bedienten virtual Host ein eigenes kleines, chronologisch richtig sortiertes Logfile, welches komfortabel ausgewertet werden kann.
Wenn man nur vier, fünf virtual Hosts hat könnte man auch an dieser Stelle abbrechen und die Logs wie üblich auswerten. Nachdem wir hier aber über 50 haben, habe ich keine Lust 50 Webalizer-Konfigurationen zu pflegen und den ganzen Mist anzupassen.
Weiter geht es mit Schritt 3...
Ablaufplan & Übersicht