This market problem is being reconstructed and will be replaced by other market problems.

Develop OpenStack Observability Enhancements & Unified User Experiences. Identify and track customer use cases for delivering OpenStack Monitoring and Logging capabilities.

High level requests that have been noted from customer base:

• solution must contain all Red Hat supported components
• solution must work in disconnected and proxy-based environments
• solution must work on supported OpenShift releases

Current solution for OpenStack is via Service Telemetry Framework which has gaps related to the high level requests.

Next generation target for helping to address these high level items is Service Telemetry Framework 2.0, which was presented to the Leadership Team via this slide deck: https://docs.google.com/presentation/d/1pu5Pjhk3RMVMZ_O49frMpqAjmvwojbHzzlWPT8wb2ko/edit?usp=sharing

Target is to align more functionality to using OpenShift as the monitoring framework that is extended via the installation of the Service Telemetry Operator (STO). Upon installation of the STO, systems internal to OpenShift should be used as much as possible, such as the existing dashboarding solutions, alerting solutions, and data store solutions.

Currently identified solutions (needs spiking, research, and collaboration with OpenShift observability teams):

• UI (dashboards) should be created so they show up in the new Observe panel in OpenShift (or the existing Monitoring panel using Grafana in the backend, migration to non-Grafana based UI components in OCP v4.11+)
• data storage for metrics should be aligned to Observability Operator (OBO) in order to avoid pollution of openshift-monitoring or user-workload monitoring data stores
• data storage for logging should be aligned to OpenShift Logging or Observability Operator managed Loki deployments
• data storage for events needs to be scoped, but likely align to Observability Operator managed Loki deployments (needs to be requested to the OBO team)

Next Gen STF deployment should be able to support both QDR (AMQP) based transport via the Smart Gateway for RHOSP 16.2 and 17.0 deployments along with new transport methods targeting RHOSP 18.0 with backports to 17.1. These new transport methods will be generally HTTPS based. All transports transiting the public network layer must be secured using certificates.