New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
monitoring: Create prometheus rules with helm chart #9837
Conversation
@@ -0,0 +1,890 @@ | |||
groups: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This yaml is directly copied from the ceph source repo. This way, we (hopefully) don't have to maintain any customizations to what is picked up from the ceph repo.
lgtm! |
f68bfb3
to
9469a77
Compare
9469a77
to
f285bdf
Compare
f285bdf
to
b14a7c0
Compare
This pull request has merge conflicts that must be resolved before it can be merged. @travisn please rebase it. https://rook.io/docs/rook/latest/development-flow.html#updating-your-fork |
The prometheus rules had been previously created if the cephcluster CR setting monitoring.enabled was set to true. The rules were not customizable and therefore not flexible enough. Now the rules are installed by the helm chart. To customize the rules, a post-processor can be applied to the helm chart. Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
Pick up the latest ceph prometheus rules from the ceph repo found at https://github.com/ceph/ceph/blob/master/monitoring/ceph-mixin/prometheus_alerts.yml. The updates include many new rules for monitoring of ceph. Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
b14a7c0
to
8dd4b77
Compare
Rook has stopped creating the prometheus rules with the cephcluster monitoring.enabled setting. Now the rules must be created separately from the cluster CR as described in the rook PR rook/rook#9837. The rules are fully owned downstream by the ocs operator now since upstream they are only installed by the helm chart. This also gives full flexibility downstream to update the rules only when QE determines we are ready for testing all the new rules. Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
Rook has stopped creating the prometheus rules with the cephcluster monitoring.enabled setting. Now the rules must be created separately from the cluster CR as described in the rook PR rook/rook#9837. The rules are fully owned downstream by the ocs operator now since upstream they are only installed by the helm chart. This also gives full flexibility downstream to update the rules only when QE determines we are ready for testing all the new rules. Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
Rook has stopped creating the prometheus rules with the cephcluster monitoring.enabled setting. Now the rules must be created separately from the cluster CR as described in the rook PR rook/rook#9837. The rules are fully owned downstream by the ocs operator now since upstream they are only installed by the helm chart. This also gives full flexibility downstream to update the rules only when QE determines we are ready for testing all the new rules. Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
Description of your changes:
The prometheus rules had been previously created if the cephcluster CR setting monitoring.enabled was set to true. The rules were not customizable and therefore not flexible enough. Now the rules are installed by the helm chart. To customize the rules, a post-processor can be applied to the helm chart.
This is proposed to replace the approach in #9503.
The rules can then be customized with a helm post-processor using tools such as kustomize. For example,
There are many possible configurations for kustomize, but here is one example for the yamls would need to exist in the current directory:
kustimization.yaml
severity.yaml: In this example, update the labels and the "for" statement in the first rule
Which issue is resolved by this Pull Request:
Resolves #9082, #9005
Checklist:
skip-ci
on the PR.