Schnittstellen

Server Registrierung

Endpoint: /monitoring/register

Beim Start des Agent, überprüft dieser, ob er bereits eine ID vom Watcher-Server zugewiesen bekommen hat.

Hardware Info

Endpoint: /monitoring/hardware-info

Ist der Agent erfolgreich registriert, schickt er einmalig beim starten seine Hardwareinformationen an den Server.

eingehender Wert		Einheit
CpuType	Typ-Bezeichnung des eingebauten CPU
CpuCores	Anzahl an CPU-Kernen
GpuType	Typ-Bezeichnung der eingebauten Grafikkarte
RamSize	Größe des verfügbaren Arbeitsspeichers

Server Metrics

Endpoint: /monitoring/metric

Im Serverweiten Tick-Rythmus von 30 Sekunden schickt der Agent einen Metric-Payload an den Server. Dieser Payload beinhaltet die folgenden Werte:

Metric	eingehender Wert	umgerechneter Wert
CPU_LOAD	prozentual	keine Umrechnung
CPU_TEMP	°C	keine Umrechnung
RAM_LOAD	prozentual	keine Umrechnung
RAM_SIZE	Byte	GigaByte
GPU_LOAD	prozentual	keine Umrechnung
GPU_TEMP	°C	keine Umrechnung
GPU_VRAM_LOAD	prozentual	keine Umrechnung
GPU_VRAM_SIZE	Bytes	GigaByte
NET_RX	Bytes/s	Megabit/s
NET_TX	Bytes/s	Megabit/s
DISK_USAGE	Bytes	Gigabyte
DISK_SIZE	Bytes	Gigabyte
DISK_TEMP	°C	keine Umrechnung

Service Discovery

Endpoint: /monitoring/service-discovery

Beim Start schickt der Agent eine Liste aller auf seinem Host laufenden Container:

Attribut	Beschreibung	Docker Variable
ServerId	ID des Hosts auf dem der Container läuft	#
ContainerId	ID des Containers auf dem Host	?
Image	Image, das der Container verwendet	image
Name	Name den der Container auf dem Host hat	container_name

Diese Daten werden einmalig gesendet und können über einen manuellen refresh aktualisert werden (kommt irgendwann). ContainerId / Image / Name werden in Form eines Container Objektes in json-Format übergeben.

Service Metrics

noch nicht implementiert

ServerListener

Endpoint: /api/message

Frägt beim Server an ob eine neue (aktive) Message für den Client existiert.

Wenn eine existiert, dann kann der Client diese Anfragen und in nutzbare Daten umwandeln.

(Im Zuge der Überreichung muss die Nachricht deaktiviert werden - am besten mit einem boolean; wenn die Nachricht stets verfügbar bleibt wird sie immer wieder vom Client abgefragt)

Kommentar: data kann container id enthalten für welche die angegebene message_type ausgeführt wird.

Die ServerListenerDto sieht wie folgt aus:

/// Command message received from the backend server.
///
/// ## Fields
/// - `message_type`: Type of command (e.g., "update_image", "restart_container", "stop_agent")
/// - `data`: Command payload (arbitrary JSON)
/// - `message_id`: Unique identifier for acknowledgment
#[derive(Debug, Deserialize, Clone)]
pub struct ServerMessage {
    pub message_type: String,
    pub data: serde_json::Value,
    pub message_id: String,
}