Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-2459

Document how to enable instance level alerts

    XMLWordPrintable

Details

    • 5
    • False
    • None
    • False
    • Hide
      Users can now enable workload monitoring for specific argo-cd instances by setting `.spec.monitoring.enabled` to "true". This would result in the operator creating a PrometheusRule containing alert rules for each argo-cd component that would trigger the firing of an alert when that component's replica count has drifted from the desired state for a certain amount of time. Users are free to modify the rules as they wish and will not have their changes overwritten by the operator
      Show
      Users can now enable workload monitoring for specific argo-cd instances by setting `.spec.monitoring.enabled` to "true". This would result in the operator creating a PrometheusRule containing alert rules for each argo-cd component that would trigger the firing of an alert when that component's replica count has drifted from the desired state for a certain amount of time. Users are free to modify the rules as they wish and will not have their changes overwritten by the operator
    • GITOPS Sprint 230

    Description

      Story (Required)

      As a user of OpenShift GitOps I would like to have access to updated documentation that explains how to configure/enable alerts for each workload and how I can expect to receive these alerts 

      Background (Required)

      Documentation needs to be updated to reflect user instructions for enabling alerts

      Out of scope

      Documentation in OpenShift docs

      Approach (Required)

      Include documentation changes to upstream argocd-operator docs and GitOps usage guide 

      Dependencies

      none

      Acceptance Criteria (Mandatory)

      Documentation is updated with clear and correct instructions for how to enable monitoring and how to expect to receive alerts 

      INVEST Checklist

      Dependencies identified

      Blockers noted and expected delivery timelines set

      Design is implementable

      Acceptance criteria agreed upon

      Story estimated

      Legend

      Unknown

      Verified

      Unsatisfied

      Done Checklist

      • Code is completed, reviewed, documented and checked in
      • Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
      • Continuous Delivery pipeline(s) is able to proceed with new code included
      • Customer facing documentation, API docs etc. are produced/updated, reviewed and published
      • Acceptance criteria are met

      Attachments

        Activity

          People

            jrao@redhat.com Jaideep Rao
            jrao@redhat.com Jaideep Rao
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: