Sensor to monitor appearance of Windows Application log Event ID 1309

Hello Brian,

Thank you very much for your contact.

Please note that the sensor will only show the number of new records per second (speed) during two specific sensor scans. The deflection is only visible between two sensor scans. As soon as the 1309 event has been "discovered" so to say, the sensor will not show any further action as long as the next 1309 event occurs.

A convenient tool to manually trigger events is by using the following command in a command window (started as Administrator) on the machine, that you monitor.

eventcreate /T INFORMATION /ID 999 /L Application /SO "eventtrigger.cmd" /D "This is manually triggered event log entry."
Best regards,
Sebastian

So how does one monitor for the APPEARANCE of an event ID? I only care THAT it happens, not HOW OFTEN it happens. I've had this sensor, and an identical WMI sensor, running for 24 hours now. During that time event ID 1309 has occurred 15 times on this server. Neither of these sensors have registered even one occurrence in PRTG.

I need to know how to use PRTG to monitor a Windows Server 2016 Application Log for instances of Event ID 1309. Each time a new instance of that event appears I need PRTG to send me an email. If you are telling me that is not possible then that is quite disheartening.

Hello Brian,

For further testing I suggest using the 'eventcreate' command above.

Assuming that your senor has a configured scanning interval of something between 60 seconds to 10 minutes, you should see new entries for the New Records channel. To verify this either check the Live Data or 2 days graph. You should see numbers above 0 here.

If so, edit the channel settings for the New Records and enable alerting based on limits. The Upper Error Limit (#/s) should be 0 which results in a short downtime of the sensor as soon as the measured values are above 0 during two sensor scans.
Afterwards, define a suiting notification trigger (state trigger). For instance, When sensors is Down for at least 0 seconds, perform Email and push notification to admin.

This will trigger an email notification every time an event based on your sensor settings occur.

Best regards,
Sebastian

Thank you, Sebastian. I have used the eventcreate command to create an Event ID 999 and both the WMI and API sensors I setup for this test saw the 999 event and registered it in the PRTG Live Data log. I have identical sensors setup (when I figure out which works better I'll remove the other) to look for Event ID 1309 in the same Application log, and neither sensor has ever registered even one instance of that Event ID showing up in the Application log on that server. Yet when I look at the Application log it shows many instances of event 1309. So why is PRTG not registering those like it does the 999 events?

Hello Brian,

The eventcreate ID '999' is just a random number for test purposes. I use this number because I can manually trigger the exact time when to expect an action on the sensor and in my mailbox.
I can't foresee when to expect a '1309' event. If the sensor with its notification trigger works as expected (e.g. with set Filter Type within the sensor's Settings tab), you should be able to expect the sensor to work properly, after simply changing the Match Values (Event ID) from 999 to 1309.

If this does not help at all, I'll need you to get in touch with us via email to [email protected] as the ticket require a deeper look into your settings. We'll basically need screenshots and configuration reports of the sensor, which are easier provided via email than in the KB. If you contact us via email, refer to this thread and I'll continue with you that way.

Best regards,
Sebastian

Hi Brian,

Look at this please:

https://www.it-admins.com/prtg-911-call-alerts-shoretel/

You would need to modify the script a little bit.. change the EVENTID to the ID you want to look for, and decide what you want to give back to the host... in theory you could remove all the $str_EventMsg = $str_EventMsg lines and have the WRITE-HOST in the IF case say Write-Host "0:Event detected" while you change the ELSE case to Write-Host "0:Event NOT detected".

If really necessary I can adjust the whole script - but I am more curious about the error 1309 you are talking about.. is this the ASP.NET/IIS related event that a quick Google search brought up or what is it that you are looking at and what data in that event might be interesting? Can you post an example and give more details?

Pretty sure there is a nice solution that would help you more.. Let me know if you want to dive in deeper..

Regards

Florian Rossmark

www.it-admins.com

Thank you, Sebastian. I will open a ticket as it is definitely not registering the 1309 events.

Thank you, Florian, I will give it a shot!

Florian ... the event ID 1309 is the ASP.NET / IIS-related event. I'll post an example below. For some reason there are times when this event entry precedes our Ecommerce website not allowing user logins. Recycling the associated IIS Application Pool for that website fixes the problem (even though the AppPool never actually goes down or reports any issues). We just want to be warned that a recycle might be necessary. Before doing that we test the site login and if the site is still working as expected we do nothing. The programmers who developed the site (it's a .Net WebApp) can't find anything wrong with their code, at least not so far.

Anywho, here is an example Event 1309 details (I have no idea why the first line is "Event code: 3005" when the Application log shows this as an event ID of 1309): http://collabedit.com/k5cae

Hi Brian,

There sure is a bug in the ASP.NET code - specifically it looks like it is in this module "SetCustomerAcctDetail". What I normally do is using TRY/CATCH/FINALLY blocks to catch and process errors or narrow them down. In any case, there must be something either in this module that is wrong. It is likely that it is within a procedure in the module or that the module tries to call an outside procedure/function with invalid data at a certain point in time while it is not accounted for. Good error handling should reveal the issue pretty quick actually. But I am sure your developers are professionals that know what they are doing.

As for you - I understand why you monitor the eventlog, trying to correct something that should not be the case in the first place.

Checking for the EVENTID is one way to tackle it, there are sensors that can try a logon to the website and alert when it does not work - what might be even better for you.

The application pool won't go down due to an ASP.NET error, the pool is mainly the executing user, while the error might cause the application in the pool to restart and possibly lose e.g. the basket any 3rd user would have put together (not necessarily, depending on how it was coded - just an example), cause the application would restart. Or the application hangs and a restart of the AppPool just acts like closing/opening a program - kind a like task manager and killing an application/task.

Definitive get your developers on that and have them add good error handling to determine the root cause, simply because this can have a bigger effect then just users not being able to logon.

Check out this sensor for logon tests: https://www.paessler.com/manuals/prtg/http_advanced_sensor

Hope this helps :-)

Florian Rossmark

www.it-admins.com

Thank you, Florian, I will pass along those details to the programmers. In the meantime I like the idea of monitoring the site via user login so I'll see if I can figure that out.