This project is read-only.

Configuring Publishers

MonitorWang "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)
  • The number of HealthChecks it is running
  • The names of the HealthChecks are running
  • A list of HealthChecks 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

New in version v1.0.4 is a feature called Result Publisher Filters - for more information on how to fine tune HealthCheck Result publication please take a look at that documention page.

Growl

 
growl.png

Growl is a fantastic system tray notification app - better explained here. MonitorWang can "publish" to a local instance of Growl - that is Growl running on the same machine as MonitorWang. 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 an iPhone! There are various applications that let you forward notifications to your iPhone, I personally use Prowl (iTunes App).

UPDATE New in v1.0.5 are 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 MonitorWang 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 MonitorWang 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 MonitorWang to pick the change up

SQLite

 
db.png

It would be useful to record MonitorWang 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 MonitorWang 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 - MonitorWang is smart enough to work out if its an actual connection string or a reference to one!
    • Save the changes and restart MonitorWang

SqlServer

 
db.png

It would be useful to record MonitorWang 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 MonitorWang starts if you have Enabled the SqlServer publisher.
  • Ensure the database/table has the right permissions for the user you are running MonitorWang 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 - MonitorWang is smart enough to work out if its an actual connection string or a reference to one!
    • Save the changes and restart MonitorWang

WCF

 
wcf.png


For situations where you need to "send" the monitoring information to another machine (MonitorWang instance) over Http, this is the publisher for you. This publisher is specifically designed for the scenario where you are running multiple MonitorWang 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 MonitorWang 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 MonitorWang 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 MonitorWang
  • 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 MonitorWang
  • 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 MonitorWang (Agent) "publish" data direct to another MonitorWang (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 MonitorWang instance (Server); this activity will set up NSB to listen for MonitorWang 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 (this is the NSB publishers Output Queue.
    • Open the publisher.castle.config file and "Enable" any publisher you want the message republished to (eg: Sql, Growl).
    • Save the changes and restart MonitorWang
  • 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 MonitorWang
  • Remember that the correct MSMQ ports must be open on any firewall that exists between the two machines.

Last edited Mar 1, 2011 at 9:30 PM by jimbobdog, version 26

Comments

hugorodgerbrown May 12, 2011 at 11:32 AM 
Is there a Publisher development 101 class - I would like to create a HipChat publisher to push certain messages to HipChat. It's not entirely obvious how I begin :-S