This project is read-only.

Getting Started

This provides information on installation and configuration of Wolfpack.

Custom plugin development

If you just want to develop either a new custom HealthCheck, Publisher or Build Analytics component then the quickest route is via the NuGet packages. Wolfpack is now on NuGet!; Rob Gibbens has created the NuGet packages to support & streamline custom HealthCheck and Publisher development. These contain just the binaries required to develop these plugins for Wolfpack. You can get the packages from the NuGet gallery via the online package browser in Visual Studio - just search for "Wolfpack"...Thanks Rob, great job!

Installing and running Wolfpack

22-Oct-2012 Wolfpack is now on Chocolatey! If you are a chocolatey user then install with "cinst wolfpack". This will pull down the wolfpack nuget package and install it to c:\chocolatey\lib\wolfpack.x.y.z. It will also create a batch file to start wolfpack, just type "wolfpack.agent" in any command window - sweeeet!

for non-chocolatey users....
To start with, download the latest binaries zip (or source and build it yourself) from the associated codeplex pages.

Wolfpack is based on the TopShelf windows service framework. This means you can run it as either a console application (recommended whilst you evaluate) or install it as an unattended windows service (recommended for real use). All exceptions are logged to the Wolfpack.log file in the application folder using Log4Net - check this if you have trouble starting Wolfpack.

To run it as a console application, open a command prompt and type,
To install and execute it as a windows service running under the Local System account, open a command prompt and type,
wolfpack.agent.exe /install
To install and execute it as a windows service running under the custom account, open a command prompt and type,
wolfpack.agent.exe /install /username:[DOMAIN\Account] /password:[Password]
To uninstall it as a windows service, open a command prompt and type,
wolfpack.agent.exe /uninstall
There are several "profiles" that alter the behaviour of Wolfpack. Supported profile names are,
  • FastStartAgentProfile - this will asynchronously startup the agent so that control is quickly returned to the Windows Service Control Manager - this stops timeouts occurring when you have a large number of plugins configured and enabled. Access these additional profiles with,
wolfpack.agent.exe /profile:[profile name]

Configuring Wolfpack

Wolfpack uses Castle/Windsor as it's IoC/Container. I've hopefully abstracted the concrete Windsor container away from the code so it should be possible to replace the IoC/Container with another framework if desired. The main use of the Container is to register "configuration" components which are used to infer and load an associated component (plugin) that performs as either a "Publisher", "HealthCheck", "Activity" or "Scheduler".

However... - I've exposed some Castle namespace components out via the "Container" helper which means Wolfpack is now locked to Castle - this was required to get the Publisher Filter functionality to work as it uses Castle Interception - the good news is that I was being a bit lazy and didn't want to create Wolfpack wrappers over the components and exposed the Castle ones directly so it would be possible to put Castle "back in the box" - you would also need to implement your own Publisher Interception mechanism in what ever IoC container you replace Castle with.

A full list of container configuration files is below but there are three main ones in the config folder to play around with initially, the check, publisher and binding config files.

The check.castle.config file contains the setting for each individual health check that Wolfpack executes. The only rule is that each one has to have a unique component id attribute value and a unique "FriendlyId" value, so it makes sense for these to be the same. Each "component" represents a health check instance. If the "Enabled" property is true then Wolfpack will query the binding.castle.config file to try to link it to a schedule (when it should execute) - if it finds a match it creates an instance of the health check and starts running it on the schedule indicated in the binding.

Configuration by Example

One of the example HealthChecks is "IsNotepadRunning" - so lets use this as a template for your first configuration modification, we'll create a new HealthCheck to check for the calc.exe process.
1. In the check.castle.config file, copy the IsNotepadRunning" component and rename the id attribute and "FriendlyId" property to "IsCalcRunning".
2. Change the "ProcessName" property to "calc.exe".
    <component id="IsCalcRunning"
				   type="Wolfpack.Core.Checks.WmiProcessRunningCheckConfig, Wolfpack.Core">
3. Update the binding.castle.config file, find the "IsNotepadRunningBindingConfig" component and copy it
4. Rename the component id to "IsCalcRunningBindingConfig".
5. Update the "HealthCheckConfigurationName" property to "IsCalcRunning" (this "binds" our new HealthCheck to the schedule named "EveryMinute")
    <component id="IsCalcRunningBindingConfig"
				   type="Wolfpack.Core.Interfaces.Entities.BindingConfiguration, Wolfpack.Core.Interfaces">
6. Restart Wolfpack, you should see your new HealthCheck "IsCalcRunning" appear. Try opening calc.exe and leave it running for a few minutes, then close it....Wolfpack should start to report failures when it is not running (remember it's not instant as it only checks once a minute).
7. That's it - you have created your first HealthCheck by reconfiguring Wolfpack. Remember you can create as many checks as you like; you can even create new "schedules" for them by creating new entries in the schedule.castle.config file. Just remember to add an entry in the binding.castle.config file to link the two together - its job as its name implies is to bind a HealthCheck to a Schedule.

Binding by Convention

A new feature of v2.3 is the creation of bindings based on a simple folder name convention. Essentially this removes the need for an entry in the bindings.castle.config file by using the folder name the healthcheck config file is located in as the name of the schedule to bind it to.
  • Any sub-folder of the "config\checks" folder is assumed to be the name of a schedule component in schedule.castle.config.
  • Wolfpack comes with a "config\checks\everyminute" folder installed. Create more health check config files into this folder to run them "Every Minute".
  • To create a new automatic binding just create a new sub folder, eg: "EveryHour" in the "config\checks" folder
    • Ensure you have a component id with the same name in your schedule.castle.config file.

Configuration Folder Structure

The Config application folder mainly contains the configuration files for each of these component roles,
  • Checks subfolder contains the healthcheck configuration files, one per health check
  • Publishers subfolder contains the publisher configuration files, one per publisher

Important Files

  • activity.castle.config - registers the configuration component for an "Activity"
    • This is a standard Castle component configuration file
    • WCF Service "Uri" - where the service listens
    • NSB queue to receive Wolfpack data
  • binding.castle.config - this is used to associate a HealthCheck to its Scheduler
    • This is a standard Castle component configuration file
    • The component "id" must be unique but is otherwise not important
    • The HealthCheckConfigurationName & ScheduleConfigurationName property values must match a component "id" in the check.castle.config and scheduler.castle.config file respectively.
  • filter.castle.config - this is used to provide configuration to each Publisher Filter
    • This is a standard Castle component configuration file
  • finaliser.castle.config - this is used to provide configuration to each Growl Notification Finaliser
    • This is a standard Castle component configuration file
  • log4net.config - standard log4net config, see for more details.
    • Errors are output to the Wolfpack.log file in the application folder - check this if you have trouble starting the service.
  • role.castle.config - this provides configuration for the Wolfpack instance
    • This is a standard Castle component configuration file
    • SiteId is the name of the instance and should be unique per Wolfpack installation. It is used to identify the origin of monitoring data
  • scheduler.castle.config - provides the configuration to the schedulers. You can create as many of these as you like with whatever intervals you require. Just use an entry in the binding.castle.config to associate a HealthCheck with the Schedule via the component "id".
    • This is a standard Castle component configuration file
Activity, HealthCheck and Publisher config components all support an "Enabled" property - set this to "true" or "false" as desired; this provides a very quick way of changing the behaviour of the monitor without having to comment out/removed whole sections of configuration.

Important... by default, only the Growl publisher is enabled. I chose this one as, although it requires you to install Growl it's a visible and simple method to demonstrate that Wolfpack is working. See this guide on setting up Growl (and the other publishers).

Remember to configure the activities, publishers and healthchecks before you start Wolfpack. Restart Wolfpack to pick up any changes you make to these files whilst it is running.

Remember the account you run Wolfpack under as a service must have permissions to perform the checks you have configured it for. For instance, if you are using the MSMQ checks the service account must have the correct permissions on the MSMQ in question.

Last edited Jan 30, 2013 at 12:37 PM by jimbobdog, version 15