Port- und Diensteverwaltung (Betreiberhandbuch)
Diese Seite beschreibt das Verfahren zur Prüfung des Portstatus und zur Fehlerbehebung in einer laufenden PlantPulse-Installation. Den vollständigen Portkatalog finden Sie unter Installationshandbuch – Portkonfiguration.
Checkliste für die tägliche Inspektion
1. Dienststatus prüfen
status.sh — Gesamtstatus des Stacks (Host)
Prüfen Sie zunächst den Stack-Status auf dem Host. Er fasst Dienstliste, Containerstatus, health und Volumes zusammen. Der Exit-Code ist der Vertrag — 0 bedeutet normal, 2 bedeutet abnormal, sodass er direkt in die Monitoring-Automatisierung übernommen werden kann.
cd /opt/kopens/plantpulse-platform-docker/bin
./status.sh
plantpulse-certs läuft ebenfalls dauerhaft, (healthy) ist der Normalzustand. Nachdem das Zertifikat einmal eingebrannt wurde, wird dessen Ablauf kontinuierlich überwacht.
Portbelegung pro Modul (im Data Lake Container)
Um die Portbelegung / PID / CPU / Speicher (PSS) der Infrastrukturkomponenten zu sehen, verwenden Sie status.sh im Data Lake Container.
cd /opt/kopens/plantpulse-platform-docker/bin
./shell.sh
/opt/kopens/plantpulse-platform/plantpulse-datalake-cli/bin/pd status
Beispielausgabe:
==============================================================================================================
PLANTPULSE PLATFORM - ALL SERVICE STATUS
==============================================================================================================
<SYSTEM RESOURCE OVERVIEW>
CPU LOAD (AVG) : 12.3% (48 cores)
MEMORY USAGE : 65.2% (123.1G / 188.7G)
DATA DISK USAGE : 45.8% (2.2T / 4.8T)
<SERVICE STATUS BY PORT>
SERVICE | PORT | STATUS | PID | CPU | MEMORY (PSS)
PP_MESSAGING[KAFKA] | 9092 | RUNNING | 12345 | 2.3% | 8.5G ( 4.5%)
PP_STORAGE[CASSANDRA] | 9042 | RUNNING | 12567 | 5.1% | 16.2G ( 8.6%)
PP_SERVER | 80 | RUNNING | 12890 | 1.2% | 4.8G ( 2.5%)
...
<SERVICE SUMMARY>
TOTAL SERVICES : 25 RUNNING / 0 STOPPED
TOTAL CPU (SUM) : 42.3%
TOTAL MEMORY (PSS) : 78.5% (148.0G)
ops-check.sh — Health + letzte kritische Logs
./ops-check.sh
Führt automatisch Folgendes aus:
- Antwort des HTTPS-Health-Endpunkts (
https://127.0.0.1:4950/api/health) prüfen - Sammeln der letzten kritischen / fatalen Logmeldungen
- Antwortzeit je Modul messen
Externer Health-Check (Anbindung an Monitoringsystem)
# 호스트 / 외부에서 — 4950 이 유일하게 publish 되는 헬스 포트입니다
curl -kfsS https://[HOST]:4950/api/health | jq
# 컨테이너 안에서 — 어떤 구성에서도 동작합니다
docker exec plantpulse-datalake curl -kfsS https://127.0.0.1:4950/api/health | jq
Konsole und Health-API werden über beide Ports bereitgestellt — 4950 (HTTPS) und 4949 (Klartext-HTTP). Gleiche Konsole, gleiche API, nur das Schema unterscheidet sich. 4949 leitet nicht mehr auf 4950 um.
4949 ist Klartext — Login-Passwort und Session-Cookie laufen unverschlüsselt. Verwenden Sie in nicht vertrauenswürdigen Netzwerken 4950. 4949 ist die Option für Umgebungen, in denen die Warnung zu selbstsignierten Zertifikaten Bediener tatsächlich aufhält.
2. Schnelldiagnose je Port
| Port | Modul | Schnellprüfung |
|---|---|---|
| 80 / 443 | server | curl -fsS http://[HOST]/api/v5/ping |
| 9042 | Aster TSDB | pd node status Cluster-Status |
| 5432 | PostgreSQL | pd node psql verbinden, dann SELECT 1; |
| 6379 | Valkey | redis-cli -a $PP_REDIS_PASSWORD ping |
| 9000 | RustFS | pd status storage — RustFS hat keinen Health-Endpunkt |
| 9092 | Kafka | kafka-broker-api-versions.sh --bootstrap-server [HOST]:9092 |
| 1883 | MQTT | mosquitto_pub -h [HOST] -p 1883 -u mq -P $PP_MQ_PASSWORD -t test -m hi |
| 7400 | CEP | curl -fsS -H "X-API-Key: $PP_CEP_API_KEY" http://[HOST]:7400/api/v1/status |
| 5500 | Data Gateway | curl -fsS http://[HOST]:5500/api/health (anonymer Readiness-Check — 200 nur bei UP) |
| 7800 | TSE | curl -fsS http://[HOST]:7800/api/health |
| 7077 | Spark Master | curl -fsS http://[HOST]:4440/json/ | jq .workers |
| 10000 | Kyuubi | beeline -u "jdbc:hive2://[HOST]:10000" -e "SELECT 1" |
| 19001 | Gravitino | curl -fsS -u gravitino:$PP_GRAVITINO_PASSWORD http://[HOST]:19001/api/metalakes |
| 7233 | Temporal | temporal --address [HOST]:7233 namespace list |
| 8380 | Kestra | curl -fsS -u admin@plantpulse.io:$PP_KESTRA_ADMIN_PASSWORD http://[HOST]:8380/api/v1/flows |
| 11004 | OPC-UA | Mit UaExpert o. Ä. opc.tcp://[HOST]:11004 verbinden |
| 10210 | HA-Daemon | curl -fsS http://[HOST]:10210/api/health |
| 4950 | Monitor | curl -kfsS https://[HOST]:4950/api/health | jq .status |
80 · 443 · 1883 · 1884 werden von plantpulse-proxy veröffentlicht, 11004 · 11005 vom OPC-UA-Plugin, 10210 vom HA-Container, der Rest von plantpulse-datalake auf den Host. Die vier Apps (server-web · batch-web · warehouse · aasx) öffnen keine Host-Ports und werden daher über ./status.sh · ./logs.sh <컨테이너> geprüft → Portkonfiguration
Werkzeuge wie pd node status · pd node psql befinden sich im Data Lake Container (Einstieg über ./shell.sh).
3. Diagnose von Portkonflikten
Belegenden Prozess ermitteln
# 특정 포트
ss -tlnp | grep ":<port> "
sudo lsof -i :<port>
# 일괄 (PlantPulse 모든 핵심 포트)
ss -tlnp | grep -E ':(80|443|1883|1884|3000|4000|4950|5432|5500|6379|7077|7233|7400|7800|8233|8380|9000|9042|9092|10000|10210|11004|19001)\s'
Konfliktbehebung
| Situation | Maßnahme |
|---|---|
| Externer Dienst belegt den Port | Externen Dienst auf anderen Port verschieben |
| Alte PlantPulse-Prozesse vorhanden | Native auf dem Host: pkill -ef plantpulse. Wenn Container: bin/down.sh, danach docker ps -a zur Restprüfung |
| Standardport aus Unternehmensrichtlinie nicht nutzbar | Host-exponierte Ports werden von compose/docker-compose.yml in ports: festgelegt. Nach Mapping-Änderung bin/restart.sh |
4. Firewall-Betrieb
Aktuelle erlaubte Regeln abfragen
# RHEL/Rocky/Oracle (firewalld)
sudo firewall-cmd --list-ports
sudo firewall-cmd --list-rich-rules
sudo firewall-cmd --list-services
# Ubuntu (ufw)
sudo ufw status numbered
sudo ufw status verbose
Neuen Port im Betrieb freigeben
# firewalld
sudo firewall-cmd --permanent --add-port=<port>/tcp
sudo firewall-cmd --reload
# ufw
sudo ufw allow <port>/tcp
Nur neue Source-IPs erlauben
# firewalld rich rule
sudo firewall-cmd --permanent --add-rich-rule="rule family=ipv4 source address=192.168.10.0/24 port port=9042 protocol=tcp accept"
sudo firewall-cmd --reload
# ufw
sudo ufw allow from 192.168.10.0/24 to any port 9042
5. JMX-Portbetrieb
Die JMX-Ports (6199–7899) dürfen nur für IPs der Überwachungs- / Monitoring-Knoten freigegeben sein. Bei Zugriff mit JConsole / VisualVM:
# SSH 터널로 안전하게 접속 (권장)
ssh -L 7099:127.0.0.1:7099 root@[HOST]
# 로컬에서
jconsole 127.0.0.1:7099
Detaillierte JMX-Portzuordnung siehe Installation: Portkonfiguration – JMX.
6. Häufig auftretende Probleme
| Symptom | Ursache | Erste Maßnahme |
|---|---|---|
| Einzelne Container abnormal | Abhängiger Container down / Ressourcenmangel | Auf dem Host ./status.sh → bei App docker compose … restart <서비스>, bei Infrastruktur im Container restart-<module>.sh |
| Port LISTEN, aber Health schlägt fehl | Boot nicht abgeschlossen / Backend-Abhängigkeit nicht bereit | Bereitschaft über ./stack-verify-boot.sh feststellen. Bei sauberer Installation dauert es bis zur Stabilität 15–18 Minuten |
| Kompletter Ausfall | Stack heruntergefahren | Auf dem Host ./up.sh (warten bis bereit, 0 = einsatzbereit) |
address already in use | Externer Prozess belegt den Port | Oben stehendes Verfahren Portkonflikt-Diagnose |
| Kein externer Zugriff (intern funktioniert) | Host-Firewall oder Cloud-SG | firewall-cmd --list-ports und Cloud-SG prüfen |
TLS-Handshake fehlgeschlagen (nur über TimeoutException sichtbar) | Zertifikats-SAN stimmt nicht überein | PP_TLS_SAN_DNS / PP_TLS_SAN_IPS prüfen. Zertifikate werden von plantpulse-certs erstellt → Sicherheitseinstellungen |
| Echtzeit-Aktualisierung abgebrochen | Idle-Timeout von Firewall / Proxy | proxy_read_timeout am vorgelagerten Proxy erhöhen. Echtzeit-Push läuft über 443 |
7. Betriebsautomatisierung
Health-Check-Cron
# /etc/cron.d/plantpulse-health (호스트에서)
*/5 * * * * root /opt/kopens/plantpulse-platform-docker/bin/ops-check.sh >> /var/log/plantpulse-ops.log 2>&1
Für die Auswertung über Exit-Codes ist status.sh besser geeignet — 0 = normal / 2 = abnormal ist der Vertrag.
*/5 * * * * root /opt/kopens/plantpulse-platform-docker/bin/status.sh >/dev/null 2>&1 || logger -t plantpulse "status.sh reported unhealthy"
Prometheus / Grafana-Integration
Konfigurieren Sie Prometheus so, dass es den von der Verwaltungskonsolen-API (plantpulse-datalake-admin-api) bereitgestellten /metrics-Endpunkt scraped.
# prometheus.yml
scrape_configs:
- job_name: plantpulse
scheme: https
tls_config:
insecure_skip_verify: true # 자체 서명 CA 를 쓰는 경우
static_configs:
- targets: ['[HOST]:4950']
Über 4949 ist dieselbe API verfügbar, aber im Klartext. Im privaten Netz und wenn die Zertifikatsprüfung eine Belastung ist, verwenden Sie 4949; andernfalls 4950.
4950/metrics liefert den Zustand des Stacks selbst — Container, Ports, Health.
Wenn Sie Anlagenwerte oder Systemmetriken per PromQL abfragen möchten, ist das eine andere Stelle.
| Was Sie sehen möchten | Wohin |
|---|---|
| Ist der Stack am Leben (Container, Ports) | Hier — 4950/metrics |
| Systemmetriken per PromQL (JMX, Edge-Zähler) | Prometheus-Integration — kompatibler Adapter der TSE |
| Systemmetriken als Dashboard | Dashboards in PlantPulse Dashboard erstellen — gebündeltes PlantPulse Dashboard (3000) |
| Anlagen-Sensorwerte | Zeitreihendatenbank — CQL |
Verwandte Dokumentation
- Installation: Portkonfiguration — vollständiger Portkatalog
- Monitoring — Prometheus / PlantPulse Dashboard / Alarmierung
- Fehlerbehebung
- Verwaltungskonsole — liefert
/metrics - Modul: startup