Uploaded image for project: 'Observability and Data Analysis Program'
  1. Observability and Data Analysis Program
  2. OBSDA-213

Clarify scalability expectations and support

XMLWordPrintable

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

      Proposed title of this feature request

      Clarify scalability expectations and support

      What is the nature and description of the request?

      We allow customers to create several kinds of resources (e.g. PrometheusRules in user namespaces). We have seen customers in that create such a large number of resources, that the monitoring stack hits scalability limits. For example when our ruler deployment has to evaluate several thousand alerting rules with expensive expressions (say aggregating the last 6 hours of samples), it simply takes too long.
      We will of course do our best to support customers by suggesting strategies to reduce this load or other work-arounds. However some customers are unable (or rarely unwilling) to consider alternate approaches.
      It would be great if we could clarify that our system will allow configurations, that create significant pressure on individual components. Unfortunately we won't be able to resolve every customers need in that respect.

      We should also add and improve our alerts regarding the functioning of our stack. Customer should not be able to find scalability limits without getting an alert on the way.

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

      A clearer understanding of what they can expect from our stack.

      List any affected packages or components.

      Alerting rules, Documentation

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

              Created:
              Updated: