Administrator Guide
Was möchten Sie tun?
| Vorhaben | Referenz |
|---|---|
| Ein-/Ausschalten · Neustart | Start und Stopp |
| Status prüfen · Überwachung | Monitoring |
| Backup erstellen und Recovery üben | Backup und Recovery |
| Passwort · API-Key ändern | Credential Rotation |
| Benutzer · Berechtigungsverwaltung | Benutzerverwaltung |
| Sicherheitsprüfung | Sicherheit |
| Bei Performance-Einbußen | Performance-Tuning |
| Wenn virtuelle Tag-Berechnungen nicht laufen | Betrieb virtueller Tags |
| Datenvolumen · Löschzeitpunkte | Datenaufbewahrungsrichtlinie |
| Firewall-Freigaben | Ports |
| Fragen zu OEE · RAM · EMS Werten | OEE · RAM · EMS FAQ |
| Suche nach Einstellungswerten | Property Reference |
| Tabellen · Schemas einsehen | Datenbankmodell |
| Redundante Konfiguration | HA |
| Upgrade-Verfahren | Upgrade |
| Upgrade · Anpassungen bei Integrationen | Upgrade Notes |
| Modulaufteilung | Moduldetails · Modulübersicht unten |
Modulübersicht
Die PlantPulse Platform besteht aus mehreren unabhängigen Modulen. Module und Container entsprechen nicht im Verhältnis 1:1 — die sechs Applikationen besitzen jeweils einen eigenen Container, während die Komponenten der Datalake-Serie gemeinsam in einem plantpulse-datalake Container laufen.
Die Komponenten der Datalake-Serie sind im separaten Hauptabschnitt Datalake zusammengefasst — Pfade · Konfigurationsdateien · Passwortänderung · Management-Konsole · pd CLI · Betrieb · Komponenten (storage · messaging · analytics · timeseries · cep · workflow · data-gateway) · FAQ.
Modulkategorien
Modulkategorien
| Kategorie | Modul | Beschreibung |
|---|---|---|
| Applikation | server | Web-Konsole, IIoT-Engine, REST API |
| batch | Scheduled Batch Processing | |
| data-gateway | REST-basiertes Data-Gateway | |
| datalake-admin-api | Management-Konsole Backend + Health API (4950 / 4949) | |
| warehouse | Iceberg-basiertes Data Warehouse | |
| Verarbeitung | cep | Complex Event Processing (Aster CEP) |
| plugin | OPC-UA / AAS Industrie-Standard-Plugins | |
| timeseries | Zeitreihen-Engine + Visualisierungs-UI | |
| Messaging | messaging | Kafka + MQTT(HiveMQ). STOMP(ActiveMQ) wurde entfernt |
| Storage | storage | Aster TSDB + PostgreSQL + Valkey + RustFS |
| Analyse | analytics | Spark + Hive + Kyuubi + Gravitino + Hadoop |
| Workflow | workflow | Temporal + Kestra |
| Datalake-Betrieb | pd CLI | Zentraler Einstiegspunkt für Start/Stopp/Neustart · Konfiguration · Node-Management |
| Datalake-Betrieb | Management-Konsole | Browser-basierte Betriebskonsole (4950 / 4949) |
| utilities | setup, backup, recovery, exporter, migrator, mirror-maker, simulator, api, lab |
Gemeinsame Modulstruktur
Jedes Servicemodul folgt einer einheitlichen Verzeichnisstruktur und Betriebsschnittstelle.
plantpulse-<module>/
├── app/ # 애플리케이션 WAR / JAR
├── bin/
│ ├── start.sh # 포그라운드 시작
│ ├── stop.sh # 정지
│ └── log-viewer.sh # 실시간 로그 (tail -F)
├── server/ 또는 lib/ # 내장 Tomcat 서버 또는 JAR
├── logs/ # system.log (메인 로그)
└── conf/ 또는 config/ # 설정 파일
Gemeinsame Betriebsbefehle
Auf dem Host — Steuerung des gesamten Stacks (/opt/kopens/plantpulse-platform-docker/bin/).
| Aufgabe | Befehl | Bemerkung |
|---|---|---|
| Gesamtsystem starten | up.sh | Warten bis bereit. 0 = einsatzbereit |
| Gesamtsystem stoppen | down.sh | Umgekehrte Reihenfolge der Abhängigkeiten, Statuserhalt |
| Gesamtsystem Neustart | restart.sh | drain → Stopp → Start → Warten bis bereit |
| Einzelapp Neustart | docker compose -f compose/docker-compose.yml restart <서비스> | Apps in eigenen Containern |
| Statusprüfung | status.sh | 0 = Normal / 2 = Anomalie |
| Integrierte Logs | logs.sh | Ohne Argument alle Container. Follow mit -f |
Im Datalake-Container — Individuelle Steuerung der Infrastrukturkomponenten (Zugriff via ./shell.sh).
| Aufgabe | Befehl |
|---|---|
| Service-Status | ./pd status [서비스] |
| Service-Neustart | ./pd restart <서비스> |
| Konfigurations-Rendering | ./pd config render |
| Aster TSDB Node | ./pd node status · ./pd node repair … |
| Diagnose | ./pd doctor |
Modulabhängigkeiten
PlantPulse wird schrittweise entsprechend der Abhängigkeitsreihenfolge gestartet. Bei Modul-Neustarts müssen diese Abhängigkeiten beachtet werden.
Hinweis zum Neustart: Wenn Infrastrukturmodule (storage / messaging / analytics) neu gestartet werden, müssen alle darauf abhängigen Applikationen ebenfalls neu gestartet werden. Am sichersten ist ein Neustart des gesamten Stacks über den Host mit
bin/restart.sh.
Port-Mapping Übersicht
| Bereich | Port | Modul |
|---|---|---|
| Extern | 80 / 443 | server (HTTP / HTTPS) |
| Extern | 4950 | monitor (Health Check, HTTPS) |
| Messaging | 9092 / 9093 / 9094 | messaging (Kafka) |
| Messaging | 1883 / 1884 | messaging (MQTT) |
| Storage | 9042 | storage (Aster TSDB) |
| Storage | 5432 | storage (PostgreSQL) |
| Storage | 6379 | storage (Valkey) |
| Storage | 9000 / 9001 | storage (RustFS) |
| Analyse | 7077 / 4440 | analytics (Spark Master / UI) |
| Analyse | 10000 | analytics (Kyuubi) |
| Analyse | 19001 | analytics (Gravitino) |
| Analyse | 9083 | analytics (Hive Metastore) |
| Zeitreihe | 7800 / 7801 | timeseries (Engine) |
| Zeitreihe | 3000 | timeseries (UI) |
| Workflow | 7233 / 8233 | workflow (Temporal) |
| Workflow | 8380 | workflow (Kestra) |
| Verarbeitung | 7400 / 7401 | cep |
| Verarbeitung | 5500 | data-gateway |
| Verarbeitung | 11004 / 11005 | plugin (OPC-UA) |
| Verarbeitung | 8007 / 8090 | plugin (AAS V2 / V3) |
| Applikation | 9500 | batch |
| Applikation | 9600 | warehouse |
| Applikation | 4000 | sql |
Für die vollständige Portliste besuchen Sie bitte die Seite Port-Konfigurationsinformationen.
Technischer Support
Für Fragen zum Modulbetrieb wenden Sie sich bitte an webmaster@kopens.com.