システムの起動と停止

概要

PlantPulse は Docker Compose スタックとして動作します。起動 / 停止 / 再起動は /opt/kopens/plantpulse-platform-docker/bin/ の共通動詞一箇所で管理され、コンテナ間の依存性順序は compose の depends_on が自動的に適用するため、運用者が個別に順序を気にする必要はありません。

終了コード 0 の意味が異なります

up.sh と restart.sh の 0 は「コマンドが成功した」ではなく**「これで利用可能」**という意味です。2026-08-14 の認証情報ローテーション時に「起動した」だけで次のステップに進み、まだ起動していないブローカーで停止する事故があったため、両動詞は準備されるまで待機するように変更されました。

status.sh は異なります — 0 = 正常 / 2 = 異常です。

推奨運用コマンド (要約)

cd /opt/kopens/plantpulse-platform-docker/bin

./up.sh                # 기동 (멱등) — 준비될 때까지 대기. 0 = 준비 완료
./down.sh              # 안전 종료 (의존 순서의 역순, 상태 보존)
./restart.sh           # graceful drain → 정지 → 기동 → 준비 대기
./status.sh            # 서비스 / health / 볼륨 요약. 0 = 정상 / 2 = 비정상
./ops-check.sh         # 헬스 + 최근 critical log
./logs.sh [서비스]     # 로그 보기 — 1회 출력, -f 로 따라가기 (인자 없으면 전체)
./stack-verify-boot.sh # 스택 전체 준비 판정
./doctor.sh            # 진단 tarball (시스템 변경 없음)

すべての動詞が --help をサポートします。古い名前(stack-run.sh · stack-stop.sh · stack-bash.sh · stack-update.sh · stack-remove.sh)もそのまま動作します。

環境変数	デフォルト値	意味
`PP_READY_TIMEOUT`	`900`	準備完了待ちの上限(秒)
`PP_READY_INTERVAL`	`15`	確認間隔(秒)
`PP_WAIT=0`	—	待機しない。この時の `0` は準備完了を意味しません

起動順序 (自動)

コンテナ間

compose の depends_on が**service_healthy 条件**で順序を守ります — 「プロセスが起動した」ではなく「利用可能」を待ちます。この順序は恣意的ではなく、アプリケーションオーケストレータの起動順序をそのまま移しています。

最後の4つ(warehouse · opcua · aasx · ha)は相互に順序がありません。

データレイクコンテナ内

インフラストラクチャコンポーネントは plantpulse-datalake した単一コンテナ内で順序を追って起動します。

順序	領域	主要コンポーネント	代表ポート
1	ストレージ	Cassandra, PostgreSQL, Valkey, MinIO	9042 / 5432 / 6379 / 9000
2	分析	Spark, Hive, Kyuubi, Gravitino	7077 / 9083 / 10000 / 19001
3	時系列	TSE Engine, UI	7800 / 3000
4	メッセージング	Kafka, MQTT	9092 / 1883
5	ワークフロー	Temporal, Kestra	7233 / 8233 / 8380
6	処理	CEP, Data Gateway, SQL, Monitor	7400 / 5500 / 4000 / 4950

所要時間

プロセス起動自体は3～5分(JVM ウォームアップ)ですが、クリーンインストールは Cassandra スキーママイグレーションと安定化に時間がかかるため、全コンポーネントが安定するまで15～18分かかります。

実測(2026-08-31、32 vCPU / 128GiB): データレイク 217秒、ウェブサーバ 316秒。既存データがある再起動はもっと速いです。

停止順序

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

順序を手動で守る必要はありません。 compose が依存順序の逆順で停止するため、データを書き込む側(アプリ)が先に停止し、データレイクが最後に停止します。各コンテナには十分な停止猶予(stop_grace_period)が設定されており — データレイクは 180秒 — Cassandra が Memtable をフラッシュする時間が確保されます。

ボリューム(pp-data · pp-temp · pp-backup · pp-security · pp-proxy-certs)は停止・削除と無関係に常に保持されます。

docker kill やホスト強制シャットダウンを使わないでください

Cassandra のフラッシュされていない Memtable データが失われる可能性があります。必ず ./down.sh を使ってください。既にコンテナが応答しない場合は緊急手順に従ってください。

再起動

全体再起動

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

(実行中の場合) データレイクに graceful drain を要求
スタック全体を依存順序の逆順で停止
depends_on 順序で再起動
準備されるまで待機 — 終了コード 0 なら利用可能な状態

bin/env.sh 変更、ロケール・タイムゾーン変更、一時的な問題解決、定期再起動に使用します。

アプリ1つだけ再起動

6つのアプリはそれぞれ個別コンテナで動作するため、そのコンテナだけ再起動すれば、残りのアプリとインフラは起動したままです。これがコンテナを分けた理由の1つです。

