What is it?
QuickMon is a simple monitoring and alerting system. It is easy to set up and allows you to monitor various resources or services from a single location.
- 'Out of the box' it already has collectors for things like 'Ping', Performance counters, Windows services, File counts/sizes plus many more (including WMI)
- It can be used as either a simple UI application tool or a proper Windows service.
- You can set up 'monitor packs' with any number and mixture of Collectors and Notifiers to suit your monitoring and alerting needs.
- Since version 2.10 it supports 'corrective' scripts to be run based on alerts.
- It is free and extendable with a whole bunch of existing collectors and notifiers built-in.
- Developers can easily extend it by adding more collectors and/or notifiers.
- It is however not intended to be in the same league as professional monitoring tools intended for enterprises but it can 'evolve' and grow with time.
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.
- Disk space – local (only) drive space available (redundant since performance counters can also do this)
- 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
- Httpping - like ping except for http/https protocol
- Registry Query - Query the registry of a computer.
- Soap Web Service - Simple pinging/polling Soap Web services
- SQL Query - Run SQL query and check the return value, row count or query time.
- Windows service state – are specified services running or not
- WMI query – specify some WMI query and check the return value
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 is included:
- Event log - Log alerts to the event log (local or remote)
- Log file – a simple text log file
- RSS feed – actually really just an xml file that you can host on a web server that is exposed as an RSS feed
- 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.When using the service please remember to edit the config file (QuickMonService.exe.config) and add some Monitor Pack to use before starting the service!
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.
At the moment there are plans to add some more features like:
- Enhance existing Collectors: add some QPerfmon functionality to PerfCounter Collector
- Check if directory exists collector - to include variables in directory name e.g. %year%, %hour% etc.
- Add some more diagnostic info to collectors to show things like duration of last 'poll' interval. This could help to troubleshoot a problematic resource being monitored when you have a long list of collectors and don't know which one is the 'slow one'.
- 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.