Uploaded image for project: 'Red Hat OpenStack Services on OpenShift'
  1. Red Hat OpenStack Services on OpenShift
  2. OSPRH-3131

Provide OpenStack service workload metrics

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Minor Minor
    • rhos-19.0.0
    • None
    • None
    • None
    • OpenStack service metrics
    • False
    • Hide

      None

      Show
      None
    • False
    • OBSDA-613Add OpenTelemetry Collection into OpenStack
    • Committed
    • Proposed
    • To Do
    • Committed
    • Proposed
    • 17% To Do, 17% In Progress, 67% Done
    • API, Deploy
    • Red Hat OpenStack Services on OpenShift

      Epic Overview

      Identify the available OpenStack services (glance, neutron, nova, designate, ironic, etc) which provide an exporter for metrics that allows scraping by Prometheus. Telemetry provided is for the service workload itself (not the Operator orchestrating the service) and is not intended to cover OpenStack-tagged metadata. Information provided is about the operational measurement of information flow managed by the service. For example, the RabbitMQ service may provide an exporter that allows for data such as number of topics created or destroyed, number of messages delivered or dropped etc.

      Goals

      As an OpenStack administrator I can gain better understanding about the processing each of my OpenStack services is managing. This allows definition of upper and lower bounds for alerting, along with historical tracking of data processed by the services to allow for predictive growth tracking.

      Requirements

      A list of specific needs or objectives that a Epic must deliver to satisfy the Feature.. Some requirements will be flagged as MVP. If an MVP gets shifted, the epic shifts.  If a non MVP requirement slips, it does not shift the epic.

      requirement Notes is Mvp?
      Identification of services which already have ability to provide metrics via exporters    
      Investigation of available data and how it applies to a standard data model    
      Guide DFGs on how to expose exporters with a standard set of labels to allow discovery of endpoints through ServiceMonitors (Observability Operator)    
      Guide DFGs on how to implement a standard API interface (CRD) for service Operators deploying observability    
      Work with OpenStack Operator team to enable observability from the umbrella Operator for service Operators in a standard way    

      (Optional) Use Cases

      < How will the user interact with this epic? >

      < Which users will use this and when will they use it? >

      < Is this epic used as part of current user interface? >

      Out of Scope

      • monitoring of the Operators themselves
      • development of new service exporters
      • sole ownership of exporter deployment and implementation in the service Operators

      Background, and strategic fit

      < What does the person writing code, testing, documenting need to know? >

      Assumptions

      < Are there assumptions being made regarding prerequisites and dependencies?>

      < Are there assumptions about hardware, software or people resources?>

      Customer Considerations

      < Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

      < Are there upgrade considerations that customers need to account for or that the feature should address on behalf of the customer?>

      Documentation Considerations

      < What educational or reference material (docs) is required to support this epic? For users/admins? Other functions (security officers, etc)? >

      < What does success look like?>

      < Does this epic have doc impact?  Possible values are: New Content, Updates to existing content,  Release Note, or No Doc Impact>

      < If unsure and no Technical Writer is available, please contact Content Strategy. If yes, complete the following.>

      • <What concepts do customers need to understand to be successful in [action]?>
      • <How do we expect customers will use the epic? For what purpose(s)?>
      • <What reference material might a customer want/need to complete [action]?>
      • <Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available. >
      • <What is the doc impact (New Content, Updates to existing content, or Release Note)?>

      Interoperability Considerations

      < Which other products and versions in our portfolio does this feature impact?>

      < What interoperability test scenarios should be factored by the layered product(s)?>

      Questions

      Question Outcome
         

            rhn-engineering-jlarriba Juan Larriba
            lmadsen@redhat.com Leif Madsen
            rhos-dfg-cloudops
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: