Allow MinIO Operator Monitoring Integration Without Prometheus Instance Requirement

[XuhuiSun95]

Is your feature request related to a problem? Please describe.
Yes. The current implementation of the MinIO Operator requires the presence of a Prometheus or Prometheus Agent instance in a specific namespace and performs validations around it. This creates limitations in environments that use alternative telemetry stacks.

For example, in deployments using OpenTelemetry Collector with OpenTelemetry TargetAllocator—where only the Prometheus CRDs are installed—we rely on OpenTelemetry to scrape metrics from ServiceMonitor and PodMonitor resources and export to a LGTM stack (Loki, Grafana, Tempo, Mimir). This setup avoids deploying a Prometheus instance entirely.

However, the operator fails or blocks integration due to the absence of an actual Prometheus deployment, even though the required CRDs and metric pipeline are functionally present. As the community moves toward decoupling Prometheus CRD usage from a hard dependency on Prometheus itself, this constraint becomes increasingly problematic.

Describe the solution you'd like
Relax or remove the validation that enforces the existence of a Prometheus or Prometheus Agent instance.
Instead, allow the operator to proceed with the creation of ServiceMonitor, PodMonitor, and PrometheusRule resources directly, regardless of whether a Prometheus instance is detected.

This enables compatibility with alternative scraping and telemetry solutions like OpenTelemetry Collector + TargetAllocator, while maintaining adherence to the Prometheus CRD structure that many tools are designed around.

Describe alternatives you've considered

• Deploying a dummy Prometheus Agent just to satisfy the operator validation (wasteful and unnecessary).

• Avoiding the operator entirely and managing deployments manually (loses the benefit of operator automation).

Additional context
This approach aligns with modern observability patterns, where teams adopt Prometheus CRDs for compatibility, but route telemetry through flexible backends like OTEL and LGTM.

Removing this dependency would enhance interoperability and lower the barrier for observability integration in cloud-native deployments.

[ramondeklein]

We won't be implementing alternatives for Prometheus for MinIO operator.