cd /opt/kopens/plantpulse-platform-docker
docker compose -f compose/docker-compose.yml restart plantpulse-server-web

docker compose restart は依存順序を守りません

複数のアプリを同時に復帰させる場合は ./restart.sh でスタック全体を再起動する方が安全です。

インフラストラクチャコンポーネントのみ再起動

./shell.sh                                                              # 데이터레이크 진입
/opt/kopens/plantpulse-platform/plantpulse-datalake-cli/bin/pd restart storage
exit

利用可能なスクリプトは pd restart storage · pd restart analytics · pd restart messaging · pd restart timeseries · pd restart workflow · pd restart cep · pd restart data-gateway · pd restart sql · restart-monitor.sh です。詳細はスタートアップガイドをご覧ください。

状態確認

ワンライン要約

./status.sh            # 0 = 정상 / 2 = 비정상

status.sh が異常と判定するのは5つです。

判定	内容
サービス一覧が読めない	compose 解析失敗または docker アクセス不可
compose が宣言したサービスにコンテナがない	起動されていない
常時コンテナが `running` ではない	ワンショット(`plantpulse-certs`)は除外
常時コンテナの health が `unhealthy` ではない	`starting` / `none` は判定保留
ヘルスチェック API が OK ではない	データレイク内でプローブ

ボリュームと conf は報告のみで終了コードに含めません — 2ノード分割インストール(PP_TIER=APP)では一部が存在しないのが正常だからです。

ワンショットの Exited (0) は成功です

plantpulse-certs は認証書を焼いて自動的に終了します。compose はこのコンテナのヘルスチェックを明示的に無効化しています(healthcheck: disable) — ワンショットにヘルスプローブを付けると「正常に動作するコンテナが永遠に unhealthy に見える」ため、全員がこの例外だけを覚えておく必要があるからです。status.sh と ops-check.sh はこのコンテナを終了コードで判定します — 手動確認時も同様にしてください。

コンテナ確認

docker ps                       # 여덟 개가 (healthy), certs 는 Exited (0)
docker stats --no-stream        # 컨테이너별 CPU / 메모리

ヘルスチェック API

# 호스트 / 외부에서 — 4950 이 publish 되어 있습니다
curl -kfsS https://<server-ip>:4950/api/health | jq

# 컨테이너 안에서 — 어떤 구성에서도 동작합니다
docker exec plantpulse-datalake curl -kfsS https://127.0.0.1:4950/api/health | jq

"status" の値は OK · WARN · FAIL の3つのみで、OK/WARN が正常範囲です。

4949 でも同じ API が利用できます

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

4949 は平文です — ログインパスワードとセッションクッキーが平文で流れます。信頼できないネットワークでは 4950 を使ってください。4949 は自己署名認証書の警告が実際に運用者をブロックするボックス向けの選択肢です。

ログ確認

./logs.sh                              # 여덟 컨테이너를 시간순으로 한 화면에
./logs.sh plantpulse-server-web -n 200 # 특정 컨테이너
./logs.sh cassandra                    # 데이터레이크 안 컴포넌트 로그 파일
./logs.sh --list                       # 볼 수 있는 대상 전체
./logs.sh -f plantpulse-proxy          # 계속 따라가기 (Ctrl-C 로 종료)

デフォルトは最後の N 行(デフォルト 200)を出力して終了です。追従するには -f を付けてください。

自動起動設定

特別な設定は不要です。 常時コンテナは compose で restart: always として宣言されており、ホストを再起動しても Docker デーモンが起動すれば自動的に上がります。ワンショット(plantpulse-certs)は restart: "no" のため再度実行されません — 再度実行すると認証書を新規生成するからです。

確認することは Docker デーモンの自動起動1つだけです。

systemctl is-enabled docker     # enabled 여야 합니다
sudo systemctl enable docker    # 아니라면

再起動直後、プロキシが一時的に赤く表示されることがあります

ホスト再起動は depends_on 順序が適用されない唯一のパスです — すべてが同時に起動するため、ウェブサーバが起動するまで(実測最大 316秒)、プロキシのヘルスチェックが一時的に失敗することがあります。再試行予算が 360秒に設定されており、docker はunhealthy を理由にコンテナを再起動しないため、自動的に回復する一時的な状態です。

緊急手順

ウェブコンソールが応答しない

cd /opt/kopens/plantpulse-platform-docker/bin

# 1. 어느 컨테이너가 문제인가
./status.sh

# 2. 프록시와 웹 서버 로그
./logs.sh plantpulse-proxy -n 100
./logs.sh plantpulse-server-web -n 200

# 3. 웹 서버만 재시작 (인프라는 유지)
cd /opt/kopens/plantpulse-platform-docker
docker compose -f compose/docker-compose.yml restart plantpulse-server-web

