Why isn't it recommended to deactivate the following property? (evt_mgmt.alert_auto_close_interval) It's only resolving incidents too early. We would like to deactivate this function or to set it the maximum amount of hours in the property.

[Christine Kerwi]

We use Event Management together with PRTG Monitoring. PRTG sends Pings/Events to ServiceNow, which create alerts on servicenow. These alerts are closed if they receive a 'OK' Event from PRTG. But there is a ootb property which closes alerts after a specific time. We've already set it up to 672 hours but it would be perfect if we could just deactivate the property. In a servicenow documentation it says, that this is not recommended, because of performance issues that could be related. Why should it lead to performance issues? Is there a maximum of hours which could be set as the properties value instead of deactivating the property and feature? Has anybody further informations of or even experiences with that feature?

[Tony Branton]

Hi Christine,

You can set this property to zero to disable the function however you then run the risk of accruing a lot of open alert records in the em_alert table.  This can have a big performance impact if the number of alert records gets into the tens of thousands.  Best practice is to set the property to a meaningful/realistic value, and to also archive/delete closed alerts once they're no longer required.

Hope this helps. 

[Christine Kerwi]

Hello Tony,

thank you for your respond.

The mentioned property is just closing the alerts. It is not deleting them. 

So if I understand you correctly it would be necessary to archive and delete the alerts.

But then I would see the Archiving and Deletion as the correct way to regulate the number of entries on the alert table. Wouldn't you say so? 

And what I can't really understand is, why the event table can have hundred of thousands of events but the alert table can't. Because this is our situation at the moment. Is it because of its references to other tables(event or incident) or do you know any difference between the tables?

What would be Best Practise for both tables regarding archiving and deletion of records?

Thank you in advance.

Best Regards 

Christine

[Christine Kerwi]

Hello Tony,

thank you for your respond.

The mentioned property is just closing the alerts. It is not deleting them. 

So if I understand you correctly it would be necessary to archive and delete the alerts.

But then I would see the Archiving and Deletion as the correct way to regulate the number of entries on the alert table. Wouldn't you say so? 

And what I can't really understand is, why the event table can have hundred of thousands of events but the alert table can't. Because this is our situation at the moment. Is it because of its references to other tables(event or incident) or do you know any difference between the tables?

What would be Best Practise for both tables regarding archiving and deletion of records?

Thank you in advance.

Best Regards 

Christine

[Tony Branton]

The em_event table has an OOB table rotation policy that drops records after 7 days. This ensures that the table doesn't grow too large and is best left unmodified.

There's no OOB archive rule or deletion process for records in the em_alert table.  If you have no business need for retaining closed alerts for a long period, you can archive them which will move the records from the em_alert table to a non-indexed table.  

Setting up an archive rule (navigate to System Archving > Archive Rule) is straightforward and you can optionally specify how long archived records should be retained before they're purged automatically. For example, you could specify an archive rule that archives closed alert records older than 180 days and purge them 365 days after they've been archived. It's just a matter of setting up a rule that meets your business needs.

System archiving is a free feature of the Now platform and is a great way to manage data growth.