Hi all,
I have been presented with an 'interesting' problem in that I have been tasked with taking over the monitoring of a number machines (circa two dozen) that currently run Nagios clients (NRPE I guess but don't know for certain yet). I have been told that these machines have a few hundred (probably more like forty or fifty, but I don't know yet) separate checks that are performed by the Nagios client and the results passed back to the server. These Nagios checks work fine and have done so for a few years. The managers would prefer to keep the Nagios client up and running until I can provide them with a working, proven alternative.
I therefore have a few options open:
- Install my own Nagios server and run Hobbit and Nagios side-by-side. Not a good option by any means. Why have two different monitoring applications?
- Convert the Nagios scripts to Hobbit ones. This would likely entail running both monitoring clients on each machine and copying/rewriting the monitor scripts one at a time, checking the results with both Nagios and Hobbit to ensure that alerts and reports are happening correctly. Once all scripts are converted, remove the Nagios client. This has clear benefits but is naturally going to take time, and pain, and will require that I have two monitor consoles, albeit temporarily.
- Write a program that acts like a Hobbit proxy server, listening on the Nagios port and translating the Nagios reports and alerts in to Hobbit ones. This has benefits in that there will only be one bit of code to write, albeit a potentially large bit. I will have written the code so if it breaks I can fix it. The downside is that there is going to be a considerable amount of time involved in writing the proxy program and I will have to learn how Nagios packets are written and how the Hobbit proxy works.
- I see if anyone more able than I has done anything remotely like this that I can beg or borrow to use.
- Something else that I haven't thought of...
I thought I'd try option 4 first!
|\/|artin
--
Martin W. Ward
TAC Network Systems Team Leader
COLT
Unit 12, Powergate Business Park
Volt Avenue, Park Royal, London
NW10 6PW, United Kingdom
Tel: + 44 (0)20 7863 5218 Internal: 8 441 5218 Fax: + 44 (0)20 7863 5610 Email: martin.ward at colt.net www.colt.net
Data | Voice | Managed Services
The message is intended for the named addressee only and may not be disclosed to or used by anyone else, nor may it be copied in any way.
The contents of this message and its attachments are confidential and may also be subject to legal privilege. If you are not the named addressee and/or have received this message in error, please advise us by e-mailing security at colt.net and delete the message and any attachments without retaining any copies.
Internet communications are not secure and COLT does not accept responsibility for this message, its contents nor responsibility for any viruses.
No contracts can be created or varied on behalf of COLT Telecommunications, its subsidiaries or affiliates ("COLT") and any other party by email Communications unless expressly agreed in writing with such other party.
Please note that incoming emails will be automatically scanned to eliminate potential viruses and unsolicited promotional emails. For more information refer to www.colt.net or contact us on +44(0)20 7390 3900.
Or
- Modify Hobbit server to understand Nagios client data without modifications to the Nagios clients at all.
I like approach #3, but I think you will get it done faster doing #2.
/Thomas Kern /301-903-2211 (O) /301-905-6427 (M)
-----Original Message----- From: Ward, Martin [mailto:Martin.Ward at colt.net] Sent: Friday, November 07, 2008 11:17 To: hobbit at hswn.dk Subject: [hobbit] Nagios client, Hobbit server anyone?
Hi all,
I have been presented with an 'interesting' problem in that I have been tasked with taking over the monitoring of a number machines (circa two dozen) that currently run Nagios clients (NRPE I guess but don't know for certain yet). I have been told that these machines have a few hundred (probably more like forty or fifty, but I don't know yet) separate checks that are performed by the Nagios client and the results passed back to the server. These Nagios checks work fine and have done so for a few years. The managers would prefer to keep the Nagios client up and running until I can provide them with a working, proven alternative.
I therefore have a few options open:
- Install my own Nagios server and run Hobbit and Nagios side-by-side. Not a good option by any means. Why have two different monitoring applications?
- Convert the Nagios scripts to Hobbit ones. This would likely entail running both monitoring clients on each machine and copying/rewriting the monitor scripts one at a time, checking the results with both Nagios and Hobbit to ensure that alerts and reports are happening correctly. Once all scripts are converted, remove the Nagios client. This has clear benefits but is naturally going to take time, and pain, and will require that I have two monitor consoles, albeit temporarily.
- Write a program that acts like a Hobbit proxy server, listening on the Nagios port and translating the Nagios reports and alerts in to Hobbit ones. This has benefits in that there will only be one bit of code to write, albeit a potentially large bit. I will have written the code so if it breaks I can fix it. The downside is that there is going to be a considerable amount of time involved in writing the proxy program and I will have to learn how Nagios packets are written and how the Hobbit proxy works.
- I see if anyone more able than I has done anything remotely like this that I can beg or borrow to use.
- Something else that I haven't thought of...
I thought I'd try option 4 first!
|\/|artin
In <1F7B01020EC4D04DA17703634B9E888E09BFE567 at ULPGCTMVMAI003.EU.COLT> "Ward, Martin" <Martin.Ward at colt.net> writes:
- Write a program that acts like a Hobbit proxy server, listening on the N= agios port and translating the Nagios reports and alerts in to Hobbit ones.= This has benefits in that there will only be one bit of code to write, alb= eit a potentially large bit. I will have written the code so if it breaks I= can fix it. The downside is that there is going to be a considerable amoun= t of time involved in writing the proxy program and I will have to learn ho= w Nagios packets are written and how the Hobbit proxy works.
I've thought of that myself a couple of times - it would be useful if Hobbit could make use of some of the Nagios modules ("plugins", in Nagios speak).
But Nagios is very different from Hobbit. The network protocol used between the Nagios server and the clients is not documented (at least, not anywhere that Google can find for me), and it is also a "pull" type of protocol, where the Nagios server polls all of the clients to pick up data.
Doing a "pull" from the Hobbit server wouldn't be all that difficult, but it would have to mimick the behaviour of the Nagios server. And since I haven't found anything about how that works, it means digging into the Nagios server code and trying to figure it out from there. Or setting up a Nagios system and doing network traces. Both would take more time than I'd like :-/
Regards, Henrik
Hi Henrik,
- Write a program that acts like a Hobbit proxy server, listening on ...
I've thought of that myself a couple of times - it would be useful if Hobbit could make use of some of the Nagios modules ("plugins", in Nagios speak).
But Nagios is very different from Hobbit. The network protocol used between the Nagios server and the clients is not documented (at least, not anywhere that Google can find for me), and it is also a "pull" type of protocol, where the Nagios server polls all of the clients to pick up data.
Doing a "pull" from the Hobbit server wouldn't be all that difficult, but it would have to mimick the behaviour of the Nagios server. And since I haven't found anything about how that works, it means digging into the Nagios server code and trying to figure it out from there. Or setting up a Nagios system and doing network traces. Both would take more time than I'd like :-/
My thoughts were that this proxy server would do the pulling, effectively mimicking the Nagios server, then push the data on to the Hobbit server in a similar way to your bbproxy program. I had planned on cheating for the initial version. For those checks that use the NRPE plug-in the proxy would simply run the check_nrpe program passing it the parameters needed to execute the remote plug-in. It would then parse the return data and massage it into Hobbit-speak.
I took a look at the weekend but came up against a wall trying to extract the relevant code from bbproxy. I think the issue I was having was that bbproxy is heavily written to merge multiple packets from the client (combining) and send them on to the Hobbit server in one go. I just needed something that told me what the format of a bbproxy data packet looked like and how to send it to the main server.
Ah well, I will see if I can get access to a production Nagios server (the one I am supposed to be replacing) and see what info I can get from that.
|\/|artin
The message is intended for the named addressee only and may not be disclosed to or used by anyone else, nor may it be copied in any way.
The contents of this message and its attachments are confidential and may also be subject to legal privilege. If you are not the named addressee and/or have received this message in error, please advise us by e-mailing security at colt.net and delete the message and any attachments without retaining any copies.
Internet communications are not secure and COLT does not accept responsibility for this message, its contents nor responsibility for any viruses.
No contracts can be created or varied on behalf of COLT Telecommunications, its subsidiaries or affiliates ("COLT") and any other party by email Communications unless expressly agreed in writing with such other party.
Please note that incoming emails will be automatically scanned to eliminate potential viruses and unsolicited promotional emails. For more information refer to www.colt.net or contact us on +44(0)20 7390 3900.
In <1F7B01020EC4D04DA17703634B9E888E09BFE56D at ULPGCTMVMAI003.EU.COLT> "Ward, Martin" <Martin.Ward at colt.net> writes:
My thoughts were that this proxy server would do the pulling, effectively mimicking the Nagios server, then push the data on to the Hobbit server in a similar way to your bbproxy program. [snip] I took a look at the weekend but came up against a wall trying to extract the relevant code from bbproxy. I think the issue I was having was that bbproxy is heavily written to merge multiple packets from the client (combining) and send them on to the Hobbit server in one go. I just needed something that told me what the format of a bbproxy data packet looked like and how to send it to the main server.
I wouldn't mix bbproxy into this at all. Write a simpler tool to run the Nagios plugin, extract the relevant data from the output, and generate Hobbit-style status-messages. Then send these the usual way (either invoke the "bb" utility to do it, or if you link your program with the "libbbgen.a" library from Hobbit, then you can use Hobbit's "sendmessage()" routine.
Regards, Henrik
On þri, 2008-11-11 at 21:13 +0000, Henrik Størner wrote:
I wouldn't mix bbproxy into this at all. Write a simpler tool to run the Nagios plugin, extract the relevant data from the output, and generate Hobbit-style status-messages. Then send these the usual way (either invoke the "bb" utility to do it, or if you link your program with the "libbbgen.a" library from Hobbit, then you can use Hobbit's "sendmessage()" routine.
Regards, Henrik
Hi Henrik, I like Your idea. It seems that even admins tend to forget that running servers is a continuous task of many people. Let me for instance take the IT department of the University of Iceland. There are 8 (eight) people involved in system administration of many kinds of hardware and at least 5 kinds of Operating Systems. Each person has their own way of doing things, and some will not let other admins get access to the system they are administering. To get real quality control and quality assurance, the warning levels and alert levels must be reviewed at each incident. For this, it is necessary to have a centrally configured system controlled by the person responsible for monitoring Quality. Preferably, all admins have equal access to change the configuration, under quality assurance responsibility.
Exactly this is where Xymon stands out from the rest.
Technically, the central configuration is enabled by the bidirectional channel between Server and Client, the central configuration of the Client in the hobbit-client.cfg and client-local.cfg files.
If it is possible to control Nagios plugins by a central configuration, then this contributes to an even more versatile Xymon, by being able to use Xymon/Hobbit and BB addons and Nagios plugins.
I am not a PHB, but I know that the administration effort is their concern. Compared to BB, The administration of Xymon is much easier and has considerably better quality management because of the centralised configuration.
This is one of the strengths of Xymon, lets use it.
-- Anna Jonna Armannsdottir <annaj at hi.is> University of Iceland Computing Services
I took a look at the weekend but came up against a wall trying to extract the relevant code from bbproxy. I think the issue I was having was that bbproxy is heavily written to merge multiple packets from the client (combining) and send them on to the Hobbit server in one go. I just needed something that told me what the format of a bbproxy data packet looked like and how to send it to the main server.
I wouldn't mix bbproxy into this at all. Write a simpler tool to run the Nagios plugin, extract the relevant data from the output, and generate Hobbit-style status-messages. Then send these the usual way (either invoke the "bb" utility to do it, or if you link your program with the "libbbgen.a" library from Hobbit, then you can use Hobbit's "sendmessage()" routine.
Sorry Henrik, I didn't explain myself very well (or at all for that matter!).
I was looking at bbproxy's source to get some idea of how to proxy a message from one machine through another to the Hobbit server, the original intention being to strip your bbproxy code of everything that I didn't need and use what's left (with acknowledgements to you as the original author). However having looked at the bbproxy code I agree with you that doing so would be more difficult than actually writing the whole program myself.
Instead I will look at Hobbit's sendmessage() routine as you suggest and see if I can use that instead. It's really just the format of the packet when it contains proxied data that I need to understand.
|\/|artin
The message is intended for the named addressee only and may not be disclosed to or used by anyone else, nor may it be copied in any way.
The contents of this message and its attachments are confidential and may also be subject to legal privilege. If you are not the named addressee and/or have received this message in error, please advise us by e-mailing security at colt.net and delete the message and any attachments without retaining any copies.
Internet communications are not secure and COLT does not accept responsibility for this message, its contents nor responsibility for any viruses.
No contracts can be created or varied on behalf of COLT Telecommunications, its subsidiaries or affiliates ("COLT") and any other party by email Communications unless expressly agreed in writing with such other party.
Please note that incoming emails will be automatically scanned to eliminate potential viruses and unsolicited promotional emails. For more information refer to www.colt.net or contact us on +44(0)20 7390 3900.
Of course, also very interesting !
.. please go ahead .. :-)
martinOn Tue, 11 Nov 2008, Ward, Martin wrote:
Hi Henrik,
- Write a program that acts like a Hobbit proxy server, listening on ...
I've thought of that myself a couple of times - it would be useful if Hobbit could make use of some of the Nagios modules ("plugins", in Nagios speak).
But Nagios is very different from Hobbit. The network protocol used between the Nagios server and the clients is not documented (at least, not anywhere that Google can find for me), and it is also a "pull" type of protocol, where the Nagios server polls all of the clients to pick up data.
Doing a "pull" from the Hobbit server wouldn't be all that difficult, but it would have to mimick the behaviour of the Nagios server. And since I haven't found anything about how that works, it means digging into the Nagios server code and trying to figure it out from there. Or setting up a Nagios system and doing network traces. Both would take more time than I'd like :-/
My thoughts were that this proxy server would do the pulling, effectively mimicking the Nagios server, then push the data on to the Hobbit server in a similar way to your bbproxy program. I had planned on cheating for the initial version. For those checks that use the NRPE plug-in the proxy would simply run the check_nrpe program passing it the parameters needed to execute the remote plug-in. It would then parse the return data and massage it into Hobbit-speak.
I took a look at the weekend but came up against a wall trying to extract the relevant code from bbproxy. I think the issue I was having was that bbproxy is heavily written to merge multiple packets from the client (combining) and send them on to the Hobbit server in one go. I just needed something that told me what the format of a bbproxy data packet looked like and how to send it to the main server.
Ah well, I will see if I can get access to a production Nagios server (the one I am supposed to be replacing) and see what info I can get from that.
|\/|artin
The message is intended for the named addressee only and may not be disclosed to or used by anyone else, nor may it be copied in any way.
The contents of this message and its attachments are confidential and may also be subject to legal privilege. If you are not the named addressee and/or have received this message in error, please advise us by e-mailing security at colt.net and delete the message and any attachments without retaining any copies.
Internet communications are not secure and COLT does not accept responsibility for this message, its contents nor responsibility for any viruses.
No contracts can be created or varied on behalf of COLT Telecommunications, its subsidiaries or affiliates ("COLT") and any other party by email Communications unless expressly agreed in writing with such other party.
Please note that incoming emails will be automatically scanned to eliminate potential viruses and unsolicited promotional emails. For more information refer to www.colt.net or contact us on +44(0)20 7390 3900.
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
participants (5)
-
annaj＠hi.is
-
henrik＠hswn.dk
-
martin.flemming＠desy.de
-
Martin.Ward＠colt.net
-
Thomas.Kern＠hq.doe.gov