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

よくある質問 (FAQ)

症状や質問から検索してください。回答は簡潔に述べ、詳細な手順はリンク先に譲ります。

設定​

サイドカーを修正したのに反映されません​

コンテナ内にはサイドカーファイルはありません。 値は compose がコンテナを再作成するときに環境変数として入ります。 docker restart は同じ環境変数で再起動するだけです。

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

それでも解決しない場合は、① bin/env.sh --print でどのファイルが優先されているか、② compose がその名前をデータレイクに渡しているかを確認してください → 反映されないとき

コンテナ内で設定ファイルを修正したのに元に戻りました​

正常です。 PP_HOME 以下の conf/ はすべて生成物であり、 pd start が毎回テンプレートから書き直します。修正する場所はホスト側の /etc/kopens/conf/<파일>.template です → テンプレートの修正

export PP_PG_PASSWORD=… bin/up.sh が静かに無視されます​

サイドカーがすでにその名前を持っている場合、サイドカーが優先されます。インストール完了後のノードで値を変更する方法は bin/passwd.sh のみです → パスワード・API キーの変更

イメージを更新したのに新しい設定のデフォルト値が入っていません​

/etc/kopens/conf はホストファイルなので自動では変更されません。起動ツールがデプロイごとに 3-way で調整しますが、オペレーターが修正したファイルは保持し、 [WARN] operator edit kept, but THE IMAGE DEFAULT CHANGED で通知します。そのファイルは手動でマージする必要があります。

docker exec plantpulse-datalake pd config diff --templates     # differs / missing 인 파일
TEMPLATE_FORCE_SEED=1 ./restart-datalake.sh                    # 통째로 이미지 기본값으로 (백업은 도구가 남긴다)

他のボックス（エッジ・AI・ワーカー）がこのデータレイクに接続できません​

ノードファイルにこのホストの LAN アドレスを記述したか確認してください。空のままにすると、compose ネットワーク内のアドレス(10.99.0.100)となり、同じボックス内でのみ通信できます。

sudo vi /etc/kopens/platform.node.env      # PP_MASTER_IP=<이 호스트의 LAN IP>
./restart-datalake.sh

Kafka だけ接続できない場合は、アドバタイズアドレスが原因です → ノードファイル

レンダラーが exit 8 で拒否します​

アドバタイズアドレスが 127.0.0.1 です。ノードファイルの PP_HOST_IP ・ PP_MASTER_IP ・ PP_KAFKA_ADVERTISED_HOST に実際のアドレスを指定してください。エラーメッセージが修正すべき名前を教えてくれます。

レンダラーが exit 3 または exit 4 で停止します​

  • exit 3 — 必須シークレットが空です。メッセージに全名前が含まれています。サイドカーに追加して再作成してください。
  • exit 4 — テンプレートの ${PP_*} に値がありません。メッセージに 이름@템플릿:줄 として表示されます。ノードファイルに値を指定するか、テンプレートを修正してください。

コンポーネント一つ（例: Hive）を停止できますか​

pd には PD_OPTIONS='{"enable-hive": false}' スイッチがありますが、現在の compose スタックはこの変数をコンテナに渡しません。 サイドカーやノードファイルに記述してもコンテナには届かないため、何も停止されません。製品側の補完が必要な事項として報告されています。旧名の PP_OPTIONS はどこからも読み取られません。

言語を韓国語に変更するには​

サイドカーに PP_LANG=ko を記述し、 restart.sh（アプリにも影響する値のため全体再起動）。管理コンソールは別途、アドレスの末尾に ?lang=ko を追加します。

パスワード・アカウント​

パスワードを変更したらプラットフォームが起動しません​

サーバー側のアカウントとサイドカーのどちらか一方だけが変更された状態です。どちらの値が有効か確認してください。

docker exec plantpulse-datalake bash -c 'PGPASSWORD="<구값>" psql -U plantpulse -h 127.0.0.1 -c "SELECT 1;"'
docker exec plantpulse-datalake bash -c 'PGPASSWORD="<신값>" psql -U plantpulse -h 127.0.0.1 -c "SELECT 1;"'

