跳到主要内容

端口及服务管理(运营者指南)

本页指导检查运行中的 PlantPulse 端口状态并排除故障的程序。完整端口清单请参考安装指南 - 端口配置信息页面。

日常巡检检查清单

1. 服务状态检查

status.sh — 整体栈状态(主机)

首先在主机上查看栈状态。汇总服务列表、容器状态、health 和卷,退出码有约定0 表示正常,2 表示异常,可直接用于监控自动化。

cd /opt/kopens/plantpulse-platform-docker/bin
./status.sh
Exited (0) 的一次性运行是成功的

plantpulse-certs 是生成证书后退出的一次性容器,所以Exited (0) 正常。compose 已显式禁用该容器的健康检查(healthcheck: disable),因此docker ps 的 health 列为空 — 用退出码status.sh 判定。

按模块查看端口占用(数据湖容器内)

要查看基础组件的端口占用 / PID / CPU / 内存(PSS),请在数据湖容器内使用status.sh

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

输出示例:

==============================================================================================================
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 + 最近 critical 日志

./ops-check.sh

自动执行以下操作:

  • 确认 HTTPS health 端点(https://127.0.0.1:4950/api/health)响应
  • 采集最近的 critical / fatal 日志消息
  • 测量按模块的响应时间

外部健康检查(监控系统集成)

# 호스트 / 외부에서 — 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 和 4950 是同一个控制台

控制台和 health API 在两个端口都服务 — 4950(HTTPS) 和4949(纯 HTTP)。是同一个控制台、同一套 API,只是方案不同。4949 不再重定向到 4950。

4949 是纯文本 — 登录密码和会话 cookie 以明文传输。在不可信网络中请使用4950 。4949 是针对自签名证书警告实际阻止运营者访问的环境的选择。

2. 按端口快速诊断

端口模块快速检查
80 / 443 / 7443servercurl -fsS http://[HOST]/api/v5/ping
9042Cassandrapd node status 集群状态
5432PostgreSQLpd 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 (匿名就绪态 — UP 时仅返回 200)
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-UA用 UaExpert 等工具opc.tcp://[HOST]:11004 连接
10210HA 守护进程curl -fsS http://[HOST]:10210/api/health
4950监视器curl -kfsS https://[HOST]:4950/api/health | jq .status
从哪个容器查询

80 · 443 · 1883 · 1884plantpulse-proxy 提供,11004 · 11005 由 OPC-UA 插件提供,10210 由 HA 容器提供,其余由plantpulse-datalake 发布到主机。四个应用(server-web · batch-web · warehouse · aasx)不开放主机端口,用./status.sh · ./logs.sh <컨테이너> 检查 → 端口配置信息

pd node status · pd node psql 等工具位于数据湖容器内(用./shell.sh 进入)。

3. 端口冲突诊断

检查占用进程

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

解决冲突

情况处置
外部服务占用端口将外部服务移至其他端口
前面的 PlantPulse 进程残留如果以本机进程形式残留,使用pkill -ef plantpulse 。如果在容器中,使用bin/down.sh 后用docker ps -a 检查残留
默认端口因公司策略不可用主机暴露的端口由compose/docker-compose.ymlports: 控制。修改映射后bin/restart.sh

4. 防火墙运维

查询当前允许规则

# 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

运行中允许新端口

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

# ufw
sudo ufw allow <port>/tcp

仅允许新的源 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 端口运维

JMX 端口(6199~7899)应仅允许管理/监控节点 IP 访问。使用 JConsole / VisualVM 连接时:

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

# 로컬에서
jconsole 127.0.0.1:7099

详细的 JMX 端口映射见安装:端口配置信息 - JMX

6. 常见问题

症状原因一级处置
部分容器异常依赖容器宕机 / 资源不足在主机上./status.sh → 应用则docker compose … restart <서비스> ,基础设施则在容器内restart-<module>.sh
端口 LISTEN 中但 health 失败启动未完成 / 后端依赖未就绪./stack-verify-boot.sh 判定就绪状态。初始安装稳定耗时 15~18 分钟
全部宕机栈已停止在主机上./up.sh (等待就绪,0 = 可用)
address already in use外部进程占用参考上面的端口冲突诊断步骤
外部无法接入(内部可以)主机防火墙或云 SG检查firewall-cmd --list-ports 及云 SG
TLS 握手失败(仅TimeoutException 显示)证书 SAN 不匹配检查PP_TLS_SAN_DNS / PP_TLS_SAN_IPS 。证书由plantpulse-certs 一次性容器生成 → 安全配置
实时更新中断防火墙·代理的 idle timeout上游代理的proxy_read_timeout 调高。实时推送通过 443 发出

7. 运维自动化

Health 检查 cron

# /etc/cron.d/plantpulse-health (호스트에서)
*/5 * * * * root /opt/kopens/plantpulse-platform-docker/bin/ops-check.sh >> /var/log/plantpulse-ops.log 2>&1

如果用退出码判定,status.sh 更好 — 0 = 正常 / 2 = 异常是约定。

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

Prometheus / Grafana 集成

配置 Prometheus 来抓取plantpulse-monitor 暴露的/metrics 端点。

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

4949 也提供相同的 API,但是明文。如果在专网内且不想处理证书验证则用 4949,其他情况用 4950。

Grafana 仪表板可使用plantpulse-timeseries/dashboard/ (端口 3000)的预配置板,或在外部 Grafana 中连接相同的数据源。

相关文档