Event Management - Alert maintenance calculation explained. - Support and Troubleshooting

Event Management - Alert maintenance calculation explained. Summary .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Table of Contents 1. Introduction 2. What is Alert Maintenance Calculation? 3. How does it work OOTB? 4. Custom Rules 5. Relationship Logic 6. Alert Maintenance Logic for Grouped Alerts. 1. Introduction This article aims to help TSEs understand Maintenance Calculation functionality and its troubleshooting. 2. What is Alert Maintenance Calculation? Usually, events/alerts are generated whenever the monitoring tools observe abnormalities with respect to the CI behavior. However, sometimes the abnormalities are caused because of planned activities at the CI level thus to avoid incident creation or any action on such known use cases, the system moves the alerts into maintenance mode. 3. How does it work OOTB? OOTB, we have an official document that explains How alerts work with CIs in maintenance however this KB explains some detailed use cases and concepts that will help to clarify more information related to working on alert maintenance calculation. We provide 2 default rules that take care of CI status and CI mapped with an active change use case The scheduled job responsible for the calculation is " Event Management - Maintenance Calculator ". This job is executed every 1 minute and will apply the rules created in the " em_maintenance_rule " table against the alerts. The CIs that match the criteria/rule are populated in the Impact Maintenance CIs [ em_impact_maint_ci ] table. One important rule to highlight here is that the CI binding to alert should be done using the OOTB mechanism, if the binding is performed using some custom BR or using a custom scheduled job then the maintenance calculation feature may not work as expected. 4. Custom Rules If the OOTB-defined rules are not satisfying the business use case then the end-user is allowed to create maintenance rules as per their business requirement, however, this falls under customization thus the end user needs to work on the logic part of the rules. The custom rules, if not defined properly may end up causing performance issues. 5. Relationship Logic OOTB, the code runs the maintenance rules and gets all the CIs that should be in maintenance. If the " Flag CIs that run on this host " field is set to true, we will look for applications running on maintenance CI hosts to add them to maintenance. The search for the relevant applications will be done in the CI Relationships ("cmdb_rel_ci") table. We are looking for Type " Runs on::Runs ", which is typically between a CI that represents a software application, to the hosting hardware/VM. 6. Alert Maintenance Logic for Grouped Alerts. Use Case- When the parent alert is closed with maintenance true, after closure if the CI comes out of maintenance, the parent alert still remains in maintenance mode. Explanation: The above behavior you detailed and witnessed is the expected behavior, by design. This is because, the state of the group - the parent and its children, is Closed. Since the group is closed, we intentionally don't update the parent alert, therefore you will not see *any* change in a closed parent alert, not only maintenance-related changes. The behavior described before will apply to all virtual alerts, i.e. - Automated, CMDB, Text-based, Patterns, and Tag Cluster (coming in Vancouver). The group's parent for Virtual Alerts is only a container for its children, so it's not a real alert, and since it's closed it means the group is closed - there's no issue and changes are irrelevant, so we don't need to waste resources on keeping it up to date with its children. As a container, it gets its data from the oldest child alert with the highest severity in its group, before it closed. For the other type of parent alerts - rules-based, Log Analytics, and Component-based, maintenance changes and other changes will apply because those parent alerts are real alerts, not virtual alerts.