Publishers

Wolfpack "publishes" two types of messages,

Startup Message - when the "agent" starts it publishes this message which contains,
  • The name of the Agent (SiteId from role.castle.config)
  • How long it took to initialise
  • A list of plug-ins (HealthCheck, Publisher, Activity) that failed to initialise and are now disabled.

HealthCheck Result Message - this is published by a HealthCheck when it has something to report and contains,
  • Agent information (SiteId, machine name)
  • HealthCheck identity
    • FriendlyId from component config in check.castle.config
    • Description (eg: Checks for the existance of process "notepad.exe" on localhost)
  • When it was generated
  • The result (true/false/null)
  • A result count (double datatype) - a value relevant to the check (eg: the number of "notepad.exe" processes running)
    • Info - more details on the result (eg: There are 0 instances of process "notepad.exe" on localhost)
  • A property bag (name/value collection) - this can be used to store other useful data gathered during the HealthCheck

Result Publisher Filters can fine tune HealthCheck Result publication - please take a look at that documention page for more on this cool feature.

Contrib

That's not the end of the story as far as plug-ins go... a separate Wolfpack Contrib project established by @RobGibbens provides additional publishers including a MongoDb publisher - check it out for more plug-in goodness!

Growl

 
growl.png

Growl is a fantastic system tray notification app - better explained here. Wolfpack can "publish" to a local instance of Growl - that is Growl running on the same machine as Wolfpack. It can also send messages to Growl running on a remote machine.

Please take some time to investigate Growl if you have not used it before - it's very powerful and really rocks if you have a SmartPhone! There are various applications that let you forward notifications to your SmartPhone (on my iPhone I use Prowl iTunes: iTunes App).

Growl Notification Finalisers

These allow you to fine tune exactly how the notification appears in Growl. Using Castle Interception your code can receive both the HealthCheck result being published to Growl and the default Growl notification already built by the Growl Publisher - your component can execute your custom logic to determine the priority or alter the message text in anyway you want. I have also included two built-in Finalisers to allow you to quickly alter the notification priority based on the success/failure or "count" of a HealthCheck - they also serve as a great base line to learn how to implement your own ones; the How To page (publishers section) also contains more information on this new feature.

NOTE! Growl is not an unattended service - it only runs for the logged in user. If someone isn't logged in to a machine Growl will not be running!
  • Install Growl (download available here)
  • Configure Wolfpack to publish to Growl.
    • Open the publisher.castle.config and find the component "GrowlConfiguration".
    • Set the "<Enabled>" property to "true", save the change
    • If you want to run Growl on a different machine to Wolfpack then you must also,
      • Enable "Allow network notifications" in Growl
      • Add a password to Growl
      • On the "GrowlConfiguration" component in publisher.castle.config set the "<Password>" property to the same password
      • Set the "<Hostname>" property to the name/ip of the Growl/remote machine
      • Set the "<Port>" property to "23053"
    • Restart Wolfpack to pick the change up

SQLite

 
db.png

It would be useful to record Wolfpack data right? Well you can using the SQLite publisher. SQLite is a free, open source database format.

The data is stored in a single table (AgentData) and uses a "blob" column to store the DataContract serialised messages. Some of the message properties are extracted (like Result) so you can query these directly.
  • The AgentData table (and any future database objects) is automatically created for you when Wolfpack starts if you have Enabled the SQLite publisher.
  • Open the publisher.castle.config and find the component "SQLiteConfiguration".
    • Set the "<Enabled>" property to "true"
    • Set the "<ConnectionString>" property to the right connection values (Data Source & Initial Catalog). This can also be a reference to a named connection in config\data.connections.config file - Wolfpack is smart enough to work out if its an actual connection string or a reference to one!
    • Save the changes and restart Wolfpack

SqlServer

 
db.png

It would be useful to record Wolfpack data right? Well you can using the SqlServer publisher.

The data is stored in a single table (AgentData) and uses a xml "blob" column to store the DataContract serialised messages. Some of the message properties are extracted (like Result) so you can query these directly without having to bust out your XQuery chops.
  • The AgentData table (and any future database objects) is automatically created for you when Wolfpack starts if you have Enabled the SqlServer publisher.
  • Ensure the database/table has the right permissions for the user you are running Wolfpack under. You will need INSERT, UPDATE, SELECT, DELETE permissions on table "AgentData"
  • Open the publisher.castle.config and find the component "SqlSeverConfiguration".
    • Set the "<Enabled>" property to "true"
    • Set the "<ConnectionString>" property to the right connection values (Data Source & Initial Catalog). This can also be a reference to a named connection in config\data.connections.config file - Wolfpack is smart enough to work out if its an actual connection string or a reference to one!
    • Save the changes and restart Wolfpack

WCF

 
wcf.png


For situations where you need to "send" the monitoring information to another machine (Wolfpack instance) over Http, this is the publisher for you. This publisher is specifically designed for the scenario where you are running multiple Wolfpack agents collecting data on remote servers but want to "administer" this data at a central location.

Obviously this publisher (client/proxy) needs to have a complimentary WCF service running somewhere to receive the data messages. Well, that's the job of the "WcfServiceHost" Activity; this plugin creates a self-hosted WCF ServiceHost within Wolfpack and this acts as a relay - it receives the monitoring data and forwards it on to the enabled publishers. So you would run one instance of Wolfpack with the WCF "Publisher" enabled (lets call this the Agent) and another instance (on another machine) with the WCF Service "Activity" enabled to receive the data (lets call this the Server).
  • On the "Server/Activity" instance open the activity.castle.config and find the component "WcfServiceHostConfig".
    • Set the "<Enabled>" property to "true"
    • Set the "<Uri>" property to the Http address desired. Beware that port 80 could be off-limits if IIS is installed on the machine.
    • Open the publisher.castle.config file and "Enable" any publisher you want the message republished to (eg: Sql, Growl).
    • Save the changes and restart Wolfpack
  • On the "Agent/Publisher" instance open the publisher.castle.config and find the component "WcfPublisherConfiguration".
    • Set the "<Enabled>" property to "true"
    • Set the "<Uri>" property to the same Http address of the WCF Service Activity instance
    • Save the changes and restart Wolfpack
  • Remember that you might need to open a port on any firewall that exists between the two machines.

NServiceBus

 
nsb.png

NServiceBus (NSB) is another way of "sending" monitoring data to another machine, this time via MSMQ. If the correct firewall ports are open you can have one Wolfpack (Agent) "publish" data direct to another Wolfpack (running the appropriate NSB message handlers). NSB also ships with a "Gateway" that allows you to send NSB/MSMQ messages via Http; whilst not as robust as direct MSMQ connections this does offer some deployment flexibility as only a single port is required.

Like WCF, this publisher requires an "Activity" to be enabled on the receiving Wolfpack instance (Server); this activity will set up NSB to listen for Wolfpack messages on MSMQ and then republish any that are received to the list of "Enabled" publishers.
  • On the "Server/Activity" instance open the activity.castle.config and find the component "BusBridgeConfig".
    • Set the "<Enabled>" property to "true"
    • Set the "<InputQueue>" property to the name of the MSMQ that will receive the messages from the "Agent" instance (eg: this should be the same value as used to set OutputQueue below).
    • Open the publisher.castle.config file and "Enable" any publisher you want the message republished to (eg: Sql, Growl).
    • Save the changes and restart Wolfpack
  • On the "Agent/Publisher" instance open the publisher.castle.config and find the component "BusPublisherConfig".
    • Set the "<Enabled>" property to "true"
    • Set the "<OutputQueue>" property to the same as that set in the "Agent" BusBridgeConfig.InputQueue config property.
    • Save the changes and restart Wolfpack
  • Remember that the correct MSMQ ports must be open on any firewall that exists between the two machines.
  • The format for the queue name when it is running on a remote machine is...
    • queue@machine
    • eg: WolfPackOutput@yourservername

Last edited Aug 17, 2012 at 7:52 AM by jimbobdog, version 10