Das Problem
Oft fällt eine Störung erst auf, wenn jemand nicht mehr arbeiten kann. Ein Datenträger, der seit Wochen Fehler meldet, ein Zertifikat, das morgen abläuft, eine Sicherung, die seit Tagen nicht gelaufen ist: Die Informationen wären da, aber niemand sieht sie sich an.
Unsere Lösung
Ein zentrales Monitoring, das alle relevanten Systeme abfragt, Verläufe aufzeichnet und bei Abweichungen alarmiert. Neue Systeme kommen über den Code dazu, nicht über manuelle Klicks – so wird nichts vergessen.
Was wir überwachen
| Bereich | Beispiele |
|---|---|
| Server | Erreichbarkeit, CPU, Speicher, Datenträger – Linux und Windows |
| Virtualisierung | Proxmox-Hosts, Ceph |
| Netzwerk | Switches über SNMP, Firewall (OPNsense) |
| Dienste | Container, Webdienste, Ablauf von TLS-Zertifikaten |
| Sicherungen | Laufzeiten, Erfolg, Speicherbelegung |
Ergebnis
- Ein Überblick über die gesamte Umgebung
- Alarm bei Ausfällen und ablaufenden Zertifikaten
- Verläufe, um Engpässe früh zu erkennen
- Monitoring, das mit der Umgebung wächst, weil es aus dem Code entsteht
So gehen wir vor
- Bestandsaufnahme – Welche Systeme, welche Schwellen, wer wird alarmiert?
- Aufbau – Monitoring bei Ihnen oder in unserem Rechenzentrum.
- Anbindung – Systeme und Netzwerkgeräte einbinden.
- Alarmregeln – gemeinsam festlegen, was wirklich alarmiert.
- Dashboards – Übersicht für Ihr Team.
- Betrieb – Pflege und Reaktion nach Vereinbarung.
Leistungsumfang
- Aufbau oder Übernahme des Monitorings
- Anbindung von Servern, Proxmox, Ceph, Netzwerk und Firewall
- Alarmregeln
- Dashboards
- laufende Pflege
Technischer Einblick
Prometheus mit node_exporter und windows_exporter für Server, SNMP-Exporter für Switches, Exporter für OPNsense, cAdvisor für Container und Traefik für Webdienste. Alertmanager alarmiert per E-Mail. Grafana zeigt Dashboards für Rechenzentrum und Sicherungen; Backup-Metriken laufen zusätzlich über InfluxDB. Der gesamte Stack wird per Ansible ausgerollt. Für Sicherheitsereignisse, Schwachstellen und Härtungsprüfung setzen wir zusätzlich Wazuh ein.
Warum cloudbase.run
- Wir überwachen unsere eigene Infrastruktur mit genau diesem Stack.
- Monitoring entsteht aus dem Code – neue Systeme werden nicht vergessen.
- Kombinierbar mit Dokumentation: dieselben Systeme, eine Quelle.
Für wen geeignet
- Unternehmen mit eigenen Servern und Netzwerk ohne zentrales Monitoring
- Bestehende Monitoring-Installationen, die niemand mehr pflegt
Für wen nicht geeignet
- Wer eine 24/7-Leitstelle mit garantierter Reaktionszeit sucht, solange wir keine Bereitschaft anbieten
- Reine Anwendungs-Performance-Analyse (APM) großer Softwareplattformen