The tree still carried a complete second publishing pipeline inherited from upstream that pgsty has never operated, plus MinIO-branded artwork the fork has no right to redistribute. None of it is a pgsty release artifact, so the history-is-immutable rule does not protect it: nothing here was ever published under this repository's name, and git history plus the pre-cutover tag keep the provenance. Removed, by category: - charts.min.io machinery: CNAME (charts.min.io), _config.yml, index.yaml, helm-reindex.sh and 90 helm-releases/minio-*.tgz. GitHub Pages is not enabled on this repository, so this was dormant - but enabling Pages for any reason would have stood up a convincing impostor of the official MinIO chart repository from our own domain. - Dockerfiles that consume upstream binaries: Dockerfile, Dockerfile.cicd, Dockerfile.hotfix, Dockerfile.release, Dockerfile.release.old_cpu, Dockerfile.scratch and docker-buildx.sh. These fetch or expect a MinIO-built binary; a Silo image must only ever contain an artifact this repository built from this commit. Dockerfile.goreleaser, the one the release workflow actually uses, stays. - buildscripts/upgrade-tests/ (compose.yml, minio.env, nginx.conf), which pinned minio/minio images through a MINIO_VERSION compose variable. The upgrade test is rebuilt on image digests in a later commit. - docs/hotfixes.md, describing an upstream hotfix distribution channel that does not exist for this fork. - MinIO trademark artwork: .github/logo.svg (a recoloured MinIO wordmark), the docs/screenshots/ set, the Grafana dashboard screenshots and docs/federation/lookup/bucket-lookup.png. The dashboards themselves are kept and rebranded separately; only the images carrying MinIO chrome go. Deliberately not touched: published releases, tags, image digests and package signatures remain byte-identical. This commit only removes paths that were never part of a pgsty release. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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 responding, cluster probe to check if server can be taken down for maintenance.
- Liveness probe available at
/minio/health/live - Cluster probe available at
/minio/health/cluster
Read more on how to use these endpoints in MinIO healthcheck guide.
Prometheus Probe
MinIO allows reading metrics for the entire cluster from any single node. This allows for metrics collection for a MinIO instance across all servers. Thus, metrics collection for instances behind a load balancer can be done without any knowledge of the individual node addresses. The cluster wide metrics can be read at
<Address for MinIO Service>/minio/v2/metrics/cluster.
The additional node specific metrics which include additional go metrics or process metrics are exposed at
<Address for MinIO Node>/minio/v2/metrics/node.
The additional bucket specific metrics which include additional go metrics or process metrics are exposed at
<Address for MinIO Node>/minio/v2/metrics/bucket.
The additional resource specific metrics which include additional go metrics or process metrics are exposed at
<Address for MinIO Node>/minio/v2/metrics/resource.
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.
Deprecated metrics monitoring
- Prometheus' data available at
/minio/prometheus/metricsis deprecated