Systemüberwachung

Übersicht

Die Überwachung von PlantPulse besteht aus 3 Schichten. Durch die kombinierte Nutzung der Werkzeuge jeder Schicht können Probleme frühzeitig erkannt und schnell behoben werden.

Schicht	Verantwortung	Frequenz
L1 Host/Stack	Container-Status/Health, Ressourcenauslastung, Health-Antworten	Jede Minute bis 5 Min. (Auto/Manuell)
L2 Plattform-integriert	Geschäftsmetriken pro Modul (Durchsatz, Lag, Warteschlangentiefe, JVM)	Echtzeit
L3 Externe Überwachung	Langzeittrends, Alarme, konsolidierte Ansicht über mehrere Hosts	Echtzeit

Plattform-Servicemodule

PlantPulse besteht aus mehreren Servicemodulen, die mit dem Präfix plantpulse- beginnen. Module und Container stehen nicht in einer 1:1-Beziehung — sechs Applikationen haben jeweils einen eigenen Container, während die übrigen Infrastrukturmodule gemeinsam in einem einzigen plantpulse-datalake Container laufen.

Ort	Modul
Eigener Container	plantpulse-server-web · plantpulse-batch-web · plantpulse-warehouse-web · plantpulse-plugin-opcua · plantpulse-plugin-aasx · plantpulse-ha
Im plantpulse-datalake Container	storage · messaging · analytics · timeseries · workflow · cep · data-gateway · sql · monitor · backup

Der Status auf Containerebene wird auf dem Host über bin/status.sh geprüft, während der Status der Module innerhalb des Data Lake über status.sh im Container eingesehen wird. Die unten aufgeführten «Ports» sind die Ports, die das Modul innerhalb des Containers öffnet; nur ein Teil davon wird auf dem Host geöffnet → Port-Konfigurationsinformationen

Kern-Servicemodule

Modul	Port	Beschreibung
plantpulse-server	80 / 443	Webserver und Verwaltungskonsole, REST API
plantpulse-cep	7400 / 7401	Complex Event Processing Engine (Aster CEP)
plantpulse-batch	9500	Batch-Verarbeitungsserver
plantpulse-data-gateway	5500	Daten-Gateway (HTTP REST-basierte Datenabfrage)
plantpulse-datalake-admin-api	4950 (HTTPS)	API der Verwaltungskonsole und Überwachungsagent. Einziger Health-Port, der auf dem Host veröffentlicht wird
plantpulse-warehouse-web	9600	Data Warehouse
plantpulse-plugin-opcua	11004 / 11005	OPC-UA Server-Plugin
plantpulse-plugin-aasx	(Host nicht öffentlich)	AASX Server-Plugin
plantpulse-ha	10210	Redundanz-Wiederherstellungsdaemon
plantpulse-proxy	80 / 443 / 1883 / 1884	Einziger Zugangspunkt für Benutzer und Anlagen

Messaging-Module (plantpulse-messaging)

Service	Port	Beschreibung
Kafka	9092	Distribuiertes Message Streaming
MQTT	1883	Leichtgewichtiges IoT-Messaging-Protokoll
MQTT Enterprise	-	MQTT Enterprise Edition

Storage-Module (plantpulse-storage)

Service	Port	Beschreibung
Cassandra 6.0	9042	Zeitreihen-Datenbank (CQL)
PostgreSQL	5432	Relationale Datenbank für Metadaten
Valkey (Redis)	6379	In-Memory Cache
RustFS	9000	Object Storage (S3 kompatibel)
JanusGraph	-	Graph-Datenbank
RustFS / WeedFS	-	Distribuiertes Dateisystem

Analyse-Module (plantpulse-analytics)

Service	Port	Beschreibung
Spark Master	7077	Distribuiertes Analyse-Engine
Spark UI	4440	Spark Verwaltungskonsole
Kyuubi	10000	Distribuiertes SQL-Gateway (JDBC/Thrift)
Gravitino	19001	Datenkatalog
Hadoop	-	Distribuiertes Dateisystem
Hive	-	Data Warehouse Query Engine

Zeitreihen-Module (plantpulse-timeseries)

Service	Port	Beschreibung
Zeitreihen-Engine	7800	Engine zur Verarbeitung von Zeitreihendaten
Zeitreihen-UI	3000	UI zur Visualisierung von Zeitreihendaten

Workflow-Module (plantpulse-workflow)

Service	Port	Beschreibung
Temporal	7233	Distribuiertes Workflow-Engine (Web UI 8233)
Kestra	8380	Workflow-Orchestrierung / Scheduler

Utility-Module