古い値で接続できればサーバー側が変更されていないことになり、新しい値で接続できればサイドカーのみ修正すればよいことになります。今後は passwd.sh を使用してください → パスワード・API キーの変更

passwd.sh が «variable not in the registry» で拒否します​

そのキーはローテーション対象ではありません。 --list に記載されている11個のみが対象です。それ以外は 手動手順に従ってください。タイプミスの場合は、類似したキーが提案されます。

ローテーションが途中で失敗しました​

同じコマンドをそのまま再実行してください。ジャーナルがどこまで進んだかを把握して続きから行います。ロールバックはありません。 probe=NEITHER や verify 실패 の場合は、人がそのコンポーネントに直接接続して状態を確認する必要があります。

ワーカーノードがあるのに passwd.sh が拒否します​

意図された動作です。マスターのみローテーションすると、ワーカーが古い値のまま残り、クラスターが半分の状態になります。手動手順で変更し、ワーカーごとにサイドカー更新＋再起動を繰り返してください。

管理コンソールのログイン画面が «設定されていません» と表示されます​

PP_DATALAKE_ADMIN_PASSWORD が空です。障害ではありません。

bin/passwd.sh PP_DATALAKE_ADMIN_PASSWORD     # --list 에 이 키가 있으면
# 없으면 (2026-09-05 이전 패키지) 사이드카에 줄을 적고 ./restart-datalake.sh

→ Web 画面ログインアカウント

データゲートウェイ・CEP コンソールにログインできません​

PP_DATA_GATEWAY_WEB_PASSWORD ・ PP_CEP_WEB_PASSWORD にはデフォルト値がなく、空の場合はそのコンソールのみ閉じられます。サイドカーに記述して restart-datalake.sh → クエリコンソール

PlantPulse Dashboard のダッシュボードがコンテナ再作成で元に戻ります​

2026-09-08 から解決済みです。 PlantPulse Dashboard の保存先がイメージ内の SQLite から PostgreSQL に 移行され、ダッシュボード・データソース・ユーザー・アラームルールがコンテナ再作成後も保持されます。

既にインストール済みの環境では 🔴 内容が自動的に引き継がれません。 空の PostgreSQL を指すと、空の PlantPulse Dashboard になります → 時系列・PlantPulse Dashboard

pd start が exit 3 で停止します (PlantPulse Dashboard)​

PP_GRAFANA_DB_PASSWORD が空です。2026-09-08 に追加された起動必須の値です — サイドカーに追加して再起動してください。

SQL ツールカードが消えました​

