管理コンソール

データレイクノードの 運用コンソール です。ブラウザで状態・指標・ログ・診断・設定・バックアップ・ワーカーを一つの画面で確認し、許可された pd コマンドを実行でき、同じアドレスで外部モニタリングシステム（Grafana · Prometheus · Zabbix）にヘルス API を提供します。

🎬 Tour the DataLake admin console · 53초 · 2026.09 기준 화면

項目	値
バックエンドモジュール	plantpulse-datalake-admin-api
動作環境	plantpulse-datalake コンテナ内 — マスター · ワーカーノード双方
アドレス (TLS)	https://<server-ip>:4950/
アドレス (平文)	http://<server-ip>:4949/ — 同一コンソール · 同一API
ログイン	PP_DATALAKE_ADMIN_USER(デフォルト admin) / PP_DATALAKE_ADMIN_PASSWORD
基本言語	英語。?lang=ko を付与すると韓国語

本節のドキュメント

画面	内容
本ページ	コンソール全般 — 接続 · ログイン · 画面構成
バッチ	バッチジョブの状態と履歴
ウェアハウス	ウェアハウス積載状況
アシスタント	現在の問題点、理由、対処法 — 自然言語質問と承認カード

接続

ブラウザで どちらか一方のアドレス にアクセスします。同一のコンソールであり、スキームのみが異なります。

https://<server-ip>:4950/?lang=ko      # TLS  — 권장
http://<server-ip>:4949/?lang=ko       # 평문 — 4950 으로 리다이렉트하지 않습니다

4949 は平文です

ログインパスワードとセッションクッキーが そのまま流れます。 信頼できないネットワークでは必ず 4950 を使用してください。4949 を残しているのはミスではなく選択です。自己署名証明書の警告が、実際に運用者のアクセスを阻止する障壁となるケースがあるためです。

TLS で接続すると、自己署名証明書の警告が表示される場合があります。実際の証明書に変更する方法は セキュリティ設定 に記載されています。

ログイン

ログイン画面には、このノードの名前と 役割（マスター / ワーカー） が併せて表示されます。複数のノードを開いて作業する場合、どのボックスであるかを確認してください。

変数	デフォルト値	説明
PP_DATALAKE_ADMIN_USER	admin	ログイン名
PP_DATALAKE_ADMIN_PASSWORD	2026-09-05以降のインストール版は開発用デフォルト値、それ以前は 空欄	空欄の場合、コンソールが開かない
PP_DATALAKE_ADMIN_API_KEY	なし	ログエンドポイントをマシンが呼び出す際の X-API-Key

パスワードの変更または初回設定方法は ウェブ画面ログインアカウント — 管理コンソール に記載されています。

«このノードのコンソールが設定されていません» と表示された場合

PP_DATALAKE_ADMIN_PASSWORD が空欄であることを意味します。コンソールのみ が起動せず、データレイクは正常に動作します。故障ではなくコミッショニングでの設定漏れであるため、値を入力して再起動してください。

画面構成 — レールとサイドバー

番号	名称
①	アイコンレール — グループ間を移動します。ダッシュボードアイコンの点一つが、このノードの総合判定です(以下)
②	一行サマリー — 「コンポーネント N個すべて正常 · サービス N/N · アラームなし」。この行が緑色であれば、これ以上の確認は不要です。下の行はこのノードの名前 · 役割 · アドレス · ノード数であり、[ノードリスト] はトポロジのノードタブへ移動します
③	データパス — 起動順に配置された段階（メッセージング → CEP → 時系列 → ストレージ → ワークフロー → 分析 → データゲートウェイ）と、各段階の «実行中 / 全体» サービス数。矢印は 宣言されたパス であり、実際の処理量ではありません。実測処理率はさらに下の流入フローカードに記載されています
④	サービス — ③ の段階に属するサービスを同じ順序で展開表示します。「メッセージング 3/4」のように空きがある段階は、ここでどのサービスであるかを確認します
⑤	コンポーネントヘルス — 全体 · 異常 · 注意 · 未計測 · 正常 · 停止。未計測は «正常» ではありません
⑥	タイムライン — コンポーネント別に時間軸上に状態をプロットします（24時間 / 48時間）。斜線は 記録がない区間 です
⑦	言語切替 — EN / KO。アドレスに ?lang=ko を付与しても同様に動作します

アラームカード は、発生しているアラームがある場合にのみ ② と ③ の間に表示されます（連続3回しきい値を超えたもののみ）。アラームがない場合はカード自体を描画しないため、図には含まれません。⑥ の下にはシステムゲージ · 流入フロー · 負荷 · ストレージ · 最近のイベントが続きます。

左側の狭い垂直帯が レール であり、9つのグループがアイコンで配置されています。レールはアイコンのみを表示します — 名前はマウスオーバー時のツールチップで表示されます。

グループを選択すると、そのグループの画面が サイドバー に展開されます。ただし、画面が一つしかないグループはサイドバーが表示されません — 選択肢がない状態でスペースだけを占有することを避けるためです。

レールの順序は、障害発生時に人が問う順序に基づいています — «現在異常があるか» → «どこに» → «何が正しいか» → «誰に知らせるか» → «何を変えるか» → «コマンド» → «別の画面へ» → «何が起きたか».

画面はすべてで 22個、グループは 9個 です。

グループ	区分	画面	回答内容
概要	—	ダッシュボード	現在異常があるか
トポロジ	—	トポロジ (タブ: データフロー · ノード)	パイプラインの どこ が詰まっているか、他へデータが流れているか
観測	状態	状態 · メトリクス	現在の判定と、過去1時間〜7日間の推移
	資源	ストレージ · 保存	ボリューム · WAL · レプリケーションスロット · ストレージサイズ / 何がいつ削除されるか
	活動	ワークフロー · イベント · ログ · 診断 · ジョブ	夜間ジョブが動作したか、何が起きたか — イベントジャーナル、サービスログ、pd doctor、ジョブ履歴
アラーム	—	アラーム	誰に、いつ知らせるか
運用	設定	設定 · APIキー · 証明書	テンプレートとレンダー結果のdiff、テンプレート編集と差し戻し · コンソール発行APIキー · 証明書
	維持	アップグレード · ワーカー	モジュール別バージョン、クラスターワーカーに対して何を変えるべきか
	バックアップ	バックアップ	バックアップセット · スケジュール編集 · 実行 · 復元
コマンド	—	コマンド	許可された pd 動詞を画面から実行
ツール	—	ツール	他製品ウェブUIへ移動するカード
記録	—	監査	このコンソールで誰が何を変えたか
アシスタント	—	アシスタント	現在の問題点、理由、対処法 — ゲートウェイ設定と承認カードまで

レールの点を確認する方法

レールの点は ダッシュボードアイコンに一つ だけ配置されています。どの画面にいても 「このノードに異常があるか」 を示し、値は /api/health の status、すなわち サーバーがコンポーネントを総合した判定 そのものです。詳細はダッシュボードで確認します。

点	意味
OK	サーバーの総合判定が正常
WARN	サーバーの総合判定が警告
FAIL	サーバーの総合判定が失敗
UNKNOWN (灰色)	判定を信頼できない — ポーリング停止、サーバー収集器停止、応答なし、不明な判定

計測不能は灰色です — 緑ではありません

灰色の点は 「正常」ではなく 「計測不能」 です。他のグループのアイコンには点が表示されません。これはそのグループが正常であることを意味するのではなく、グループ別状態をレールに描画しない仕様であることを意味します。

静かであることは正常ではありません。 ミュート · ルールオフ · 最小重要度未満 · 抑制区間 · チャネルなし — アラームが鳴らない理由は5つあり、コンソールはこれらをそれぞれ異なる文章で通知します。

画面別の留意事項

画面	留意事項
トポロジ	2つのタブは同一システムの2つの視点です — データフロー(MQTT → Kafka → 消費者)とノード(マスター · ワーカー)。ダッシュボードが «異常あり» と示した場合、ここで どの区間 であるかを確認します
状態および情報 → コンポーネント	行を選択するとコンポーネント詳細へ移動します。pd status 表と同一行であり、15秒ごとに更新されます。起動直後の数十秒間の STOPPED はウィンドウ（window）です
ログ	pd logs --list が宣言したファイルのみを表示します。アプリコンテナ(サーバー · バッチ · ウェアハウス)のログはここに含まれません — ホストの logs.sh を使用してください
診断	pd doctor の結果。 «検査実行» ボタンで即座にもう一度実行します。一度に一つしか処理できないため、 «busy» と表示された場合はしばらく経ってから再度押してください
ジョブ	バックアップ · アーカイブ · 維持ジョブの履歴を 一箇所 で確認。バックアップ画面はバックアップのみを個別に確認します
設定	«今レンダーすると何が変わるか»(pd config diff)と «自分のテンプレートがイメージデフォルトと異なるか»(pd config diff --templates)。画面でテンプレートを修正するとリビジョンが残り、差し戻し可能です。値(パスワード · アドレス)の正本は引き続きホストにあります → 設定変更方法
アップグレード	イメージタグ(/etc/plantpulse-image.env)とモジュール別バージョン・リビジョン(/etc/plantpulse-modules.json)。 確認のみを行い、更新はしません → 以下
ワーカー	クラスターワーカーに対して 何を変えるべきかコマンドを提示するだけで、実行はしません。 実行はホストで行います → クラスターインストール
バックアップ	セットリスト · スケジュール · 現在の動作状況。 «Schedule editor» が pd backup schedule set を呼び出します。日程は systemd タイマーではなく backup_schedule 表 + Quartz です → バックアップ · 復元
コマンド	サーバーが定めた 許可リスト の pd 動詞のみが実行されます(リストは画面右側に表示されます)。それ以外のコマンドはコンテナシェルにて → pd CLI · 以下
ツール	他製品のウェブUIをカードとしてまとめ、新タブで開きます。 アドレスのホストは 現在接続しているホスト に従うため、どのボックスから開いてもそのボックスのツールへ移動します。このノードに存在しないサービスのカードは描画されません
ワークフロー	Temporal と Kestra 両方 を併せて確認します。 読み取り専用 — この画面では実行・トリガー・一時停止・終了は行いません。「対象外」はまだ実行記録がなく判定するものがないことを意味します
保存	テーブル TTL · トピック保存 · コールドティア · アーカイブジョブをまとめて管理。「なし」は有効期限のない表(カウンタ・現在値)です
資格証明	単独の画面はありません。 状態および情報 → コンポーネント 詳細のカードから、そのコンポーネントの値を 一件ずつ 確認・変更します → 以下
アシスタント	このノードについて自然言語で質問し、承認カードで実行します。LLMゲートウェイを直接接続する必要があります → アシスタント
監査	このコンソールで誰が何を変えたか。 ワーカーノードには監査ストレージがないため、常に «読み取り不可» と表示されます — 異常なく静かであるという意味ではありません

主要画面

トポロジ — パイプラインのどこが詰まっているか。データフローとノードの2つのタブで構成されます。

状態および情報 — コンポーネント別の判定。pd status と同一行であり、15秒ごとに更新されます。最下部の コンポーネントバージョン 表は、このノードではなく この版 の構成です — 公式バージョン · 自社バージョン · ポート · ライセンス · 出典 · モジュール。- は該当なしを意味します(そのまま使用するコンポーネントには自社バージョンがなく、リスニングポートがないものも存在します)。コンポーネント詳細にも同一の値が表示されます。

ワークフロー — 夜間アーカイブとバッチフローが予定通り動作したか。2つのエンジンを併せて確認します: Temporal(Aster TSDB → Iceberg アーカイブ)と Kestra(バッチフロー)。

読み取り専用です

実行はエンジンが行います。この画面は トリガー · 一時停止 · 終了を行いません — 閲覧のみです。スケジュールを変更する場所はバックアップ画面(または pd backup schedule set)です。

保存 — 何がいつ削除されるか。Aster TSDB テーブル TTL とサイズ、Kafka トピック保存、コールドティアおよびそれを充填するアーカイブジョブを一つの画面にまとめます。

保存期間を視覚的に確認する最短ルート

pp.tm_tag_point の TTL が 3650日 と表示されます。値を変更する方法は データ保存期間 に記載されています。

設定 — 「今レンダーすると何が変わるか」と「自分のテンプレートがイメージデフォルトと異なるか」。

バックアップ — セットリスト · 日程 · 現在の動作状況。

ツール — 他製品ウェブUIをカードとしてまとめ、新タブで開きます。

監査 — このコンソールで誰が何を変えたか。

空の画面が «異常なし» を意味するわけではありません

まだデータを提供していない画面は空である旨を通知し、それが «異常なし» という意味ではないことを併記します。空の画面を正常として読み違えないでください。

観測グループの4画面

先の 「主要画面」 が «何が間違っているか» を扱ったのに対し、観測グループの4画面は «なぜそうなるか» に答えます。4画面すべて 観測 → 状態 / 資源 / 活動 サイドバーからアクセスします。

メトリクス — 単一コンポーネントの計測履歴

番号	場所	内容
①	サイドバー	観測グループの各画面 — 状態および情報 · メトリクス / ストレージ · 保存 / ワークフロー · イベント · ログ · 診断 · ジョブ
②	左側	コンポーネントリスト — 一つを選択します
③	リスト下	灰色で塗られたコンポーネントの意味と、 一度に一つしか照会しない という案内
④	右上	期間 — 1時間 · 6시간 · 24時間 · 48時間 · 7日
⑤	本文	単位別にまとめられたチャート (% · B/S · BYTES · LOAD …)

ダッシュボードと分離した理由

ダッシュボードは 何も選択せずに 閲覧する分類画面であるため、1日を超える期間設定がありません。 対してこの画面は、 単一のコンポーネント · 単一の期間を選択して 深掘りするための場所です。

7日を超える期間と、データレイク自身ではない «プラントデータ» は PlantPulse Dashboard の役割 です。 この画面に 「PlantPulse Dashboard で開く」 リンクがないのは意図的です — 存在が確認されていないダッシュボードへ誘導するリンクは、ない方が勝るためです。

灰色は «ない» ではなく «サーバーが「ない」と回答した» です

コンポーネントが灰色に塗られるのは、 そのコンポーネントに対して応答が届き、その応答が 「収集なし」 であった場合のみ です。まだ誰も閲覧していないコンポーネントには何も表示しません — 推測で塗布すれば、それがまた新たな «捏造された判定» となるためです。

一度に一つのコンポーネントのみを照会します。別のコンポーネントを選択すると、リクエストが 移行するだけで 増加することはありません。

ストレージ — ディスクに何があり、どの程度滞在するか

番号	場所	内容
①	サイドバー	資源区分 — ストレージ · 保存
②	最上部	ボリューム — ランタイムツリー · データ · 一時 · バックアップそれぞれの使用率と判定
③	その下	PostgreSQL WAL と レプリケーションスロット — PG_WAL · MAX_SLOT_WAL_KEEP_SIZE · MAX_WAL_SIZE · 役割、およびスロット表
④	左下	Aster TSDB ディスク — データ · コミットログ · スナップショットとキースペース別サイズ
⑤	右下	Kafka ディスク — 設定ファイル · ログディレクトリ · サイズ · 保存 · 最古セグメント · 次回クリーンアップ予想

この画面が設けられた理由 — 停止したレプリケーションスロットがディスクを圧迫する

2026-09-03 に実際に起きた事象です。レプリケーションスロット replica_worker_1 が 非活性のまま 1.4 GB の WAL を保持 しており、max_slot_wal_keep_size は -1(無制限) でした。 製品のどの画面もそれを提示しなかったため、運用者が気づく方法は ディスクが満杯になること だけでした。

そのため、画面順序を次のように設定しています — ボリューム(充填しているか) → WAL·スロット(何が保持しているか) → ストレージサイズと保存(減少するか)。スロット表の «活性» と «保持WAL» を併せて確認してください。

イベント — このノードで起きたこと

番号	場所	内容
①	上端	範囲 — 24時間 / 7日
②	その横	種類フィルタ — アラーム発生・解消 · 開始・開始됨 · 停止・停止됨 · 再起動 · バックアップ開始・終了 · ジョブ開始・終了 · ブート · デプロイ · 運用者 · PD
③	カードヘッダ	イベント (N) — 現在の範囲に含まれる件数
④	表ヘッダ	時刻 · 種類 · コンポーネント · 重要度 · メッセージ
⑤	本文	失敗したバックアップのように ERROR である行は赤色で色分けされます

監査記録が同一画面の下部に付随します。 「何が起きたか」と「我々が何をしたか」は障害対応中には同一の問いであり、2つの画面に分けると時計を二度読み直さなければなりません。同一の時間範囲で下部に連結させ、01:25 の再起動とその命令を出した運用者を並べて表示します。

メモリ保存ストレージの場合、再起動で消失します

ストレージが memory であるノードは、 直近数百件のみを RAM に保持し、再起動すると消失します。 画面上でその旨を一行で通知します — 不完全な履歴を完全なものとして読み違えないでください。

読み取り不能なイベントストレージを «静かな夜» のように描画しません。 ローディング · イベントあり · 範囲が空であること · まだ提供されていないエンドポイント · 計測不能(理由を含む) の5つをそれぞれ個別に描画します。

アラーム — 何をアラームとしてカウントし、どこへ知らせるか

番号	場所	内容
①	最上部	アクティブアラーム — 現在発生しているもの。なければ 「アクティブアラームはありません」
②	中央	ルール カード
③	表ヘッダ	コンポーネント · 通知 · 連続 · 抑制(秒) · 異常時の基準 · 出典 · 動作
④	一行	単一コンポーネントのルール。 [修正] でその行のみを変更します
⑤	下部	チャネル カード + [チャネル追加] — 「有効なチャネル N個」
⑥	その下	チャネルがない場合はその旨を通知します

3つのカードが1画面にあるのは、 一つの問いを三度問うこと だからです — 現在異常があるか(アクティブ) · 何を異常と定義したか(ルール) · 誰がそれを聞くか(チャネル)。 これらを分けると、 静かに空である可能性が高い三番目 を誰も確認しなくなります。

静かであることは正常ではありません — 理由は5つあります

アクティブアラームが鳴らない理由は5つあり、画面は それぞれを異なる文章で 記載します。

画面文言	意味
ミュート済み	そのアラームを人間がオフにした
ルールがオフになっている	ルール表の «通知» がオフ
最小重要度未満	ルールの «異常時の基準» に達していない
抑制区間内	ルールの «抑制(秒)» ウィンドウ内にある
チャネルなし	送信先がない

ヘッダーに 「そのうち N個が静かです」 と併記されます。単一の «無音» バッジで一括りにしないのは、5つの対処法がそれぞれ異なるためです。

また、 設定を読み取れなかったものを «設定なし» と描画しません。 サーバーが store: "NA" と理由を提示すれば、表の上にその文章を記載します — 設置直後であるかのように空の画面を描画しません。設定を 保存できない ノードでは編集ボタンが完全に消失します。押せる灰色のボタンは 「保存した」 と回答して何も変更しないためです。

活動グループの4画面 — 何が起きたか

ジョブ — 長時間を要するすべての作業を一つの台帳に

番号	場所	内容
①	最上部	現在実行中 — ない場合はその旨を通知します
②	その下	種類 · 状態フィルタ — バックアップ · 復元 · 復元計画 · ダンプ · 診断 · 開始 · 停止 · 再起動 · 設定レンダー · PD / 実行中 · 成功 · 失敗 · 不明
③	カードヘッダ	履歴 (N)
④	表ヘッダ	状態 · 種類 · 対象 · 開始 · 所要 · 主体 · 出典 · メッセージ
⑤	失敗行	失敗は理由まで一行に — 例: 「exit 0 だがストレージが増加しなかった — 何も書き込まれなかった」
⑥	不明行	「pd restart は完了行を書き込まない — 結果がジャーナルにない」
⑦	出典列	バックアップ台帳 / pdジャーナル — どの台帳から来た行か

この画面が設けられた理由 — 台帳が3つに分かれていた

バックアップ · 復元 · ダンプ · pd doctor · サービス操作はすべて数分単位の時間を要しますが、終了後に それぞれ異なる場所 に記録が残っていました — コンソールのジョブ台帳、バックアップ台帳、およびブラウザから開始しなかった実行に対する pd 自身のジャーナル。画面ごとに自前分しか表示しなかったため、「今日このボックスで何が動作し、成功したか」は監査ログでしか答えられませんでしたが、 監査ログは HTTP 呼び出しを記録せず、結果を記録しません。

«不明» は失敗でも成功でもありません

個別の結果として描画します。例えば pd restart は完了行を残さないため、 結果がジャーナルにありません — それを成功と塗れば嘘になり、失敗と塗っても嘘になります。

ここでは何も開始・キャンセル・再試行しません。 それらの操作は、確認手順と影響範囲が既に記載されている画面(バックアップ · 診断)にあります。 キャンセルボタンがないのは、このサーバーに実行をキャンセルするエンドポイントが存在しないため です。

ログ — このノードに «存在する» ログ

番号	場所	内容
①	左ヘッダ	ログリスト
②	初行	起動 バッジが付与されたブートログ
③	リスト	コンポーネント · ファイル名 · サイズ · 最終更新
④	右ヘッダ	ログ内容
⑤	検索	文字列 — リテラルであり正規表現ではありません · レベルチップ (TRACE · DEBUG · INFO · WARN · ERROR)
⑥	期間	〜から〜まで · [検索] · [消去]
⑦	右上端	改行 トグル

パスをブラウザが決定しません

クライアントは パスを提示しません。 サーバーが発行した ID を送信し、パスはサーバーが保持しています — 脱出可能な ?path= のようなパラメータは一切存在しません。

ログ本文は テキストのみ で描画されます。ログの一行に <script> が含まれている可能性があり、それを実行するログビューアは運用コンソールに開けられた穴であるためです。

「宣言されたがディスクにないファイル」は 「空ファイル」 ではありません

結果は 2つではなく3つ です — 読み取った / サーバーが pd に問い合わせできなかった / 宣言はされたがファイルがない。後者の2つは 「このノードにログがない」 や 「空ファイル」 ではなく 計測不能 として描画します。

リストに表示されるのは pd logs --list が 宣言したファイル のみです。アプリコンテナ(サーバー · バッチ · ウェアハウス)のログはここに含まれません — ホストの logs.sh を使用してください。

診断 — pd doctor が計測したもの

