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

ログおよびモニタリング

ログ確認​

ログは**Dockerが保持しています。**ホストに溜まるログファイルを別途削除する必要はありません — ローテーションは compose に設定されています。

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

./logs.sh                    # 스택 전체를 따라 본다
./logs.sh plantpulse-copilot-web   # 서비스 하나 — compose 서비스 이름 그대로 (여러 개 나열 가능)
./logs.sh --tail 50          # 기본보다 «적게» 보고 싶을 때
-f を付ける必要はありません

logs.sh はすでに追従(-f)で回っています。後ろに付けた --tail の値が既定値に優先します。

compose を直接呼び出しても構いません。

cd /opt/kopens/plantpulse-ai-docker
docker compose logs -f --tail=200 plantpulse-rag-api
docker compose logs -f plantpulse-litellm

どのコンテナを見ればよいか​

症状確認するコンテナ
画面が表示されないplantpulse-proxy · plantpulse-copilot-web
回答が返ってこないplantpulse-litellm · plantpulse-llm
文書が見つからないplantpulse-rag-api · plantpulse-lightrag
文書を読み込めないplantpulse-docling-serve · plantpulse-document-understanding-api
時系列分析ができないplantpulse-timeseries-insight-api · -server
管理コンソールがおかしいplantpulse-admin-api · plantpulse-admin-web
コネクタ・グラフミラー・設備タイムラインがおかしいplantpulse-digital-thread-api · plantpulse-digital-thread-neo4j
映像が索引化されない・音声での質問ができない（映像・音声を有効にしたインストール）plantpulse-asr · plantpulse-asr-audio · plantpulse-document-understanding-api · plantpulse-rag-api

コンテナ全体のリストと役割は 設置概要 にあります。

AI ツール呼び出しの観察 — 質問の「ツール行」と Phoenix​

AI が回答を作る過程で何をしたかを見られる場所は2つあります。

場所何が見えるか開き方
質問の回答上のツール行（「ツール N個使用 · N秒」）その回答が呼んだツールと問い合わせた値、失敗したツール質問（/chat）からそのまま
Arize Phoenix（plantpulse-phoenix）LLM 呼び出しのトレース — プロンプト・応答本文までホストには開いていません — 診断時のみ PP_DEBUG_PORTS=1 で開きます → サービスポートマップ
Phoenix は既定で動いています — ホストポートだけ閉じています

Phoenix は基本スタックに含まれ、トレースを継続的に収集しています。2026.09 から 6006 をホストに公開 しないだけです — 認証がない状態で保持しているのが質問と回答の本文であるためです。管理コンソール LLM のログ 画面にはモデル・トークン・遅延のみがあり、本文は Phoenix のみにあります。

質問の回答ごとに付くツール行を展開すると、どのツールがどの値で呼ばれたか、失敗したものがあるかを確認できます。自動化が回った回は、自動化の実行記録に「根拠 — ツール呼び出しN回」として残ります。

サービス状態モニタリング​

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

./status.sh    # compose ps + 외부 노출 지점(copliot-web :80) 응답 확인
./health.sh    # 위에 더해 호스트 디스크 · 컨테이너 자원 · 서비스별 최근 로그
./doctor.sh    # 무엇이 잘못됐는지 진찰 — 아무것도 바꾸지 않습니다

素早く確認するなら status.sh、障害中なら health.sh で広く見た後 doctor.sh で絞り込みます。

ヘルスチェックエンドポイント​

サービスヘルスチェック URL備考
AI Chat Webhttp://127.0.0.1/actuator/healthプロキシを経由して入ります
RAGhttp://127.0.0.1:7115/healthrag-api。キーなしで可能（免除パス）
時系列インサイトhttp://127.0.0.1:8970/healthキーなしで可能（免除パス）
LiteLLMhttp://127.0.0.1:4000/health/liveliness/health はマスターキーを要求する場合があります
管理コンソールhttp://127.0.0.1:5959/healthコンテナ自体のヘルスは /ping。ポートは PI_ADMIN_WEB_PORT（既定 5959）— 変更していればその値で。以降のサービス状態の集計はコンソール画面で
デジタルスレッドホストから到達不可 — 管理コンソールホームのデジタルスレッド API カード7140 は公開していません。カードは /health を読み、グラフミラー投影が failed なら degraded（黄色信号）に下がります。コネクタ定期同期の状態（connector_sync）もここに載りますが情報表示のみで黄色信号を発生させません
文書理解ホストから到達不可 — docker exec plantpulse-document-understanding-api python3 -c "import urllib.request;print(urllib.request.urlopen('http://localhost:7120/health').read().decode())"映像・音声を有効にしたインストールでは components.asr.status が up である必要があります（オフのインストールは disabled — 正常）。文字起こしサービングが落ちていれば degraded です
7114 は死んだアドレスです

以前は LightRAG を 7114 で直接公開していましたが、現在は**rag-api（7115）が唯一の 窓口**であり、LightRAG 自体はコンテナ内にのみ存在します。7114 を叩いて「死んでいる」と判断 しないでください — そもそもそこには存在しません。

ホストに開いていないもの

Qdrant・vLLM・埋め込み・リランカー・docling・時系列推論・admin-api はホストポートを 公開していません（2026-08-21）。Phoenix も 2026.09 から、デジタルスレッド API（7140）とその専用 Neo4j も 2026.10 から同様です。コンテナ内でのみ互いを呼び出すため 127.0.0.1 で 叩いても応答しません。診断が必要な場合はデバッグオーバーレイで復活させます → サービスポートマップ

統合 MCP は Platform のものです

Platform の server-web が提供するため、ヘルスチェックもPlatform側を見ます。

指標 — /metrics​

2026.10 再リリースから Python バックエンド5つ（RAG・時系列インサイト API・文書理解・ビジョン・デジタルスレッド）がPrometheus テキスト形式の指標を GET /metrics で出力します。新しいポートはなく、各サービスの元のポートに付くパスです。

サービス指標アドレスホストから
RAGhttp://127.0.0.1:7115/metrics到達可能
時系列インサイト APIhttp://127.0.0.1:8970/metrics到達可能
文書理解・ビジョン・デジタルスレッドplantpulse-document-understanding-api:7120 · plantpulse-vision-api:7130 · plantpulse-digital-thread-api:7140 の /metrics到達不可 — 同じ compose ネットワーク内から取得します
curl -s -H "X-API-Key: <PI_INBOUND_API_KEY>" http://127.0.0.1:7115/metrics | grep '^http_requests_total' | head
/metrics はキーが必要です

ヘルスパス（/ping · /health）とは異なり、インバウンドキーの背後にあります。Prometheus で取得する際は X-API-Key ヘッダーや authorization:（Bearer）設定で PI_INBOUND_API_KEY を渡します。キーなしで呼ぶと 401 になります。

指標意味
http_requests_total処理したリクエスト数 — メソッド・パステンプレート・ステータス系列（2xx など）別
http_request_duration_secondsリクエスト遅延ヒストグラム — 同じラベル
http_requests_in_flight現在処理中のリクエスト数
app_build_infoサービス名・バージョン・リリース（release ラベル、例 2026.10）。値は常に1

パスラベルは実際のパスではなくパステンプレートであり、どのルートにも一致しないリクエストは <unmatched> 一つに畳み込まれます — ID の入ったパスごとに時系列が生成されることはありません。プロセス・GC といった基本指標も併せて出力されます。

1つのリクエストをログで追跡する — X-Request-ID​

同じ5つのサービスはリクエストごとに id を付与し、応答ヘッダー X-Request-ID として返し、そのリクエストが処理される間のすべてのログ行に request_id として記録します。呼び出す側が X-Request-ID（1〜128文字、英数字・. _ -）を付けて送れば、その値をそのまま 使用します。画面に表示されたエラーをログと突き合わせる際は、この値一つで検索します。

docker compose logs plantpulse-rag-api 2>&1 | grep '<request_id 값>'

ディスクが一杯になったとき​

ログファイルを手動で削除する必要はありません — コンテナログは Docker がローテーションします。 ディスクを消費するのは大抵イメージとボリュームです。

docker system df                 # 무엇이 얼마나 쓰고 있나
docker image prune -f            # 태그 없는 옛 이미지 정리
docker volume prune を不用意に実行しないでください

Neo4j 2インスタンス・Qdrant・LightRAG ストレージ・インストールごとに学習した時系列モデル（pi-ttm-tuned-models）と TLS 証明書がボリュームにあります。コンテナが停止している間に実行するとナレッジグラフとベクトル索引、現場で学習した モデルが消えます。

health.sh がホストディスクとコンテナリソースを併せて表示するので、整理前にまずそれを確認してください。

関連項目​