SQL はデータゲートウェイコンソール(https://<server-ip>:5501/)で実行します。管理コンソールのツール画面に Data Gateway カードがあります。

起動・状態​

pd status に STOPPED が一つあるのに、ちょうど起動したところです​

起動中のウィンドウです。 analytics の Kyuubi が最後に起動しますが、spark-master から約54秒かかります。1分後に再確認してください。それでも続く場合は pd logs --lines 100 <서비스> を確認してください。

docker ps は Up なのにサービスがすべて停止しています​

メモリ OOM を疑ってください。PID 1 が systemd のため、Java だけが停止しコンテナは生存しています。

dmesg -T | grep -i "memory cgroup"
docker inspect plantpulse-datalake --format '{{.State.OOMKilled}}'

→ メモリ上限の引き上げ

pd stop が STILL RUNNING(exit 7) で終了しました​

すぐに pd start しないでください。 pd kill --dry-run で残りを確認し、 pd kill → pd status で空になったことを確認 → pd start を実行してください。

pd start が «already running» で拒否します​

すでに起動しています。再起動するには pd stop から実行してください。 FORCE=1 は生存中のプロセスの上に同じポートで再度起動するため、使用しないでください。

初回起動が10分以上かかります​

初回起動は Aster TSDB のスキーマ生成により、ストレージだけで最大500秒かかることがあります。コンテナ起動猶予が900秒である理由です。 bin/logs.sh -f plantpulse-datalake で進行状況を確認してください。

コンソールに «Another job is already running on this node» が表示されます​

2026-09-04 以前の admin-api イメージの症状です。 pd env の IMAGE_BUILT_AT を確認し、古い場合は update.sh を実行してください。新しいイメージでも «検査実行» ボタンは一度に一つしか受け付けないため、少し待ってから再度押してください。

pd をホストで実行すると «command not found» です​

pd はコンテナ内にのみ存在します。 docker exec plantpulse-datalake pd … または bin/shell.sh でコンテナに入って実行してください。

データ​

データが入ってきません​

MQTT → Kafka → コンシューマーのチェーンのどこで詰まっているかを pd flow で確認します。

docker exec plantpulse-datalake pd flow

LAG が大きい場合、コンシューマー（サーバー・CEP・バッチ）が遅いか停止していることを示し、 NA は «一度も読み取られていない» ことを示します — MEMB が 0 ならコンシューマーが起動していないこと、0 より大きくトピックが空なら正常です。管理コンソールのトポロジー画面が同じことを図で表示します。

ディスクが満杯になります / 減りません​

docker exec plantpulse-datalake pd storage        # 얼마나 있나 — 볼륨 · WAL · 슬롯 · 스냅샷
docker exec plantpulse-datalake pd retention      # 언제 사라지나 — TTL · 토픽 보존 · 콜드 티어
  • Aster TSDB の snapshots が大きい場合、 pd node cleanup（スナップショット削除 — 破壊的）。
  • slot.orphan が見える場合、削除されたワーカーのレプリケーションスロットが WAL を保持しています — ホスト側で ops-check.sh --reclaim を実行してください。
  • 停止したモジュールのログが原因の場合、 pd clean を実行してください。
  • pd retention の TTL none は «有効期限なし» ではなく «テーブルデフォルトなし» です。行ごとに TTL が記録されるテーブル(ts_data_points)は正常に失効します。
  • cold_tier の last advance が48時間以上動かない場合、アーカイブジョブが停止しています — ホットディスクが減らない本当の原因であることがよくあります。

Kafka が «advertises 127.0.0.1» で DOWN です​

ノードファイルのアドレスが空です → ノードファイル。コンテナ内の broker.properties ・ server.properties はカフカディストリビューションのサンプルファイルなので、見ても驚かないでください — ブローカーが読み取るのは kafka.properties の一つだけです。

時系列データが数日で消えます​

時系列の一点の寿命は PP_TSE_DATAPOINT_TTL です（デフォルト365日）。2026-09-05 以前は31日間のリテラルでした。値は書き込み時点で記録されるため、引き上げても既に書き込まれた行は復活しません → 変数リファレンス

バックアップ​

バックアップが作成されているかどうか確認するには​

docker exec plantpulse-datalake pd backup schedule      # 잡 다섯의 일정 · 마지막 결과
docker exec plantpulse-datalake pd backup list          # 세트 목록

管理コンソールのバックアップ画面が同じものを表示します → バックアップ・復元

夜間バックアップ時刻を変更するには​

docker exec plantpulse-datalake pd backup schedule set --job postgres-diff --cron "0 45 2 * * ?"

コンテナを再作成しても保持されます — 値はデータレイク DB の backup_schedule 行に保存されるためです。

--calendar は古いフラグです

まだ受け付けられますが、警告が表示されます。さらに悪いのは値をそのまま渡す点です — このカラムは Quartz cron(초 분 시 일 월 요일、6桁)を保持するのに、systemd 構文 (*-*-* 02:45:00)を記述すると誤った式が保存されます。 --cron を使用してください。

cassandra-full がずっと fail (exit 120 (medusa)) です​

2026-09-04 以前のイメージでは Medusa 設定を誰も使用せず、毎日失敗していました。現在は Aster TSDB 起動時に pd が書き直します — pd restart storage の後に pd backup run --engine cassandra --type full で確認してください。

ログ​

ログはどこで確認できますか​

ホストで bin/logs.sh plantpulse-datalake（最後の200行、 -f で追跡）、コンテナ内で pd logs [서비스] を実行します。アプリコンテナのログは pd logs にはなく、 logs.sh <서비스> で確認します → ログとヘルス

誰がいつサービスを停止したか知りたいです​

イベントジャーナル plantpulse-datalake-admin-api/logs/pd-events.jsonl、または管理コンソールのイベント画面で確認できます。コンソールで実行したコマンドは operator:<name> として残ります。コンソールで変更した設定は監査画面に残ります。

関連情報​