Zum Hauptinhalt springen

Verwaltung von Ports und Diensten (Betreiberhandbuch)

Diese Seite beschreibt die Vorgehensweise zur Prüfung des Portstatus eines laufenden PlantPulse-Systems und zur Fehlerbehebung. Den vollständigen Portkatalog finden Sie auf der Seite Installationsanleitung - Portkonfiguration.

Tägliche Prüfliste​

1. Statusprüfung der Dienste​

status.sh — Gesamtstatus des Stacks (Host)​

Zunächst prüfen wir den Stackstatus auf dem Host. Er fasst Dienstliste, Containerstatus, Health und Volumes zusammen, und der Exit-Code ist der Vertrag — 0 bedeutet normal, 2 bedeutet abnormal, sodass dies direkt in Monitoring-Automatisierungen verwendet werden kann.

cd /opt/kopens/plantpulse-platform-docker/bin
./status.sh
Bei einmaligen Aufgaben ist Exited (0) ein Erfolg

plantpulse-certs ist ein einmaliger Vorgang, der nur Zertifikate erzeugt und dann endet, daher ist Exited (0) normal. Da compose den Healthcheck dieses Containers explizit deaktiviert hat (healthcheck: disable), ist auch die Health-Spalte von docker ps leer — status.sh wird anhand des Exit-Codes beurteilt.

Portbelegung je Modul (im Data-Lake-Container)​

Um 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 + aktuelle Critical-Logs​

./ops-check.sh

Folgendes wird automatisch ausgeführt:

  • Prüfung der Antwort des HTTPS-Health-Endpunkts (https://127.0.0.1:4950/api/health)
  • Sammlung aktueller critical/fatal-Log-Meldungen
  • Messung der Antwortzeit je Modul

Externer Health-Check (Anbindung an Monitoring-Systeme)​

# 호스트 / 외부에서 — 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
4949 und 4950 sind dieselbe Konsole

Konsole und Health-API werden über beide Ports bereitgestellt — 4950 (HTTPS) und 4949 (Klartext-HTTP). Es handelt sich um dieselbe Konsole und dieselbe API, nur das Schema unterscheidet sich. 4949 leitet nicht mehr zu 4950 weiter.

4949 ist Klartext — Login-Passwörter und Session-Cookies werden unverschlüsselt übertragen. Verwenden Sie in nicht vertrauenswürdigen Netzwerken 4950. 4949 ist eine Option für Umgebungen, in denen Warnungen wegen selbstsignierter Zertifikate den Betreiber tatsächlich blockieren.

2. Schnelldiagnose je Port​

PortModulSchnellprüfung
80 / 443 / 7443servercurl -fsS http://[HOST]/api/v5/ping
9042Cassandrapd node status Clusterstatus
5432PostgreSQLNach Verbindung mit pd node psql SELECT 1;
6379Valkeyredis-cli -a $PP_REDIS_PASSWORD ping
9000MinIOcurl -fsS http://[HOST]:9000/minio/health/live
9092Kafkakafka-broker-api-versions.sh --bootstrap-server [HOST]:9092
1883MQTTmosquitto_pub -h [HOST] -p 1883 -u mq -P $PP_MQ_PASSWORD -t test -m hi
7400CEPcurl -fsS -H "X-API-Key: $PP_CEP_API_KEY" http://[HOST]:7400/api/v1/status
5500Data Gatewaycurl -fsS http://[HOST]:5500/api/health (anonyme Readiness — 200 nur wenn UP)
7800TSEcurl -fsS http://[HOST]:7800/api/health
7077Spark Mastercurl -fsS http://[HOST]:4440/json/ | jq .workers
10000Kyuubibeeline -u "jdbc:hive2://[HOST]:10000" -e "SELECT 1"
19001Gravitinocurl -fsS -u gravitino:$PP_GRAVITINO_PASSWORD http://[HOST]:19001/api/metalakes
7233Temporaltemporal --address [HOST]:7233 namespace list
8380Kestracurl -fsS -u admin@plantpulse.io:$PP_KESTRA_ADMIN_PASSWORD http://[HOST]:8380/api/v1/flows
11004OPC-UAVerbindung mit UaExpert o. Ä. zu opc.tcp://[HOST]:11004
10210HA-Dämoncurl -fsS http://[HOST]:10210/api/health
4950Monitorcurl -kfsS https://[HOST]:4950/api/health | jq .status
In welchem Container wird nachgefragt

80 · 443 · 1883 · 1884 werden von plantpulse-proxy, 11004 · 11005 vom OPC-UA-Plugin, 10210 vom HA-Container und die übrigen von plantpulse-datalake auf dem Host publiziert. Die vier Apps (server-web · batch-web · warehouse · aasx) öffnen keine Host-Ports, prüfen Sie diese daher mit ./status.sh · ./logs.sh <컨테이너> → Portkonfiguration

Werkzeuge wie pd node status · pd node psql befinden sich im Data-Lake-Container (Zugang über ./shell.sh).

3. Diagnose von Portkonflikten​

Prüfung des belegenden Prozesses​

# 특정 포트
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|7443|7800|8233|8380|9000|9042|9092|10000|10210|11004|19001)\s'

Konfliktlösung​

SituationMaßnahme
Ein externer Dienst belegt den PortExternen Dienst auf einen anderen Port verlegen
Rückstand eines alten PlantPulse-ProzessesBei nativem Rückstand auf dem Host: pkill -ef plantpulse. Bei Containern: bin/down.sh, danach mit docker ps -a auf Rückstände prüfen
Standardport laut Unternehmensrichtlinie nicht zulässigDer auf dem Host exponierte Port wird durch compose/docker-compose.yml in ports: festgelegt. Nach Änderung des Mappings: bin/restart.sh

4. Firewall-Betrieb​

Abfrage der aktuell erlaubten Regeln​

# 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

Freigabe eines neuen Ports im laufenden Betrieb​

# firewalld
sudo firewall-cmd --permanent --add-port=<port>/tcp
sudo firewall-cmd --reload

# ufw
sudo ufw allow <port>/tcp

Nur eine neue Quell-IP zulassen​

# 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. Betrieb der JMX-Ports​

JMX-Ports (6199–7899) dürfen nur für IPs von Leitstand-/Monitoring-Knoten freigegeben werden. Beim Zugriff über JConsole / VisualVM:

# SSH 터널로 안전하게 접속 (권장)
ssh -L 7099:127.0.0.1:7099 root@[HOST]

# 로컬에서
jconsole 127.0.0.1:7099

Detailliertes JMX-Port-Mapping siehe Installation: Portkonfiguration - JMX.

6. Häufig auftretende Probleme​

SymptomUrsacheErste Maßnahme
Einzelne Container abnormalAbhängiger Container ausgefallen / RessourcenmangelAuf dem Host ./status.sh → bei App docker compose … restart <서비스>, bei Infrastruktur im Container restart-<module>.sh
Port ist LISTEN, aber Health schlägt fehlBoot noch nicht abgeschlossen / Backend-Abhängigkeit nicht bereitBereitschaft mit ./stack-verify-boot.sh beurteilen. Eine saubere Installation braucht 15–18 Minuten bis zur Stabilisierung
GesamtausfallStack ist ausgefallenAuf dem Host ./up.sh (warten bis bereit, 0 = einsatzbereit)
address already in useBelegung durch externen ProzessSiehe oben Diagnose von Portkonflikten
Kein externer Zugriff möglich (intern funktioniert)Host-Firewall oder Cloud-SGfirewall-cmd --list-ports und Cloud-SG prüfen
TLS-Handshake schlägt fehl (nur als TimeoutException sichtbar)SAN-Diskrepanz im ZertifikatPP_TLS_SAN_DNS / PP_TLS_SAN_IPS prüfen. Zertifikate werden durch den plantpulse-certs-Einmalvorgang erzeugt → Sicherheitseinstellungen
Unterbrechung bei Echtzeit-UpdatesIdle-Timeout von Firewall/ProxyIdle-Timeout-Wert des vorgeschalteten Proxys proxy_read_timeout 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

Zur Beurteilung anhand des Exit-Codes eignet sich status.sh besser — 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"

Anbindung an Prometheus / Grafana​

Konfigurieren Sie, dass Prometheus den von plantpulse-monitor bereitgestellten /metrics-Endpunkt scrapt.

# prometheus.yml
scrape_configs:
  - job_name: plantpulse
    scheme: https
    tls_config:
      insecure_skip_verify: true    # 자체 서명 CA 를 쓰는 경우
    static_configs:
      - targets: ['[HOST]:4950']
Für Scraping wird 4950 empfohlen

Über 4949 wird dieselbe API bereitgestellt, jedoch im Klartext. In privaten Netzwerken, wo die Zertifikatsprüfung eine Last darstellt, kann 4949 verwendet werden, andernfalls 4950.

Für das Grafana-Dashboard können Sie das vorkonfigurierte Board von plantpulse-timeseries/dashboard/ (Port 3000) nutzen oder dieselbe Datenquelle mit einem externen Grafana verbinden.

Verwandte Dokumente​