cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 13

Configuring "Windows Event Log Monitor" alerting

Jump to solution

What is the correct way to configure Windows Event Log Monitor alerting, making it as generic as possible? E.g. I'd like to get an email any time there's an error, and to include the text of the error in the email.

At the moment, we have generic "Application down" and "Component down" alerts. By default they do not include the ${WindowsEventMessages} value - and probably shouldn't, as it's specific to Windows Events logs.

Does this mean I need to separate my "component down" alerts into two: for Windows Event logs, and for all others?

Would someone be willing to post a screenshot of your trigger conditions for the Windows Event Monitor alerts? I imagine it'll be something like this?

TIA.

1 Solution

Since you are going to ask me "HolyGuacamole, which question are you answering?",  I am going to pre-empt this a bit So, I am answering this question

So here I go whining again: WHY? Why can't I send application tier in the email when I can check for it in trigger conditions?

Well, you can. There is nothing a little SQL macro cannot make up for. If your application custom property name is AppTier, then use the following SQL macro in your trigger action in lieu of an out of the box variable that isn't available today.

${SQL:SELECT AppTier FROM APM_ApplicationCustomProperties WHERE ApplicationID=${ApplicationID}}

p.s: I haven't tested this but I am fairly confident it will work

View solution in original post

25 Replies
Level 13

Thank you all for your responses thus far.

We did have "component down" alerts but never sent emails from them, so few people ever saw them. Application monitors were taking care of all our needs: if a component went down, "application down" alerts would trigger. (I see there are exceptions to this logic, e.g. when a component is in the "warning" state but for now, let's skip that part.)

However if I need to include Event Log messages, yet not have redundant alerts, I would need to:

  1. Suppress alerts from "Errors in Event Logs" app monitors.
  2. Create a new set of component alerts (with tier-based escalation), for "Errors in Event Logs" component monitors.

I.e. there is no way for me to have generic (as in, "not specific to particular monitors") app or component alerts that are yet that include event log messages? Does this sound right?

Thanks again.

0 Kudos
Product Manager
Product Manager

You can add the macro ${WindowsEventMessages} to your "Component' alerts. if the macro isn't applicable to the component that is alerted on then the macro will not appear in the message text. When/if the alert triggered is for a Windows Event Log Monitor the macro will populate properly and contain the full text of the Windows Event Log in the message body.

You can add the macro ${WindowsEventMessages} to your "Component' alerts. if the macro isn't applicable to the component that is alerted on then the macro will not appear in the message text. When/if the alert triggered is for a Windows Event Log Monitor the macro will populate properly and contain the full text of the Windows Event Log in the message body.

Thanks aLTeReGo. So for a generic component monitor, I'd need to add something like, "if this alert is triggered by a Windows Event Log Monitor, the event(s) may appear below" kind of a heading? There isn't a more elegant way of doing it, correct?

Any idea why Application custom properties are no longer available as trigger conditions, and not populating in alerts? Breaks my alerts escalation logic.

0 Kudos

Application Custom Properties are available for under the Trigger Condition both under the "APM: Application" or "APM: Component" property types. You are correct however that Application Custom Properties are not available as macros to be included in message body text for the "APM: Component" property type.

Application Custom Properties.png

You are correct however that Application Custom Properties are not available as macros to be included in message body text for the "APM: Component" property type.

Thank you. Is there a reason for that?

My goal with this and all our alerts is to display the "tier" (importance) of the node, application or interface in question. Otherwise I'd have to create separate alerts for each tier and it gets messy. If the variable is available in "trigger conditions", why isn't it, in "trigger actions". It's just a database field value, isn't it?

0 Kudos

That is super, super useful aLTeReGo . How come that doesn't show up as a variable to select when trying to build variables? That is immensely valuable.

0 Kudos

That is super, super useful aLTeReGo . How come that doesn't show up as a variable to select when trying to build variables? That is immensely valuable.

For me, it only started showing up once I added a component trigger condition (example in the 1st post).

(That in turn led to a bunch of other application-related variables disappearing and not getting populated in the alerts, such as application custom properties. Still can't wrap my mind around it.)

The reason you lost variables akhasheni is because you changed the monitor type from SAM monitor (APM: Application)  to SAM component. (APM: Component).

Any of the variables that are triggered/have types from SAM application that don't exist for SAM component and vice versa won't work. Component is for an individual component only and not for multiple, APM:application is for an unlimited number of components across multiple applications as needed, as well.

So if you tried to add, say a variable to trigger an alert from another part of the Orion suite, it's just going to trigger things based on the "Type of property to monitor" (see that at the top of my previous screenshot).

The reason you lost variables akhasheni is because you changed the monitor type from SAM monitor (APM: Application)  to SAM component. (APM: Component).

That part I do get. What I don't get is why a variable can be used as a trigger condition - cannot be used in the trigger action (e.g. in the body of the email).

Say, I want to trigger an alert on a condition of a component being down (or having non-zero stats value) and the application tier being less than 10. I also want (well, "need", really) to include that application tier in it so an admin knows the importance of it, and can decide whether he can finish his soup first, or get right to it.

So here I go whining again: WHY? Why can't I send application tier in the email when I can check for it in trigger conditions?

Are component alerts the only ones where trigger actions are somewhat crippled?

akhasheni I would tend to agree it's inconsistent, but given that NPM 12 is on it's way "soon" (soon being a timeframe solarwinds hasn't given anyone) with an entirely different alerting scheme which will resolve a number of our issues, I'm not really worrying about trying to make it work in the short term. We'd be discussing features that are clearly set to change in scope/functionality, anyway.

NPM 12.0 BETA4 + QOE NOW AVAILABLE

0 Kudos

Since you are going to ask me "HolyGuacamole, which question are you answering?",  I am going to pre-empt this a bit So, I am answering this question

So here I go whining again: WHY? Why can't I send application tier in the email when I can check for it in trigger conditions?

Well, you can. There is nothing a little SQL macro cannot make up for. If your application custom property name is AppTier, then use the following SQL macro in your trigger action in lieu of an out of the box variable that isn't available today.

${SQL:SELECT AppTier FROM APM_ApplicationCustomProperties WHERE ApplicationID=${ApplicationID}}

p.s: I haven't tested this but I am fairly confident it will work

View solution in original post

So, in SAM 6.2.2, I've tried using this in the To: field of an alert, but as soon as I paste it into the field, it immediately parses the string on the spaces. Any ideas? All I want to do is use an application custom property in a component alert...

${SQL:SELECT AdditionalContactEmail FROM APM_ApplicationCustomProperties WHERE ApplicationID=${ApplicationID}}

pastedImage_0.png

0 Kudos

Since it's a component level alert, did you try just using the macro instead.

${N=SwisEntity;M=Application.CustomProperties.AdditionalContactEmail}

The custom SQL is being parsed most likely because it's invalid. Try the following instead only if the macro by itself doesn't work

${SQL:SELECT AdditionalContactEmail FROM APM_ApplicationCustomProperties WHERE ApplicationID=${N=SwisEntity;M=Application.ApplicationID}}

The macro version worked: ${N=SwisEntity;M=Application.CustomProperties.AdditionalContactEmail}. Before posting the question, I had tried several options, including ${Application.AdditionalContactEmail} and ${N=SwisEntity;M=Application.AdditionalContactEmail}, I think. But I guess I wasn't drilling down deep enough into the object. Thanks for the help!

Is there documentation on how macros are structured, how to use them, and which ones exist? I assume that's in the help in NPM?

And for the record, the SQL still doesn't work in the To: field...

0 Kudos

I am glad it worked for you. You can work out the variables from the Alert wizard itself. Simply select the correct object type first in the Trigger condition - in this case Component

pastedImage_0.png

Simply use the Insert Variable buttons in your trigger actions

pastedImage_1.png

Then make sure your first drop downs is set to the object you are looking for and the second drop down to Variable Category for easier search. Select all the variables you want, and you can see the macros below the variable list (and in the body of the message of course)

pastedImage_4.png

0 Kudos

Since you are going to ask me "HolyGuacamole, which question are you answering?",  I am going to pre-empt this a bit So, I am answering this question

So here I go whining again: WHY? Why can't I send application tier in the email when I can check for it in trigger conditions?

Well, you can. There is nothing a little SQL macro cannot make up for. If your application custom property name is AppTier, then use the following SQL macro in your trigger action in lieu of an out of the box variable that isn't available today.

${SQL:SELECT AppTier FROM APM_ApplicationCustomProperties WHERE ApplicationID=${ApplicationID}}

It works. Well done. Thank you HolyGuacamole.

0 Kudos

It should, provided the property type to monitor is set for APM:Component.

WindowsEventMessages.png

0 Kudos

Wouldn't you want to add a SAM application monitor for event log monitoring and then just alert based on that SAM monitor? Seems kinda backwards to try to hardcore that into the alert, harder than it has to be. Here's one of the application monitors I'm using, for example. It watches for event log matches and if an error is received in either then I have a basic sam alert tied to that application monitor being down, as indicated.  The logs are saved so if you open the component monitor you have full verbose of the error log anyway.

I couldn't find any way to have the error included in the email in any format directly, though. I just include a link to the application monitor (see trigger email).There is the solarwinds log and event forwarder (free) for emailing specific errors back, if I recall correctly.

aria app monitor.jpg

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

Here is the actual alert and it's trigger conditions thus far:

Image:

aria app monitor trigger.jpg

As I have multiple event logs monitored in the same monitor, I want any of the ones I have selected to trigger. 

Trigger email:

${TimeStamp} - ${Status}

Individual Componenets and their statuses:

${ComponentsWithStatusFormatted}

${APM:ApplicationDetailsURL}

0 Kudos

Wouldn't you want to add a SAM application monitor for event log monitoring and then just alert based on that SAM monitor? Seems kinda backwards to try to hardcore that into the alert, harder than it has to be.

I agree. But I also think getting at least a hint of what the error is in the email is critical for a good alerting system, especially if the admin is off-site and not remoted in. My boss thinks so too so he asked me to see if there is a way to implement it.

I couldn't find any way to have the error included in the email in any format directly, though.

Same here.

Level 13

yes, component type 42 means "Windows Event Log Monitor", and instead of component status, it makes more sense to trigger on statistic data (which in case of this component stands for number of events matching given criteria):

Alert.png

0 Kudos