From ingvar at hexapodia.net Wed Jul 2 08:18:46 2008 From: ingvar at hexapodia.net (Ingvar) Date: Wed, 02 Jul 2008 09:18:46 +0100 Subject: [noctool-devel] W00t, I think Message-ID: I've integrated the networking code into the rest of teh code base (it was a bit chunkier than expected) and have carefully intervowen tis wit the rest. Things are compiling cleanly, I think (will have to do another test) and unless there are objections, I am feeling fairly ready to check the whole chunk in. Yes, it touches scarily many parts of the code-base outside the "network*.lisp" files (hooks into the scheduler, into the graphing and a few more places). Shouldn't make a blind bit of difference unless you have network connections. //Ingvar From ingvar at hexapodia.net Thu Jul 3 08:00:08 2008 From: ingvar at hexapodia.net (Ingvar) Date: Thu, 03 Jul 2008 09:00:08 +0100 Subject: [noctool-devel] Re: [noctool-cvs] CVS source [ network update ] In-Reply-To: <20080703073024.DAD38751B3@common-lisp.net> References: <20080703073024.DAD38751B3@common-lisp.net> Message-ID: > Update of /project/noctool/cvsroot/source > In directory clnet:/tmp/cvs-serv14870 > > Modified Files: > classes.lisp graphing.lisp network-globals.lisp > network-utils.lisp network.lisp noctool.asd packages.lisp > scheduler.lisp tests.lisp > Log Message: > IM > > Bulk update of (mostly) network-code-related changes. > There's one change that pertains to graph code (setting the last-updated > field). Fair chunk of update. It is my belief that the network code should now work (more or less) and is ready to be played with. The general idea is "request a list of objects for a specific class to get the IDs you need to subscribe to", "subscribing to a piece of equipment gets updates for all the monitors", "if you want graph data you have to subscribe to the graph" and "you get updates until you unsubscribe". I'll try to get something on the hacking page, in the next week-or-so. //Ingvar From download at hpc.unm.edu Mon Jul 7 15:00:30 2008 From: download at hpc.unm.edu (Jim Prewett) Date: Mon, 7 Jul 2008 09:00:30 -0600 (MDT) Subject: [noctool-devel] network-remote-calls.lisp Message-ID: Hi Ingvar, I think you forgot to add network-remote-calls.lisp to the CVS repository. noctool.asd now says that it needs this file - I'm assuming this is merely an oversight. Thanks, Jim James E. Prewett Jim at Prewett.org download at hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210 From ingvar at hexapodia.net Wed Jul 9 15:05:00 2008 From: ingvar at hexapodia.net (Ingvar) Date: Wed, 09 Jul 2008 16:05:00 +0100 Subject: [noctool-devel] Re: [noctool-cvs] CVS source In-Reply-To: <20080709144007.3DF9E1F00E@common-lisp.net> References: <20080709144007.3DF9E1F00E@common-lisp.net> Message-ID: > Modified Files: > scheduler.lisp classes.lisp > Log Message: > > moved :BEFORE PROCESS method for EVENT class into scheduler.lisp Noooo! Now it won't compile from a clean image (the class definitions in classes.lisp provide the definition of the PROXIES generic, that's not available at the time scheduler.lisp is compiled). Yes, I found this the hard way (as I needed to have two images running to test the network code) and the non-SLIME kept breaking on load. Probably should've been a bit more clearer on why things were done as they were. One way would be to split "classes.lisp" into "classes.lisp" and "methods.lisp" and have scheduler.lisp depend on classes.lisp and do the PROCESS :BEFORE method definition in scheduler.lisp and the rest of the stuff in classes.lisp in methods.lisp. Alternatively, re-jigger the ASDF definition to have schedler.lisp depend on classes.lisp. //Ingvar From download at hpc.unm.edu Wed Jul 9 15:57:05 2008 From: download at hpc.unm.edu (Jim Prewett) Date: Wed, 9 Jul 2008 09:57:05 -0600 (MDT) Subject: [noctool-devel] Re: [noctool-cvs] CVS source In-Reply-To: References: <20080709144007.3DF9E1F00E@common-lisp.net> Message-ID: AAARRRRRGGGGGHHHHHH !!!! SORRY about that! > Noooo! Now it won't compile from a clean image (the class definitions in > classes.lisp provide the definition of the PROXIES generic, that's not > available at the time scheduler.lisp is compiled). Yes, I found this the > hard way (as I needed to have two images running to test the network > code) and the non-SLIME kept breaking on load. Probably should've been a > bit more clearer on why things were done as they were. I was having the opposite problem of the event class not existing when the classes.lisp was loaded. There is some sort of dependency tangle :P FWIW, I seem to be able to > Alternatively, re-jigger the ASDF definition to have schedler.lisp depend on > classes.lisp. I don't particularly care... I just want (require :noctool) to work ;P :) Jim From ingvar at hexapodia.net Wed Jul 9 16:11:21 2008 From: ingvar at hexapodia.net (Ingvar) Date: Wed, 09 Jul 2008 17:11:21 +0100 Subject: [noctool-devel] Re: [noctool-cvs] CVS source In-Reply-To: References: <20080709144007.3DF9E1F00E@common-lisp.net> Message-ID: Jim writes: > AAARRRRRGGGGGHHHHHH !!!! > > SORRY about that! No worries. > > Noooo! Now it won't compile from a clean image (the class definitions in > > classes.lisp provide the definition of the PROXIES generic, that's not > > available at the time scheduler.lisp is compiled). Yes, I found this the > > hard way (as I needed to have two images running to test the network > > code) and the non-SLIME kept breaking on load. Probably should've been a > > bit more clearer on why things were done as they were. > > I was having the opposite problem of the event class not existing when > the classes.lisp was loaded. There is some sort of dependency tangle :P > > FWIW, I seem to be able to Hm. Odd... I suspect the inclusion of the network files into the main ASDF definition re-jiggered the order. Because now it works and before I merged the network stuff into the main ASDF it didn't. > > Alternatively, re-jigger the ASDF definition to have schedler.lisp depend on > > classes.lisp. > > I don't particularly care... I just want (require :noctool) to work ;P :) It seems to be working, barring a slightly annoying compilation error for SPLIT-SEQUENCE (probably SBCL-version-dependent, as the warning I get is: The class SB-PRETTY:PRETTY-STREAM was not changed, and there's no guarantee that the loaded code (which expected another layout) will work. Let's leave things as they are, for now, since it actually seems to work (not that I understand why, but my head if mostly full of network audits at the moment). //Ingvar From download at hpc.unm.edu Wed Jul 9 16:42:21 2008 From: download at hpc.unm.edu (Jim Prewett) Date: Wed, 9 Jul 2008 10:42:21 -0600 (MDT) Subject: [noctool-devel] Re: [noctool-cvs] CVS source In-Reply-To: References: <20080709144007.3DF9E1F00E@common-lisp.net> Message-ID: > It seems to be working, barring a slightly annoying compilation error for > SPLIT-SEQUENCE (probably SBCL-version-dependent, as the warning I get is: > The class SB-PRETTY:PRETTY-STREAM was not changed, and there's no guarantee > that the loaded code (which expected another layout) will work. I *THINK* this is an error related to SBCL + SLIME. I've seen this before (not with noctool, but other packages) where when some package is compiled under SLIME and loaded not under slime or vice-versa this error pops up. Try recompiling all of your sources and see if you still get this (very obnoxious) error. > > Let's leave things as they are, for now, since it actually seems to work (not > that I understand why, but my head if mostly full of network audits at the > moment). Yeah... I'm not awake enough yet to grok it fully either ;P ttyl, Jim From ingvar at hexapodia.net Sat Jul 12 18:55:20 2008 From: ingvar at hexapodia.net (Ingvar) Date: Sat, 12 Jul 2008 19:55:20 +0100 Subject: [noctool-devel] Re: NOCtool and SNMP In-Reply-To: <7A7B2254-9610-4754-8529-0E62D210F553@gmail.com> References: <7A7B2254-9610-4754-8529-0E62D210F553@gmail.com> Message-ID: Chun Tian writes: [ I have CCd the noctool-devel mailing list ] > Hi, Ingvar Mattsson > > I'm a UNIX system administrator and Lisp programmer in China. > > Recently I saw your NOCtool project [1] on common-lisp.net. I also > want to build such a package for monitor my UNIX servers. My plan is > write a pure lisp SNMP client first, then IPMI client, then other > monitoring support (HTTP, Ping, ...), finally build a Web server on cl- > http and add graph drawing facility. > > It seems that your project already done the later part of my plan:) Yeah, it's slowly getting there and I was looking at SNMP packages a while back, since I can see that having (some sort of) SNMP support would make it much easier monitoring some types of equipment. > Now I have a working SNMP client (even server) package[2]. For this > project, I also write a USOCKET UDP patch and LispWorks UDP support. > If your're still interesting in improve your package to monitor more > things, you may want to see my work. > > The SNMP package is on SVN: (tested on LispWorks, other CLs maybe need > small fixes) > > https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/trunk > > The USOCKET UDP patch (as an ASDF package, waiting USOCKET author > merge it): > > https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/usocket-udp/trunk > > The IPMI package (still under development, not usable) > > https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/ipmi/trunk Cool. Are the packages in such a stage that it would make sense to package them up so ASDF-INSTALL can grab and build them? From what I can tell, what's needed is an ASDF system definition file, a tar-ball with the relevant source files and an entry in CLiki. //Ingvar From binghe.lisp at gmail.com Sun Jul 13 05:13:37 2008 From: binghe.lisp at gmail.com (Chun Tian (binghe)) Date: Sun, 13 Jul 2008 13:13:37 +0800 Subject: [noctool-devel] Re: NOCtool and SNMP In-Reply-To: References: <7A7B2254-9610-4754-8529-0E62D210F553@gmail.com> Message-ID: > >> Now I have a working SNMP client (even server) package[2]. For this >> project, I also write a USOCKET UDP patch and LispWorks UDP support. >> If your're still interesting in improve your package to monitor more >> things, you may want to see my work. >> >> The SNMP package is on SVN: (tested on LispWorks, other CLs maybe >> need >> small fixes) >> >> https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/ >> trunk >> >> The USOCKET UDP patch (as an ASDF package, waiting USOCKET author >> merge it): >> >> https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/usocket-udp/trunk >> >> The IPMI package (still under development, not usable) >> >> https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/ipmi/ >> trunk > > Cool. Are the packages in such a stage that it would make sense to > package > them up so ASDF-INSTALL can grab and build them? From what I can > tell, what's > needed is an ASDF system definition file, a tar-ball with the > relevant source > files and an entry in CLiki. No problem, I'll soon package them up and upload to my space on common- lisp.net. When I'm done, I'll notice you again. By the way, what is your main development CL platform? I'll consider fix it first. > > > //Ingvar > From download at hpc.unm.edu Sun Jul 13 11:08:36 2008 From: download at hpc.unm.edu (Jim Prewett) Date: Sun, 13 Jul 2008 05:08:36 -0600 (MDT) Subject: [noctool-devel] Re: NOCtool and SNMP In-Reply-To: References: <7A7B2254-9610-4754-8529-0E62D210F553@gmail.com> Message-ID: Hello, For NOCtool, we're targeting SBCL primarily. Jim James E. Prewett Jim at Prewett.org download at hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210 On Sun, 13 Jul 2008, Chun Tian (binghe) wrote: > > > > > Now I have a working SNMP client (even server) package[2]. For this > > > project, I also write a USOCKET UDP patch and LispWorks UDP support. > > > If your're still interesting in improve your package to monitor more > > > things, you may want to see my work. > > > > > > The SNMP package is on SVN: (tested on LispWorks, other CLs maybe need > > > small fixes) > > > > > > https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/trunk > > > > > > The USOCKET UDP patch (as an ASDF package, waiting USOCKET author > > > merge it): > > > > > > https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/usocket-udp/trunk > > > > > > The IPMI package (still under development, not usable) > > > > > > https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/ipmi/trunk > > > > Cool. Are the packages in such a stage that it would make sense to package > > them up so ASDF-INSTALL can grab and build them? From what I can tell, > > what's > > needed is an ASDF system definition file, a tar-ball with the relevant > > source > > files and an entry in CLiki. > > No problem, I'll soon package them up and upload to my space on common- > lisp.net. When I'm done, I'll notice you again. > > By the way, what is your main development CL platform? I'll consider fix it > first. > > > > > > > //Ingvar > > > > _______________________________________________ > noctool-devel mailing list > noctool-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/noctool-devel > From binghe.lisp at gmail.com Sun Jul 13 15:16:33 2008 From: binghe.lisp at gmail.com (Chun Tian (binghe)) Date: Sun, 13 Jul 2008 23:16:33 +0800 Subject: [noctool-devel] Re: NOCtool and SNMP In-Reply-To: References: <7A7B2254-9610-4754-8529-0E62D210F553@gmail.com> Message-ID: <1F2E3C8F-5459-4627-BAF7-9885904DD3C8@gmail.com> Hi, Ingvar Now you can ASDF-install my SNMP package. I've fixed it under SBCL/ CMUCL/Clozure CL today Call this: * (asdf-install:install :snmp) should work, I test it and seems good. But you should use USOCKET 0.4 branch or trunk, current release version (0.3.x) doesn't have DATADRAM class and WAIT-FOR-INPUT support, cannot fit SNMP package. No document yet, but I can give you two example usage: * (snmp:snmp-walk "localhost" '(#(1 3 6 1 2 1 1))) (((# "Linux debian-amd64 2.6.24-1-amd64 #1 SMP Sat May 10 09:28:10 UTC 2008 x86_64") (# #) (# #) (# "Root (configure /etc/snmp/snmpd.local.conf)") (# "debian-amd64") (# "Unknown (configure /etc/snmp/snmpd.local.conf)") ... * (snmp:with-open-session (s "localhost" :version snmp:+snmp-version-2c+ :community "public") (snmp:snmp-get s '(#(1 3 6 1 2 1 1 1 0) #(1 3 6 1 2 1 1 5 0)))) ("Linux debian-amd64 2.6.24-1-amd64 #1 SMP Sat May 10 09:28:10 UTC 2008 x86_64" "debian-amd64") In old versions of SNMP package, user can use "sysDescr.0" instead of #(1 3 6 1 2 1 1 1 0). But this facility need a LALR parser. It was ZEBU but very hard to use and even install correctly. Now I'm working on write a ASN.1 compiler to get alive without any LALR parser. Just give me more days I can work it out. I'll watching you guys on how to integrate SNMP monitor ability into your NOCtool:) Any bug reports and idea are welcome! Regards, Chun Tian (binghe) ? 2008-7-13???2:55? Ingvar ??? > Chun Tian writes: > [ I have CCd the noctool-devel mailing list ] >> Hi, Ingvar Mattsson >> >> I'm a UNIX system administrator and Lisp programmer in China. >> >> Recently I saw your NOCtool project [1] on common-lisp.net. I also >> want to build such a package for monitor my UNIX servers. My plan is >> write a pure lisp SNMP client first, then IPMI client, then other >> monitoring support (HTTP, Ping, ...), finally build a Web server on >> cl- >> http and add graph drawing facility. >> >> It seems that your project already done the later part of my plan:) > > Yeah, it's slowly getting there and I was looking at SNMP packages a > while > back, since I can see that having (some sort of) SNMP support would > make it > much easier monitoring some types of equipment. > >> Now I have a working SNMP client (even server) package[2]. For this >> project, I also write a USOCKET UDP patch and LispWorks UDP support. >> If your're still interesting in improve your package to monitor more >> things, you may want to see my work. >> >> The SNMP package is on SVN: (tested on LispWorks, other CLs maybe >> need >> small fixes) >> >> https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/ >> trunk >> >> The USOCKET UDP patch (as an ASDF package, waiting USOCKET author >> merge it): >> >> https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/usocket-udp/trunk >> >> The IPMI package (still under development, not usable) >> >> https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/ipmi/ >> trunk > > Cool. Are the packages in such a stage that it would make sense to > package > them up so ASDF-INSTALL can grab and build them? From what I can > tell, what's > needed is an ASDF system definition file, a tar-ball with the > relevant source > files and an entry in CLiki. > > //Ingvar > From download at hpc.unm.edu Mon Jul 21 15:16:58 2008 From: download at hpc.unm.edu (Jim Prewett) Date: Mon, 21 Jul 2008 09:16:58 -0600 (MDT) Subject: [noctool-devel] proposed patch to image library Message-ID: Hi All, Attached, find a patch to the image libray that adds the method write-gif-to-stream. This probably could have been more generically written so as to accomodate PNGs as well. So, do with it what you will... Jim p.s. what is the appropriate channel for discussing the image library? James E. Prewett Jim at Prewett.org download at hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210 -------------- next part -------------- --- image.lisp 2008-07-21 09:13:44.000000000 -0600 +++ image.lisp.orig 2008-07-21 09:13:12.000000000 -0600 @@ -410,29 +410,3 @@ do (setf (aref png-data y x delta) (aref img (+ base-ix delta)))))) (zpng:write-png png file-name))) - -(defgeneric write-gif-to-stream (image stream &optional comment)) - -(defmethod write-gif-to-stream ((image image) stream &optional (comment "a")) - ;; Use Xach's skippy library - (let ((colormap (make-color-table image))) - (let ((gif-data (make-array (* (image::height image) (image::width image)) - :element-type '(unsigned-byte 8))) - (skippy-tab (image::skippify-color-table colormap))) - (loop for n from 0 below (length gif-data) - do (let ((base-ix (* n 3))) - (let ((key (list (aref (image-data image) (+ base-ix 0)) - (aref (image-data image) (+ base-ix 1)) - (aref (image-data image) (+ base-ix 2))))) - (setf (aref gif-data n) (gethash key colormap))))) - (skippy:write-data-stream - (skippy:make-data-stream - :height (image::height image) - :width (image::width image) - :color-table skippy-tab - :comment comment - :initial-images (list (skippy:make-image - :height (image::height image) :width (image::width image) - :color-table skippy-tab - :image-data gif-data))) - stream)))) From binghe.lisp at gmail.com Mon Jul 21 15:18:19 2008 From: binghe.lisp at gmail.com (Chun Tian (binghe)) Date: Mon, 21 Jul 2008 23:18:19 +0800 Subject: [noctool-devel] Fwd: [ann] cl-net-snmp 3.0 released References: <54b85cab-496c-4b40-81d5-5eb34d81fba1@z6g2000pre.googlegroups.com> Message-ID: A.T.T. > > Hi, Lispers > > After one and a half year since I started this project (0.01 on May > 2007, 1.2 on Oct 2007), I'm glad to > release cl-net-snmp 3.0 today, the pure-lisp implementation of Simple > Network Management Protocol (SNMP, RFC 2271). > > From this release, I throw out the ZEBU LALR parser and write a simple > ASN.1 compiler (based on LispWorks parsergen) to > generate Lisp code from ASN.1 MIB files, then use ASDF to load them > directly. Any ASN.1 Object Identifier value are treated as a Lisp > variable. > > This project is part of my big plan: write a new system administration > platform (like HP OpenView) completely in Common Lisp. > > Cliki page: (contains link to other resources) > > http://www.cliki.net/cl-net-snmp > > Current Supported Platforms: > > * LispWorks > * CMUCL > * SBCL > * Clozure CL > * Allegro CL > > Features: > > * Full SNMP protocol support (SNMPv1, SNMPv2c, SNMPv3) > * Support MIB and ASN.1 object id names > * Fast BER encode/decode based on CLOS > * UDP retransmit support > * [LispWorks] Simple SNMP Server > * [LispWorks] GUI MIB Browser > > Download: > > You can use ASDF-INSTALL to install cl-net-snmp 3.0, or download > following release files: > > * The core: SNMP 3.0: > > http://common-lisp.net/project/cl-net-snmp/release/snmp_3.0.tar.gz > > * ASN.1 runtime and compiler, version 2.3: > > http://common-lisp.net/project/cl-net-snmp/release/asn.1_2.3.tar.gz > > * UDP patch for usocket, version 1.2: > > http://common-lisp.net/project/cl-net-snmp/release/usocket-udp_1.2.tar.gz > > * LispWorks UDP support, version 2.1: > > http://common-lisp.net/project/cl-net-snmp/release/lispworks-udp_2.1.tar.gz > > Sample Usage: > > ? (snmp:snmp-walk "debian-amd64.local" '("system")) > (((# > "Linux debian-amd64 2.6.25-2-amd64 #1 SMP Fri Jun 27 00:16:12 UTC > 2008 x86_64") > (# #) > (# # 0:34:48.48>) > (# > "Root (configure /etc/snmp/snmpd.local.conf)") > (# "debian-amd64") > (# "Unknown (configure /etc/snmp/ > snmpd.local.conf)") > (# #) > (# #) > (# #) > (# #) > (# #) > (# #) > (# #) > (# #) > (# #) > (# "The SNMP Management Architecture MIB.") > (# "The MIB for Message Processing and > Dispatching.") > (# > "The management information definitions for the SNMP User-based > Security Model.") > (# "The MIB module for SNMPv2 entities") > (# "The MIB module for managing TCP > implementations") > (# > "The MIB module for managing IP and ICMP implementations") > (# "The MIB module for managing UDP > implementations") > (# "View-based Access Control Model for > SNMP.") > (# #) > (# #) > (# #) > (# #) > (# #) > (# #) > (# #) > (# #))) > > Regards, > > Chun Tian (binghe) > From ingvar at hexapodia.net Mon Jul 21 16:16:35 2008 From: ingvar at hexapodia.net (Ingvar) Date: Mon, 21 Jul 2008 17:16:35 +0100 Subject: [noctool-devel] proposed patch to image library In-Reply-To: References: Message-ID: Jim Prewett writes: > Hi All, > > Attached, find a patch to the image libray that adds the method > write-gif-to-stream. > > This probably could have been more generically written so as to accomodate > PNGs as well. So, do with it what you will... I'll see what I can do. :) > Jim > p.s. what is the appropriate channel for discussing the image library? Normally, mail to my private mailbox. But, seeing as how the Image library is the screaming, beating heart of NOCtool's graphing component, I guess this isn't necessarily a bad place for it. If you want the full story, I can try to retell it somewhere... //Ingvar From download at hpc.unm.edu Mon Jul 28 11:45:46 2008 From: download at hpc.unm.edu (Jim Prewett) Date: Mon, 28 Jul 2008 05:45:46 -0600 (MDT) Subject: [noctool-devel] average "monitor" Message-ID: Hello, I'm wondering if anyone has any thoughts on how one might make an "monitor" that represents the average of several other monitors. I'm looking at http://meta.rocksclusters.org/ganglia/ right now where they display a graph of the average load over some 450+ machines. How might you implement something like that in NOCtool? Thanks, Jim p.s. anyone seen any "good" monitoring UIs? something they like... I can't say I ever really have :P James E. Prewett Jim at Prewett.org download at hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210 From ingvar at hexapodia.net Mon Jul 28 15:12:56 2008 From: ingvar at hexapodia.net (Ingvar) Date: Mon, 28 Jul 2008 16:12:56 +0100 Subject: [noctool-devel] average "monitor" In-Reply-To: References: Message-ID: Jim writes: > Hello, > > I'm wondering if anyone has any thoughts on how one might make an > "monitor" that represents the average of several other monitors. I'd actually be inclined to call that a "view" and either have it be one or more "equipment"s or one or more "monitor"s (or, possibly, a composite of them) and default to either "min", "avg" or "max" (in the case of "equipment"-centred views, I suspect either "avg" or "max" would be the right default, for views composed of "monitor"s, I am less sure). I can probably think of even more interesting ways of aggregating measures into useful values, if given a few more moments to think about it. [1] Just so that's on record, somewhere. :) The typical use-case, as I see it, is to slap sufficient inter-related things into one or more views, so all you'd look at frequently is the status for the view-as-such, then opening the view up to watch components within the view (be that one or more equipment objects or one or more monitors; sort of how the equipment aggregates monitors). > I'm looking at http://meta.rocksclusters.org/ganglia/ right now where they > display a graph of the average load over some 450+ machines. How might > you implement something like that in NOCtool? Depends on, I would've thought. > p.s. anyone seen any "good" monitoring UIs? something they like... I > can't say I ever really have :P Closest I've seen so far is HP OpenView and Spectrum (no longer Cabletron, but surprisingly still alive). Both rely heavily on the admin(s) to set up decent views, as uncareful adding of monitored elements tends towards "crowded". //Ingvar [1] Off the top of my head, I could probably make a case for: minimum measure/alert level arithmetic mean of measure/alert level median of measure/alert level geometric mean of measure/alert level (this'd be "multiply all N measures together, extract the Nth root, this is the geomean) maximum of measure/alert level Minimum is the one I'd have teh hardest time to defend, but... The three averages are variously useful for performance indication (artithmean is useful for a fine-grained load-balancing; median is handy for most practical purposes, I would've thought and the geomean ought to spike as you starts towards having more servers with an issue, while being fairly unresponsive when there's just a small problem) Max is handy whenever you have a small number of things aggregated (or not much load-balancing between them).