Dem GoogleBot auf der Spur

Google versucht immer mehr Urls in den Index zu bekommen und geht dabei teils kuriose Wege. Da werden Urls beliebig neu zusammengebaut, Javascript-Links falsch interpretiert und beliebige Urls erstellt. Um da den Überblick zu behalten und frühzeitig eingreifen zu können, muss man sich passender Strategien und Tools bedienen. Eines dieser Tools ist Splunk. Und das stelle ich in diesem Beitrag vor.

Diesen Beitrag habe ich im Januar 2014 angefangen zu schreiben. Das Thema war SplunkStorm. Gestern, fast ein Jahr später habe ich den Podcast von Jens und Markus gehört. Und da erzählt der Knut, dass sie gerade Splunk testen. Da dachte ich mir: Der passende Zeitpunkt für die Veröffentlichung meines Blogbeitrags ist gekommen. Aber wie die Zeit vergeht: SplunkStorm nimmt keine neuen Kunden mehr auf und es gibt wiedermal ein neues Produkt. SplunkCloud! Deshalb habe ich mir den alten Artikel genommen und mit den neuen Features von SplunkCloud neu geschrieben. Es hat sich einiges getan. Los geht’s:

Was macht der Googlebot?

Die Crawl-Statistiken in den Google Webmastertools sind recht nett, helfen jedoch nicht wirklich bei der tiefergehenden Analyse der Bot-Zugriffe. Sobald es darum geht, zu erfahren, welche Urls Google gecrawled hat, benötigt man eigene Daten. Gerade bei neu erstellten Seiten möchte man wissen, wann Google das erste Mal die Seite gecrawled hat. Ein weiterer wichtiger Punkt ist: crawled Google nur die richtigen Urls? Es gibt zwar Tools wie strucr, onpage, deepcrawl, ScreamingFrog und Konsorten, aber so langsam entwickelt sich der GoogleBot weiter und crawled auch Javascript-Links. Die genannten Tools crawlen bisher nur „normale“ Links. Um genauer zu analysieren, was Google da so veranstaltet, helfen die Tools an der Quelle. Und die Quelle ist in diesem Fall der eigene Webserver/ das eigene System.

LogFiles: Datenquelle der Vergangenheit

Bevor es GoogleAnalytics gab, waren WebControlling-Systeme, die per Javascript-Snippet die Zugriffe zählten, entweder teuer oder aufwendig. Deshalb benutzte man Logfile-Tools wie awstats. Die waren nicht so genau, denn sämtliche Bots wurden mitgezählt. Wegen der Ungenauigkeit ist die Logfile-Analyse für Websites in Vergessenheit geraten. Jedoch finden wir in den Logfiles alle Zugriffe des GoogleBots. Das machen wir uns zu nutze! Früher nutzte man dafür gerne Mescalero oder ähnliches, heute geht es in der Cloud:

SplunkCloud: Logfile-Analyse als Software-as-a-Service

Der Markt der Logfile-Analyse-Tools ist relativ groß. Diese Tools sind nicht speziell für die Auswertung von Website-Zugriffen gemacht, sondern haben als Ziel das generelle Verarbeiten von Maschinen-Meldungen. Splunk ist schon recht lange auf dem Markt vertreten und hat sich als Anbieter etabliert. Splunk hat mehrere unterschiedliche Tools auf dem Markt. Diese unterscheiden sich nur leicht im Namen. Damit du nicht durcheinander kommst, hier eine kurze Auflistung:

• SplunkCloud (Software-as-a-Service), ist Thema dieses Blogposts
• SplunkStorm (Vorgänger von SplunkCloud, es werden keine neuen Accounts mehr erstellt)
• SplunkEnterprise (Software für den eigenen Server, unterschiedliche Lizenzen, siehe weiter unten)

Mit dem Nachfolger von SplunkStorm hat Splunk einen großen Schritt in Richtung Usability gemacht. Die Kinderkrankheiten sind weg und nun kann man die Webserver-Logs problemlos importieren. Mit der Sandbox kann man SplunkCloud 15 Tage kostenlos testen. Die Limits sind 5GB/ Tag bzw. 28GB insgesamt. Zum Testen reichen diese Limits!

So kommen die Daten zu SplunkCloud

