How do I use the Service Monitoring feature?

EventSentry's service monitoring feature allows you to be notified when a service changes its status, or when a service and/or driver are added or removed.

System Health

It's important to understand that Service Monitoring is a System Health item and can be added to any system health package. System Health items do not actually send notifications, but instead log messages to the Application event log or consolidate information to your database. This is a bit different than Event Log filters which monitor the event log and forward events to an action (e.g. email). Other Health items include Diskspace Monitoring, Software Monitoring, and Performance Monitoring.

Configuring Service Monitoring

With the default installation of EventSentry, a package named Services has already been created for you.

However, you can add a Services object to any System Health package. A benefit of having separate Service Monitoring packages is you could assign each to a separate group or host(s), and configure your packages to only monitor specific services that are relevant to you on these separate groups/hosts, for example.

Now click on the Services object in your package and you will see several options to configure

Focus - The first order of business when setting up this feature is what are you going to monitor. You have the option to "Monitor & alert on all services, exclude listed" which will let you exclude common services that you have no interest in monitoring. The next is to "Only monitor listed" which will only monitor the services you declare. New in EventSentry 5.1 is the option to "Monitor all services, only inventory listed." With this option, the services you list in this pane will still track their status and write to your database so you can track them in Web Reports. However, they will not generate email alerts or show status warnings in Web Reports. Finally, you have the option to monitor nothing at all with "Disable."

Event Logging - Based on whether you are "Monitoring Service Status Changes" and/or "Monitoring Service Addition / Removal" EventSentry will log status changes to the event log of the machine the agent is monitoring. Here you also have the ability to decide whether you would like to log the changes as an Error, Warning, or Information event. In our example we will set the logging to Error.

Database Consolidation - Next, you have the option to record to your database in the database pane which will also log all service status changes and/or service addition/removals to the database, enabling you to view the current service status and history through the web reports. Please note that you will still need to select the appropriate option above in order for information to be logged to the database. Configuring database logging is as simple as adding your database action.

Status Control - Finally, we have the option to keep services in a particular status. Lets say that you want to make sure that the DNS Server service is running at all times. EventSentry will automatically start the DNS Server service if the status changes from running to stopped. Using Service Status Control allows you to set a desired status for the service and EventSentry will try to maintain this status.

Logging and Alerting

As I mentioned before, because Service Monitoring is a System Health object in EventSentry, you will not receive any notifications from Serving Monitoring directly. Instead, service monitoring will log alerts to the event log. In the previous step we configured Service Monitoring to log all service status changes to the event log as errors. As a result you will notice events similar to the one showsn below in the Application log (with the event source of EventSentry).

Each time any monitored service changes its status, you will see an event similar to the one shown above, in the application event log. As you can see, the event was logged as an Error because we set EventSentry to log service changes as an Error instead of Information or Warning. For a list of all the possible messages logged by Service Monitoring please see our online documentation.

Now that EventSentry is logging service changes to the event log we can set up a filter that will alert us of these status changes. Note that the default installation of EventSentry has a catch-all package named "Email Notification" that will forward all warning and error events from an EventSentry feature to your default email action. Therefore, you may find that once you have configured your service monitoring package you are already receiving email alerts for your services. However, many times the Email Notification package is unassigned/disabled to reduce noise depending on how you initially configured EventSentry so you can set up more specific event log filters to alert you for service status changes if you don't want to enable this package.

The easiest way for us to do this is to simply use the include option in the EventSentry Event log Viewer which will automatically create a filter based on the event you are currently viewing.

However, for the sake of this tutorial we will manually walk through how to create a specific filter that will notify us only when the Print Spooler service changes its status and ignore status changes of other services.

Creating the filter

To keep things organized, we will create new package called Service Changes, assign it globally, and add an include filter named Print Spooler.

Now we will declare our target as Default Email which will send an email if the conditions specified on this filter match an event. Since we know that the event occurs in the Application log and it will log as an Error, we can focus this filter on only events that share those properties. We will also fill in EventSentry as the source, Service Monitoring as the category, and 10100 as the event id.

Seeing as we configured Service Monitoring to log changes to the database, assigned it globally, and created an include filter, we are all set right? Well, not quite.

With the current filter, you will receive an email for every service change reported by the service monitoring object. This means that you will potentially receive dozens of emails a day from services known to change their status frequently (e.g. CD-ROM Driver). As such, we will use a content filter to focus this filter on only alerting us when the Print Spooler service changes its status.

You could also focus the filter to only send you an email only if the Print Spooler changes from running to stopped and nothing else.

Then you can take it a step further and say that you would only like to be notified if the Print Spooler service changes status on a certain machine. In our case we only will be notified when this service changes status on HOST1 (note: you could achieve the same thing by assigning the package only to HOST1).

Conclusion

After following this tutorial you should have the general understanding of how to set up email notifications based on service changes and how health objects require filters in order to notify you. Using EventSentry to monitor your services will let you know when the services you care about are not behaving accordingly and react immediately.