What is it?
QuickMon is a simple monitoring and alerting tool. It is easy to set up and allows you to monitor various resources or services from a single location.
- It allows you to monitor various resources on the local or remote computers.
- It can generate 'Alerts' to notify you or simply record problems as they occur.
- You can set up 'Monitor packs' that monitor multiple resources as one unit.
- When an alert is triggered it also can also run a corrective batch script to attempt a fix.
- It supports 'Remote agents' from version 3.0 so resources on (and from) remote computers can be monitored.
- It can be extended if needed (by developers)
- It is not intended to be in the same league as professional monitoring tools for enterprises but it can 'evolve' and grow with time.
For some more screenshots of the new version see QuickMon3
Overview of architecture
QuickMon has a plug-in architecture that allow 'agents' to be added to the system easily. There are two 'types' of agents:
- Collectors - gathers information about the state of some resource, service or whatever the creator of the collector implements.
- Notifiers - reports/records 'alerts' in some format. This could be in any means that record or sends information.
A set of collectors and notifiers can be configured in what is called a 'monitor pack' to all operate together. This pack is essentially an XML configuration file that describes which agents to use and the settings needed to configure them. A monitor pack can contain multiple collectors and notifiers, even of the same type, each one with different configuration parameters.
To use these 'monitor packs
' you can use either the provided Windows client application
or Windows service. There is also a standalone 'configuration editor'.
gather information about resources, services etc. The main purpose of each collector is to return a global 'state' of the resource - which is one of only 3 possible values: good, warning or error. A collector can also be configured to only operate within a set of 'service windows' plus be dependent on 'parent' collectors. If a parent collector returns an error state then the child collectors are not checked e.g. you can have a parent 'Ping' collector - that simply checks if a machine is available, and child collectors checking resources on the same machine - if the parent (ping) collector returns an error there is no point to check other resources since it is not available anyway.
Collectors can also be disabled if needed within a monitor pack so that it is not checked until it is enabled again. All dependent collectors are then skipped as well.
The following is a list of the existing collectors that are included:General
- Folder - is a special placeholder (or virtual) agent that does no 'work' by itself and simply acts to group dependent child collectors.
- Event log - count number of matching event log entries
- File count and size – file/directory size or existence.
- Performance counters – monitor performance counters
- Ping – ping machine response times. In version 3 it supports HTTP and Socket pings as well.
- Registry Query - Query the registry of a computer.
- Soap Web Service - Simple pinging/polling Soap Web services
- Windows service state – are specified services running or not
- WMI query – specify some WMI query and check the return value
- BizTalk ports and orchestrations – check if ports/orchestrations are running
- BizTalk suspended count – check the suspended instance count
- SQL Query - Run SQL query and check the return value, row count or query time.
- SQL server database size – check database size
- SQL server table size – check row count
A collector also includes functionality to show a configuration dialog window with which configuration for that type of collector can be edit plus another window to display the details of the type of resource it 'service'.
record or post alert messages raised to the type of technology they use. They are configured to record alerts of a certain level (or worse) e.g. 'Warnings' and 'Errors' or just 'Errors'.
Like collectors the notifiers contain functionality to edit its type of configuration. Some notifiers also contain a 'viewer' window or mechanism to view the gathered alert information. This is because some notifiers like the SMTP notifier don't have anything to 'view' once the message has been sent.
Lastly, a notifier can be configured to only accept alerts for specified collectors if needed. This is useful if some alerts are not relevant for the audience of the notifier.
The following is a list of the existing notifiers that are included:
- Event log - Log alerts to the event log (local or remote)
- Log file – a simple text log file
- SMTP – Sending out alerts as emails
- SQL database – storing alert details in a sql server
By default alerts are raised 'only' for when a collector detects a change in the state it is returning. There is a setting for each collector entry to have alert messages be repeated after a specified number of minutes. There is also another setting to suppress alert messages if the state of a collector change too quickly (multiple times).
A monitor pack
is a set of configurations of multiple collectors and notifiers that will all work together. You can have multiple monitor packs for different purposes and even run them side-by-side (using multiple instances of the Windows UI client).
loads a monitor pack and display the statuses of the collectors. The global status (of all the active collectors) is used to change the application icon so you can easily see if all is 'good', some errors/warning or everything is in error.
Note on Admin mode: The UI tool itself does not require Admin mode (like in Windows 7/8) but some Collectors and Notifiers might require it - especially the first time they start up. For example, the Event log notifier requires Admin mode to create the Event Source the first time. Since version 2.8.2 the UI app will automatically restart in Admin mode if it detects a related security exception.
A Windows service
is also provided that essentially does the same job except it runs in the background without a UI. The advantage is that it can run even if no one is logged onto the computer. It must however be configured to run under an user account that has access to all the resources it need to access.
From version 3.0 the service also acts as the 'Remote host'.
Because of the 'plug-in' architecture it is easy to add new agents (collectors or notifiers). All that is required is to implement a standard .Net interface.
Other possible future ideas
At the moment there are plans to add some more features like:
- Enhance existing Collectors: add some QPerfmon functionality to PerfCounter Collector
- Mail aggregator - I'm already busy working on this off-line to have alerts sent by mail grouped/batched rather than each one posted by itself. This is useful if you start having the 'spam myself' problem... (See http://mailaggregator.codeplex.com/)
Please don't be shy to report any issues or suggestions. Log it under discussions or issues as needed or even drop me a message.