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

よくあるご質問 (FAQ)

症状または質問から探してください。回答は短く、詳しい手順はリンク先をご覧ください。

設定

サイドカーを修正しても反映されません

コンテナ内には sidecar ファイルがありません。 値は 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 # 통째로 이미지 기본값으로 (백업은 도구가 남긴다)

別のボックス (Edge · AI · Worker) がこのデータレイクに接続できません

ノードファイルにこのホストの 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_*} に値がありません。メッセージに 이름@템플릿:줄 として表示されます。ノードファイルに値を指定するか、テンプレートを修正します。

コンポーネント 1 つ (例: Hive) を無効にできますか

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

言語を日本語に変更するには

サイドカーに PP_LANG=ko を記入して restart.sh (アプリにも影響する値であり、全体的に再起動します)。管理コンソールは別で、URL の末尾に ?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 실패 の場合は、ユーザーがそのコンポーネントに直接接続して状態を確認する必要があります。

Worker ノードがあるのに 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クエリコンソール

Grafana パスワードを変更してコンテナを再作成したら元に戻りました

既知の問題です。Grafana のデータディレクトリがボリュームではなく、イメージツリー内にあります → Grafana

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

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

起動 · ステータス

pd status に STOPPED が 1 つあるのに、今やっと起動しました

起動の猶予期間です。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 stopSTILL RUNNING (終了コード 7) で終了しました

すぐに pd start しないでください。pd kill --dry-run で残っている内容を確認して pd killpd status で空になったことを確認 → pd start

pd start が「already running」で拒否されます

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

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

初回起動は Cassandra スキーマ作成により storage のみで 500 秒まで かかることがあります。コンテナ起動タイムアウトが 900 秒である理由です。bin/logs.sh -f plantpulse-datalake で進行状況を確認してください。

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

2026-09-04 より前の admin-api イメージの症状です。pd envIMAGE_BUILT_AT を確認して古い場合は update.sh。新しいイメージでも「検査の実行」ボタンは一度に 1 つのみ受け入れるので、しばらく待ってから再度クリックしてください。

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 · 토픽 보존 · 콜드 티어
  • Cassandra snapshots が大きい場合は pd node cleanup (スナップショット削除 — 破壊的)。
  • slot.orphan が表示される場合は削除されたワーカーのレプリケーション スロットが WAL をロックしています — ホスト ops-check.sh --reclaim
  • 停止したモジュールのログの場合は pd clean
  • pd retentionTTL none は「有効期限なし」ではなく「テーブルのデフォルトなし」という意味です。行ごとに TTL が記録されるテーブル (ts_data_points) は正常に有効期限切れになります。
  • cold_tierlast advance が 48 時間以上動かない場合はアーカイブジョブが停止しています — ホットディスクが減らない本当の原因であることが多いです。

Kafka が「advertises 127.0.0.1」で DOWN です

ノードファイルのアドレスが空です → ノードファイル。コンテナ内の broker.properties · server.properties は Kafka ディストリビューションのサンプルファイルなので、驚かないでください — ブローカーが読むのは 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 --calendar "*-*-* 02:45:00"

コンテナを再作成しても保持されます。

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

2026-09-04 より前のイメージは Medusa 設定が誰にも使用されていなかったため毎日失敗していました。現在は Cassandra 起動時に 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> に記録されます。コンソールから変更した設定は監査画面に記録されます。

さらに詳しい情報