Bei den Cloud Creators entwickeln wir nicht nur Cloud-Anwendungen für unsere Kunden, sondern übernehmen auf Wunsch auch den Betrieb und die kontinuierliche Wartung von Software und Infrastruktur. Damit dies zuverlässig gelingt müssen wir alle Systeme zentral im Blick haben und wissen, was auf unseren Servern passiert. Um Logs zu zentralisieren, setzen wir das Log-Aggregationssystem “Loki” ein, das von den Machern von Grafana stammt. Grafana selbst verwenden wir dann, um Logs zentral zu durchsuchen, zu filtern und in unseren Dashboards darzustellen.

Logs vs Metriken

Loki ist, salopp gesagt, für Logs, was Prometheus für Metriken ist. Dazu ist wichtig zu verstehen, worin der Unterschied liegt: Prometheus Metriken sind reine Zahlenwerte, deren Verlauf in sog. Zeitreihen abgespeichert wird. Sie können zwar annotiert werden, die dafür verwendeten Labels bleiben innerhalb einer Zeitreihe aber immer gleich. Metriken eignen sich also hervorragend, um Kenngrößen wie z. B. die CPU-Auslastung oder den verfügbaren Speicherplatz eines Servers zu überwachen.

Logs dagegen sind eine Sammlung von Textzeilen, die mit einem Zeitstempel versehen sind. Auch Logs können mit statischen Labels annotiert werden, die dazu dienen, zuzuordnen, woher die Log-Zeilen stammen und welche Systeme sie betreffen. Logs eignen sich also vor allem dazu, uns mitzuteilen, was genau auf den entsprechenden Systemen vor sich geht. Anders als Prometheus verfolgt Loki zudem einen “Push” Ansatz, bei dem Ereignisse jederzeit und vor allem auch unregelmäßig eingehen können. Dadurch eignet sich Loki auch dazu, uns über außergewöhnliche Ereignisse zu informieren.

Wie die Logs zu Loki kommen

Loki ermöglicht es, Logs effizient und durchsuchbar abzuspeichern, sodass wir jederzeit schnell herausfinden können, was gerade im Moment auf den unterschiedlichen Systemen unserer Kunden passiert oder aber in der Vergangenheit passiert ist. Dafür stellt Loki eine HTTP API zur Verfügung, über die Daten eingespeist und auch abgefragt werden können.

Es ist also möglich Logs direkt nach Loki zu schreiben und beispielsweise für die Ergebnisse aus unseren regelmäßigen Trivy Container-Image Scans machen wir das auch genau so. Damit das reibungslos funktioniert, mussten wir allerdings ein eigenes kleines Tool entwickeln und dabei einiges beachten, wie z. B. sicherzustellen, dass Daten, beispielsweise bei vorübergehenden Netzwerkproblemen, nicht verloren gehen.

Für Logs, wie sie auf Linux Servern üblicherweise anfallen, stellt Loki das Tool “Promtail” zur Verfügung, das Logs, z. B. aus Dateien an Loki weiterreichen kann.

Wir setzen allerdings stattdessen auf das mächtigere Tool “Vector.dev”. Es unterstützt eine Vielzahl an unterschiedlichen Quellen für Logs, bietet großartige Möglichkeiten Logs auszusortieren, umzuformatieren oder durch externe Quellen anzureichen. Vor allem aber kann es als flexible Middleware für Loki eingesetzt werden, um z. B. besagte Anreicherung zentral, an einer Stelle vorzunehmen, bevor die Daten in Loki abgespeichert werden. Das erleichtert den Konfigurationsaufwand und entlastet die Server unserer Kunden.

Wie das Ergebnis aussehen kann, zeigt der folgende Screenshot eines unserer Dashboards, das die Herkunftsländer von unerlaubten Zugriffsversuchen auf einen unserer SSH-Server zeigt.

Diese Art von Brute-Force-Login-Versuchen kennt vermutlich jeder, der einen Server betreibt und zeigt, warum man auf jeden Fall lange und gute Passwörter verwenden oder gleich auf andere Authentifizierungsmethoden setzen sollte. Interessant ist übrigens, dass es für Mailserver nicht viel besser aussieht, aber die Verteilung nach Ländern deutlich anders ausfällt. Die Spammer dieser Welt scheinen also anderswo zuhause zu sein.

Wie wir Loki absichern

Dieses Beispiel zeigt: Wo ein Server offen ist, wird auch jemand versuchen darauf zuzugreifen. Auch wenn wir das von Kunden ab und zu hören, hilft es auf gar keinen Fall, darauf zu vertrauen, dass “es ja niemand weiß”.

Leider bietet Loki selbst keine Möglichkeit, Zugriffe zu authentifizieren. Neben den zur Verfügung stehenden Firewall Einstellungen, setzen wir deshalb einen sog. Reverse Proxy ein. Das bedeutet, dass Loki nicht direkt aus dem Internet erreichbar ist, sondern nur über einen vorgeschalteten HTTPS Server. In unserem Fall sorgt er dafür, dass nur verschlüsselte Verbindungen erlaubt sind und nur von Clients, die sich durch ein entsprechendes Zertifikat ausweisen können (TLS Client Auth). Außerdem sorgt der Reverse Proxy dafür, dass die Logs von verschiedenen Kunden getrennt voneinander beim richtigen Loki-Tenant gespeichert werden. So stellen wir gleichzeitig sicher, dass unsere Kunden nicht auf die Logs anderer Kunden zugreifen können.

Wenn auch Sie Unterstützung bei der Überwachung Ihrer Infrastruktur oder beim Betrieb Ihrer Anwendung benötigen, dann sprechen Sie mit uns!