Best practice approach to managing sysevent volumes..

[Eugene Severi]

Hi all

Keen to hear about any best practice approaches out there when it comes to managing sysevent volumes.

When there are too many events being processed typically caused by a rouge source generating and queuing too many events, this can seriously compromise and even cripple, the performance of the entire platform.

It would be great to be aware of typical processing trends, in turn knowing what is normal, so we can see volumes creep up before degradation becomes an issue.

Thinking of using API, query the sysevent table for a pending event count (group by queuename or something) and ingest into an external monitoring system. But I'm hoping there is something available which is a bit more native, seeing it's such an important topic.

It would be great also if there is data showing average processing times or event per/min rates etc.

Has anyone tackled this?

Thanks

Eugene

[Community Alums]

HI @Eugene ,

Go through this Product Doc : Event collection to the instance using web service API

Mark my answer correct & Helpful, if Applicable.

Thanks,

Sandeep

[Marcin Mierzick]

Hi Eugene!

To insert records in the event [em_event] table with a single call, use this web service API:

https://<instancename>.service-now.com/api/global/em/jsonv2

Do not add additional fields to an event by adding a custom field to the event table [em_event]. However, additional fields should be included in the Additional information [additional_info] field of the event. 

Valuable data contained in Additional information fields of events can be useful, for example, for reporting. Alert fields are automatically populated from fields that have the same name in the event. This behavior holds true for Additional information event fields and for Additional information fields that Event Rule adds. Therefore, to populate a custom alert field with the value in Additional information fields, use the custom field name in the Additional information field. You can also use Event Rules for this purpose. Values in the Additional information field of an Event that are not in JSON key/value format are normalized to JSON format when the event is processed.

You can check for more here (Event collection to the instance using web service API)

For checking average time see this topic: Chat average wait time calculation

Regards,

Marcin

[Eugene Severi]

Hi Marcin

Thanks for this feedback.. while this looks very useful when using ITOM, the sysevent table I refer to is the internal table in servicenow which manages the system events which queue while awaiting processing.

When the queue is backed up, the all activities i.e. email sending, json processing etc on the system can be delayed while the backlog is being processed.

Looking for a way to track the sysevent volumes being processed to know when numbers are climbing and an intervention may be required.

Aside from watching the table, grouped by queue I haven't seen a better way to manage this.

https://<instancename>.service-now.com/nav_to.do?uri=%2Fsysevent_list.do%3Fsysparm_query%3DGROUPBYqueue

Cheers

Eugene