Für gelegentliches Analysieren von Logfiles bietet sich das händische Hochladen der Logfiles an. Dabei dürfen die Dateien beim Upload über den Browser bis zu 500MB groß sein. Die Art des Logfiles, in meinem Fall Apache, hat Splunk direkt erkannt. Für eine dauerhaftes Auswerten der Daten ist der händische Upload eher lästig.

Während ich beim alten SplunkStorm entweder die REST-Api genutzt habe oder aber die Daten direkt mit SysLog zum System geschickt habe, gibt es beide Möglichkeiten nicht mehr. Jetzt bietet Splunk die Möglichkeit entsprechende Forwarder zu benutzen. Das beschränkt die Nutzer leider auf diejenigen, die Vollzugriff auf ihren Server haben. Vor einem Jahr hatte ich den Forwarder auch getestet, der lieft auf meinem Server aber nicht sehr stabil. Ich gehe davon aus, dass der auch gut weiter entwickelt wurde.

Möglichkeiten der Abfragen

Neben dem Erstellen dauerhafter Dashboards bietet Splunk als grundlegendes Feature auch die Möglichkeit spontane Abfragen (adhoc) auf die Daten zu machen. Die Oberfläche ist hübsch aufgeräumt:

Diese Daten sind von der Domain „zedwoo.de“ und beinhalten nur ein paar Tage. Die folgenden Beispielabfragen und Screenshots beruhen auf den Daten einer echten Seite mit ca. 5GB an Logfiles. Da es Kundendaten sind, zeige ich nur das Diagramm. Im Original sieht man natürlich auch die Urls. Mit diesen Beispielabfragen sieht jeder, welche Macht in den Daten steckt.

Beispielabfragen

So oft kommt der Googlebot vorbei:

So oft kommt der Bilderbot vorbei:

Wie sieht es bei einer einzelnen Url aus. Wird die regelmäßig gecrawled?

Welche Seiten crawled der GoogleBot, sind aber gar nicht vorhanden (404):

Diese Screenshots zeigen nur einen kleinen Ausschnitt aus den Möglichkeiten mit Splunk. Natürlich gibt es auch einen CSV-Export und die Möglichkeit, Dashboards zu erstellen. Wem die vorhanden Funktionen von Splunk noch nicht reichen, kann entweder die Apps nutzen oder aber selber Apps programmieren.

Weitere mögliche Fragen wären:

• Crawled Google Urls mit Session-Id?
• Crawled Google im Verzeichnis der Css-Dateien?
• Crawled Google Dateien, die in der robots.txt ausgeschlossen wurden?
• Crawled Google Urls mit Parametern?

Du weißt noch mehr spannende Fragen? Dann schreib die unten in die Kommentare!

Die Möglichkeiten, die vorhandenen Daten zu analysieren, sind schier unerschöpflich und auch bei großen Datenmengen innerhalb von Sekunden erledigt.

Kosten

Splunk war schon immer sehr unübersichtlich in der Anzeige der Kosten. Aber während es bei Splunkstorm einen netten kostenlosen Account gab, sind diese Zeiten jetzt vorbei. SplunkCloud als SaaS soll bei 675$ im Monat beginnen. Für den eigenen Server staffeln sich die Preise nach Daten pro Tag in GB: 1.800$ (jährlich) oder 4.500$ (einmalig).

Und dann gibt es noch eine Free-Lizenz, die greift, wenn man nicht mehr als 500MB an Daten pro Tag auf den Splunk-Server schaufelt. Das sollte für die meisten Zwecke ausreichen.. Auf ein paar besondere Features der Enterprise-Version muss man dann leider verzichten.

Wenn es nicht ausreicht und man nur die Google-Zugriffe auswerten möchte, kann man die Logfiles vor dem Upload auf die entsprechenden Einträge reduzieren. Wie man das mit wenigen Befehlen auf der Konsole macht, wird vielleicht schon bald hier im Blog stehen,

Fazit

Splunk ist ein sehr gutes Tool, wenn man Logfiles jeglicher Art analysieren möchte. Es vereinfacht die Arbeit mit großen Datenmengen enorm. Die Veränderungen seit SplunkStorm sind fein und mit dem neu geschaffenen Bereich der Apps hat es einiges an Potenzial. Auch wenn ich lieber im OpenSource-Bereich unterwegs bin, werde ich Splunk auf jeden Fall im Auge behalten.