Add Alert Rule Classification Mapping enhancement #1917
Conversation
|
@simonpasquier @avlitman @machadovilaca Hi, |
sradco
force-pushed
the
add_alert_rule_classification_mapping_enhancement
branch
from
1bd174b to
8daffb4
Compare
|
/unassign @moadz |
|
@sradco: The specified target(s) for Use DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/test markdownlint |
sradco
force-pushed
the
add_alert_rule_classification_mapping_enhancement
branch
from
8daffb4 to
948ae4b
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
sradco
force-pushed
the
add_alert_rule_classification_mapping_enhancement
branch
from
948ae4b to
86158ff
Compare
sradco
force-pushed
the
add_alert_rule_classification_mapping_enhancement
branch
10 times, most recently
from
8303044 to
269ec99
Compare
Signed-off-by: Shirly Radco <sradco@redhat.com>
sradco
force-pushed
the
add_alert_rule_classification_mapping_enhancement
branch
from
269ec99 to
f828ba8
Compare
|
@sradco: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
| - **Special-cases first**: alert families that require per-alert-instance classification (for example, where the effective component depends on runtime alert labels) are evaluated before general rules. | ||
| - **General mappings next**: stable mappings for well-known platform and workload areas. | ||
| - **Fallback last**: when nothing matches, we apply the documented fallback behavior. | ||
| - Adding or updating heuristics is a code change in the monitoring plugin (see `monitoring-plugin-machadovilaca/pkg/alertcomponent/matcher.go`), and should remain aligned with `cluster-health-analyzer` to avoid drift between backend and UI behavior. |
There was a problem hiding this comment.
Would it make sense to extend the cluster-health-analyzer then? Health analyzer is deployed via COO as well so it seems a little bit redundant to have the same logic in the monitoring-plugin (which is also deployed via COO if I am not mistaken).
There was a problem hiding this comment.
actually is the plan to introduce it in monitoring-plugin or monitoring-console-plugin? I am always a little bit confused by these two, but one can be deployed via COO whereas the second is default in OpenShift AFAIK.
| ## Proposal | ||
|
|
||
| ### User Stories | ||
| - As a multi-cluster admin, I will be able to see which clusters require my attention drill down by impacted component and scope of impact to the specific related alerts. |
There was a problem hiding this comment.
But the components don't have any hierarchy right? I think hiearchical structure of the components (as proposed in the cluster/component health feature for the cluster-health-analyzer) might be more interesting.
3 participants
This enhancement describes the alert rules classification
mapping details, logic and motivation.
This enhancements is related to #1822