Motivation

Regelmäßig gesellen sich neue Dienste und Geräte in den eigenen Verantwortungsbereich, so dass es immer schwieriger wird im Auge zu behalten, ob ein Dienst gerade seinen Dienst verrichtet oder nicht. In der Vergangeheit wurde das ganze mittels Prometheus, Telegraf, InfluxDB, Loki und Grafana gelöst. Doch leider isi selbst diese Konstruktion recht Komplex und daher auf anfällig für unbemerkte Ausfälle. Nach längeren Recherchen bin ich auf das Tool Statping-ng gestoßen, welches selbst als Go-Binary verfügbar ist und somit sehr einfah zum Laufen gebracht werden kann. Dank eines Enpunktes für Prometheus kann das Tool selbst auch von Prometheus ausgelesen werden und somit entfällt die Notwendigkeit von Scrapern wie z.B. den BlackboxExporter. Das führt auch gleich zu den eigentlichen Möglichkeiten wie Statping-ng das Monitoring abbildet: HTTP-Probes, TCP-Cheks, ICMP-Checks, DNS-Checks. Somit eignet sich das Tool ebenfalls um eizelne Geräte im Netzwerk, wie z.B. Drucker, Modem, Router, Regelungen auf Ihre Erreichbarkeit zu prüfen und je nach Konfiguration über diverse Meldewege (darunter auch Slack oder Telegram) über einen Ausfall zu berichten.

Der erste Test

Für den ersten Test wurde einfach, die auf der github-Seite des Tools zur Verfügung stehende Binary heruntergeladen und ausgeführt. Nach dem Start der Anwendung ist unter http://localhost:8080 das Webinterface der Anwendung erreichbar. Nach kurzer Einrichtung wird das Ganze mit Beispieldaten gefüllt und man kann sofort beginnen zu testen. Beim testen sind mir ein paar Dinge aufgefallen, die einer Anpassung des Tools bedürfen:

• Ankündigungen sind nur global und nicht für einzelne Services über die API abrufbar.
• Redundanz von Informationen in der öffentlichen Darstellung (Dashboard)
• Fehlende Summierung der Subservices einer Gruppe
• Ein- und Ausklappen von Gruppen nicht möglich => Übersichtlichkeit bei vielen Subservices nicht vorteilhaft
• Anzeige der prozentualen Verfügbarkeit in der Übersicht wäre wünschenswert

Anpassungsarbeiten

Anpassungen am Backend

1. Erweiterung der Services-API um eine einfache möglichkeit Ankündigungen auf Service-Ebene darzustellen:
   • Einfügen einer Route in handlers/routes.go:

     api.Handle("/api/services/{id}/messages", scoped(apiServiceGetMessages)).Methods("GET")
     

   • Implementieren der dazugehörigen Funktion in handlers/services.go:

     func apiServiceGetMessages(r *http.Request) interface{} {
     	srv, err := findService(r)
     	if err != nil {
     		return err
     	}
     	msgs := srv.Messages
     	return msgs
     }
     

2. Permalink auch in der API nutzbar machen
   • Implementieren einer Find-Funktion unter Verwendung des Permalink in types/services/database.go:

     func FindPermaLink(id string) (*Service, error) {
     	for _, service := range allServices {
     		if service.Permalink.String == id {
     			return service, nil
     		}
     	}
     	return nil, errors.Missing(&Service{}, id)
     }
     

   • Verwenden der Funktion in handlers/services.go:

     if id == 0 && servicer == nil {
     	servicer, err = services.FindPermaLink(vars["id"])
     }
     

Anpassungen am Frontend

Am Frontend selbst habe ich zahlreiche Anpassungen vorgenommen. Teils die fehlende Übersetzung in die deutsche Sprache nachgepflegt, redundante Elemente entfernt und die Servicegruppen bzw. Services schmaler und daurch etwas übersichtlicher dargestellt. Da die Änderungen recht Umfangreich waren, verweise ich gerne auf das GitHub-Repository und präsentiere hier nur einen Screenshot vom Ergebnis:

Installation der “Spezialversion”

Das GitHub-Repository ist ein Fork des Originalprojektes und wurde von mir so konfiguriert, dass die GitHub-Actions Pipeline bei jeder Änderung eine neue Version (für amd64) erzeugt und als Binary in den Artefakten ablegt. Somit könnt ihr einfach die Binary herunterladen und das Ganze als Anwendung starten.