Service Telemetry Operator and Telemetry Operator use both Prometheus as the storage backend for metrics. Prometheus specifies in their documentation the following

Prometheus values reliability. You can always view what statistics are available about your system, even under failure conditions. If you need 100% accuracy, such as for per-request billing, Prometheus is not a good choice as the collected data will likely not be detailed and complete enough. In such a case you would be best off using some other system to collect and analyze the data for billing, and Prometheus for the rest of your monitoring. 

See https://prometheus.io/docs/introduction/overview/#when-does-it-not-fit

We had some confusion before with users aiming to leverage STF or the Telemetry Operator for use cases that don't fit Prometheus limitations.

Hence, it would be nice to include in STF and Telemetry Operator guides some reference to this known limitation.

Expected behavior

• Have a section called "When STF is not a good fit" in https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html/service_telemetry_framework_1.5/assembly-introduction-to-stf_assembly#assembly-introduction-to-stf_assembly to include this information
• Have a section called "When Telemetry Operator is not a good fit" in https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/customizing_the_red_hat_openstack_services_on_openshift_deployment/rhoso-observability_custom_dataplane to include this information

Or, since Prometheus is provided by Cluster Observability Operator

• Have a section called "When COO is not a good fit" in https://docs.redhat.com/en/documentation/openshift_container_platform/4.16/html/cluster_observability_operator/cluster-observability-operator-overview#cluster-observability-operator-overview
• Have STF and Telemetry Operator guides to point to COO

Additional context

• This enhancement in the docs is a nice to have