• Icon: Feature Feature
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • PM Monitoring
    • False
    • None
    • False
    • Not Selected
    • 0

      Proposed title of this feature request

      Implement predefined scrape profiles in CMO.

      What is the nature and description of the request?

      Over the 4.10 and 4.11 development cycles we have explored and evaluated the notion of scrape profiles. A scrape profile comprises a distinct set of service monitors that can be identified by a common label or annotation. All ServiceMonitors that belong to a scrape profile will share a trait that change the overall behavior of the in-cluster stack. Users can configure one scrape profile in the configuration ConfigMap.
      For example a minimal scrape profile would target ServiceMonitors, that ignore all but the absolutely required metrics. Required metrics are all that are needed to support the dependents of the monitoring stack (prometheus-adapter, console, default alerts). The other end of the spectrum would be a "collect everything" profile where not metric is dropped whatsoever in order to give maximum insight and maybe improve debugging capabilities.
      We will define which profiles CMO will consider and implement these profiles for the ServiceMonitors that we own. Owners of other operators will have to implement these profiles themselves. Until they do, the existing ServiceMonitors will be scraped.

      Why does the customer need this? (List the business requirements)

      This feature will add flexibility to our stack and enable a wider range of customer use cases. For large clusters this should improve scalability of our stack.

      List any affected packages or components.

      CMO and optionally other operators, that are scraped by the in-cluster stack.

            rh-ee-rfloren Roger Florén
            jfajersk@redhat.com Jan Fajerski
            0 Vote for this issue
            8 Start watching this issue