Modul	Beschreibung
plantpulse-datalake-cli (pd)	CLI für Start/Stopp/Neustart, Konfiguration und Knotenmanagement des Data Lake
plantpulse-setup	Initial Setup Tool (Modelle, CSV-Konfiguration)
plantpulse-backup	Backup-Service
plantpulse-recovery	Datenwiederherstellungstool
plantpulse-exporter	Asset-Daten-Exporttool
plantpulse-migrator	Datenmigrationstool (Spark-basiert)
plantpulse-mirror-maker	Datenreplikationstool
plantpulse-simulator	Datensimulator (für Tests)
plantpulse-api	REST API Client-Bibliothek

Überprüfung des Service-Status

Prüfen Sie zuerst den Gesamtstatus des Stacks auf dem Host.

cd /opt/kopens/plantpulse-platform-docker/bin
./status.sh          # 0 = 정상 / 2 = 비정상
./ops-check.sh       # 헬스 + 최근 critical log

Den Status der Infrastrukturmodule auf Port-Ebene prüfen Sie innerhalb des Data-Lake-Containers.

./shell.sh
/opt/kopens/plantpulse-platform/plantpulse-datalake-cli/bin/pd status

Beispielausgabe:

==============================================================================================================
 PLANTPULSE PLATFORM - ALL SERVICE STATUS
 2026-03-01 12:00:00
==============================================================================================================

<SYSTEM RESOURCE OVERVIEW>
--------------------------------------------------------------------------------------------------------------
 포트   서비스                     상태
--------------------------------------------------------------------------------------------------------------
 9092   PP_MESSAGING[KAFKA]        ● RUNNING
 1883   PP_MESSAGING[MQTT]         ● RUNNING
 9042   PP_STORAGE[CASSANDRA]      ● RUNNING
 5432   PP_STORAGE[POSTGRESQL]     ● RUNNING
 6379   PP_STORAGE[REDIS]          ● RUNNING
 9000   PP_STORAGE[MINIO]          ● RUNNING
 7077   PP_ANALYTICS[SPARK-MASTER] ● RUNNING
 4440   PP_ANALYTICS[SPARK-UI]     ● RUNNING
 10000  PP_ANALYTICS[KYUUBI]       ● RUNNING
 19001  PP_ANALYTICS[GRAVITINO]    ● RUNNING
 7233   PP_WORKFLOW[ENGINE]        ● RUNNING
 8380   PP_WORKFLOW[BATCH]         ● RUNNING
 7800   PP_TIMESERIES[ENGINE]      ● RUNNING
 3000   PP_TIMESERIES[UI]          ● RUNNING
 7400   PP_CEP                     ● RUNNING
 5500   PP_DATA_GATEWAY            ● RUNNING
 4000   PP_SQL                     ● RUNNING
 4950   PP_MONITOR                 ● RUNNING
 60000  PP_AGENT                   ● RUNNING
 80     PP_SERVER                  ● RUNNING
 9500   PP_BATCH                   ● RUNNING
 9600   PP_WAREHOUSE               ● RUNNING
 11004  PP_PLUGIN[OPCUA]           ● RUNNING

In der obigen Liste werden App-Container nicht angezeigt

status.sh innerhalb des Data Lake betrachtet nur die Module dieses Containers. Es handelt sich nicht um eine Störung, auch wenn die Einträge PP_SERVER · PP_BATCH · PP_WAREHOUSE · PP_PLUGIN als STOPPED angezeigt werden oder ganz fehlen — diese Applikationen laufen in ihren eigenen Containern, und die Beurteilung erfolgt über bin/status.sh auf dem Host.

Umgebungsvariablen

Werte auf der Hostseite werden durch /opt/kopens/plantpulse-platform-docker/bin/env.sh bestimmt, während die Werte, die der Container tatsächlich sieht, durch compose/docker-compose.yml festgelegt werden. Detaillierte Beziehungen und Prioritäten finden Sie in der Referenz für Umgebungsvariablen. Nachfolgend sind die Namen aufgeführt, die innerhalb des Containers gültig sind.

Variable	Beschreibung	Beispiel
PP_SCHEME	Schemaname	PP
PP_MODE	Betriebsmodus	MASTER
PP_HOST_IP	Interne IP	192.168.0.41
PP_SERVICE_IP	Service-IP	192.168.0.41
PP_MASTER_IP	Master-Knoten-IP	192.168.0.41
PP_DATA_DIR	Datenverzeichnis	/data1/pp-data
PP_TEMP_DIR	Temporäres Verzeichnis	/data1/pp-temp
PP_BACKUP_DIR	Backup-Verzeichnis	/data1/pp-backup
PP_CLUSTER_CORES	Anzahl der Cluster-CPU-Kerne	16
PP_CLUSTER_MEMORY_BY_CORE	Speicher pro Kern	2G
PP_OPTIONS	Zusätzliche Optionen (JSON)	{"use-infra":true,"use-app":true}

Überwachungsobjekte

Nachfolgend sind die wichtigsten Objekte und Elemente aufgeführt, die auf der PlantPulse-Plattform überwacht werden sollten. Eine regelmäßige Überprüfung dieser Punkte trägt zu einem stabilen Betrieb bei.

Objekt	Überwachungspunkte
Applikationsserver	CPU, Speicher, Disk, Threads
JVM	Heap-Speicher, GC, Class Loading
PostgreSQL	Connection Pool, Query-Performance, Disk
Aster TSDB	Cluster-Status, Latenz, Compaction
Redis	Speicher, Hit-Rate, Verbindungsanzahl
Engine	Pipeline-Durchsatz, Warteschlangentiefe, Fehlerrate
Netzwerk	OPC-Verbindung, WebSocket, Latenz

Überwachung über die Webkonsole

Systemüberwachungsbildschirm

Pfad: /monitoring/index

Zeigt den Echtzeit-Systemstatus in Form eines Dashboards an. Wenn eine Kennzahl den «Normalbereich» in der folgenden Tabelle verlässt, kann dies die Ursache für eine Performance-Minderung sein und sollte überprüft werden.

Kennzahl	Beschreibung	Normalbereich
CPU-Auslastung	CPU-Last des Servers	< 70%
JVM Heap-Speicher	Heap-Auslastung / Maximum	< 80%
Aktive Threads	Anzahl der laufenden Threads	< 500
MPS (Messages/sec)	Anzahl der verarbeiteten Nachrichten pro Sekunde	Unter dem eingestellten Rate-Limit
Pipeline-Warteschlange	Anzahl der wartenden Nachrichten	< 10.000
DB-Verbindungen	Anzahl der aktiven DB-Verbindungen	< Pool-Maximum

Serverstatus

Pfad: /server/status

Punkt	Beschreibung
Server-Betriebszeit	Uptime
Engine-Status	RUNNING / STOPPED / ERROR
Letzter Startzeitpunkt	Zeitstempel des letzten Engine-Starts
Versionsinformation	Plattformversion

Log-Überwachung

Logs sind Textdateien, die den Betriebszustand des Systems aufzeichnen. Bei Problemen hilft die Analyse der Logs erheblich bei der Ursachenermittlung.

Auf dem Host — logs.sh

Da es acht Container gibt, ist es am schnellsten, ohne Argumente zu starten, wenn nicht bekannt ist, in welchem Container das Problem liegt.

cd /opt/kopens/plantpulse-platform-docker/bin

./logs.sh                              # 여덟 컨테이너를 시간순으로 한 화면에 (서비스 이름 접두)
./logs.sh plantpulse-server-web -n 200 # 웹 서버 컨테이너
./logs.sh cassandra                    # 데이터레이크 안 컴포넌트 로그 파일
./logs.sh --list                       # 볼 수 있는 대상 전체 (그 시점의 실제 목록)
./logs.sh -f plantpulse-server-web     # 계속 따라가기 (Ctrl-C 로 종료)

Standardmäßig werden die letzten N Zeilen (Standard 200) ausgegeben und der Vorgang beendet. Um den Logs zu folgen, fügen Sie -f hinzu.

Log-Dateien im Container

# 웹 서버 — 자기 컨테이너 안에 있습니다
./shell.sh plantpulse-server-web
tail -f /opt/kopens/plantpulse-platform/plantpulse-server/logs/system.log
grep -i "ERROR\|EXCEPTION" /opt/kopens/plantpulse-platform/plantpulse-server/logs/system.log | tail -100

# 인프라 — 데이터레이크 컨테이너 안
./shell.sh
tail -f /opt/kopens/plantpulse-platform/plantpulse-storage/db/cassandra/logs/system.log

Um Logs gesammelt auf den Host zu kopieren, verwenden Sie ./tools/copy-log-to-local.sh; für Bundles zur Support-Anfrage nutzen Sie ./doctor.sh.

Log-Level

Level	Beschreibung
INFO	Informationen zum Normalbetrieb
WARN	Warnmeldungen (z.B. Performance-Minderung, Wiederholungsversuche)
ERROR	Fehler aufgetreten (Verarbeitungsfehler, Verbindungsfehler etc.)

Wichtige Log-Muster

Ergreifen Sie bei Auftreten der folgenden Log-Muster die entsprechenden Maßnahmen:

Muster	Bedeutung
Engine started successfully	Engine wurde erfolgreich gestartet
Pipeline queue overflow	Pipeline-Warteschlange überschritten — bitte Verarbeitungsgeschwindigkeit prüfen
Cassandra connection failed	Verbindung zu Aster TSDB fehlgeschlagen — bitte Cluster-Status prüfen
OPC connection lost	Verbindung zum OPC-Server unterbrochen — bitte Netzwerk und OPC-Server prüfen
Rate limit exceeded	Durchsatz überschritten — bitte Wert für engine.pipeline.ratelimit anpassen

Datenbanküberwachung

Eine regelmäßige Überwachung des Datenbankstatus hilft dabei, Performance-Minderungen oder Ausfälle präventiv zu verhindern.

PostgreSQL

# 활성 연결 확인
psql -h HOST -U plantpulse -d pp -c "
SELECT count(*) as active_connections
FROM pg_stat_activity
WHERE state = 'active';"

# 느린 쿼리 확인
psql -h HOST -U plantpulse -d pp -c "
SELECT pid, now() - pg_stat_activity.query_start AS duration, query
FROM pg_stat_activity
WHERE state != 'idle' AND now() - pg_stat_activity.query_start > interval '5 seconds'
ORDER BY duration DESC;"

# 테이블 크기 확인
psql -h HOST -U plantpulse -d pp -c "
SELECT relname, pg_size_pretty(pg_total_relation_size(relid))
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 10;"

Aster TSDB

# 클러스터 상태
nodetool status

# 테이블별 통계
nodetool tablestats pp

# 컴팩션 상태
nodetool compactionstats

# GC 로그 확인
nodetool gcstats

# 지연 히스토그램
nodetool tablehistograms pp tm_tag_point

Aster TSDB Statuscodes:

Status	Beschreibung
UN	Up / Normal — Normalzustand
DN	Down / Normal — Knoten ist ausgefallen
UJ	Up / Joining — Tritt dem Cluster bei
UL	Up / Leaving — Verlässt den Cluster

Redis

# Redis 상태 확인
redis-cli -a 설치-시-변경 INFO

# 메모리 사용량
redis-cli -a 설치-시-변경 INFO memory

# 키 수 확인
redis-cli -a 설치-시-변경 DBSIZE

# 슬로우 로그
redis-cli -a 설치-시-변경 SLOWLOG GET 10

JMX-Überwachung

Hinweis: JMX (Java Management Extensions) ist eine Technologie, die es ermöglicht, den internen Zustand von Java-Applikationen extern zu überwachen. PlantPulse stellt über JMX mehr als 150 Attribute zur Verfügung.

JMX-Verbindung

# JMX 포트 활성화 (setenv.sh에 추가)
export JAVA_OPTS="$JAVA_OPTS \
  -Dcom.sun.management.jmxremote \
  -Dcom.sun.management.jmxremote.port=9090 \
  -Dcom.sun.management.jmxremote.ssl=false \
  -Dcom.sun.management.jmxremote.authenticate=false"

JMX MBean

• ObjectName: plantpulse:name=MBean
• Kategorien: engine, cache, storage, network, pipeline, cep, scheduler, monitoring sowie 4 weitere (insgesamt 12)

Wichtige JMX-Attribute

Attribut	Beschreibung
engine.status	Engine-Status
engine.uptime	Betriebszeit
pipeline.queue.size	Pipeline-Warteschlangengröße
pipeline.mps	Nachrichten pro Sekunde
cache.tag.count	Anzahl der gecachten Tags
storage.cassandra.status	Aster TSDB Verbindungsstatus

Codahale Metrics

Hinweis: Codahale Metrics ist eine Bibliothek zur Erfassung von Performance-Kennzahlen einer Applikation. In PlantPulse werden über 70 Metriken erfasst, die unter dem Pfad /admin/tool/metrics eingesehen werden können.

Metrik-Typen

Typ	Beschreibung
Counter	Kumulativer Zähler (z.B. Anzahl Ereignisse, Anzahl Fehler)
Timer	Misst Verarbeitungszeiten (Durchschnitt, p95, p99)
Histogram	Zeigt die Verteilung von Werten (Warteschlangentiefe, Batch-Größe)
Gauge	Zeigt den Wert zum aktuellen Zeitpunkt (Aktive Verbindungen, Speicher)

Standard-Healthcheck-API

Web-Apps und Plugin-Services bieten einen Healthcheck-Endpunkt gemäß der gemeinsamen Plattformspezifikation an: GET /api/health. In den Haupt-Web-Apps (server / batch / cep / sql / data-gateway) bedeutet dieser Endpunkt Readiness. Ein Status UP wird nicht allein dadurch gemeldet, dass der Prozess (Kontext) läuft, sondern nur dann, wenn die interne Engine / Kernabhängigkeiten normal funktionieren und die App bereit ist, Traffic zu empfangen (Plattform-Designentscheidung 2026-06).

curl -fsS http://127.0.0.1:9500/api/health
# 준비 완료:           200 {"status":"UP","service":"plantpulse-batch-web","ts":1765500000000,"checks":{"timer":true,"redis":true}}
# 기동 진행 중:         503 {"status":"STARTING",...}
# 기동 후 의존성 다운:   503 {"status":"DEGRADED",...,"checks":{...}}

• Readiness — meldet 200 UP nur bei vollständiger Bereitschaft. Während des Startvorgangs wird 503 STARTING gemeldet, und wenn nach dem Start einige Abhängigkeiten ausfallen, wird 503 DEGRADED zurückgegeben.
• Kein Dependency-Ping — «checks» lesen nur die In-Memory-Statusflags, die jeder Service bereits pflegt (Live-DB-Abfragen oder Netzwerk-Pings sind untersagt, um die Datenspeicher nicht durch Polling zu belasten).
• Anonymer Zugriff — kann ohne Authentifizierung aufgerufen werden (für Betriebsprüfungen / automatisierte Deployment-Verifizierung).
• Caching-Verbot — Header der Reihe Cache-Control: no-cache sind immer enthalten.
• Die Antwortfelder bestehen aus status / service (Artefaktname) / ts (epoch ms) sowie checks (DetailsService-Check-Details) für Readiness- promovierte Services.

Service	Health URL	Bedeutung	checks / Bemerkung
server	http://HOST:80/api/health	readiness	engine — Engine-Lifecycle-Status (UP nur bei Abschluss aller vorherigen Startphasen RUNNING)
batch	http://HOST:9500/api/health	readiness	timer (Batch-Pipeline läuft) / redis (InMemory-Verbindung)
cep	http://HOST:7400/api/health	readiness	engine (CEP Engine+Consumer+Recovery abgeschlossen) / redis (InMemory-Verbindung)
sql	https://HOST:4001/api/health	readiness	database_manager (DB-Manager Initialisierung abgeschlossen) — wird über HTTPS bereitgestellt
data-gateway	http://HOST:5500/api/health	readiness	database / inmemory / query_log — nur dieser Pfad ist von HTTPS-Zwang (CONFIDENTIAL) ausgenommen, localhost-HTTP-Probes sind erlaubt
warehouse (S3 Service)	http://HOST:9600/api/health	readiness	temporal — Status der Temporal-Worker-Registrierung. Wenn nicht registriert: STARTING + 503 (Webserver startet zuerst, Worker folgt, daher ist 503 unmittelbar nach Boot normal). Enthält 3 gemeinsame Felder + System/JVM-Metriken
plugin — AAS V3	http://HOST:8090/api/health	liveness	Keine Readiness-Promovierung
plugin — OPC-UA Browse UI	http://HOST:12780/api/health	liveness	Port konfiguriert über opc.ua.browser.ui.port (Standard 12780)

Es gibt zwei Verwendungszwecke:

1. Betriebsprüfung — manuelle Überprüfung, crontab / externe Überwachung mittels Readiness-Probes.
2. Automatisierte CI-Deployment-Verifizierung — ein deploy:dev Job pollt nach dem Deployment diese URL (DEPLOY_HEALTH, 240 Sek.), um den Start zu bestätigen (siehe Konfigurations- und Deployment-Guide). Da es die Readiness bedeutet, ist ein 503 während des Bootvorgangs normal; das Polling wartet auf den Wechsel zu UP.

Rollenunterscheidung: plantpulse-datalake-admin-api (:4950) ist ein Infrastruktur-Überwachungsagent, der Host-, JVM- und Modulkennzahlen sammelt und exponiert, während /api/health der von jeder Web-App selbst bereitgestellte Readiness-Endpunkt ist. Sie ersetzen sich nicht gegenseitig, sondern ergänzen sich.

In Containerumgebungen wird die Readiness jeder App bereits durch den Healthcheck von Compose beurteilt, sodass der Operator mit einer einzigen Zeile bin/status.sh die Beurteilung aller acht Container gleichzeitig erhält.

Healthcheck-Skripte

Mit Healthcheck-Skripten kann automatisch überprüft werden, ob die wichtigsten Dienste der Plattform ordnungsgemäß funktionieren.

Automatischer Healthcheck

Nachfolgend finden Sie ein Beispielskript zur automatischen Überprüfung des Status der Hauptservices:

#!/bin/bash
# healthcheck.sh

# 표준 헬스체크 (GET /api/health)
BODY=$(curl -fsS -m 5 http://localhost/api/health 2>/dev/null)
case "$BODY" in
  *'"status":"UP"'*) : ;;  # 정상
  *) echo "[ALERT] PlantPulse server is not responding: ${BODY:-no response}"
     # 알림 발송 로직 추가
     ;;
esac

# PostgreSQL 체크
pg_isready -h HOST -p 5432 -U plantpulse
if [ $? -ne 0 ]; then
    echo "[ALERT] PostgreSQL is not responding"
fi

# Cassandra 체크
nodetool status | grep -q "^UN"
if [ $? -ne 0 ]; then
    echo "[ALERT] Cassandra node is down"
fi

# Redis 체크
redis-cli -a 설치-시-변경 ping | grep -q "PONG"
if [ $? -ne 0 ]; then
    echo "[ALERT] Redis is not responding"
fi

