MinIO AIStor supports publishing bucket notification events to a AMQP 0-9-1 service endpoint such as RabbitMQ. Prerequisites AMQP 0-9-1 service endpoint. MinIO AIStor relies on the https://github.com/streadway/amqp project for AMQP connectivity. The project is primarily tested against RabbitMQ deployments, though other AMQP 0-9-1-compatible services may also work. This procedure assumes a RabbitMQ deployment using the 0-9-1 protocol as the service endpoint.

AIStor Server publishes cluster, node, bucket, and resource metrics using the Prometheus Data Model. The procedure on this page documents the following: Configuring a Prometheus service to scrape and display metrics from an AIStor Server deployment Configuring an alert rule on an MinIO AIStor metric to trigger an AlertManager action This tutorial uses metrics version 2. You can also use metrics version 3, which is recommened for new deployments. For more information about version 3, see Metrics and alerts.

MinIO AIStor allows you to temporarily remove nodes from active service for planned maintenance operations. Removing nodes allows administrators to gracefully take nodes offline without disrupting cluster operations, similar to the cordon functionality in Kubernetes. A cordoned node finishes in-flight operations and marks itself as unavailable for any other operation. Use this to do hardware maintenance on a node, complete operating system updates, or perform troubleshooting. MinIO AIStor cordoning on Kubernetes In Kubernetes environments, the MinIO AIStor cordoning function applies to the Pod running the associated workload. It does not affect any other Pods or services running on the Kubernetes worker, and acts to ensure the scheduler does not reschedule that Pod during ongoing maintenance operations. The following diagram illustrates the node state transitions during the maintenance workflow:

MinIO AIStor supports decommissioning and removing server pools from a deployment with two or more pools. To decommission, there must be at least one remaining pool with sufficient available space to receive the objects from the decommissioned pools. MinIO AIStor supports queueing multiple pools in a single decommission command. Each listed pool immediately enters a read-only status, but draining occurs one pool at a time. Decommissioning is designed for removing an older server pool whose hardware is no longer sufficient or performant compared to the pools in the deployment. MinIO AIStor automatically migrates data from the decommissioned pools to the remaining pools in the deployment based on the ratio of free space available in each pool.

AIStor Server publishes its server logs to the system console. These logs can include errors, information output, or other information useful during troubleshooting or debugging. Server logs do not emit for all operations and cannot support audit trail or similar compliance requirements. If you require such a trail, configure and use audit logging instead. You can read the server logs using any of the following methods: Run journalctl -u minio from any host machine. Run mc admin logs against the MinIO AIStor deployment. Record logs to disk New feature — opt-in only Disk-based log recording is a new feature that is disabled by default. Enable it only after thorough testing at scale with your application workload. MinIO is actively optimizing this feature in subsequent releases. MinIO AIStor can record API, error, and audit logs directly to disk as compressed JSON files. This complements webhook-based logging for compliance, forensics, and offline analysis. Logs are stored internally and managed automatically by MinIO AIStor.

This section documents best practices and tutorials for updating the MinIO AIStor server on Linux and Kubernetes infrastructure to a newer release. All MinIO AIStor software supports non-disruptive upgrades with zero downtime. In optimal environments, cluster-wide upgrades typically complete in under 500 milliseconds with large clusters (1000+ nodes) completing in less than 5 seconds. Applications using MinIO or S3 SDKs can rely on the built-in transparent retry to ensure continuous operations during the update procedure.

Description mc admin object info displays a summary of part and shard information about a specified object. The output includes information for each part or shard of the object, including: Part number Pool number Node Erasure set Drive Filename Size By default, the output uses a set of gridded blocks to indicate the parts of object. Colors indicate the status of the specific part.

The mc admin heal command scans for objects that are damaged or corrupted and heals those objects. mc admin heal is resource intensive and typically not required as a manual process, even after drive failures or corruption events. As a part of normal operations, MinIO AIStor: automatically heals objects damaged by silent bit rot corruption, drive failure, or other issues on each POST or GET operation. performs periodic background object healing using the scanner. aggressively heals objects after drive replacement. Refer to Object Healing for more details on how MinIO AIStor heals objects.

The mc admin accesskey sts-revoke command removes security token service (sts) credentials associated with an account. Revoke all STS tokens for an account, or specify the type(s) of STS tokens to revoke for an account. Syntax Example The following command removes all STS access tokens for account user1 from the myaistor deployment:

Creates a new policy on the target MinIO AIStor deployment. MinIO AIStor deployments include the following built-in policies by default: consoleAdmin readonly readwrite diagnostics writeonly Syntax Example Consider the following JSON policy document saved at a file called /tmp/listmybuckets.json: