need advice 🔗 link

Ok, I'm writing a couple of custom monitors for some tasks at the office.  These can be either client or server scripts and can easily be scripted either way.  What would you recommend for server versus client extensions?  What criteria would you use to decide?  Some guidelines would be helpful for determining which type of script to pursue.

=G=

My 2 cents:

I'd use server side if I were you because that way you can have a
centralised configuration file so if you need to change the behaviour of
the script it's easy, that's why I'm going to convert all our existing
scripts to server-side (where possible).  The only time you wouldn't I
guess is if the test is specialised for a small number of systems (like
a backup script) or it's results will be specific to that server alone.

Thanks,
Jason.

-----Original Message-----
From: Galen Johnson [mailto:user-d2ff723b6cb6@xymon.invalid] Sent: 10 April 2007 02:06
To: user-ae9b8668bcde@xymon.invalid
Subject: [hobbit] need advice

Ok, I'm writing a couple of custom monitors for some tasks at the office.  These can be either client or server scripts and can easily be scripted either way.  What would you recommend for server versus client extensions?  What criteria would you use to decide?  Some guidelines would be helpful for determining which type of script to pursue.

=G=

Galen Johnson wrote:

I think the biggest challenge is managing the script configurations, if you have multiple servers and need to keep the script in sync across all of them, or find that you need to have subtle variations in each of the scripts on the clients.

If you have a configuration management system such as cfengine, where you can easily manage remote client configurations from a central location, then a client side script isn't an issue.  If you don't, having the script run as a server side script is much easier to manage and change as needed.

Tom
-- 
Tom Georgoulias
Systems Engineer
McClatchy Interactive
user-6a0b8b0f0ae1@xymon.invalid

My advice is if the custom monitor works for more than 1 client, put it
on the server to centralize it. When it needs to be changed, change it
once on the server and all the client displays get properly changed. 
Now if you need to add data to the client-data stream, you will have to
modify the real hobbit-client script to include the new data, but do it
so that it can run on all clients even if the data is not available on
some client. Then use the server-side processing of client-data to do
the analysis, reporting, alerting and rrdtool updates.

I have a TSM backup reporting script that I run on some of my clients,
but after 4.3 comes out, I will work on including the TSM status data in
the client-data stream and modify the server to analyze it and report on
it.

/Thomas Kern
/XXX-XXX-XXXX  

Galen Johnson wrote :

Hi,

I tend to write server-side scripts whenever possible. It prevents
people from slightly changing scripts without notice. It sometimes is
handy to have both server-side and client-side (reporting the exact same
information). For instance, I can monitor most database server remotely,
but some customers don't like the idea of remote access. So the script
runs locally (and gets its config from the hobbit server).

Regards,

-- 
Charles Goyard - user-a6cdca7046e2@xymon.invalid - (+33) 1 45 38 01 31

Galen Johnson wrote:

Thanks for all the input...


=G=