example, RAID6 can protect against two drive failure whereas in MinIO erasure code you can lose as many as half of drives and still the data remains safe. Further, MinIO's erasure code is at the object level and can heal one object at a time. For RAID, healing can be done only at the volume level which translates into high downtime. As MinIO encodes each object individually, it can heal objects incrementally. Storage servers once deployed should not require drive replacement or healing for the lifetime...

contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, gender identity and expression, level of experience,
nationality, personal appearance, race, religion, or sexual identity and
orientation.

## Our Standards

Examples of behavior that contributes to creating a positive environment
include:

## Prerequisites

- It is assumed you have users created and configured with relevant access policies, to start with
  use basic "readwrite" canned policy to test all the operations before you finalize on what level
  of restrictions are needed for a user.

- No "admin:*" operations are needed for FTP/SFTP access to the bucket(s) and object(s), so you may
  skip them for restrictions.

## Usage

Node level Replication metrics can be viewed in the Grafana dashboard using [json file here](https://raw.githubusercontent.com/minio/minio/master/docs/metrics/prometheus/grafana/replication/minio-replication-node.json)

![Grafana](https://raw.githubusercontent.com/minio/minio/master/docs/metrics/prometheus/grafana/replication/grafana-replication-node.png)

## How to enable Fan-Out Uploads ?

Fan-Out uploads are automatically enabled if `x-minio-fanout-list` form-field is provided with the PostUpload API, to keep things simple higher level APIs are provided in our SDKs for example in `minio-go` SDK:

```
PutObjectFanOut(ctx context.Context, bucket string, fanOutContent io.Reader, fanOutReq minio.PutObjectFanOutRequest) ([]minio.PutObjectFanOutResponse, error)

MinIO server configuration file allows users to provide topology that allows for heterogeneous hostnames, allowing MinIO to deployed in pre-existing environments without any further OS level configurations.

### Usage

```
minio server --config config.yaml
```

## Request, System and Cluster Metrics

At a high level metrics are grouped into three categories, listed in the following sub-sections. The path in each of the tables is relative to the top-level endpoint.

### Request metrics 

These are metrics about requests served by the (current) node.

# Cluster Metrics

MinIO collects the following metrics at the cluster level.
Metrics may include one or more labels, such as the server that calculated that metric.

These metrics can be obtained from any MinIO server once per collection by using the following URL:

```shell
https://HOSTNAME:PORT/minio/v2/metrics/cluster
```

Replace ``HOSTNAME:PORT`` with the hostname of your MinIO deployment.

```sh
podman run -it \
    --name opa \
    --publish 8181:8181 \
    docker.io/openpolicyagent/opa:0.40.0-rootless \
       run --server \
           --log-format=json-pretty \
           --log-level=debug \
           --set=decision_logs.console=true
```

### 2. Create a sample OPA Policy

In another terminal, create a policy that allows root user all access and for all other users denies `PutObject`:

```sh

be same across the federated deployment, i.e. all the MinIO instances within a federated deployment should use same
etcd back-end.

#### MINIO_DOMAIN

This is the top level domain name used for the federated setup. This domain name should ideally resolve to a load-balancer
running in front of all the federated MinIO instances. The domain name is used to create sub domain entries to etcd. For