This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Trigger action standards?

I'm curious to know what, if anything, people have come up with for trigger action standards?  I have the opportunity and necessity to revamp our Alerts so I figured I'd implement some standards while I do it.

I'm thinking about the Trigger Action Title, and the Subject and Message for email actions.  What kind of standards have others come up with and what's the reasoning behind them?

  • Personally I try to get the important info into the subject as it will determine if someone will double click it to open the alert email. Then in the body of the email I have all the alert details compressed into as minimal information that is needed. Otherwise it's just an information overload.

    HTH

  • I would say Trigger action name should be something which would make anyone understand by just seeing.. so u can keep it short and simple

    for subject of the email, it should clearly state whats the alert about and include detail of thresholds, and status.

    Body can be detailed and this would depend on which team you are sending to. For instance if its a to an L0 team then you can give them more details... If its for an L2/L3 teams then you can give them device details including status and what exactly the alert is about and possible actions they can take...

  • I'd suggest 3 areas of standardizing:

    1. Alert naming standards (or convention) - pointing severity and corelated with RESET naming;

    2. Alert subject standards - all basic information like what, when and where;

    3. Alert details standards - body with all necessary details for relevant recipients - as an option link or description of procedure to follow up.

  • The approach here is identifying the common parameters that work across the differing alerts, as alerting output generated by SAM will be wholly different to the information you would put into alerts generated by Vman or IPAM for example.

    Common standards we deploy for customers:

    1. Plain Text or HTML, where with HTML create a template which has good tabular structure, common data value pairs (Hostname, IP, Site, Priority, Owner (last 3 examples come from custom properties) and use colour backgrounds to indicate importance

    2. Prefix email subjects with ALERT and RESET for clear indication and build the message and subjects in a way that you do not need to change much if anything in the text

    3. Next in Subject come the priority, which we tend to build into the custom property definition and the alert

    4. Look to utilise the Alert 'Message displayed when this alert is triggered' field in the rest of the alert output. The wording here is often likely to be usable in other output methods, which this field can be referenced with a variable

    5. For the email body, as indicated above keep it clean and simple to absorb. Long wordy sentences (and with some customers I have seen paragraphs of text used for the output) are difficult to digest. Use data value pairs such as:

    Hostname: ${N=SwisEntity;M=Node.Caption}

    IP Address: ${N=SwisEntity;M=Node.IP_Address}

    Device Importance:

    Site:

    Device Owner:

    etc.

    6. Always include the name of the alert that generates the alert, tucked nicely at the bottom

    One last comment on this; look for better external notification than email, for which I will now step off my soap box..

    Hope this helps.

    Mark Roberts

    Prosperon - UK SolarWinds Partners

    Installation | Consultancy | Training | Licenses

    facebook_icon.jpglinkedin.pngblogger.pngtwitter-icon.jpg 

  • Lets see everyone's coolest Actions - Macro based and SQL.

    Show us what you use as a disk alert, CPU alert and Applications.

    How does one make 1 catch all for all of the above?