日志及监控
查看日志
日志由 Docker 持有。 不需要手动清理堆积在主机上的日志文件 — 轮转已在 compose 中设置好。
cd /opt/kopens/plantpulse-ai-docker/bin
./logs.sh # 스택 전체를 따라 본다
./logs.sh plantpulse-copilot-web # 서비스 하나 — compose 서비스 이름 그대로 (여러 개 나열 가능)
./logs.sh --tail 50 # 기본보다 «적게» 보고 싶을 때
-flogs.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 在生成答案过程中做了什么,有两个位置。
| 位置 | 内容 | 打开方式 |
|---|---|---|
| 提问答案上方的工具行(「使用了 N 个工具 · N 秒」) | 该答案调用的工具及传入的值、失败的工具 | 在提问(/chat)中直接查看 |
Arize Phoenix(plantpulse-phoenix) | LLM 调用追踪 — 直到提示词 · 响应正文 | 默认不对主机开放 — 只在诊断时通过 PP_DEBUG_PORTS=1 打开 → 服务端口映射 |
Phoenix 包含在默认技术栈中,持续采集追踪数据。自 2026.09 起,只是不再向主机发布 6006 端口 —— 因为没有认证,而其中承载的正是问题与答案的正文。管理控制台 LLM 的日志 画面只显示模型 · token · 延迟,正文只保存在 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 Web | http://127.0.0.1/actuator/health | 经由代理进入 |
| RAG | http://127.0.0.1:7115/health | rag-api。无需密钥(豁免路径) |
| 时序洞察 | http://127.0.0.1:8970/health | 无需密钥(豁免路径) |
| LiteLLM | http://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 |
以前曾将 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
探测也无效。如需诊断,可通过调试覆盖层恢复访问 →
服务端口映射
由 Platform 的 server-web 提供,因此健康检查也应查看 Platform 一侧。
指标 — /metrics
自 2026.10 重新发布版本起,五个 Python 后端(RAG · 时序洞察 API · 文档理解 · 视觉 · 数字线程)已可
通过 GET /metrics 输出 Prometheus 文本格式的指标。没有新增端口,只是在各服务原有端口上附加了路径。
| 服务 | 指标地址 | 主机是否可访问 |
|---|---|---|
| RAG | http://127.0.0.1:7115/metrics | 可访问 |
| 时序洞察 API | http://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 等基础指标也会一并输出。
在日志中串联单个请求 — X-Request-ID
这五个服务会为每个请求分配一个 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 实例 · Qdrant · LightRAG 存储 · 各安装现场训练出的时序模型(pi-ttm-tuned-models)
以及 TLS 证书都保存在卷中。若在容器停止期间执行此命令,知识图谱、向量索引以及现场训练出的
模型都会丢失。
health.sh 可以同时显示主机磁盘和容器资源占用情况,清理前请先查看该工具。