System diagnostics
Check the deployed version, the connection state of dependent components and configuration hygiene verdicts on one screen
Required permission: Global admin
System diagnostics shows the build information of the running deployment and the dependent components it is actually connected to. Open it first right after installation, right after an upgrade, and whenever something looks wrong. Passwords, access keys and tokens are not shown, and addresses are shown only up to scheme://host:port.
The screen has four parts.
| Part | Contents |
|---|---|
| Overall verdict (총평) | Healthy (정상) / Needs attention (주의 필요) / Down (장애), version, time of the last check and how long it took |
| Deployment info (배포 정보) | Commit and build time of the frontend and the backend — check that the deployment really changed |
| Dependent components (의존 컴포넌트) | Reachability and extra details of PostgreSQL, object storage (per bucket), Prometheus, Alertmanager, Kubernetes, MLflow tracking, the container registry, the pip and apt package proxies, the training runner, inference serving, the build watcher and the edge fleet sweep. Cards in a warning or failed state carry a hint line naming the environment variables to fix. Two per-tenant cards (tenant namespaces, MLflow workspaces) are here too |
| Configuration hygiene (설정 위생) | Verdicts on settings that cause problems in production. Only those needing action appear as cards; passed ones appear only as a count |
Run a check
- Open the screen. Each time it opens, it connects to every dependent service once.
- To check again, press Check again (다시 점검) at the top right. There is no automatic refresh (the check is a heavy call).
- Scroll down and review Configuration hygiene. Each card states what is wrong and which environment variable to fix.
System diagnostics — configuration hygiene
The two per-tenant cards
These two cards check each active tenant rather than shared infrastructure. A card is healthy when every tenant has the resource, down when none do, and a warning when some are missing. Expand a card to see the result per tenant.
| Card | What it checks | What breaks without it | How to fix |
|---|---|---|---|
| Tenant namespaces (테넌트 네임스페이스) | The cluster has an Active tenant-<code> namespace | Training and serving submissions for that tenant are rejected. The Kubernetes card only looks at nodes, so it stays green | kubectl create namespace tenant-<code>. It is created when the tenant is created and when a runtime is published, but is missing if you rebuilt the cluster or deleted it by hand. If it says "deleting", wait for the tenant deletion to finish |
| MLflow workspaces (MLflow 워크스페이스) | Each tenant has its MLflow workspace | Training runs to the end, but metric logging and model registration fail with 404 | Restart the app; startup recreates every tenant's workspace. Submitting a training run also creates that tenant's workspace. geo-mlops-admin db reset recreates the workspaces at the end, and prints mlflow workspace provisioning skipped if that step fails |
On a production server, also clean up the following.
- If you run behind HTTPS,
GEO_MLOPS_AUTH_COOKIE_SECURE=true - Turn off seeding of the demo role accounts by emptying
GEO_MLOPS_RBAC_BOOTSTRAP_ROLE_PASSWORD(WARNING while it keeps the default) - Turn off the development mock DataOps server —
GEO_MLOPS_MOCK_DATAOPS_ENABLED=false - Shared secret for the Alertmanager webhook —
GEO_MLOPS_ALERTMANAGER_WEBHOOK_TOKEN - For CORS, put the real origins in
GEO_MLOPS_CORS_ALLOW_ORIGINSinstead of a wildcard