Sie können dieses Skript in die crontab eintragen, um es periodisch auszuführen:

# 5분마다 헬스체크
*/5 * * * * /opt/scripts/healthcheck.sh >> /var/log/plantpulse-healthcheck.log 2>&1

PlantPulse Dashboard Überwachungs-Dashboards

Die Plattformüberwachung wird visuell über das PlantPulse Dashboard bereitgestellt. URL für den Zugriff: http://localhost:3000/

Hinweis: Das PlantPulse Dashboard ist ein mitgeliefertes Datenvisualisierungstool, das verschiedene Metriken von PlantPulse in Graphen und Charts darstellt. Im PLANTPULSE-Ordner werden standardmäßig 5 Dashboards bereitgestellt.

---

1. PlantPulse - Server

Dies ist das Kern-Dashboard, mit dem der Gesamtzustand des Plattformservers auf einen Blick erfasst werden kann.

SUMMARY (Zusammenfassung)

Panel	Typ	Beschreibung
VERSION	Stat	Informationen zur Plattformversion
Serverstartdatum	Stat	Zeitstempel des ersten Engine-Starts
CPU-Last	Gauge	CPU-Auslastung des Servers
Speicherauslastung	Gauge	Speicherauslastung des Servers
Empfang pro Sekunde	Stat	Empfangene Nachrichten pro Sekunde (MPS)
Gesamtspeicherungen	Stat	Kumulierte Anzahl der gespeicherten Daten
Netzwerkverzögerung	Stat	Netzwerkverzögerung beim Nachrichtenerhalt (ms)
Diagnose	Stat	Status der Diagnoseereignisse

SERVER-METRICS (Server-Metriken)

Panel	Typ	Beschreibung
CACHE / MQTT / KAFKA / WEBSOCKET / DATABASE / TSE	Stat	Verbindungsstatus der jeweiligen Services
Server-CPU-Auslastung	Graph	Zeitreihe der CPU-Auslastung
Server-Speicherverbrauch	Graph	Zeitreihe des Speicherverbrauchs
JAVA Heap-Verbrauch	Graph	JVM Heap-Speicherverbrauch
Daten-DISK R/W Status	Graph	Disk-Lese-/Schreibverkehr
Empfang pro Protokoll	Graph	Empfangsvolumen nach Protokoll (OPC, MQTT, Kafka etc.)
Empfangsverzögerung	Graph	Zeitreihe der Netzwerkverzögerung
Gesamtempfangsvolumen	Graph	Kumulatives Nachrichtenvolumen
Empfang pro 1 Sekunde	Graph	Trend des Nachrichtenerhalts pro Sekunde
Pipeline-Warteschlange	Graph	Pipeline-Warteschlangentiefe
Pipeline-Offload-Queue	Graph	RocksDB Offload-Warteschlange
Pipeline-Validierungsfehler	Graph	Anzahl der fehlgeschlagenen Validierungen
Pipeline-Worker-Zeit	Graph	Bearbeitungszeit der Worker
Timeout-Nachrichten-Backup	Graph	Anzahl der Timeout-Nachrichten-Backups
Pipeline-Sammler	Graph	Betriebsstatus des Sammlers
Storage-Speicherpuffer	Graph	Größe des Speicherpuffers
Streaming-Durchsatz	Graph	WebSocket-Streaming-Durchsatz
Streaming-Aktiv-Threads	Graph	Anzahl aktiver Streaming-Threads
Streaming-Warteschlange	Graph	Anzahl der wartenden Streaming-Einträge
Storage-Speicherungen	Graph	Anzahl der DB-Speicherungen
Storage-Batch-Vorgänge	Graph	Anzahl der Batch-Speicherungen
Storage-Worker-Anzahl	Graph	Anzahl der Speicher-Worker
DDS-Verarbeitung	Graph	Anzahl der Kafka-DDS-Verteilungen
Async-Thread-Aktiv-Count	Graph	Anzahl aktiver asynchroner Threads
Async-Thread-Pool-Größe	Graph	Größe des Thread-Pools
Diagnosefehlerrate	Graph	Trend der Diagnosefehler
Logging-Ausnahmen	Graph	Trend der Ausnahme-Logs
GC-Zeit	Graph	JVM GC-Dauer
DISK-Auslastung	Graph	Trend der Diskauslastung

---

2. PlantPulse - Data Lakehouse

Dieses Dashboard überwacht die Performance und den Status der Datenbank- und Storage-Schichten.

DATA-GATEWAY (Daten-Gateway)

Panel	Beschreibung
TOTAL_QUERY	Gesamtzahl der Abfragen
QPS	Abfrage-Durchsatz pro Sekunde (Gauge)
QUERY_LATENCY	Zeitreihe der Abfragelatenz
QUERY_LATENCY_MAX	Maximale Abfragelatenz
SUCCESS / ERROR	Anzahl der Erfolge und Fehler

CACHE (REDIS)

Panel	Beschreibung
CLIENTS	Anzahl der Redis-Clientverbindungen
ALLOCATOR	Status des Speicherzuweisers
KEY_COUNT	Anzahl der gespeicherten Schlüssel
FRAGMENTATION	Speicherfragmentierungsrate

CEP

Panel	Beschreibung
JAVA_HEAP_USED	CEP-Engine Heap-Speicher
EVENT_INGESTION_RATE	Event-Ingestionsrate
EQL_CPU_TIME	Keine Werte — CEP misst keine CPU-Zeit pro Aussage
EQL_MAP_COUNT	Anzahl der bereitgestellten EQL-Aussagen
EVENT_INGEST_DIFF	Event-Ingestion-Differenz
EVENT_DELAY_HISTOGRAM	Event-Verzögerungsverteilung
CEP_STATEMENT_MATCH_RATE	Statement-Matching-Rate
EQL_STATEMENT_OUTPUT_RATE	Statement-Ausgaberate

META-STORE (POSTGRES)

Panel	Beschreibung
TOTAL_CONNECTIONS	Gesamtzahl der Verbindungen
QUERY_LATENCY	Abfragelatenz
TOTAL_READS_HITS	Anzahl der Lesezugriffe
TOTAL_DB_SIZE	Gesamte DB-Größe

EVENT-STORE (CASSANDRA)

Panel	Beschreibung
NATIVE_CLIENT	Native Client-Verbindungen
LATENCY	Lese-/Schreiblatenz
READ_PER_SECONDS / WRITE_PER_SECONDS	Lese-/Schreibvorgänge pro Sekunde
HEAP / DIRECT_MAPPED_MEMORY	JVM-Speicher
CACHE / CACHE_HIT_RATE	Cache und Hit-Rate
TOTAL_DATA_SIZE	Gesamte Datengröße
MEMTABLE	Memtable-Status
COMPACTION / COMPACTION_BYTES	Compaction-Status
TABLE_COMPACTIONS / TABLE_SSTABLE_COUNT	Compaction und SSTable pro Tabelle
BLOOM_FILTER_FALSE_RATIO	Bloom-Filter-Falschpositivrate
TABLE_READ_LATENCY / TABLE_RANGE_LATENCY / TABLE_WRITE_LATENCY	Latenzen pro Tabelle
PENDINGS / FLUSH / THREAD_POOL	Warteschlangen, Flush, Thread-Pool
STATEMENT / COMMITLOG / EXCEPTION / MUTATION	Interne Metriken
COMPRESSION / TOTAL_SSTABLE	Kompression und SSTable-Status

TIMESERIES-STORE (TSE)

Panel	Beschreibung
TSE_MEMORY	Zeitreihen-Engine-Speicher
TSE_HTTP_TIME	HTTP-Antwortzeit
TSE_DATASTORE	Datenstore-Status
TSE_QUEUE_PROCESS_COUNT	Anzahl der verarbeiteten Warteschlangeneinträge

ANALYTICS-STORE (SPARK)

Panel	Beschreibung
MEMORY_USED	Spark-Speicherverbrauch
CONNECTION	Anzahl der Verbindungen
OPERATION	Anzahl der Vorgänge
REQUEST_RATE	Anfragerate

---

3. PlantPulse - Edge Gateway

Dieses Dashboard überwacht den Status der Edge-Geräte, die PLC-Verbindungen und den Datenempfang.

Zusammenfassungs-Panels

Panel	Beschreibung
Gesamte Edge-Gateways	Anzahl registrierter Edge-Gateways
Strom (Normal/Anomal)	Anzahl normaler und anomaler Stromzustände
PLC	Anzahl der PLC-Verbindungen
Gesamte Datenkapazität	Gesamte Größe der erfassten Daten
Empfangssumme pro Sekunde	Summe des Empfangs aller Edges pro Sekunde (Gauge)
Max. Empfangslatenz	Maximale Empfangslatenz (ms) (Gauge)
Log	Log-Status

PLC STATUS (PLC-Status)

Panel	Beschreibung
PLC-Ping-Fehler	Trend der fehlgeschlagenen PLC-Verbindungspings
PLC verbunden / getrennt	Trend des PLC-Verbindungsstatus
PLC-Leseverfolge	Trend der erfolgreichen Datenlesevorgänge
PLC-Lesefehler	Trend der fehlgeschlagenen Datenlesevorgänge
Systemfehlertrend	Trend der Systemfehler

DATA POINT (Datenpunkt)

Panel	Beschreibung
Gesamtsendungen pro Sekunde SUM(MPS)	Summe der Sendungen aller Edges pro Sekunde
Punktübertragungen	Trend der übertragenen Datenpunkte
Übertragungs-Bytes	Bytes der übertragenen Daten
Min/Avg/Max Empfangslatenz	Verteilung der Empfangslatenz

