Operations
Health checks
The liveness and readiness routes each Telark service exposes, and how to check the whole install.
Check the whole install
kubectl get pods -n telark
helm test telark -n telarkhelm test starts a pod that calls the readiness route of every service that has one, then checks that the Kubernetes API serves the telark.io group. It should end with Phase: Succeeded.
Probe routes
Every API service serves both routes on its http port (8080). They need no authentication.
| Probe | Route |
|---|---|
| Liveness | GET /api/v1/status/live |
| Readiness | GET /api/v1/status/ready |
What "ready" means per service:
| Service | Ready when |
|---|---|
exporter | Redis is reachable and its application cache has synced |
discovery | Redis is reachable. Startup, exporter and Kubernetes problems show as degraded, not unready |
auth | The process is up |
notifier | Connected to NATS |
analyzer | Redis answers a ping |
ui | No probes. The dashboard is static files behind nginx and serves only GET /healthz, so the chart sets services.ui.includeHealthCheck: false |
To call a route yourself:
kubectl port-forward -n telark svc/telark-discovery-service 8080:8080
curl -s localhost:8080/api/v1/status/readyProbe timings
All services share one block, app.shared.healthCheck:
| Setting | Liveness | Readiness |
|---|---|---|
initialDelaySeconds | 15 | 5 |
periodSeconds | 15 | 5 |
timeoutSeconds | 15 | 15 |
failureThreshold | 3 | 3 |
The defaults allow for slow cold starts. Lower them only after you have measured pod start times in your cluster.