Executing a program when a resource fails

Posted on December 13th, 2012

A very powerful new feature was recently added to Overseer network monitoring software, in 5.0.101. This feature is the Overseer ‘Actions’ system. Actions are processes that can be triggered when monitoring– typically when a resource fails, or new events are available. Currently the only action type, is to execute a program– but being able to execute a program with parameters is an incredibly powerful feature, enabling you to do almost anything.

Actions are configured under Manage->Actions. You can also ‘test’ an action, making it easier to get your parameters just right. Once you have an action defined, you must link this action to a resource. To do so, edit a resource and choose the ‘Actions’ option in the left tree. You can then use the ‘Add’ button to choose the action you’d like, along with the trigger type. Now, whenever that instance(such as ‘first failure’ or ‘every failure’) occurs for that resource, the action will be executed.

Additionally, under the ‘History’ tab for a resource, you can see the full detail of any actions that are triggered– both the input(command line, including parameters) as well as the output(stdout and stderr from your executed program).


Overseer 5.0.106 has been released

Posted on December 13th, 2012

I just released a new version of Overseer Network Monitor, 5.0.106. This version adds a couple variables that can be used in custom texts– most notably, %SQLQUERY% and %SQLRESULT% for the DBQuery resource type. These were added at the request of a user– if you have variables that you’d like added, please let me know.

In addition in this release, I was able to re-create a rather complex bug that some users have had in certain environments. I was able to solve this issue, which was essentially a bug in the underlying .NET Framework. Fortunately, I was able to work around this problem and it should no longer be a problem for the users that operate in those environments.


Overseer 5.0.101 has been released

Posted on December 7th, 2012

I have just released Overseer 5.0.101. This release actually has a very powerful feature, that’s been requested by many customers. Customers have requested that upon failure of a resource, that Overseer can launch a program with parameters. As of 5.0.101, Overseer has an ‘Actions’ system that lets you do just that– launch a program with parameters upon first failure, every failure, every check, recovery, or new events(event log entries). ¬†This can be very useful for many different types of functionality.

I’ll be posting more blog posts detailing how this works, but for now I just wanted to get this released. You can add/edit your actions under Manage->Actions, and assign them to a resource using the ‘Actions’ section when editing a resource. The help file(both online and the local version) has been updated with information on actions.


How to fix errors connecting to MSSQL Server

Posted on December 6th, 2012

With the addition of the database query monitoring feature of Overseer Network Monitor, I’ve had a couple users come to me with errors connecting to their MSSQL server using Overseer. This is primarily because the default configuration of Microsoft SQL Server disables TCP/IP communication for security reasons. When Overseer is unable to access the MSSQL server, you may get an error like this:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (Provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server

Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding

 

To properly configure MSSQL server to listen on TCP/IP, you’ll have to follow these steps:

 

1. Find and run the “SQL Server Configuration Manager” on the start menu. This should be under “Microsoft SQL Server 2008 R2->Configuration Tools”.


2. Once you open the SQL Server Configuration Manager, navigate to SQL Server Network Configuration->Protocols for MSSQLSERVER. Find ‘TCP/IP’ on the right side, and double-click it:

 

3. On the TCP/IP Properties page, make sure ‘Enabled’ is set to Yes, and ‘Listen All’ is set to yes, per this screenshot:

 

4. Also, make sure the port is specified on the ‘IP Addresses’ tab, under the “IPAll” section. This should typically be 1433:

 

Once this is done, you’ll have to restart the MSSQL Server service, and then attempt to connect to it with Overseer again. If things still don’t work, you may have a firewall blocking port 1433, either on the MSSQL Server machine, the Overseer machine, or potentially a hardware firewall in between– make sure port 1433 is allowed/forwarded as needed.