# 4. 회복되지 않으면 진단 번들
bin/doctor.sh

プロキシが緑だが画面が 502 の場合

プロキシのヘルスチェックは自分自身 + アップストリーム到達のみを確認します(バックエンドの健全性はウェブサーバ自身のヘルスチェックが判定します)。プロキシが緑だが画面が表示されない場合は plantpulse-server-web を確認してください。

OOM (Out Of Memory)

# 1. 어느 컨테이너가 OOM 인가
docker inspect plantpulse-server-web --format '{{.State.OOMKilled}} {{.State.ExitCode}} {{.RestartCount}}'

# 2. 호스트 커널 로그
dmesg | grep -i "out of memory\|oom"

# 3. 컨테이너별 사용량
docker stats --no-stream

コンテナごとに上限値が個別に設定されています — データレイクは DOCKER_DATALAKE_MEMORY(デフォルト 80G)、アプリは DOCKER_SERVER_MEMORY · DOCKER_BATCH_MEMORY などです(環境変数参照)。値を調整した後 ./restart.sh で適用します。

1つのアプリの OOM が全体を停止させません

各アプリが mem_limit を個別に持つのは、コンテナ分割の最初の目的です。1つのアプリが上限に達してもインフラと他のアプリは稼働し続けます。

DB 接続失敗

すべてのデータベースは plantpulse-datalake 内にあります。

cd /opt/kopens/plantpulse-platform-docker/bin
./shell.sh                                                            # 데이터레이크 진입

/opt/kopens/plantpulse-platform/plantpulse-datalake-cli/bin/pd node psql       # PostgreSQL
/opt/kopens/plantpulse-platform/plantpulse-datalake-cli/bin/pd node cql        # Cassandra
/opt/kopens/plantpulse-platform/plantpulse-datalake-cli/bin/pd node status     # Cassandra 링 상태

インフラのみ復帰させるにはコンテナ内で pd restart storage を、それでもだめな場合はホストから ./restart.sh を使います。

データ破損が疑われる場合

cd /opt/kopens/plantpulse-platform-docker/bin

./down.sh                                  # 즉시 정지 (추가 손상 방지)
ls -lh /data1/pp-backup/docker-volume/     # 최신 백업 확인
./doctor.sh                                # 진단 번들 (데이터를 임의로 수정하지 마세요)

生成された tarball をwebmaster@kopens.comに送信してください。

運用チェックリスト

日次点検

点検項目	コマンド / 確認方法	正常基準
全体サービス状態	`./status.sh`	終了コード 0
運用ヘルス	`./ops-check.sh`	critical ログなし
ヘルスチェック API	`curl -kfsS https://<server-ip>:4950/api/health`	`status` が `OK` または `WARN`
コンテナ	`docker ps`	8つが `(healthy)`、certs は `Exited (0)`
ディスク使用量	`df -h /data1`	使用率 80% 未満
コンテナリソース	`docker stats --no-stream`	上限比で余裕あり
Cassandra 状態	コンテナ内で `pd node status`	すべてのノード UN (Up/Normal)

週次点検

点検項目	コマンド / 確認方法	正常基準
Cassandra Compaction	コンテナ内で `pd node compactionstats`	Pending タスク過多でない
Cassandra テーブル	コンテナ内で `pd node table-stats`	異常増加なし
Kafka トピック / lag	コンテナ内で `pd node topic`	遅延メッセージ数が正常範囲
バックアップ確認	`ls -lh /data1/pp-backup/docker-volume/`	正常なバックアップが存在
Docker 使用量	`docker system df`	未使用イメージの蓄積なし
ログ容量	`du -sh /opt/kopens/plantpulse-platform-docker/logs`	異常増加なし
セキュリティアップデート	OS パッケージアップデート確認	既知の脆弱性なし

バイナリ(ネイティブ)環境

現在のリリースはバイナリ(ネイティブ)インストールをサポートしていません

以下の内容はバイナリインストールで構築した既存システムのために保持しています。現行出荷版は上記の Docker Compose スタック1つのみのため、コンテナ環境では以下の手順(systemd サービス、Windows サービス、個別プロセス起動)を使わないでください。

バイナリ環境では運用スクリプトが /opt/kopens/plantpulse-platform/plantpulse-startup/ にあります — start-daemon.sh · stop.sh · restart.sh · status.sh · kill.sh · log-viewer.sh。詳細はバイナリインストールをご覧ください。

Linux 起動 (systemd)

systemd サービスが登録されている場合は、以下のコマンドで起動できます。

# 1. 스토리지 서비스 시작
sudo systemctl start plantpulse-postgresql
sudo systemctl start plantpulse-redis
sudo systemctl start plantpulse-cassandra

# Cassandra가 완전히 시작될 때까지 대기 (약 30~60초)
until cqlsh 127.0.0.1 -e "DESCRIBE KEYSPACES" > /dev/null 2>&1; do
    echo "Cassandra 시작 대기 중..."
    sleep 5
done
echo "Cassandra 시작 완료"

# 2. 메시징 서비스 시작
sudo systemctl start plantpulse-kafka
sudo systemctl start plantpulse-mqtt

# 3. 엔진 서비스 시작
sudo systemctl start plantpulse-timeseries
sudo systemctl start plantpulse-cep

# 4. 웹서버 시작
sudo systemctl start plantpulse-server

# 5. 에이전트 시작
sudo systemctl start plantpulse-agent

Linux 手動起動

systemd を使わない場合は、各モジュールの起動スクリプトを直接実行できます。

# 스토리지
/opt/kopens/plantpulse-platform/plantpulse-storage/db/postgres/bin/pg_ctl start -D /opt/kopens/plantpulse-platform/plantpulse-storage/db/postgres/data
/opt/kopens/plantpulse-platform/plantpulse-storage/db/valkey/bin/valkey-server /opt/kopens/plantpulse-platform/plantpulse-storage/db/valkey/conf/valkey.conf &
/opt/kopens/plantpulse-platform/plantpulse-storage/db/cassandra/bin/cassandra

# 메시징
/opt/kopens/plantpulse-platform/plantpulse-messaging/kafka/bin/kafka-server-start.sh -daemon /opt/kopens/plantpulse-platform/plantpulse-messaging/kafka/config/server.properties
/opt/kopens/plantpulse-platform/plantpulse-messaging/mqtt/bin/startup.sh

# 엔진
/opt/kopens/plantpulse-platform/plantpulse-timeseries/bin/startup.sh
/opt/kopens/plantpulse-platform/plantpulse-cep/bin/startup.sh

# 웹서버
/opt/kopens/plantpulse-platform/plantpulse-server/bin/startup.sh

# 에이전트
/opt/kopens/plantpulse-platform/plantpulse-plugin/opc-ua/bin/startup.sh

起動スクリプト (依存性確認付き)

以下は依存性を確認しながら順序立てて起動するスクリプト例です。

#!/bin/bash
# plantpulse-start-all.sh - 전체 플랫폼 시작 스크립트

KOPENS_HOME="/opt/kopens"
LOG_FILE="/var/log/plantpulse/startup.log"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

wait_for_port() {
    local host=$1 port=$2 timeout=${3:-60}
    local elapsed=0
    while ! nc -z "$host" "$port" 2>/dev/null; do
        if [ $elapsed -ge $timeout ]; then
            log "ERROR: $host:$port 연결 타임아웃 (${timeout}초)"
            return 1
        fi
        sleep 2
        elapsed=$((elapsed + 2))
    done
    log "OK: $host:$port 연결 확인"
    return 0
}

# 1. PostgreSQL
log "PostgreSQL 시작 중..."
sudo systemctl start plantpulse-postgresql
wait_for_port 127.0.0.1 5432 30 || exit 1

# 2. Redis
log "Redis 시작 중..."
sudo systemctl start plantpulse-redis
wait_for_port 127.0.0.1 6379 15 || exit 1

# 3. Cassandra
log "Cassandra 시작 중..."
sudo systemctl start plantpulse-cassandra
wait_for_port 127.0.0.1 9042 120 || exit 1

# 4. Kafka & MQTT
log "Kafka 시작 중..."
sudo systemctl start plantpulse-kafka
wait_for_port 127.0.0.1 9092 30 || exit 1

log "MQTT 시작 중..."
sudo systemctl start plantpulse-mqtt
wait_for_port 127.0.0.1 1883 15 || exit 1

# 5. TSE
log "시계열 엔진 시작 중..."
sudo systemctl start plantpulse-timeseries
wait_for_port 127.0.0.1 7800 30 || exit 1

# 6. CEP
log "CEP 엔진 시작 중..."
sudo systemctl start plantpulse-cep
wait_for_port 127.0.0.1 7400 30 || exit 1

# 7. 웹서버
log "PlantPulse 웹서버 시작 중..."
sudo systemctl start plantpulse-server
wait_for_port 127.0.0.1 80 60 || exit 1

# 8. OPC Agent
log "OPC Agent 시작 중..."
sudo systemctl start plantpulse-agent
wait_for_port 127.0.0.1 60000 30 || exit 1

log "전체 플랫폼 시작 완료"

Windows 起動

Windows サービス

Windows 環境でサービスとして登録されている場合は、サービス管理ツール(services.msc)またはコマンドプロンプトから起動できます。

# 서비스 시작 (관리자 권한 PowerShell)
Start-Service PlantPulse-PostgreSQL
Start-Service PlantPulse-Redis
Start-Service PlantPulse-Cassandra
Start-Service PlantPulse-Kafka
Start-Service PlantPulse-MQTT
Start-Service PlantPulse-TSE
Start-Service PlantPulse-CEP
Start-Service PlantPulse-Server
Start-Service PlantPulse-Agent

バッチファイル起動

@echo off
REM plantpulse-start-all.bat - 전체 시작 배치 파일

echo [%date% %time%] PostgreSQL 시작 중...
net start PlantPulse-PostgreSQL
timeout /t 10 /nobreak > nul

echo [%date% %time%] Redis 시작 중...
net start PlantPulse-Redis
timeout /t 5 /nobreak > nul

echo [%date% %time%] Cassandra 시작 중...
net start PlantPulse-Cassandra
timeout /t 60 /nobreak > nul

echo [%date% %time%] Kafka 시작 중...
net start PlantPulse-Kafka
timeout /t 10 /nobreak > nul

echo [%date% %time%] MQTT 시작 중...
net start PlantPulse-MQTT
timeout /t 5 /nobreak > nul

echo [%date% %time%] 시계열 엔진 시작 중...
net start PlantPulse-TSE
timeout /t 10 /nobreak > nul

echo [%date% %time%] CEP 시작 중...
net start PlantPulse-CEP
timeout /t 10 /nobreak > nul

echo [%date% %time%] 웹서버 시작 중...
net start PlantPulse-Server
timeout /t 30 /nobreak > nul

echo [%date% %time%] OPC Agent 시작 중...
net start PlantPulse-Agent
timeout /t 10 /nobreak > nul

echo [%date% %time%] 전체 시작 완료
pause

停止順序

停止は起動の逆順で実行する必要があります。データを収集するエージェントを最初に停止し、最後にデータベースを停止します。

順序	サービス	説明
1	OPC Agent	データ収集停止
2	PlantPulse ウェブサーバ (Tomcat)	ウェブサービス停止
3	CEP	イベント処理停止
4	TSE	時系列エンジン停止
5	MQ (Kafka / MQTT)	メッセージブローカー停止
6	Cassandra	時系列 DB 停止
7	Redis (Valkey)	キャッシュ停止
8	PostgreSQL	メタ DB 停止

注意: Cassandra を他のサービスより先に停止するとまだフラッシュされていない Memtable データが失われる可能性があります。エージェントとウェブサーバを必ず先に停止してデータ書き込みを中止してから Cassandra を停止してください。Cassandra 停止前に nodetool drain コマンドで Memtable を強制フラッシュすることをお勧めします。

Linux 停止コマンド

# 1. 에이전트 종료
sudo systemctl stop plantpulse-agent

# 2. 웹서버 종료
sudo systemctl stop plantpulse-server

# 3. 엔진 종료
sudo systemctl stop plantpulse-cep
sudo systemctl stop plantpulse-timeseries

# 4. 메시징 종료
sudo systemctl stop plantpulse-mqtt
sudo systemctl stop plantpulse-kafka

# 5. Cassandra 안전 종료 (Memtable 플러시 후 종료)
/opt/kopens/plantpulse-platform/plantpulse-storage/db/cassandra/bin/nodetool drain
sudo systemctl stop plantpulse-cassandra

# 6. Redis 종료
sudo systemctl stop plantpulse-redis

# 7. PostgreSQL 종료
sudo systemctl stop plantpulse-postgresql

Windows 停止コマンド

# 역순으로 서비스 중지 (관리자 권한 PowerShell)
Stop-Service PlantPulse-Agent
Stop-Service PlantPulse-Server
Stop-Service PlantPulse-CEP
Stop-Service PlantPulse-TSE
Stop-Service PlantPulse-MQTT
Stop-Service PlantPulse-Kafka
Stop-Service PlantPulse-Cassandra
Stop-Service PlantPulse-Redis
Stop-Service PlantPulse-PostgreSQL

@echo off
REM plantpulse-stop-all.bat - 전체 종료 배치 파일

echo [%date% %time%] OPC Agent 종료 중...
net stop PlantPulse-Agent
timeout /t 5 /nobreak > nul

echo [%date% %time%] 웹서버 종료 중...
net stop PlantPulse-Server
timeout /t 10 /nobreak > nul

echo [%date% %time%] CEP 종료 중...
net stop PlantPulse-CEP
timeout /t 5 /nobreak > nul

echo [%date% %time%] 시계열 엔진 종료 중...
net stop PlantPulse-TSE
timeout /t 5 /nobreak > nul

echo [%date% %time%] MQTT 종료 중...
net stop PlantPulse-MQTT
timeout /t 5 /nobreak > nul

echo [%date% %time%] Kafka 종료 중...
net stop PlantPulse-Kafka
timeout /t 10 /nobreak > nul

echo [%date% %time%] Cassandra 종료 중...
net stop PlantPulse-Cassandra
timeout /t 30 /nobreak > nul

echo [%date% %time%] Redis 종료 중...
net stop PlantPulse-Redis
timeout /t 5 /nobreak > nul

echo [%date% %time%] PostgreSQL 종료 중...
net stop PlantPulse-PostgreSQL
timeout /t 10 /nobreak > nul

echo [%date% %time%] 전체 종료 완료
pause

再起動

一般的な再起動

プラットフォーム全体を再起動するには、停止後に起動を順序立てて実行します。

# 전체 종료 (역순)
sudo systemctl stop plantpulse-agent
sudo systemctl stop plantpulse-server
sudo systemctl stop plantpulse-cep
sudo systemctl stop plantpulse-timeseries
sudo systemctl stop plantpulse-mqtt
sudo systemctl stop plantpulse-kafka
/opt/kopens/plantpulse-platform/plantpulse-storage/db/cassandra/bin/nodetool drain
sudo systemctl stop plantpulse-cassandra
sudo systemctl stop plantpulse-redis
sudo systemctl stop plantpulse-postgresql

# 전체 시작 (정순)
sudo systemctl start plantpulse-postgresql
sudo systemctl start plantpulse-redis
sudo systemctl start plantpulse-cassandra
sleep 60  # Cassandra 시작 대기
sudo systemctl start plantpulse-kafka
sudo systemctl start plantpulse-mqtt
sudo systemctl start plantpulse-timeseries
sudo systemctl start plantpulse-cep
sudo systemctl start plantpulse-server
sudo systemctl start plantpulse-agent

ローリング再起動 (無中断再起動)

クラスタ環境ではサービスを中断せずにノードを1つずつ再起動するローリング再起動を実行できます。

#!/bin/bash
# rolling-restart.sh - 클러스터 Rolling Restart
# 사용법: ./rolling-restart.sh node1 node2 node3

NODES=("$@")

for NODE in "${NODES[@]}"; do
    echo "=== $NODE 재시작 시작 ==="

    # 1. 로드밸런서에서 노드 제거
    echo "$NODE 로드밸런서에서 제거 중..."
    # curl -X POST http://loadbalancer/api/remove-node -d "node=$NODE"

    # 2. 연결 드레인 대기 (기존 요청 처리 완료 대기)
    echo "기존 연결 드레인 대기 (30초)..."
    sleep 30

    # 3. 서비스 재시작
    echo "$NODE 서비스 재시작 중..."
    ssh "$NODE" "sudo systemctl restart plantpulse-server"

    # 4. 헬스체크 통과 대기
    echo "$NODE 헬스체크 대기 중..."
    until ssh "$NODE" "curl -sf http://localhost/api/v5/ping > /dev/null 2>&1"; do
        sleep 5
    done

    # 5. 로드밸런서에 노드 재등록
    echo "$NODE 로드밸런서에 재등록 중..."
    # curl -X POST http://loadbalancer/api/add-node -d "node=$NODE"

    echo "=== $NODE 재시작 완료 ==="
    echo "다음 노드 진행 전 안정화 대기 (60초)..."
    sleep 60
done

echo "Rolling Restart 완료"

お知らせ: ローリング再起動はウェブサーバ(Tomcat)に適用されます。Cassandra クラスタのローリング再起動は nodetool drain の後、各ノードを順序立てて再起動してください。

状態確認

プロセス確認

# 전체 PlantPulse 관련 프로세스 확인
ps aux | grep plantpulse

# 특정 서비스 프로세스 확인
ps aux | grep plantpulse-server
ps aux | grep cassandra
ps aux | grep kafka

ポート確認

# 핵심 포트 한 번에 확인
for port in 5432 6379 9042 9092 1883 7800 7400 80 60000; do
    if nc -z 127.0.0.1 $port 2>/dev/null; then
        echo "OK: 포트 $port 열림"
    else
        echo "FAIL: 포트 $port 닫힘"
    fi
done

ヘルスチェック API

PlantPulse ウェブサーバは /api/v5/ping エンドポイント経由でヘルスチェックを提供します。

# 기본 헬스체크
curl -sf http://localhost/api/v5/ping
# 응답: {"status":"OK","timestamp":1709884800000}

# HTTP 상태 코드만 확인
curl -sf -o /dev/null -w "%{http_code}" http://localhost/api/v5/ping
# 200이면 정상

ログ確認

# PlantPulse 웹서버 로그
tail -f /opt/kopens/plantpulse-platform/plantpulse-server/logs/system.log

# Cassandra 로그
tail -f /opt/kopens/plantpulse-platform/plantpulse-storage/db/cassandra/logs/system.log