番号	場所	内容
①	タイトル横	モード — MASTER / ワーカー
②	案内	「最終実行」であることと [検査実行] ボタン
③	その下	診断結果 (計測日時)
④	要約	失敗 · 対象外 · 通過 · 検査数
⑤	グループカード	inputs · tools · … グループ別に分割配置
⑥	表ヘッダ	判定 · 検査 · 内容

ポーリングは行いません — 画面上の数字は «最終実行» です

pd doctor はすべての検査を回して 3秒ほど かかるため、定期的に実行しません。画面の結果はこのノードが保持している 最終実行 であり、③ の時刻がそれをいつ計測したかを示します。 再度計測するには [検査実行] を押してください — 一度に一つしか動作しないため、「busy」と表示された場合はしばらく経ってから再度押してください。

「対象外 0」 と 「計測不能」 は異なります

回答は5通りあり、それぞれ個別に描画します — エンドポイントがまだない / セッション断絶 / リクエスト失敗 / コマンドが全く回らなかった(理由必須) / コマンドは回ったが 検査が0件.

特に後者の2つが重要です。ドキュメント状態が na であることは 「すべて通過」ではありません — 何も計測できなかったことを意味し、必ず理由が付帯します。検査リストが空であることは、また別の三番目のケースです。 どちらを空パネルで描画しても、 何も計測していない画面で 「異常なし」 と読み違える ことになります。

「対象外」 項目には 行ごとに理由が付帯します — 画面はそのように案内します。

ワーカー — コマンドを «提示する» だけです

番号	場所	内容
①	カードヘッダ	ワーカー (計測時刻)
②	表ヘッダ	ワーカー · アドレス · 名簿 · リング · POSTGRESQL · スロット · REDIS · ヘルス · 状態
③	一行	単一ワーカー。レプリケーションスロット名と 遅延量 まで一行に表示
④	その下	ワーカーヘルス — 展開すると詳細表示
⑤	次のカード	何を計測したか
⑥	通過項目	ワーカー名簿(/etc/kopens/workers.roster) · Aster TSDB リング · PostgreSQL · Redis レプリカ · ワーカーヘルスエージェント · このノード自身の物理アドレス
⑦	対象外	ワーカーコンテナ · ワーカーボリューム — 理由がそのまま記載されます

提示しているだけで、実行したわけではありません

ワーカーの追加・削除コマンド(worker-add.sh · worker-decommission.sh · worker-remove.sh)は Docker デーモン · 名簿ファイル · compose オーバーレイを操作しますが、これら3つはすべて ホスト に存在します。この画面の背後の API はデータレイクコンテナ内で動作しており、 Docker ソケットを保持していません。

そのため、以下の4つの区分で厳格に管理しています —

1. 動詞形式のコントロールが存在しません。 画面上の唯一のボタンは コピー です
2. すべてのコマンドは 「ホストで実行」 というタイトルと 作業ディレクトリ を伴って提示されます
3. コマンドが画面にある間は 読み取り専用案内 が常に付随し、その文言は サーバー由来 です — 画面が API の主張と食い違うことを防ぎます
4. 上記3つが崩れた場合、 ビルドに失敗 します

変更すべき点がない場合は、コマンドカード自体が表示されません — 上記の図がその状態です。

「対象外」 は 「異常なし」 ではありません

上記図の ワーカーコンテナ · ワーカーボリューム が該当します。理由がそのまま記載されています — Docker ソケットがこのコンテナにマウントされていないため ここでは覗き見できない という意味であり、問題がないという意味ではありません。

運用・コマンドの2画面と資格証明

これらは 変更側 に近く、「何を表示するか」よりも 「何をしないか」 がより重要です。

アップグレード — 確認のみを行う

番号	場所	内容
①	サイドバー	運用グループ — 設定 / アップグレード · ワーカー / バックアップ
②	カードヘッダ	現在このノード
③	イメージタグ	ビルド名 · build.version · ベイクコミット · ビルド日時 · 読取先(/etc/plantpulse-image.env) · 判定
④	その下	イメージダイジェストは ホストで 確認するという説明 — イメージ内では特定不能です
⑤	次のカード	このイメージを構成するプロジェクト — 「N個中 M個がここでリビジョンを明示します」
⑥	表	プロジェクト · 判定 · バージョン · リビジョン · 読取先(MANIFEST · build-info.json · dist.env … プロジェクトごとに異なります)

この画面は «更新してくれません» — コマンドを «提示する» だけです

サーバーへ送る唯一のボタンは 事前点検 であり、それも読み取り専用診断(pd doctor)です。 コマンドブロックに付随するコントロールは コピー一つのみ であり、そのボタン名はあらゆる言語で 「コピー」 です — 「実行」 でも 「適用」 でもありません。

また、 「最新です」 類の中文はバンドルに一切含まれていません。 このノードは自身が動作しているイメージタグを閲覧することも、リリース済みのバージョンを照会することもできません。安心させる文章は捏造となり、それを読んだ運用者は 更なる調査を止めてしまいます — これこそが本画面が起こし得る最悪の嘘であるため、最初から作成していません。

pd doctor は計測に3秒ほど要するため、 定期的に実行しません。 ボタンを押すとジョブとして動作し、そのジョブをポーリングします。

コマンド — シェルではない

番号	場所	内容
①	最上部	常時案内 — 「定められたコマンドのみ実行します」
②	ターミナルヘッダ	コンソール名と 状態点 — 準備中 · 送信中 · ストリーミング · 切断
③	本文	出力(スクロールバック · ANSI色)
④	最下行	プロンプト — Tab補完 · ↑↓履歴 · Ctrl+L消去
⑤	右ヘッダ	「読み取り専用 N個, ノード変更 M個」
⑥	右側	読み取り専用 動詞 (help version status storage flow env doctor config list config diff node status logs --list backup list backup status backup schedule)
⑦	その下	ノード変更 — 赤枠で分離表示 (config render)

ターミナルのように見えますがシェルではありません

外見だけがターミナルです — 履歴 · スクロールバック · ANSI色 · Tab補完。 実際に動作するのはサーバーが強制する pd 許可リスト のみです。

これをシェルと誤認した人は、 拒絶を «バグ» と読み違えます。 そのため、案内はスクロールバックの色付き一行ではなく、 画面に常に固定された要素 としています — スクロールで押し上げられた警告は、もはや警告として機能しないためです。

許可リストは画面が開くたびに サーバーから受信します。 ドキュメントやコードにコピーを保持しません — コピーはいつか乖離し、その際運用者が読むのは乖離した側になります。リストを受信できなかった場合は オートコンプリートがオフになり、その旨を通知します — 推測したリストで代替することはありません。

ノードを変更するコマンドは確認を得た後にのみ実行されます。 また、拒絶された場合はサーバーが提示した 拒絶理由がそのまま 画面に表示されます — 「失敗」と一括りにすると、製品の安全装置が原因不明のエラーに見えてしまうためです。

出力に混在する資格証明はサーバー側でマスクされます

画面案内の通りです — 「この出力の資格証明は サーバーを離れる前に マスクされます」。 ブラウザが受信して隠すのではなく、最初から送られてきません。

資格証明 — コンポーネント詳細のカード

資格証明は その値を使用するコンポーネントのページ で確認・変更します。単独の資格証明画面は存在しません。 状態および情報 画面でコンポーネント行を選択して詳細へ移動すると 資格証明 カードが表示されます。サーバーがそのコンポーネントに紐付ける資格証明を保持していない場合、カード自体が表示されません。

列	内容
項目	その値が何か — 管理者アカウント · 内部APIキー 等
環境変数	変数名
アカウント	アカウント名。読み取り専用です
パスワード / キー	ドットでマスクされており、 値表示 でその一件のみを露出させます
接続確認	接続確認済み · 値が不一致 · 確認不可 (接続不能) · 接続確認対象外
最終変更	最後に変更された時刻
右端	[変更] 、または変更不能な理由(ロック)

カード下部にはこのコンポーネントの 直近変更 リクエスト3件が表示され、失敗したリクエストは [再実行] 可能です。全履歴は 監査 画面に記載されています。

値は «押すと» 表示されます — そしてその操作が記録されます

リストに 機密値は含まれていません。 値表示 を押すと、その変数名一つで個別にリクエストを送り、値一つだけを受信します。このリクエストは POST であるため監査に残り、名称がアドレスに載ることもありません。

変更はキューに入り、スタックが再起動します

[変更] は値を即座に変更しません。パネルが進行順序を先に提示し、 生成 (32文字) または 値入力 を選択した後、 コンソールパスワード と 変数名 を再入力して初めてキューに入ります。

1. 新しい値を暗号化して保存し、変更をキューに入れます
2. データレイク内で、この値を確認または読み取る箇所に適用します
3. データレイクの全サービスを新値で再起動します — 数分間中断します。 この値を使用する他製品は、自身のコンテナを再作成する際に新値を受信します
4. 各コンポーネントが新値で接続できるか確認します。段階が失敗した場合、リクエストは失敗として残り、同一の値で再実行します

コンソールはアカウントが一つであり役割が存在しないため、ログインしたユーザーはすべての資格証明を変更可能です。パスワードと変数名を再要求することが、その代わりの安全装置となっています。パスワードと新値が通過するため、必ず 4950(TLS) で行ってください。

