Monitoring, das Ihnen gehört.

Matmon ist die schlanke Alternative zu den großen Monitoring-Suiten. Sensoren, Probes, Alarme, Logs, Wallboards und Berichte – auf Ihrem eigenen Docker-Host oder als Windows-Dienst, mit einer optionalen Cloud, wenn Sie Reichweite brauchen.

Loslegen
  • Über 40 Sensortypen
  • Docker oder Windows-Dienst
  • Selbst gehostet, läuft offline
  • Standorte ohne offenen Port
  • Privat kostenlos
Architektur

Verbindungen und Datenflüsse

Jede Verbindung wird von innen nach außen aufgebaut. Keine eingehenden Ports an entfernten Standorten. Verbindung wählen für Richtung, Protokoll, Port und Inhalt.

Überwachte Netze

Matmon PrimaryDocker (ghcr.io/real-ttx/matmon) oder Windows-Dienst
Primary – TCP 8099
  • Web-UI und REST-API
  • Sensor-Scheduler
  • Alarmierung und Eskalation
  • Verlauf und Berichte
  • Syslog- / Trap-Empfang
  • Backups

Gesamter Zustand in einem Datenvolume (/app/data). Keine Cloud-Abhängigkeit.

Benutzer und Dienste

VerbindungOpt-inInitiatorAntwort
Probe → Primary · HTTP(S), TCP 8099 · nur ausgehend

Übertragen

  • Heartbeat alle 30 s
  • Abruf der Sensorzuweisungen, Sofort- und Discovery-Jobs
  • Messergebnisse

Nicht übertragen

  • Keine eingehende Verbindung zum Probe-Standort
  • Keine Verbindung zur Matmon Cloud

Details

  • Auth: X-Matmon-Probe-Token
  • Primary nicht erreichbar: Ergebnisse auf Disk gepuffert (7 Tage / 100.000), Nachlieferung mit Originalzeitstempel
Agent → Primary · HTTP(S), TCP 8099 · nur ausgehend

Übertragen

  • Gleiches Protokoll wie die Probe: Heartbeat, Zuweisungen, Ergebnisse
  • Lokale Metriken: CPU, Speicher, Datenträger
  • Update-Prüfung gegen den Primary (stündlich)

Nicht übertragen

  • Kein eingehender Port, kein WinRM oder SSH nötig
  • Keine Verbindung zur Matmon Cloud

Details

  • Registrierung: matmon-agent enroll --url … --code … (Einmal-Code); Klartext-HTTP zu öffentlichem Host wird abgelehnt
  • Windows-Dienst (LocalSystem), systemd, launchd
  • Eigenständige Binary: win-x64, linux-x64, linux-arm64, macOS
Primary oder Probe → Gerät · Syslog / Traps → Matmon

Übertragen

  • Abfrage: ICMP, HTTP(S), DNS, TCP, SNMP, Hersteller-APIs (Proxmox, Hyper-V, Synology …)
  • Eingehend: Syslog UDP/TCP 514, SNMP-Traps UDP 162 – nur mit aktiviertem Empfänger

Nicht übertragen

  • Keine Software auf dem Gerät
  • Zugangsdaten nicht im Klartext – DataProtection-verschlüsselt, auch im Backup

Details

  • Geräte in einem entfernten Netz fragt die Probe in diesem Netz ab
  • Empfänger laufen auf Primary, Probe oder Agent
Browser → Primary · HTTP, TCP 8099

Übertragen

  • Web-UI, REST-API, Wallboards (Nur-Lesen-Links)
  • Web-Push an die installierte PWA

Nicht übertragen

  • Kein externer Identity Provider nötig – lokale Konten funktionieren offline

Details

  • Kein eingebautes TLS: HTTPS am Reverse Proxy terminieren (Matmon__TrustedProxies)
  • Zugriff von außen ohne Portweiterleitung: Full Access über die Matmon Cloud
Primary → SMTP-Server / Webhook-URL · direkt

Übertragen

  • Alarmmeldungen per SMTP
  • Webhooks: ntfy, Pushover, Gotify, Telegram, Teams, Slack, Discord, eigene

Nicht übertragen

  • Kein Umweg über Matmon-Server – außer beim Absender „Matmon Cloud“

Details

  • SMS und Anruf nur über den Absender Matmon Cloud, nur bei kritischen Alarmen
Primary → cloud.matmon.eu · HTTPS 443 · ausgehend, Opt-in

Übertragen

  • Heartbeat alle 30 s: Version, Hostname, Anzahlen (Sensoren, Probes, Karten, Alarme), Name / Version / Status der Probes
  • Cloud-Absender: Empfänger und Alarmtext; SMS / Anruf: nur Zusammenfassung
  • Backups (manuell oder geplant): Konfiguration, Secrets verschlüsselt; Verlauf optional
  • Full Access: UI über einen WebSocket-Tunnel (wss), aufgebaut vom Primary

Nicht übertragen

  • Messwerte im Heartbeat
  • Zugangsdaten im Klartext
  • Eingehende Verbindungen zum Primary
  • Datenverkehr von Probes oder Agents