# Kafka 로그
tail -f /opt/kopens/plantpulse-platform/plantpulse-messaging/kafka/logs/server.log

# 에이전트 로그
tail -f /opt/kopens/plantpulse-platform/plantpulse-plugin/opc-ua/logs/agent.log

# 시작 시 에러 로그만 필터링
grep -i "error\|exception\|fail" /opt/kopens/plantpulse-platform/plantpulse-server/logs/system.log | tail -20

JVM 状態確認

# Java 프로세스 목록 확인
jps -lv

# PlantPulse 서버 힙 메모리 확인
jstat -gc $(pgrep -f plantpulse-server) 1000 5

# GC 로그 확인
tail -f /opt/kopens/plantpulse-platform/plantpulse-server/logs/gc.log

# 스레드 덤프 (문제 진단 시)
jstack $(pgrep -f plantpulse-server) > /tmp/thread-dump-$(date +%Y%m%d%H%M%S).txt

systemd サービス状態

# 전체 PlantPulse 서비스 상태 확인
systemctl list-units 'plantpulse-*' --all

# 특정 서비스 상세 상태
sudo systemctl status plantpulse-server
sudo systemctl status plantpulse-cassandra

自動起動設定

Linux (systemd enable)

サーバ起動時にサービスが自動的に起動するように設定します。

# 자동 시작 활성화
sudo systemctl enable plantpulse-postgresql
sudo systemctl enable plantpulse-redis
sudo systemctl enable plantpulse-cassandra
sudo systemctl enable plantpulse-kafka
sudo systemctl enable plantpulse-mqtt
sudo systemctl enable plantpulse-timeseries
sudo systemctl enable plantpulse-cep
sudo systemctl enable plantpulse-server
sudo systemctl enable plantpulse-agent

# 자동 시작 상태 확인
systemctl list-unit-files 'plantpulse-*' | grep enabled

お知らせ: systemd ユニットファイルで After= ディレクティブを使ってサービス間の起動順序の依存性を設定しておけば、起動時にも正しい順序で起動します。例:
[Unit]
Description=PlantPulse Server
After=plantpulse-postgresql.service plantpulse-redis.service plantpulse-cassandra.service
Requires=plantpulse-postgresql.service plantpulse-redis.service

[Service]
Type=forking
User=kopens
ExecStart=/opt/kopens/plantpulse-platform/plantpulse-server/bin/startup.sh
ExecStop=/opt/kopens/plantpulse-platform/plantpulse-server/bin/shutdown.sh
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Windows サービス自動起動

# 서비스 자동 시작 설정
Set-Service -Name "PlantPulse-PostgreSQL" -StartupType Automatic
Set-Service -Name "PlantPulse-Redis" -StartupType Automatic
Set-Service -Name "PlantPulse-Cassandra" -StartupType Automatic
Set-Service -Name "PlantPulse-Kafka" -StartupType Automatic
Set-Service -Name "PlantPulse-Server" -StartupType Automatic
Set-Service -Name "PlantPulse-Agent" -StartupType Automatic

# 자동 시작 상태 확인
Get-Service PlantPulse-* | Select-Object Name, StartType, Status

緊急手順

サーバ応答なし

ウェブサーバが応答しない場合は、以下の順序で対処してください。

# 1. 헬스체크 확인
curl -sf --connect-timeout 5 http://localhost/api/v5/ping
echo "HTTP 응답 코드: $?"

# 2. 프로세스 상태 확인
ps aux | grep plantpulse-server

# 3. 포트 점유 확인
ss -tlnp | grep ':80'

# 4. 스레드 덤프 (행(hang) 의심 시)
jstack $(pgrep -f plantpulse-server) > /tmp/thread-dump-$(date +%Y%m%d%H%M%S).txt

# 5. GC 상태 확인
jstat -gcutil $(pgrep -f plantpulse-server) 1000 3

# 6. 웹서버만 재시작 (다른 서비스는 유지)
sudo systemctl restart plantpulse-server

# 7. 재시작 후 헬스체크 확인
sleep 30
curl -sf http://localhost/api/v5/ping

OOM (Out Of Memory)

# 1. OOM 발생 확인
dmesg | grep -i "out of memory\|oom"

# 2. 힙 덤프 확인 (자동 생성된 경우)
ls -la /opt/kopens/plantpulse-platform/plantpulse-server/logs/heapdump*

# 3. 메모리 사용량 확인
free -h
ps aux --sort=-%mem | head -10

# 4. JVM 힙 크기 조정 (catalina.sh 또는 setenv.sh)
# JAVA_OPTS="-Xms4g -Xmx8g -XX:+HeapDumpOnOutOfMemoryError"
# 설정 변경 후 재시작
sudo systemctl restart plantpulse-server

DB 接続失敗

