Xymon client design (was Xymon is practically dead)
list TJ Yang
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 <user-6a0b8b0f0ae1@xymon.invalid> 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
-- T.J. Yang
list Jerald Sheets
Sent from my iPhone Please ignore spelling/grammar.
▸
On Jul 2, 2010, at 11:27 AM, TJ Yang <user-61afc885aa73@xymon.invalid> 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 <user-6a0b8b0f0ae1@xymon.invalid> 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...
tjTom-- 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 user-f970bfd1395f@xymon.invalid
list Henrik Størner
▸
On Fri, Jul 02, 2010 at 10:27:41AM -0500, TJ Yang wrote:
On Fri, Jul 2, 2010 at 9:44 AM, Tom Georgoulias <user-6a0b8b0f0ae1@xymon.invalid> 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
list TJ Yang
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 <user-ce4a2c883f75@xymon.invalid> 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 <user-6a0b8b0f0ae1@xymon.invalid> 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
--
T.J. Yang
list dOCtoR MADneSs
▸
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<user-ce4a2c883f75@xymon.invalid> 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 <user-6a0b8b0f0ae1@xymon.invalid> 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
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
list TJ Yang
▸
<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
-- T.J. Yang
list Jerald Sheets
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 <user-61afc885aa73@xymon.invalid> 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 suggestYes, 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-- T.J. Yang
list Stef Coene
▸
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 <user-6a0b8b0f0ae1@xymon.invalid> 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
list dOCtoR MADneSs
Le 02/07/2010 22:50, Jerald Sheets a écrit :
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 <user-61afc885aa73@xymon.invalid> wrote:
>Yes, there is xymon IRC created on freenode. But the problem is not
> 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
>
many people go there.
This M.L. has most xymon audience. Please don't be shy on sharing your
idea by email.
tj
>--
>
>
>
>
T.J. Yang
list Neil Franken
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:user-61afc885aa73@xymon.invalid]
Sent: 02 July 2010 05:28 PM
To: user-ae9b8668bcde@xymon.invalid; user-f970bfd1395f@xymon.invalid
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
<user-6a0b8b0f0ae1@xymon.invalid> 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
-- T.J. Yang
list Neil Franken
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:user-ce4a2c883f75@xymon.invalid]
Sent: 02 July 2010 05:56 PM
To: user-ae9b8668bcde@xymon.invalid; user-f970bfd1395f@xymon.invalid
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 <user-6a0b8b0f0ae1@xymon.invalid> 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
list Wiskbroom
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:user-ce4a2c883f75@xymon.invalid] Sent: 02 July 2010 05:56 PM To: user-ae9b8668bcde@xymon.invalid; user-f970bfd1395f@xymon.invalid 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