Xymon client design (was Xymon is practically dead)
Hi, Tom
Hope you don't mind I changed the subject and cc to hobbitmon-developer on this topic.
On Fri, Jul 2, 2010 at 9:44 AM, Tom Georgoulias <tomg at mcclatchyinteractive.com> wrote:
On 07/02/2010 05:47 AM, Neil Franken wrote:
Xymon is just one part of the equation for me. I see a lot of potential for Xymon in the Windows world but the BBWin client is well a very quiet project as well. I am not sure yet if we would maybe fork the code or create a new client. At this point I would suggest that maybe we look at a Java based client for xymon so we can run on a huge variety of platforms with one client. Anyway the whole client is a whole different ball game.
I would not be in favor of a java based client, the current design is much better on unix systems. It's one of the reasons xymon works well.
I can understand why Neil has this idea, it flashed in brain before. Why not write once and run every where ? The idea is good but there is resources needed to convert hobbit client into java. Who are going to do it ?
Back to the existing hobbit client implementation.
I do have concerns about hobbitclient-OS??.sh shell script's programming style. There is no check return status of system command it call and there is no error handling when system command faild. I got many purple alert when one of the system command failed or didn't finish in time.
tj
Tom
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
-- T.J. Yang
Sent from my iPhone Please ignore spelling/grammar.
On Jul 2, 2010, at 11:27 AM, TJ Yang <tjyang2001 at gmail.com> wrote:
Hi, Tom
Hope you don't mind I changed the subject and cc to hobbitmon-developer on this topic.
On Fri, Jul 2, 2010 at 9:44 AM, Tom Georgoulias <tomg at mcclatchyinteractive.com> wrote:
On 07/02/2010 05:47 AM, Neil Franken wrote:
Xymon is just one part of the equation for me. I see a lot of potential for Xymon in the Windows world but the BBWin client is well a very quiet project as well. I am not sure yet if we would maybe fork the code or create a new client. At this point I would suggest that maybe we look at a Java based client for xymon so we can run on a huge variety of platforms with one client. Anyway the whole client is a whole different ball game.
I would not be in favor of a java based client, the current design is much better on unix systems. It's one of the reasons xymon works well.
I can understand why Neil has this idea, it flashed in brain before. Why not write once and run every where ? The idea is good but there is resources needed to convert hobbit client into java. Who are going to do it ?
Back to the existing hobbit client implementation.
I do have concerns about hobbitclient-OS??.sh shell script's programming style. There is no check return status of system command it call and there is no error handling when system command faild. I got many purple alert when one of the system command failed or didn't finish in time.
This looks like a job for the bug tracker!
Seriously... While we're brainstorming like this, we shoul be capturing it all somewhere besides email, whether some project management tool, bugzilla, or whatever...
tj
Tom
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
-- T.J. Yang
This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
Hobbitmon-developer mailing list Hobbitmon-developer at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hobbitmon-developer
On Fri, Jul 02, 2010 at 10:27:41AM -0500, TJ Yang wrote:
On Fri, Jul 2, 2010 at 9:44 AM, Tom Georgoulias <tomg at mcclatchyinteractive.com> wrote:
On 07/02/2010 05:47 AM, Neil Franken wrote:
Xymon is just one part of the equation for me. I see a lot of potential for Xymon in the Windows world but the BBWin client is well a very quiet project as well. I am not sure yet if we would maybe fork the code or create a new client. At this point I would suggest that maybe we look at a Java based client for xymon so we can run on a huge variety of platforms with one client. Anyway the whole client is a whole different ball game.
I would not be in favor of a java based client, the current design is much better on unix systems. It's one of the reasons xymon works well.
I can understand why Neil has this idea, it flashed in brain before. Why not write once and run every where ?
One very simple reason: The client needs to know about the specifics of the operating system it is running on - that's the whole purpose of having a client! Java tries very hard to isolate the underlying OS from the apps running inside the JVM, which runs counter to this.
In other words - when you want to report on metrics specific to the OS, it doesn't really make sense to use an OS-agnostic tool.
Another reason is that the client shouldn't require a lot of additional software besides what comes with the OS. And the output from the OS-specific tools will be well known to the admins who are going to use the data from Xymon.
Regards, Henrik
How about P.M. tool like this http://code.google.com/p/xymon/ ?
tj
On Fri, Jul 2, 2010 at 10:56 AM, Henrik Størner <henrik at hswn.dk> wrote:
On Fri, Jul 02, 2010 at 10:27:41AM -0500, TJ Yang wrote:
On Fri, Jul 2, 2010 at 9:44 AM, Tom Georgoulias <tomg at mcclatchyinteractive.com> wrote:
On 07/02/2010 05:47 AM, Neil Franken wrote:
Xymon is just one part of the equation for me. I see a lot of potential for Xymon in the Windows world but the BBWin client is well a very quiet project as well. I am not sure yet if we would maybe fork the code or create a new client. At this point I would suggest that maybe we look at a Java based client for xymon so we can run on a huge variety of platforms with one client. Anyway the whole client is a whole different ball game.
I would not be in favor of a java based client, the current design is much better on unix systems. It's one of the reasons xymon works well.
I can understand why Neil has this idea, it flashed in brain before. Why not write once and run every where ?
One very simple reason: The client needs to know about the specifics of the operating system it is running on - that's the whole purpose of having a client! Java tries very hard to isolate the underlying OS from the apps running inside the JVM, which runs counter to this.
In other words - when you want to report on metrics specific to the OS, it doesn't really make sense to use an OS-agnostic tool.
Another reason is that the client shouldn't require a lot of additional software besides what comes with the OS. And the output from the OS-specific tools will be well known to the admins who are going to use the data from Xymon.
Regards, Henrik
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
-- T.J. Yang
Le 02/07/2010 18:17, TJ Yang a écrit :
How about P.M. tool like this http://code.google.com/p/xymon/ ?
tj
On Fri, Jul 2, 2010 at 10:56 AM, Henrik Størner<henrik at hswn.dk> wrote:
On Fri, Jul 02, 2010 at 10:27:41AM -0500, TJ Yang wrote:
On Fri, Jul 2, 2010 at 9:44 AM, Tom Georgoulias <tomg at mcclatchyinteractive.com> wrote:
On 07/02/2010 05:47 AM, Neil Franken wrote:
Xymon is just one part of the equation for me. I see a lot of potential for Xymon in the Windows world but the BBWin client is well a very quiet project as well. I am not sure yet if we would maybe fork the code or create a new client. At this point I would suggest that maybe we look at a Java based client for xymon so we can run on a huge variety of platforms with one client. Anyway the whole client is a whole different ball game.
I would not be in favor of a java based client, the current design is much better on unix systems. It's one of the reasons xymon works well.
I can understand why Neil has this idea, it flashed in brain before. Why not write once and run every where ?
One very simple reason: The client needs to know about the specifics of the operating system it is running on - that's the whole purpose of having a client! Java tries very hard to isolate the underlying OS from the apps running inside the JVM, which runs counter to this.
In other words - when you want to report on metrics specific to the OS, it doesn't really make sense to use an OS-agnostic tool.
Another reason is that the client shouldn't require a lot of additional software besides what comes with the OS. And the output from the OS-specific tools will be well known to the admins who are going to use the data from Xymon.
Regards, Henrik
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
Hi,
Is there an IRC channel, a forum or something more "live" than ML to discuss about xymon project ? I've some ideas, maybe stupids, that I could suggest
<snip>
Hi,
Is there an IRC channel, a forum or something more "live" than ML to discuss about xymon project ? I've some ideas, maybe stupids, that I could suggest
Yes, there is xymon IRC created on freenode. But the problem is not many people go there. This M.L. has most xymon audience. Please don't be shy on sharing your idea by email.
tj
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
-- T.J. Yang
Definitely.
When you share on email, everyone benefits today, tomorrow, and forever because all the conversation and history gets saved in the archive. Things that pass by on the IRC never get seen again unless someone makes the time to clip it out of the IRC window and save it to disk somewhere.
Jerald M. Sheets jr.
On Fri, Jul 2, 2010 at 4:27 PM, TJ Yang <tjyang2001 at gmail.com> wrote:
<snip>
Hi,
Is there an IRC channel, a forum or something more "live" than ML to
discuss
about xymon project ? I've some ideas, maybe stupids, that I could suggest
Yes, there is xymon IRC created on freenode. But the problem is not many people go there. This M.L. has most xymon audience. Please don't be shy on sharing your idea by email.
tj
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
-- T.J. Yang
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
An HTML attachment was scrubbed... URL: <http://lists.xymon.com/pipermail/xymon/attachments/20100702/29e1201f/attachment.html>
Hi Henrik
Agreed. However I have done some experimenting with a package called JCrontab. It is a scheduler and what I do is schedule VBS scripts and other exe to run via this scheduler. The scheduler runs the scripts/program and reads from the standard io . Since all my scripts/exe write to the standard io I can return OS specific information to the Java application which in turn open a socket and writes to Xymon. It is very simple and extensible. Anyway just a thought. The more ideas we have to discuss the better.
Regards Neil
-----Original Message----- From: Henrik Størner [mailto:henrik at hswn.dk] Sent: 02 July 2010 05:56 PM To: hobbit at hswn.dk; hobbitmon-developer at lists.sourceforge.net Subject: [hobbit] Re: [Hobbitmon-developer] Xymon client design (was Xymon is practically dead)
On Fri, Jul 02, 2010 at 10:27:41AM -0500, TJ Yang wrote:
On Fri, Jul 2, 2010 at 9:44 AM, Tom Georgoulias <tomg at mcclatchyinteractive.com> wrote:
On 07/02/2010 05:47 AM, Neil Franken wrote:
Xymon is just one part of the equation for me. I see a lot of potential for Xymon in the Windows world but the BBWin client is well a very quiet project as well. I am not sure yet if we would maybe fork the code or create a new client. At this point I would suggest that maybe we look at a Java based client for xymon so we can run on a huge variety of platforms with one client. Anyway the whole client is a whole different ball game.
I would not be in favor of a java based client, the current design is much better on unix systems. It's one of the reasons xymon works well.
I can understand why Neil has this idea, it flashed in brain before. Why not write once and run every where ?
One very simple reason: The client needs to know about the specifics of the operating system it is running on - that's the whole purpose of having a client! Java tries very hard to isolate the underlying OS from the apps running inside the JVM, which runs counter to this.
In other words - when you want to report on metrics specific to the OS, it doesn't really make sense to use an OS-agnostic tool.
Another reason is that the client shouldn't require a lot of additional software besides what comes with the OS. And the output from the OS-specific tools will be well known to the admins who are going to use the data from Xymon.
Regards, Henrik
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
Neil;
Great tool, but it is java based...
.vp
Hi Henrik
Agreed. However I have done some experimenting with a package called JCrontab. It is a scheduler and what I do is schedule VBS scripts and other exe to run via this scheduler. The scheduler runs the scripts/program and reads from the standard io . Since all my scripts/exe write to the standard io I can return OS specific information to the Java application which in turn open a socket and writes to Xymon. It is very simple and extensible. Anyway just a thought. The more ideas we have to discuss the better.
Regards Neil
-----Original Message----- From: Henrik Størner [mailto:henrik at hswn.dk] Sent: 02 July 2010 05:56 PM To: hobbit at hswn.dk; hobbitmon-developer at lists.sourceforge.net Subject: [hobbit] Re: [Hobbitmon-developer] Xymon client design (was Xymon is practically dead)
On Fri, Jul 02, 2010 at 10:27:41AM -0500, TJ Yang wrote:
On Fri, Jul 2, 2010 at 9:44 AM, Tom Georgoulias wrote:
On 07/02/2010 05:47 AM, Neil Franken wrote:
Xymon is just one part of the equation for me. I see a lot of potential for Xymon in the Windows world but the BBWin client is well a very quiet project as well. I am not sure yet if we would maybe fork the code or create a new client. At this point I would suggest that maybe we look at a Java based client for xymon so we can run on a huge variety of platforms with one client. Anyway the whole client is a whole different ball game.
I would not be in favor of a java based client, the current design is much better on unix systems. It's one of the reasons xymon works well.
I can understand why Neil has this idea, it flashed in brain before. Why not write once and run every where ?
One very simple reason: The client needs to know about the specifics of the operating system it is running on - that's the whole purpose of having a client! Java tries very hard to isolate the underlying OS from the apps running inside the JVM, which runs counter to this.
In other words - when you want to report on metrics specific to the OS, it doesn't really make sense to use an OS-agnostic tool.
Another reason is that the client shouldn't require a lot of additional software besides what comes with the OS. And the output from the OS-specific tools will be well known to the admins who are going to use the data from Xymon.
Regards, Henrik
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
On Friday 02 July 2010, TJ Yang wrote:
Hi, Tom
Hope you don't mind I changed the subject and cc to hobbitmon-developer on this topic.
On Fri, Jul 2, 2010 at 9:44 AM, Tom Georgoulias
<tomg at mcclatchyinteractive.com> wrote:
On 07/02/2010 05:47 AM, Neil Franken wrote:
Xymon is just one part of the equation for me. I see a lot of potential for Xymon in the Windows world but the BBWin client is well a very quiet project as well. I am not sure yet if we would maybe fork the code or create a new client. At this point I would suggest that maybe we look at a Java based client for xymon so we can run on a huge variety of platforms with one client. Anyway the whole client is a whole different ball game.
I would not be in favor of a java based client, the current design is much better on unix systems. It's one of the reasons xymon works well. Indeed. I vote against a java based client. Xymon is fast and light. Java is bloaded and slow. (I know people will say java can be small and fast, but I never found a fast and small java application). Me, as a sysadmin will not allow a java environment installed just for running a basic monitoring client if that client is now a simple shell script and a simple C program.
I can understand the need for a java client for the more uncommon OS'es, but don't make it the only available client for linux / unix / windows.
I do have concerns about hobbitclient-OS??.sh shell script's programming style. There is no check return status of system command it call and there is no error handling when system command faild. I got many purple alert when one of the system command failed or didn't finish in time. That's easy to solve. Just update the scripts and add some error trapping. I can do that if needed. But I never had the need because I never had a purple alert because some system command gave an error.
Stef
Hi Tom
Java based client would only be for Windows, Mac-OS the unix one is perfect. Just thinking that a java project is not tied down to windows specifics like the bbwin problem we have. A Eclipse project will run in netbeans, jbuilder et with minimal effort. Since BBWin is just really a socket client with a timer thread I can do a Java client with minimal effort. Anyway just a idea we don't have to act on it.
Regards Neil
-----Original Message----- From: TJ Yang [mailto:tjyang2001 at gmail.com] Sent: 02 July 2010 05:28 PM To: hobbit at hswn.dk; hobbitmon-developer at lists.sourceforge.net Subject: [hobbit] Xymon client design (was Xymon is practically dead)
Hi, Tom
Hope you don't mind I changed the subject and cc to hobbitmon-developer on this topic.
On Fri, Jul 2, 2010 at 9:44 AM, Tom Georgoulias <tomg at mcclatchyinteractive.com> wrote:
On 07/02/2010 05:47 AM, Neil Franken wrote:
Xymon is just one part of the equation for me. I see a lot of potential for Xymon in the Windows world but the BBWin client is well a very quiet project as well. I am not sure yet if we would maybe fork the code or create a new client. At this point I would suggest that maybe we look at a Java based client for xymon so we can run on a huge variety of platforms with one client. Anyway the whole client is a whole different ball game.
I would not be in favor of a java based client, the current design is much better on unix systems. It's one of the reasons xymon works well.
I can understand why Neil has this idea, it flashed in brain before. Why not write once and run every where ? The idea is good but there is resources needed to convert hobbit client into java. Who are going to do it ?
Back to the existing hobbit client implementation.
I do have concerns about hobbitclient-OS??.sh shell script's programming style. There is no check return status of system command it call and there is no error handling when system command faild. I got many purple alert when one of the system command failed or didn't finish in time.
tj
Tom
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
-- T.J. Yang
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
participants (7)
-
doctor＠makelofine.org
-
henrik＠hswn.dk
-
nfranken＠theunlimitedworld.co.za
-
questy＠gmail.com
-
stef.coene＠docum.org
-
tjyang2001＠gmail.com
-
wiskbroom＠hotmail.com