# 1. PostgreSQL 연결 확인
psql -h 127.0.0.1 -U plantpulse -d plantpulse -c "SELECT 1"

# 2. Cassandra 연결 확인
cqlsh 127.0.0.1 -e "DESCRIBE KEYSPACES"

# 3. Redis 연결 확인
redis-cli -h 127.0.0.1 ping

# 4. 연결 수 확인 (PostgreSQL)
psql -h 127.0.0.1 -U plantpulse -d plantpulse -c "SELECT count(*) FROM pg_stat_activity"

# 5. DB 서비스 재시작 (필요 시)
# 주의: DB 재시작 전 반드시 웹서버와 에이전트를 먼저 종료해 주세요
sudo systemctl stop plantpulse-agent
sudo systemctl stop plantpulse-server
sudo systemctl restart plantpulse-postgresql
sudo systemctl start plantpulse-server
sudo systemctl start plantpulse-agent

運用チェックリスト

日次点検

点検項目	コマンド / 確認方法	正常基準
全体サービス状態	`systemctl list-units 'plantpulse-*'`	すべてのサービスが active (running)
コアポート確認	ポート確認スクリプト (上記参照)	すべてのポートが開いている
ヘルスチェック API	`curl http://localhost/api/v5/ping`	HTTP 200、status OK
ディスク使用量	`df -h`	使用率 80% 未満
メモリ使用量	`free -h`	使用率 85% 未満
エラーログ	`grep ERROR plantpulse.log \| tail -20`	繰り返しエラーなし
Cassandra 状態	`nodetool status`	すべてのノードが UN (Up/Normal)

週次点検

点検項目	コマンド / 確認方法	正常基準
Cassandra Compaction	`nodetool compactionstats`	Pending タスク過多でない
PostgreSQL 統計	`pg_stat_activity` 照会	idle 接続過多でない
Kafka Consumer Lag	`kafka-consumer-groups.sh --describe`	遅延メッセージ数が正常範囲
JVM GC 統計	`jstat -gcutil`	Full GC 発生頻度が低い
バックアップ確認	最近のバックアップファイル確認	正常なバックアップが存在
ログファイル容量	`du -sh */logs/`	異常増加なし
セキュリティアップデート	OS パッケージアップデート確認	既知の脆弱性なし

概要​

推奨運用コマンド (要約)​

起動順序 (自動)​

コンテナ間​

データレイクコンテナ内​

停止順序​

再起動​

全体再起動​

アプリ1つだけ再起動​

インフラストラクチャコンポーネントのみ再起動​

状態確認​

ワンライン要約​

コンテナ確認​

ヘルスチェック API​

ログ確認​

自動起動設定​

緊急手順​

ウェブコンソールが応答しない​

OOM (Out Of Memory)​

DB 接続失敗​

データ破損が疑われる場合​

運用チェックリスト​

日次点検​

週次点検​

バイナリ(ネイティブ)環境​

Linux 起動 (systemd)​

Linux 手動起動​

起動スクリプト (依存性確認付き)​

Windows 起動​

Windows サービス​

バッチファイル起動​

停止順序​

Linux 停止コマンド​

Windows 停止コマンド​

再起動​

一般的な再起動​

ローリング再起動 (無中断再起動)​

状態確認​

プロセス確認​

ポート確認​

ヘルスチェック API​

ログ確認​

JVM 状態確認​

systemd サービス状態​

自動起動設定​

Linux (systemd enable)​

Windows サービス自動起動​

緊急手順​

サーバ応答なし​

OOM (Out Of Memory)​

DB 接続失敗​

運用チェックリスト​

日次点検​

週次点検​

概要

推奨運用コマンド (要約)

起動順序 (自動)

コンテナ間

データレイクコンテナ内

停止順序

再起動

全体再起動

アプリ1つだけ再起動

インフラストラクチャコンポーネントのみ再起動

状態確認

ワンライン要約

コンテナ確認

ヘルスチェック API

ログ確認

自動起動設定

緊急手順

ウェブコンソールが応答しない

OOM (Out Of Memory)

DB 接続失敗

データ破損が疑われる場合

運用チェックリスト

日次点検

週次点検

バイナリ(ネイティブ)環境

Linux 起動 (systemd)

Linux 手動起動

起動スクリプト (依存性確認付き)

Windows 起動

Windows サービス

バッチファイル起動

停止順序

Linux 停止コマンド

Windows 停止コマンド

再起動

一般的な再起動

ローリング再起動 (無中断再起動)

状態確認

プロセス確認

ポート確認

ヘルスチェック API

ログ確認

JVM 状態確認

systemd サービス状態

自動起動設定

Linux (systemd enable)

Windows サービス自動起動

緊急手順

サーバ応答なし

OOM (Out Of Memory)

DB 接続失敗

運用チェックリスト

日次点検

週次点検