Port and Service Management (Operator Guide)

This page guides you through the procedure for checking the port status of a running PlantPulse instance and troubleshooting issues. For the full port catalog, refer to the Installation Guide - Port Configuration Information page.

Daily Inspection Checklist

1. Checking Service Status

status.sh — Overall stack status (host)

First, check the stack status on the host. It summarizes the service list, container status, health, and volumes, and the exit code is the contract — 0 means normal, 2 means abnormal, so it can be used directly in monitoring automation.

cd /opt/kopens/plantpulse-platform-docker/bin
./status.sh

Viewing all nine by the same standard

plantpulse-certs also runs at all times, and (healthy) is normal. Once a certificate is baked, it continuously watches for expiration.

Per-module port usage (inside the datalake container)

To view port usage / PID / CPU / memory (PSS) for infrastructure components, use status.sh inside the datalake container.

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

Example output:

==============================================================================================================
 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 + recent critical logs

./ops-check.sh

This automatically performs the following:

• Confirms the HTTPS health endpoint (https://127.0.0.1:4950/api/health) responds
• Collects recent critical / fatal log messages
• Measures response time per module

External health check (monitoring system integration)

# 호스트 / 외부에서 — 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 and 4950 are the same console

The console and health API are served on both ports — 4950 (HTTPS) and 4949 (plaintext HTTP). It's the same console and the same API, just a different scheme. 4949 no longer redirects to 4950.

4949 is plaintext — login passwords and session cookies flow unencrypted. On untrusted networks, use 4950. 4949 is an option for boxes where a self-signed certificate warning would actually stop an operator in their tracks.

2. Quick Diagnosis by Port

Port	Module	Quick Check
80 / 443	server	curl -fsS http://[HOST]/api/v5/ping
9042	Aster TSDB	pd node status cluster status
5432	PostgreSQL	Connect via pd node psql then SELECT 1;
6379	Valkey	redis-cli -a $PP_REDIS_PASSWORD ping
9000	RustFS	pd status storage — RustFS has no health endpoint
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 (anonymous readiness — returns 200 only when 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	Connect via UaExpert etc. to opc.tcp://[HOST]:11004
10210	HA daemon	curl -fsS http://[HOST]:10210/api/health
4950	Monitor	curl -kfsS https://[HOST]:4950/api/health | jq .status

Which container to ask

For 80 · 443 · 1883 · 1884, plantpulse-proxy answers; for 11004 · 11005, the OPC-UA plugin answers; for 10210, the HA container answers; and for the rest, plantpulse-datalake publishes them to the host. The four apps (server-web · batch-web · warehouse · aasx) do not open host ports, so check via ./status.sh · ./logs.sh <컨테이너> → Port Configuration Information

Tools such as pd node status · pd node psql live inside the datalake container (enter via ./shell.sh).

3. Diagnosing Port Conflicts

Checking the process holding the port

# 특정 포트
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'

Resolving conflicts

Situation	Action
External service is holding the port	Move the external service to a different port
Leftover previous PlantPulse process	If it remains natively on the host, pkill -ef plantpulse. If it's on the container side, bin/down.sh then confirm with docker ps -a that it's gone
Default port not usable per company policy	The port exposed to the host is set by ports: in compose/docker-compose.yml. After changing the mapping, bin/restart.sh

4. Firewall Operations

Viewing currently allowed rules

# 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

Allowing a new port while operating

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

# ufw
sudo ufw allow <port>/tcp

Allowing only a new source IP

# 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 Port Operations

JMX ports (6199–7899) should only be allowed for control/monitoring node IPs. When connecting via JConsole / VisualVM:

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

# 로컬에서
jconsole 127.0.0.1:7099

For detailed JMX port mappings, see Installation: Port Configuration Information - JMX.

6. Common Issues

Symptom	Cause	Initial Action
Some containers abnormal	Dependency container down / resource shortage	On the host, ./status.sh → for apps, docker compose … restart <서비스>; for infrastructure, restart-<module>.sh inside the container
Port is LISTEN but health fails	Boot not complete / backend dependency not ready	Determine readiness with ./stack-verify-boot.sh. A clean install can take 15–18 minutes to stabilize
Total outage	Stack is down	On the host, ./up.sh (wait until ready, 0 = usable)
address already in use	External process holding the port	Follow the Diagnosing Port Conflicts procedure above
Cannot connect externally (internal works)	Host firewall or cloud SG	Check firewall-cmd --list-ports and the cloud SG
TLS handshake failure (appears only as TimeoutException)	Certificate SAN mismatch	Check PP_TLS_SAN_DNS / PP_TLS_SAN_IPS. Certificates are baked by plantpulse-certs → Security Settings
Real-time updates dropping	Idle timeout on firewall/proxy	Raise the proxy_read_timeout on the front-end proxy. Real-time push goes out over 443

7. Operational Automation

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

To judge by exit code, status.sh is better — the contract is 0 = normal / 2 = abnormal.

*/5 * * * * root /opt/kopens/plantpulse-platform-docker/bin/status.sh >/dev/null 2>&1 || logger -t plantpulse "status.sh reported unhealthy"

Prometheus / Grafana Integration

Configure Prometheus to scrape the /metrics endpoint exposed by the management console API (plantpulse-datalake-admin-api).

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

4950 is recommended for scraping

The same API is also available on 4949, but it is plaintext. Use 4949 if you're inside a private network and certificate verification is burdensome; otherwise use 4950.

This is «is the stack alive» — not equipment data

What 4950/metrics provides is the status of the stack itself, such as containers, ports, and health. If you want to view values coming from equipment or system metrics via PromQL, you need a different place.

What you want to view	Where
Whether the stack is alive (containers, ports)	Here — 4950/metrics
System metrics via PromQL (JMX, edge counters)	Prometheus Integration — TSE's compatible adapter
System metrics as dashboards	Building Dashboards in PlantPulse Dashboard — bundled PlantPulse Dashboard (3000)
Equipment sensor values	Time Series Database — CQL

Related Documents

• Installation: Port Configuration Information — full port catalog
• Monitoring — Prometheus / PlantPulse Dashboard / alerts
• Troubleshooting
• Management Console — where /metrics is served from
• Module: startup