c0ac25bfff
Readiness as no reasoning to be cluster scope because that is not how the k8s networking works for pods, all the pods to a deployment are not sharing the network in a singleton. Instead they are run as local scopes to themselves, with readiness failures the pod is potentially taken out of the network to be resolvable - this affects the distributed setup in myriad of different ways. Instead readiness should behave like liveness with local scope alone, and should be a dummy implementation. This PR all the startup times and overal k8s startup time dramatically improves. Added another handler called as `/minio/health/cluster` to understand the cluster scope health. |
||
|---|---|---|
| .. | ||
| healthcheck | ||
| prometheus | ||
| README.md | ||
MinIO Monitoring Guide
MinIO server exposes monitoring data over endpoints. Monitoring tools can pick the data from these endpoints. This document lists the monitoring endpoints and relevant documentation.
Healthcheck Probe
MinIO server has two healthcheck related un-authenticated endpoints, a liveness probe to indicate if server is working fine and a readiness probe to indicate if server is not accepting connections due to heavy load.
- Liveness probe available at
/minio/health/live - Readiness probe available at
/minio/health/ready
Read more on how to use these endpoints in MinIO healthcheck guide.
Prometheus Probe
MinIO server exposes Prometheus compatible data on a single endpoint. By default, the endpoint is authenticated.
- Prometheus data available at
/minio/prometheus/metrics
To use this endpoint, setup Prometheus to scrape data from this endpoint. Read more on how to configure and use Prometheus to monitor MinIO server in How to monitor MinIO server with Prometheus.