Details

  • Auth: X-Matmon-Instance-Token nach PKCE-Claim
  • Eigene Schalter: Alarm-Weiterleitung, Full Access, Backup-Ziel
  • Verbindung aus: Überwachung läuft weiter; SMS / Anruf, Fernzugriff und Cloud-Backups entfallen

Mehr: So funktioniert Matmon →

So sieht es aus

Die echte Matmon-Oberfläche, die öffentliche Infrastruktur überwacht. Kein Mockup – schalten Sie die Seite auf dunkel, und die Bilder folgen.

Das Matmon-Dashboard: Sensorzahlen, Statusleiste und Live-SensorenDas Matmon-Dashboard: Sensorzahlen, Statusleiste und Live-Sensoren

Das Dashboard – Zahlen, der Sensorstatus auf einen Blick, hervorgehobene Sensoren und jeder Live-Wert.

Matmon sensor tree with folders, hosts and sensor chipsMatmon sensor tree with folders, hosts and sensor chips

Ein Baum für alles – Probes, Ordner, Hosts und Sensoren mit ihren Live-Werten.

Matmon sensor detail page with value cards, channels and a latency chartMatmon sensor detail page with value cards, channels and a latency chart

Jeder Sensor mit seinen Kanälen, Schwellwerten und der Statistik der letzten Stunde, des Tages und der Woche.

Matmon Events page, Syslog tab: device messages and SNMP traps with severity, sender and programMatmon Events page, Syslog tab: device messages and SNMP traps with severity, sender and program

Das zentrale Log – was Switches, Firewalls und Server melden, dazu die SNMP-Traps einer USV, in einer durchsuchbaren Live-Liste (hier von Demo-Geräten).

Matmon notification sender: a webhook with the ntfy preset, its address, method, headers and bodyMatmon notification sender: a webhook with the ntfy preset, its address, method, headers and body

Ein Push-Absender in zwei Klicks: Vorlage ntfy wählen (oder Pushover, Gotify, Telegram, Teams, Slack, Discord) – die Anfrage ist ausgefüllt.

Matmon wallboard on a TV: health, open alerts, clock, latency and certificate widgetsMatmon wallboard on a TV: health, open alerts, clock, latency and certificate widgets

Ein Wallboard aus Widgets, über seinen Nur-Lesen-Link auf dem Bildschirm an der Wand.

The Matmon menu on a phone, with the alert status at the topThe Matmon menu on a phone, with the alert status at the topA Matmon sensor with its latency chart on a phoneA Matmon sensor with its latency chart on a phone

Jede Seite funktioniert auf dem Handy: das Menü wird zur Schublade, Tabellen werden zu Karten – und Matmon lässt sich als App installieren.

Für sensible Netze gebaut

Ihre Messdaten bleiben, wo sie entstehen.

Matmon ist ein Monitoring, das Sie selbst betreiben. Das gilt ohne jede Einstellung:

Läuft ohne Cloud

Überwachung, Alarme per E-Mail und Webhook, lokale Konten und die Lizenzprüfung funktionieren offline.

Kein offener Port am Standort

Probes und Agents verbinden sich ausgehend. Selbst der Fernzugriff über die Cloud ist ein Tunnel, den Ihr Matmon öffnet.

Keine Telemetrie

Keine Analyse, kein „Nach Hause telefonieren“. Die Cloud-Verbindung ist freiwillig und jeder Teil hat einen Schalter.

Geheimnisse bleiben verschlüsselt

Gerätezugänge werden verschlüsselt gespeichert – auch im Backup. Eine Backup-Passphrase versiegelt ein Paket für einen anderen Rechner.

Ein Datenordner

Alles, was Matmon speichert, liegt in einem Volume. Umziehen heißt: Ordner kopieren.

Lizenz offline geprüft

Ein signierter Lizenzschlüssel, geprüft auf Ihrem Server – mit Kulanzzeit, falls die Cloud nicht erreichbar ist.

So funktioniert Matmon – Verbindung für Verbindung →

DockerLinux-Server, NAS, Raspberry Pi
docker compose up -d Compose-Datei
WindowsWindows 10 / 11, Windows Server
Setup mit Dienst und Tray-Symbol .exe herunterladen
Matmon CloudReichweite, Alarme aufs Telefon, Statusseiten
Jede Instanz im Setup verbinden Bei der Cloud anmelden

Neuigkeiten

  • Agent hosts can be notebooks: with "This machine may be offline" a silent agent shows the host offline for how long instead of an error and raises no alert, warns only after a …
  • Template sets for pfSense (over SNMP: ping, CPU, load, memory, packet filter and its states, the WAN interface, the web certificate) and STARFACE phone systems (SIP answer, …
  • A Proxmox VE Backup Jobs sensor: the backup jobs of a node or cluster with one channel per covered guest - the result of its last backup (failed backups named with Proxmox's …
  • Backup sensors per task: the Proxmox Backup Server sensor has a channel per backed-up guest (hours since its last backup, named after the guest, a failed backup of it shown), …
  • Run now on an agent or probe no longer waits behind its sensor pass (run jobs have their own loop, one check per sensor type at a time); a run that takes longer than 12 s shows …

Alle Änderungen