生成された値はリクエスト時に 一度だけ 表示されます。再表示は不可能です。

«ここで読み取り不可» を «設定なし» と読み違えないでください

値欄の 空欄 は本当に空であることを意味し、 ここで読み取り不可 は本コンソールがその値を読み取れなかったことを意味します。ロックされた行には理由が付帯します — アカウント名は変更しない、他の値から計算される、変更する現在値がない、変更ツールが未実装。

ホストで変更する手順は パスワード変更 に記載されています。

ツール画面のカード

カード	アドレス	内容
CEP	https://<호스트>:7401/	EQLルールとそれがマッチしたイベント
PlantPulse Dashboard	https://<호스트>:3000/	時系列データのダッシュボード
Timeseries Engine	https://<호스트>:7801/	時系列データではなく エンジン自体 の管理画面
Spark	http://<호스트>:4440/	Spark マスター · ワーカー · 実行中のアプリケーション
Temporal	http://<호스트>:8233/	ワークフロー実行と履歴
Kestra	https://<호스트>:8380/	データパイプライン — フロー · 実行 · ログ
RustFS	http://<호스트>:9001/	オブジェクトストレージ — バケット · オブジェクト · アクセスキー
Data Gateway	https://<호스트>:5501/	SQL実行コンソール。 旧SQLツールカードはこれに統合されました(2026-09-07)

カードが起動するツールのうち3つは 使用方法を別途整理しています — データゲートウェイコンソール · 時系列解析器 · CEPコンソール。

TLS ツインポートを持つ画面は TLS 側へリンクされます。本コンソールが TLS(4950) であるため、平文アドレスを提示しないためです。

コンソールによる pd の呼出頻度

コンソールの画面は、リクエストごとに pd を回しません。バックエンドの収集ループが 一度に一つずつ 回して最新ドキュメントをキャッシュし、画面はそのキャッシュを読み取ります。

動詞	周期
pd status --json · pd logs --list	15秒
pd node status --json · pd storage --json	30秒
pd flow --json · pd config diff --json · pd env --json	60秒
pd doctor --json · pd retention --json · pd config diff --templates --json	300秒

周期に従えば、60秒のうち約46秒が pd の実行に費やされます。したがって、 コンソールが動作しているボックスで pd status が時折遅くなるのは正常 です。

ヘルス API

コンソールが描画する画面はすべて /api/* 上にあり、全リストとスキーマはコンソールが /api/openapi.json を読み取って API表として提示します。

curl -kfsS https://<server-ip>:4950/api/health | jq          # TLS
curl  -fsS  http://<server-ip>:4949/api/health | jq          # 평문 — 같은 API
docker exec plantpulse-datalake curl -kfsS https://127.0.0.1:4950/api/health | jq   # 컨테이너 안 — 어떤 구성에서도
curl -kfsS https://<server-ip>:4950/api/services | jq        # 서비스 목록과 상태

ホストの status.sh · ops-check.sh · doctor.sh · stack-verify-boot.sh がすべてこの /api/health を読み取ります。/api/health は認証なしで応答し、それ以外の API はログインセッションまたは X-API-Key(ログエンドポイント) が必要です。

Prometheus 連携

https://<server-ip>:4950/metrics をスクレイプします。自己署名 CA の場合は insecure_skip_verify を有効にします。プラットフォーム同梱の PlantPulse Dashboard(3000) または外部 Grafana でデータソースとして接続してください。

よくある問題

症状	原因	対処
コンソールが開かない · «設定されていません»	PP_DATALAKE_ADMIN_PASSWORD が空欄	ウェブ画面ログインアカウント
4949 は動作するが 4950 が動作しない	証明書の問題	ブラウザの警告を確認、または セキュリティ設定 で証明書を交換
ヘルスエンドポイント応答なし	データレイクコンテナ異常	ホストで status.sh → logs.sh plantpulse-datalake
画面全体が «Not measured»	ポーリング停止または旧イメージ	pd env の IMAGE_BUILT_AT を確認。2026-09-04以前の admin-api は «Another job is already running» を頻発させていました
ツールカードが表示されない	そのサービスがこのノードにない(ワーカー)またはポーリング未応答	マスターノードのコンソールへ
Prometheus スクレイプ 5xx	バックエンドモジュールダウン	status.sh で依存モジュールを確認
監査画面が «読み取り不可»	ワーカーノード	正常 — マスターで確認してください

関連ドキュメント

• ウェブ画面ログインアカウント
• pd CLI — コンソールが提示する情報の正本
• システムモニタリング — 各ウェブアプリの readiness ヘルスチェック
• ポートおよびサービス管理