Noch immer denken die meisten Admins intuitiv an Nagios & Co., wenn es um das Thema Monitoring geht. Zweifellos spielen jene Werkzeuge bis heute eine große Rolle, doch wirken sie in jüngerer Zeit zunehmend altbacken: Moderne Tools wie Prometheus laufen den alteingesessenen Lösungen zunehmend den Rang ab.
Osquery von Facebook ist dafür ein weiteres Beispiel: Das Programm soll gerade für riesige Serverflotten Echtzeitmonitoring der wichtigsten Systeme ermöglichen, ohne ins Schwitzen zu geraten. Dabei mutet die Art des Zugriffs auf die von Osquery erhobenen Daten anfangs etwas abenteuerlich an: Will der Admin die aktuellen Vitalwerte eines Systems erfahren, nutzt er dazu ein SQL-ähnliches Interface direkt auf dem Host oder holt sich die gewünschten Daten per Log-Aggregator beim Server ab.
Dieser Artikel stellt Osquery vor, erläutert, wie es sich auf Linux- und Windows-Systemen installieren lässt, und zeigt die wichtigsten Anwendungsfälle im Alltag.
Um die Motivation hinter Osquery zu verstehen, hält man sich am besten vor Augen, wie klassische Monitoring-Systeme funktionieren. Die grundlegenden Prinzipien sind immer die gleichen: Ein zentraler Monitoring-Dienst bekommt von Hosts Monitoring-Resultate entweder zugeschickt oder holt sich diese ab. Ergebnisse entstehen dadurch, dass das Monitoring-System auf den jeweiligen Systemen eine Vielzahl so genannter Checks ausführt. Oft sind das banale Shell-Skripte, die irgendeine Funktionalität des Zielsystems testen. Im Netz finden sich für die diversen Monitoring-Systeme tausende Skripte, mit denen sich beinahe jeder Aspekt eines modernen Betriebssystems überwachen lässt.
Das Problem: All diese Checks wirken nicht wie aus einem Guss, sondern eher wie ein Flickenteppich. Erschwerend kommt hinzu, dass Nagios & Co. keine feste Sammlung von Default-Checks mitbringen, um entfernte Systeme zu überprüfen. Baut ein Admin also ein neues Monitoring-System, fängt er auch mit der Konfiguration der grundlegenden System-Checks für einzelne Hosts wieder bei Adam und Eva an. Dass es keine generalisierte Schnittstelle zu den Daten von Nagios & Co. gibt, auf die sich aus anderen Diensten heraus zugreifen lässt, ist da fast schon ein untergeordnetes Problem.
Hier setzt Osquery an. Das Werkzeug hat gar nicht den Anspruch, Lösungen wie Nagios & Co. komplett zu ersetzen. Das Ziel der Facebook-Entwickler, die für Osquery verantwortlich zeichnen, war ein anderes: Osquery bietet für eine Vielzahl verschiedener Betriebssysteme ein basales Low-Level-Monitoring. Auf den Zielsystemen lässt sich mittels Osquery etwa schnell herausfinden, welche Benutzer gerade eingeloggt sind, welche USB-Geräte angeschlossen sind oder ob ein bestimmter Dienst aktuell läuft.
Die Funktionsvielfalt von Osquery geht allerdings weit über das bloße Anzeigen angeschlossener Geräte hinaus. Neben der Monitoring-Komponente spielen auch das Thema Sicherheit und damit einhergehend das Thema Compliance eine große Rolle. Wer etwa regelmäßig überprüfen möchte, ob auf einem System bestimmte Regeln der Host-Firewall geladen sind, wie viele lokale Anwender gerade eingeloggt sind oder ob sich Dateien im Verzeichnis "/etc" ungeplant verändern, kriegt mit Osquery dafür ebenfalls das richtige Tool an die Hand.
Wer sich erstmals mit Osquery beschäftigt, wird über die Vielfalt der unterstützten Betriebssysteme staunen. Anders als viele andere Werkzeuge geben die Entwickler sich nämlich nicht mit dem Klassiker Linux zufrieden. Ein aktuelles Osquery ist nämlich auch auf allen gängigen Windows-Varianten und auf macOS lauffähig. Die Schnittstelle zur Anwenderseite, also die Art und Weise, wie der Nutzer aus Osquery Daten abfragt, ist auf Grundlage einer generischen API meist gleich. Es ist also egal, ob ein System Windows, Linux oder macOS nutzt: Die Anfrage mittels Osquery, um eine bestimmte Information zu erhalten, ist gleich.
Ausnahmen bilden hier freilich Spezifika im Hinblick auf einzelne Betriebssysteme: macOS etwa loggt Ereignisse, die mit dem Authentifizierungssystem zu tun haben, in das Apple System Log. Soll Osquery also von Macs etwa Informationen über die "sudo"-Aufrufe der letzten Stunden liefern, muss Osquery dafür in anderen Logs nachsehen als auf einem Linux-System. Entsprechend unterscheiden sich die Anfragen an den Dienst (Bild 1).
Mittlerweile beherrscht Osquery allerdings auch eine Art eingebautes Discovery, auf dessen Basis sich Anfragen an Bedingungen knüpfen lassen. Der Admin könnte im oben genannten Beispiel also einfach eine ASL-Abfrage für alle Systeme des Setups starten und die Bedingung definieren, dass der OS-Typ macOS sein muss. Osquery führt die Abfrage dann nur auf jenen Systemen aus, die zur festgelegten Bedingung passen.