Event Management - How do I structure the layout of content in the alert description field? E.g. line feeds and carriage returns

[RichG]

Hi everyone

I'm using event management (Kingston) where I've created an event rule to transform and compose data received through the API into an alert.

I want the information in the description of the alert to be meaningful/helpful and laid out in a clear way.

So I've used the transform and compose tab to put several attributes into the description field of the alert. Meaningful.... tick.

The bit that I'm stuck on is how I but some basic structure in the description field such as line feeds or carriage returns so that those different attributes don't appear to the user as one big mass of words wrapped together? The info isn't helpful to the user if they can't read it.

Many thanks

[stevemacamway]

Rich - I'm not certain about Kingston, but in Jakarta I could not get it to add carriage returns. What you might try doing is adding in a '\n' (that is: backslash n) to see if that picks up. Again, it didn't work in Jakarta, but it may have changed in Kingston. 

Example: 

"Notes: Testing with carriage returns.\nType: threat\nUser ID:JohnDow"

might become:

--------------------------------------------

Notes: Testing with event_class field.

Type: threat

User ID:JohnDow

--------------------------------------------

We've moved to London now (direct from Jakarta), and the Description field is now multi-line so the CRs seem to work fine. 

 Steve

[RichG]

Thanks Steve.

I tried something similar, but I'll try it with the example you gave.

Another post suggested using:

Variable1 + '/n' + Variable2

...however it just showed the + '/n' + part exactly as entered...

I'll give it a go without the quotes and the plus signs. Thanks.

The other thing I was considering was whether somehow I could put the line feed into a variable as a mechanism to get it to work as a line feed. Not sure how exactly I'll try it yet, and it feels unnecessarily hacky... but it might result in the data mapping to the description field as follows:

Variable1 LineFeedVariable Variable2

In order to get the output looking like:

Variable1

Variable2

Thought it could be worth a try... though surprised there's not a better way of doing this via the gui.

(Wrote reply with the dollas and brackets originally but it didn't show properly in the post!)

[stevemacamway]

Yeah, I think they caught onto that since it is a multi-line field in London. 

[RichG · Accepted solution]

Hi Steve I've just managed to come back to this problem to spend some time on it and therefore missed your last post. Are you saying London fixes the problem and that they make it easier to structure the description? That's great if they have? In the meantime, I've created a solution which relied on using the 'EvtMgmtCustomIncidentPopulator'. Not ideal but it's fine given that it's a restricted group configuring the event rules. I don't have the code to hand rigjt now, but the following describes what I've done. Basically to choose/map content into the description field of the incident agnostic of which source system is supplying that data and the names of the fields received through the API into the event additional field I have set it up as follows: -User creates a manual attribute in the event rule being created for that source system. -The first manual attribute is called desc_1. -The data from the additional information (or from elsewhere in the event) that needs to appear first in the description field of the incident is mapped to this attribute. -For subsequent data that you want to appear in the incident description field create more sequential manual attributes named desc_2 , desc_3 etc and map the relevant data to it. -The number will determine the order the data appears. -As few or as many fields as you like can be added and this can vary from event rule to event rule. -In the 'EvtMgmtCustomIncidentPopulator' script create a while loop that runs while the existence of the field called 'desc_i' in the additional information field of the alert is true, where i is the iteration of the while loop starting with i = 1. -The loop would obviously increment each time, but is flexible enough to allow/cope with varying numbers of the desc_ fields in the event rules. - The loop adds the content of the desc_i field to a variable followed by two line feeds each time it runs. Obviously this is added to the pre-existing content of the variable each time it runs. -The variable is then mapped to the incident description field when the loop ends. This sounds more complicated than it actually is. Notes: -You only ever set up the EvtMgmtCustomIncidentPopulator script once. After that you never touch it again. You only have to add desc_i fields to event rules when you're mapping them. For us this is one event rule per source monitoring system. Simple. -It does rely on the person setting up the event rule naming the desc_i fields sequentially, but this is just training and I'd expect colleagues with access to event management to need to have been trained even without this solution in place. I'm sure other things could be done in the code to handle non-sequencial data, but this is fine for us. -When trying to read the alert.additional_info fields in the EvtMgmtCustomIncidentPopulator script, remeber to parse the JSON within the script. I found an article on the community about this, I'd need to dig it out to reference it. Hopefully this is useful to others? Thanks for your suggestions.