メインコンテンツまでスキップ

ポート及びサービス管理（運用ガイド）

このページは、運用中の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 — ヘルス＋最近のcriticalログ​

./ops-check.sh

次を自動で実行します。

  • HTTPSヘルスエンドポイント(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は同じコンソールです

コンソールとヘルスAPIは両ポートでサービスされます — 4950(HTTPS)と4949(平文HTTP)。同じコンソール・同じAPIで、スキームのみ異なります。4949はもはや4950にリダイレクトしません。

4949は平文です — ログインパスワードとセッションクッキーがそのまま流れます。信頼できないネットワークでは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 (匿名readiness — 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-UAUaExpertなどで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・1884はplantpulse-proxyが、11004・11005はOPC-UAプラグインが、10210はHAコンテナが、その他はホストにplantpulse-datalakeがpublishします。4つのアプリ(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.ymlのports:が定めます。マッピング変更後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. 頻出トラブル​

症状原因1次対処
一部コンテナ異常依存コンテナ停止・リソース不足ホストで./status.sh → アプリならdocker compose … restart <서비스>、インフラならコンテナ内でrestart-<module>.sh
ポートはLISTENだがhealth失敗起動未完了・バックエンド依存性未準備./stack-verify-boot.shで準備状況判定。クリーンインストールは安定まで15～18分かかります
全体停止スタック停止ホストで./up.sh (準備されるまで待機、0=利用可能)
address already in use外部プロセス使用上記ポート競合診断手順
外部接続できない(内部はできる)ホストファイアウォール またはクラウドSGfirewall-cmd --list-ports及びクラウドSG確認
TLSハンドシェイク失敗(TimeoutExceptionのみで見える)証明書SAN不一致PP_TLS_SAN_DNS/PP_TLS_SAN_IPS確認。証明書はplantpulse-certsワンショットがベイクします → セキュリティ設定
リアルタイム更新切断ファイアウォール・プロキシのidle timeoutフロント段プロキシのproxy_read_timeout上向き。リアルタイムプッシュは443経由です

7. 運用自動化​

ヘルスチェック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連携​

plantpulse-monitorが公開する/metricsエンドポイントをPrometheusがスクレイプするよう構成します。

# 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に同じデータソースを接続できます。

関連文書​