Logs und Monitoring
Logs einsehen
Die Logs verwaltet Docker. Auf dem Host müssen keine Logdateien manuell gelöscht werden — die Rotation ist in der compose-Datei konfiguriert.
cd /opt/kopens/plantpulse-ai-docker/bin
./logs.sh # 스택 전체를 따라 본다
./logs.sh plantpulse-copilot-web # 서비스 하나 — compose 서비스 이름 그대로 (여러 개 나열 가능)
./logs.sh --tail 50 # 기본보다 «적게» 보고 싶을 때
-f ist nicht nötiglogs.sh folgt dem Log bereits (-f). Ein nachgestellter Wert --tail überschreibt den Standardwert.
Sie können compose auch direkt aufrufen.
cd /opt/kopens/plantpulse-ai-docker
docker compose logs -f --tail=200 plantpulse-rag-api
docker compose logs -f plantpulse-litellm
Welcher Container ist zuständig
| Symptom | Zu prüfender Container |
|---|---|
| Oberfläche erscheint nicht | plantpulse-proxy · plantpulse-copilot-web |
| Keine Antwort | plantpulse-litellm · plantpulse-llm |
| Dokument wird nicht gefunden | plantpulse-rag-api · plantpulse-lightrag |
| Dokument kann nicht eingelesen werden | plantpulse-docling-serve · plantpulse-document-understanding-api |
| Zeitreihenanalyse funktioniert nicht | plantpulse-timeseries-insight-api · -server |
| Admin-Konsole verhält sich auffällig | plantpulse-admin-api · plantpulse-admin-web |
| Konnektor · Graph-Spiegel · Anlagen-Zeitachse verhalten sich auffällig | plantpulse-digital-thread-api · plantpulse-digital-thread-neo4j |
| Videos werden nicht indiziert · Sprachabfrage funktioniert nicht (Installation mit Video · Audio) | plantpulse-asr · plantpulse-asr-audio · plantpulse-document-understanding-api · plantpulse-rag-api |
Die vollständige Containerliste samt Aufgaben finden Sie unter Installationsübersicht.
KI-Tool-Aufrufe beobachten — Tool-Zeile der Abfrage und Phoenix
Es gibt zwei Stellen, an denen sichtbar wird, was die KI bei der Antworterstellung getan hat.
| Stelle | Inhalt | Zugang |
|---|---|---|
| Tool-Zeile über der Antwort („N Tools verwendet · N Sekunden") | Die von dieser Antwort aufgerufenen Tools, die übergebenen Werte, fehlgeschlagene Tools | Direkt in der Abfrage (/chat) |
Arize Phoenix (plantpulse-phoenix) | LLM-Aufruf-Traces — bis hin zu Prompt- und Antwortinhalt | Auf dem Host nicht geöffnet — nur zur Diagnose über PP_DEBUG_PORTS=1 öffnen → Service-Port-Map |
Phoenix ist Teil des Basis-Stacks und sammelt weiterhin Traces. Seit 2026.09 wird 6006 lediglich nicht mehr auf dem Host veröffentlicht — denn ohne Authentifizierung würden dort die Inhalte von Fragen und Antworten liegen. Die Log-Ansicht des LLM in der Admin-Konsole zeigt nur Modell · Token · Latenz; die Inhalte liegen ausschließlich in Phoenix.
Klappt man die Tool-Zeile unter jeder Antwort auf, sieht man, welches Tool mit welchen Werten aufgerufen wurde und ob eines fehlgeschlagen ist. Läufe, die von einer Automatisierung ausgelöst wurden, erscheinen im Ausführungsprotokoll der Automatisierung als „Nachweis — N Tool-Aufrufe".
Service-Status überwachen
cd /opt/kopens/plantpulse-ai-docker/bin
./status.sh # compose ps + 외부 노출 지점(copliot-web :80) 응답 확인
./health.sh # 위에 더해 호스트 디스크 · 컨테이너 자원 · 서비스별 최근 로그
./doctor.sh # 무엇이 잘못됐는지 진찰 — 아무것도 바꾸지 않습니다
Für einen schnellen Blick status.sh; im Störungsfall erst mit health.sh breit schauen und dann mit doctor.sh eingrenzen.
Health-Check-Endpunkte
| Service | Health-Check-URL | Hinweis |
|---|---|---|
| AI Chat Web | http://127.0.0.1/actuator/health | Läuft über den Proxy |
| RAG | http://127.0.0.1:7115/health | rag-api. Ohne Key erreichbar (ausgenommener Pfad) |
| Zeitreihen-Insights | http://127.0.0.1:8970/health | Ohne Key erreichbar (ausgenommener Pfad) |
| LiteLLM | http://127.0.0.1:4000/health/liveliness | /health kann den Master-Key verlangen |
| Admin-Konsole | http://127.0.0.1:5959/health | Container-eigene Health unter /ping. Port ist PI_ADMIN_WEB_PORT (Standard 5959) — bei Änderung entsprechend anpassen. Die dahinterliegende Service-Status-Aggregation in der Konsolenansicht |
| Digital Thread | Vom Host nicht erreichbar — Karte Digital Thread API auf der Startseite der Admin-Konsole | 7140 wird nicht veröffentlicht. Die Karte liest /health; ist die Graph-Spiegel-Projektion failed, fällt sie auf degraded (gelb) zurück. Auch der Status der zyklischen Konnektor-Synchronisation (connector_sync) erscheint hier, ist aber rein informativ und erzeugt kein Gelb |
| Dokumentenverständnis | Vom Host nicht erreichbar — docker exec plantpulse-document-understanding-api python3 -c "import urllib.request;print(urllib.request.urlopen('http://localhost:7120/health').read().decode())" | Bei Installationen mit Video · Audio muss components.asr.status den Wert up haben (bei deaktivierter Installation disabled — normal). Fällt das Transkript-Serving aus, steht dort degraded |
Früher war LightRAG direkt über 7114 geöffnet; heute ist rag-api (7115) der einzige Zugang, und LightRAG selbst existiert nur innerhalb des Containers. Schließen Sie nicht aus einem Test gegen 7114 auf „tot" — dort ist schlicht nichts.
Qdrant · vLLM · Embedding · Reranker · docling · Zeitreihen-Inferenz · admin-api veröffentlichen keine Host-Ports (2026-08-21). Phoenix ebenso seit 2026.09, die Digital Thread API (7140) und deren dediziertes Neo4j seit 2026.10. Da sie sich nur containerintern aufrufen, führt ein Test über 127.0.0.1 ins Leere. Für Diagnosen lassen sie sich per Debug-Overlay reaktivieren →
Service-Port-Map
Da server-web der Platform es bereitstellt, erfolgt der Health-Check auf Platform-Seite.
Metriken — /metrics
Ab dem Re-Release 2026.10 liefern die fünf Python-Backends (RAG · Zeitreihen-Insights-API · Dokumentenverständnis · Vision · Digital Thread) Metriken im Prometheus-Textformat unter GET /metrics. Es gibt keine neuen Ports — der Pfad hängt am jeweils vorhandenen Port des Service.
| Service | Metrik-Adresse | Vom Host |
|---|---|---|
| RAG | http://127.0.0.1:7115/metrics | erreichbar |
| Zeitreihen-Insights-API | http://127.0.0.1:8970/metrics | erreichbar |
| Dokumentenverständnis · Vision · Digital Thread | /metrics von plantpulse-document-understanding-api:7120 · plantpulse-vision-api:7130 · plantpulse-digital-thread-api:7140 | nicht erreichbar — Scraping innerhalb desselben compose-Netzwerks |
curl -s -H "X-API-Key: <PI_INBOUND_API_KEY>" http://127.0.0.1:7115/metrics | grep '^http_requests_total' | head
/metrics erfordert einen KeyAnders als die Health-Pfade (/ping · /health) liegt er hinter dem Inbound-Key. Beim Scraping mit Prometheus übergeben Sie PI_INBOUND_API_KEY per X-API-Key-Header oder über die authorization:-Konfiguration (Bearer). Ein Aufruf ohne Key ergibt 401.
| Metrik | Bedeutung |
|---|---|
http_requests_total | Anzahl verarbeiteter Requests — je Methode · Pfadvorlage · Statusklasse (z. B. 2xx) |
http_request_duration_seconds | Histogramm der Request-Latenz — gleiche Labels |
http_requests_in_flight | Anzahl aktuell in Bearbeitung befindlicher Requests |
app_build_info | Servicename · Version · Release (Label release, z. B. 2026.10). Wert ist stets 1 |
Das Pfad-Label ist nicht der tatsächliche Pfad, sondern eine Pfadvorlage; Requests, die auf keine Route passen, werden zu einem einzigen <unmatched> zusammengefasst — so entsteht nicht pro ID-haltigem Pfad eine eigene Zeitreihe. Standardmetriken zu Prozess · GC werden ebenfalls ausgegeben.
Einen Request im Log nachverfolgen — X-Request-ID
Dieselben fünf Services vergeben je Request eine ID, geben sie im Antwort-Header X-Request-ID zurück und führen sie in allen Logzeilen während der Verarbeitung als request_id mit. Sendet die aufrufende Seite ein X-Request-ID (1–128 Zeichen, Buchstaben · Ziffern · . _ -), wird dieser Wert unverändert übernommen. Um einen auf der Oberfläche angezeigten Fehler dem Log zuzuordnen, genügt dieser eine Wert.
docker compose logs plantpulse-rag-api 2>&1 | grep '<request_id 값>'
Wenn die Festplatte voll läuft
Logdateien müssen nicht manuell gelöscht werden — Container-Logs rotiert Docker. Den Platz belegen in der Regel Images und Volumes.
docker system df # 무엇이 얼마나 쓰고 있나
docker image prune -f # 태그 없는 옛 이미지 정리
docker volume prune nicht leichtfertig ausführenIn den Volumes liegen die beiden Neo4j-Instanzen · Qdrant · der LightRAG-Speicher · die installationsspezifisch trainierten Zeitreihenmodelle (pi-ttm-tuned-models) und die TLS-Zertifikate. Wird der Befehl ausgeführt, während Container gestoppt sind, gehen Wissensgraph, Vektorindex und die Vor-Ort trainierten Modelle verloren.
health.sh zeigt Host-Disk und Container-Ressourcen gemeinsam an — sehen Sie vor dem Aufräumen zuerst dort nach.
Siehe auch
- Servicebetrieb — Befehle zum Starten und Stoppen
- Service-Port-Map
- Installationsübersicht — die Aufgaben der fünfundzwanzig Container