Monitoring
Monitoring
Monitoring der Plattform erfolgt über Health-Check-Endpunkte, Kubernetes-Bordmittel und das Customer Portal Dashboard.
Health-Check-Endpunkte¶
| Service | Endpunkt | Prüft |
|---|---|---|
| Customer API | GET /health |
Service-Status |
| Customer API | GET /ready |
PostgreSQL-Verbindung |
| RAG API | GET /health |
Service-Status, Qdrant-URL und Collection-Name |
| Connector Service | GET /health |
Service-Status |
| OS Manager | GET /health |
Service-Status + Node-Info |
Kubernetes-Bordmittel¶
# Pod-Status aller Services
kubectl get pods -n inovetra-platform
# Ressourcenverbrauch
kubectl top pods -n inovetra-platform
# Logs eines Services (z.B. Customer API)
kubectl logs -f deployment/inovetra-customer-api -n inovetra-platform
# Events (Fehler, Warnungen)
kubectl get events -n inovetra-platform --sort-by='.lastTimestamp' | tail -20
Customer Portal Dashboard¶
- Die Monitoring-Seite zeigt: Pod-Status, Ressourcenverbrauch, Speicherplatz
- Erreichbar über: Portal → Monitoring
Empfohlene Prüfungen¶
| Prüfung | Intervall | Methode |
|---|---|---|
| Pod-Status | Alle 5 Minuten | kubectl get pods oder Portal |
| Disk-Auslastung | Täglich | df -h auf der VM |
| PVC-Auslastung | Wöchentlich | kubectl get pvc -n inovetra-platform |
| Zertifikats-Ablauf | Monatlich | kubectl get certificate -n inovetra-platform |
| Log-Analyse | Bei Bedarf | kubectl logs |
Externer Uptime-Monitor
Für automatisiertes Monitoring kann ein externer Uptime-Monitor auf https://<domain>/api/customer/health konfiguriert werden.
containerd statt Docker
K3s nutzt containerd, nicht Docker. Container-Operationen auf dem Host über k3s crictl durchführen, nicht über docker.