SuWiMo Documentation

#

SuWiMo
Documentation

Indholdsfortegnelse: * [1. Introduktion og Formål](#1-introduktion-og-formål) * [2. Arkitektur og Overordnet Design](#2-arkitektur-og-overordnet-design) * [2.1 Central Hub (SuWiMoHub)](#21-central-hub-suwimohub) * [2.2 Plugin-baseret Design](#22-plugin-baseret-design) * [3. Sensorer](#3-sensorer) * [3.1 Sensorinterface](#31-sensorinterface) * [3.2 Statusniveauer](#32-statusniveauer) * [3.3 Passiv Sensorlogik](#33-passiv-sensorlogik) * [4. Hierarkisk Struktur (Træstruktur)](#4-hierarkisk-struktur-træstruktur) * [4.1 Dynamisk Træ via Konfiguration](#41-dynamisk-træ-via-konfiguration) * [4.2 Statuspropagering](#42-statuspropagering) * [5. Notifikationssystem og Logging](#5-notifikationssystem-og-logging) * [5.1 Notifier Interface](#51-notifier-interface) * [5.2 Historik og Logging](#52-historik-og-logging) * [6. Distribution og Decentralisering](#6-distribution-og-decentralisering) * [6.1 AssetAZ Observables](#61-assetaz-observables) * [6.2 Distribuerede Hubs](#62-distribuerede-hubs) * [7. Brugsscenarier og Eksempler](#7-brugsscenarier-og-eksempler) * [8. Fremtidige Funktioner / TODO](#8-fremtidige-funktioner--todo)

1. Introduktion og Formål

SuWiMo (Surveillance Without Moving) er et system udviklet til enkel og effektiv statusovervågning af mange uafhængige sensorer organiseret i en hierarkisk træstruktur. Formålet med SuWiMo er at give et hurtigt, visuelt overblik over systemets tilstand, hvor status let kan aflæses som grøn (OK), gul (advarsel) eller rød (kritisk fejl).

SuWiMo fokuserer på tillidsvalidering og identificering af afvigelser i realtid, snarere end detaljeret monitorering eller datalogging som traditionelle overvågningssystemer.

2. Arkitektur og Overordnet Design

2.1 Central Hub (SuWiMoHub)

SuWiMoHub fungerer som den centrale orchestrator, der står for al polling, statusvurdering og statuspropagering i træstrukturen. Hubben håndterer ikke selv sensorlogik, men trækker på plugins via interfaces.

• Centraliseret styring af polling-interval.
• Indlæsning af sensor- og notifier-plugins.
• Dynamisk opbygning og opdatering af status-træet.

2.2 Plugin-baseret Design

SuWiMo benytter en modulær plugin-arkitektur, hvor forskellige typer af plugins implementerer specifikke interfaces efter deres funktion:
• Sensor-plugins implementerer sensorinterface til overvågning og statusrapportering.
• Notifier-plugins implementerer notifierinterface til at sende notifikationer ved statusændringer.
• Logger-plugins implementerer logningsinterface til historisk registrering af statusændringer.

Disse plugins registreres og administreres af Nenjim-systemet, hvilket sikrer nem distribution, versionering og udskiftelighed.

3. Sensorer

3.1 Sensorinterface

Sensorer implementerer et simpelt, standardiseret interface:

public interface SuwimoSensor {
    SensorStatus poll();
}
public class SensorStatus {
    StatusLevel level;  // GREEN, YELLOW, RED
    String message;     // Kort forklaring på tilstand
}

3.2 Statusniveauer

• Green: Normal drift.
• Yellow: Advarsel, kræver opmærksomhed.
• Red: Kritisk fejl, kræver øjeblikkelig handling.

3.3 Passiv Sensorlogik

Sensorer kører ikke aktivt. De er passive komponenter, som kun evaluerer og returnerer deres status, når hubben poller dem.

4. Hierarkisk Struktur (Træstruktur)

4.1 Dynamisk Træ via Konfiguration

Træstrukturen defineres i en JSON-konfigurationsfil, hvor hver node har et unikt ID, et navn, en valgfri sensor og en parent-reference. Eksempel:

[
  { "id": "internet", "name": "Internetforbindelse", "sensor": "PingGoogle", "parent": null },
  { "id": "zfs-check", "name": "ZFS array", "sensor": "ZfsStatus", "parent": "server01" },
  { "id": "server01", "name": "Serverrummet", "sensor": null, "parent": null }
]

4.2 Statuspropagering

Den dårligste status blandt børn og egen sensor propagerer op gennem træet. Det gør det muligt at se den værste tilstand hurtigt fra en node eller træets rod.

5. Notifikationssystem og Logging

5.1 Notifier Interface

Notifikationskomponenter implementerer et interface, der reagerer på statusændringer:

public interface SuwimoNotifier {
    void statusChanged(SensorEvent event);
}
public class SensorEvent {
    String sensorId;
    StatusLevel oldStatus;
    StatusLevel newStatus;
    String message;
    ZonedDateTime timestamp;
}

5.2 Historik og Logging

Historiske log-events registreres hver gang en sensor ændrer tilstand. Denne funktionalitet implementeres som et separat plugin, der eksempelvis kan logge til fil, database eller anden ekstern tjeneste.

6. Distribution og Decentralisering

6.1 AssetAZ Observables

SuWiMoHub eksponerer sin status som en AssetAZ Observable. Det gør det muligt for andre hubs eller AssetAZ-instanser at abonnere på sensorstatus fra eksterne hubs.

6.2 Distribuerede Hubs

Flere SuWiMoHubs kan installeres decentralt, tæt på de ressourcer de overvåger, og udveksle sensorstatus via AssetAZ's P2P-netværk. Dette sikrer effektiv isolation af fejl og lokal robusthed.

7. Brugsscenarier og Eksempler

Eksempler på anvendelser af SuWiMo:
• Overvågning af servermiljøer (CPU, RAM, ZFS arrays)
• Netværksstatus (Internet-ping, DNS-opløsning)
• Overvågning af applikationstilgængelighed og integritet (HTTP-checks med checksum)
• Husovervågning (temperatur, dørsensorer, strøm)

8. Fremtidige Funktioner / TODO

• Implementering af GUI med træstruktur (træk-og-slip sensororganisering)
• Avanceret historikvisning (grafer og mønstergenkendelse)
• Yderligere notifier-plugins (push-notifikationer, SMS, Discord, syslog)
• Avancerede permissions og adgangskontrol
• Automatisk timeout-tilstand (sensor bliver rød efter manglende respons)