EDGE H/W (Edge-Hardware)

Panel	Beschreibung
CPU	CPU-Auslastung des Edge-Geräts
Speicher	Speicherverbrauch
Disk (SSD)	Diskauslastung
Netzwerk Up/Down	Netzwerkverkehr
Temperatur	Gerätetemperatur

---

4. PlantPulse - Statistik

Dieses Dashboard verfolgt langfristige Statistiken wie das tägliche Datenwachstum und Spitzenwerte der Systemressourcen. Es ist nützlich, um langfristige Wachstumstrends des Systems zu erkennen.

Panel	Beschreibung
Gesamte Datenkapazität	Gesamte Größe der gespeicherten Daten
Tägliche Datenkapazität	Trend der täglichen Datenkapazität
Täglicher Nachrichtentransport	Anzahl der täglichen Nachrichtensendungen
Tägliches Datenwachstum	Trend des täglichen Datenwachstums
Empfangsvolumen	Trend der empfangenen Nachrichten
Netzwerkverzögerung Avg/Max	Statistiken zur Netzwerkverzögerung
SSTABLE-Zuwachs	Trend des Aster TSDB SSTable-Wachstums
Max. DB-Clientverbindungen	Maximalwert der DB-Verbindungen
Max. asynchrone Threads	Peak der asynchronen Verarbeitung
JAVA Max. GC-Zeit	Maximale GC-Dauer
CQL Prepared Max	Maximalwert der CQL Prepared Statements
Max. Partitionsgröße	Maximale Aster TSDB Partitionsgröße
JAVA Min. Heap-Freiraum	Minimalwert des verfügbaren JVM-Heaps
Max. async Warteschlange	Maximales Warten in der asynchronen Queue
Max. Speicherpuffergröße	Maximalwert des Speicherpuffers
Backup-Verarbeitungsmenge	Anzahl der verarbeiteten Backup-Nachrichten

---

5. PlantPulse - Messaging

Dieses Dashboard überwacht den Status der MQTT-, Kafka- und WebSocket-Message-Broker.

SUMMARY (Zusammenfassung)

Panel	Beschreibung
MQTT / KAFKA / WEBSOCKET	Verbindungsstatus der jeweiligen Broker
CPU	CPU-Auslastung des Servers
JAVA_HEAP	JVM Heap-Verbrauch
NETWORK_READ_BYTES	Empfangene Netzwerk-Bytes

MQTT

Panel	Beschreibung
CPU_USED	MQTT-Broker CPU (Gauge)
MEMORY_USED	Speicherverbrauch
CONNECTIONS	Anzahl der Clientverbindungen
NETWORK IN/OUT	Netzwerk-Ein- und Ausgänge
GC_COUNT / GC_TIME_MS	GC-Häufigkeit und Dauer
THREAD_COUNT	Anzahl der Threads
INCOMING / OUTGOING	Anzahl der empfangenen und gesendeten Nachrichten
RETAINED_COUNT	Anzahl der Retained-Nachrichten
SUBSCRIPTIONS	Anzahl der Abonnements
TOTAL_MESSAGE	Gesamtzahl der Nachrichten

KAFKA

Panel	Beschreibung
CPU_USED	Kafka-Broker CPU (Gauge)
MEMORY_USED	Speicherverbrauch
GLOBAL_TOPIC	Globaler Topic-Status
NETWORK IN/OUT	Netzwerk-Ein- und Ausgänge
TOPIC_BYTE_IN/OUT_PER_SEC	Bytes pro Sekunde nach Topic
MESSAGE_PER_SEC_MEAN_RATE / 1M_RATE	Nachrichtendurchsatz pro Sekunde
NETWORK_REQUEST_FETCH	Anzahl der Fetch-Anfragen
OFFLINE_PARTITION_COUNT	Anzahl der Offline-Partitionen
ACTIVE_CONTROLLER_COUNT	Anzahl der aktiven Controller

WEBSOCKET

Panel	Beschreibung
CPU_USED	WebSocket-Server CPU (Gauge)
MEMORY_USED	Speicherverbrauch
CONNECTION_COUNT	Anzahl der WebSocket-Verbindungen
ENQUEUE / DEQUEUE	Anzahl der Queue-Ein- und Ausgänge

---

Integration von Überwachungswerkzeugen

ELK Stack

Die Container-Logs können über eine Pipeline aus Filebeat → Logstash → Elasticsearch → Kibana erfasst werden, um eine Umgebung für die Log-Suche und -Analyse aufzubauen. Dies wird für große Betriebsumgebungen empfohlen. Die Standardausgabe der Container wird über den Docker-Logging-Treiber erfasst, Dateilogs innerhalb der Container über Host-Mounts (PLANTPULSE_LOG_DIR).