February 2006 - Xymon - Xymon mailman web

[hobbit] Logfile monitoring - I'd like some comments
by Mark.Deiss＠acs-inc.com 16 Feb '06

16 Feb '06

Suggest that the framework be able to support a client side model in addition to the server side model being contemplated (i.e. a bulk of the handling being done on the hobbit collector server). It is fine to talk about some initial client side processing and passing assorted areas of interest from system and application log files for the real work to be done on the collector. The point about administrating multiple clients from a central collector with rules is well taken. (Aside: why not use swatch as much as possible?). I think client-side processing will be important on AIX and Tru64 servers which maintain system error logs that are in a binary format. You need the platform tools to effectively parse the output. Passing this out in date ranges for later, further processing on a hobbit collector will result in a maintenance support issue. You need some flexibility in how much to pass on which I do not see being practical on a collector-side model. The AIX and Tru64 crowd will still be spending time on the clients making client-side rule decisions on their regular expressions on how much to relay to the collector for a particular event. Getting a valid set of information out of a particular event is not always a simple, predictable matter. This area has been addressed with external modules developed on deadcat using different approaches. It would appear sites using AIX and Tru64 will be starting from scratch with the Hobbit model and will need to develop some new tools to fit within the Hobbit collector side model. Gets worse for Tru64 with the newer versions that require parsing tool sets that even HP support is not happy with. I am amused per the one HP list recommendation that you do not parse the ~5.1+ binary error logs - for a failure, you ship the logs to HP support and let them struggle with it. (sigh....I have resorted to scanning the newer logs using the older tools such as dia out of desperation) At least initially, the easist approach would be for the Hobbit collector side approach to follow the stated aim regarding the ascii text files, application and OS. The AIX and Tru64 sites may want to run one of the deadcat variants as a client side only model and tweak it as a totally separate client test. For the linux client base, why not configure logwatch to parse your application/system logs and pump them over into the hobbit collector for the additional processing? This product is capable of handling log files with various date names. I "think".... it may also be able to handle compressed files. -----Original Message----- From: Hubbard, Greg L [mailto:greg.hubbard at eds.com] Sent: Wednesday, February 15, 2006 5:40 PM To: hobbit at hswn.dk Subject: RE: [hobbit] Logfile monitoring - I'd like some comments My two cents/pence/francs/pesetas/whatever (I am overcharging): I think it would be cool if the Hobbit client could watch arbitrary log files for arbitrary messages and turn that into status alarms. But don't assume that /var/log or /var/adm or /var/adm is accessible to ordinary (as in Hobbit client) users -- not around here, anyway. Besides, I already have another solution for managing my UNIX syslogs -- what I don't have is a way to manage all of my application log files. Wonder how it would work if the client somehow retrieved "orders" from the BB server at startup and this was used to drive a client-side scanner? I like the notion of centralized configuration, but... Otherwise, you might as well forward all the logs to the central server (syslog-ng?) and have the server parse them. But this wouldn't work for the logs that I want to root through with the clients. GLH -----Original Message----- From: Rob Munsch [mailto:rmunsch at solutionsforprogress.com] Sent: Wednesday, February 15, 2006 4:22 PM To: hobbit at hswn.dk Subject: Re: [hobbit] Logfile monitoring - I'd like some comments Henrik Stoerner wrote: >the amount of log data that Hobbit needs to process. So you can setup a >regexp of stuff in the logfile that you *never* want to see, and a >regexp of stuff that you *always* want to report - regardless of how >much the log grows. > Well, that covers my comment. I'd much rather give a list of "this stuff is always Good" than try to cover every instance of Bad, so that's awesome. It would be ideal if the central config was somewhat bb-hosts-ish, and could accept (in addition to aforementioned includes) host-specific directives for what to log. I am assuming that how to react will already be host-specific like every other test, yes? As far as the logs rotating out... couldn't hobbit look for an environment variable for the format of the rotated logs...? The filenames vary host to host, but on a given host, a quick look at /var/log tells you what to expect, right? Lastly - being someone who couldn't program his way out of a paper stack, i will now cheekily suggest that on install, hobbit could look at /var/log and guesstimate the format, and ask for human confirmation (as it already does for the hobbit user and homedir). Even if this automated | dream doesn't happen, could it still be set manually or via config? -- Rob Munsch Solutions For Progress IT 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

2 2

Problems with latest snapshot
by CHRIS.MORRIS＠RWEnpower.com 16 Feb '06

16 Feb '06

Hi Henrik, I am trying to use the latest snapshot to have a play with the Logfile monitoring. I tried yesterday's as well but have similar problems. All configures and compiles ok but the following are issues. 1) bb-hostsvc.sh works for info and trends columns but get "Premature end of script headers" for all other tests. url is "http://server/hobbit-cgi/bb-hostsvc.sh?HOST=hostname&SERVICE=test" whereas on working system from 30th Jan snapshot the url is "http://server/hobbit-cgi/bb-hostsvc.sh?HOSTSVC=hostname.test&IP=192.168.0.1 0&DISPLAYNAME=hostname" 2) hobbitd keeps crashing with signal 6. The hobbitlaunch.log shows :- 2006-02-16 10:34:37 Status: Host=trl0002, test=bbtest 2006-02-16 10:34:37 Status: Host=trl0002, test=http 2006-02-16 10:34:37 Status: Host=trl0002, test=bbd 2006-02-16 10:34:37 Status: Host=trl0002, test=conn 2006-02-16 10:34:37 Status: Host=trl0002, test=bbgen 2006-02-16 10:34:37 Status: Host=trl0002, test=hobbitd 2006-02-16 10:34:37 Loaded 6 status logs 2006-02-16 10:34:37 Setting up network listener on 0.0.0.0:1985 2006-02-16 10:34:37 Setting up signal handlers 2006-02-16 10:34:37 Setting up hobbitd channels 2006-02-16 10:34:37 Setting up status channel (id=1) 2006-02-16 10:34:37 calling ftok('/usr/local/hobb/server',1) 2006-02-16 10:34:37 ftok() returns: 0x1056815 2006-02-16 10:34:37 shmget() returns: 0x5A000C 2006-02-16 10:34:37 Setting up stachg channel (id=2) 2006-02-16 10:34:37 calling ftok('/usr/local/hobb/server',2) 2006-02-16 10:34:37 ftok() returns: 0x2056815 2006-02-16 10:34:37 shmget() returns: 0x5A800D 2006-02-16 10:34:37 Setting up page channel (id=3) 2006-02-16 10:34:37 calling ftok('/usr/local/hobb/server',3) 2006-02-16 10:34:37 ftok() returns: 0x3056815 2006-02-16 10:34:37 shmget() returns: 0x5B000E 2006-02-16 10:34:37 Setting up data channel (id=4) 2006-02-16 10:34:37 calling ftok('/usr/local/hobb/server',4) 2006-02-16 10:34:37 ftok() returns: 0x4056815 2006-02-16 10:34:37 shmget() returns: 0x5B800F 2006-02-16 10:34:37 Setting up notes channel (id=5) 2006-02-16 10:34:37 calling ftok('/usr/local/hobb/server',5) 2006-02-16 10:34:37 ftok() returns: 0x5056815 2006-02-16 10:34:37 shmget() returns: 0x5C0010 2006-02-16 10:34:37 Setting up enadis channel (id=6) 2006-02-16 10:34:37 calling ftok('/usr/local/hobb/server',6) 2006-02-16 10:34:37 ftok() returns: 0x6056815 2006-02-16 10:34:37 shmget() returns: 0x5C8011 2006-02-16 10:34:37 Setting up client channel (id=7) 2006-02-16 10:34:37 calling ftok('/usr/local/hobb/server',7) 2006-02-16 10:34:37 ftok() returns: 0x7056815 2006-02-16 10:34:37 shmget() returns: 0x5D0012 2006-02-16 10:34:37 Setting up logfiles 2006-02-16 10:39:39 Task hobbitd terminated by signal 6 and gdb shows This GDB was configured as "i386-redhat-linux"... Core was generated by `hobbitd --pidfile=/var/log/hobbit2/hobbitd.pid --restart=/usr/local/hobb/server'. Program terminated with signal 6, Aborted. Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x40050801 in __kill () from /lib/i686/libc.so.6 (gdb) bt #0 0x40050801 in __kill () from /lib/i686/libc.so.6 #1 0x400505da in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x40051d82 in abort () at ../sysdeps/generic/abort.c:88 #3 <signal handler called> #4 0x400a9671 in strstr (phaystack=0x0, pneedle=0x8066358 "\n[linux]\n") at ../sysdeps/generic/strstr.c:58 #5 0x08050569 in do_message (msg=0x8066300, origin=0x805a716 "") at hobbitd.c:3033 #6 0x08053083 in main (argc=8, argv=0xbfffe964) at hobbitd.c:4051 #7 0x4003f177 in __libc_start_main (main=0x8051ad0 <main>, argc=8, ubp_av=0xbfffe964, init=0x8049338 <_init>, fini=0x805a070 <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbfffe95c) at ../sysdeps/generic/libc-start.c:129 3) The client is running happily and the server appears to be receiving the data :- snip from hobbitd.log 2006-02-16 12:06:27 -> do_message/1 (19068 bytes): client trl0002.linux linux 2006-02-16 12:06:27 -> update_statistics 2006-02-16 12:06:27 <- update_statistics 2006-02-16 12:06:27 -> oksender 2006-02-16 12:06:27 <- oksender(1-a) 2006-02-16 12:06:27 ->handle_client 2006-02-16 12:06:27 -> posttochannel 2006-02-16 12:06:27 Posting message 1 to 1 readers 2006-02-16 12:06:27 <- posttochannel 2006-02-16 12:06:27 <-handle_client 2006-02-16 12:06:27 Setup complete 2006-02-16 12:06:27 Sending heartbeat to pid 10123 Any ideas ? Regards, Chris **************************************************************************** The information contained in this email is intended only for the use of the intended recipient at the email address to which it has been addressed. If the reader of this message is not an intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination or copying of the message or associated attachments is strictly prohibited. If you have received this email in error, please contact the sender by return email or call 01793 877777 and ask for the sender and then delete it immediately from your system.Please note that neither RWE npower nor the sender accepts any responsibility for viruses and it is your responsibility to scan attachments (if any). *****************************************************************************

2 1

AW: [hobbit] Network I/O Graph empty
by christian.maxeiner＠usd.de 16 Feb '06

16 Feb '06

Am I the only one with this problem? Any ideas? ________________________________ Von: Maxeiner, Christian Gesendet: Donnerstag, 9. Februar 2006 10:43 An: hobbit at hswn.dk Betreff: [hobbit] Network I/O Graph empty My network I/O Graph is empty. This is the error message from rrd-data.log: 2006-02-09 10:38:19 RRD error updating /users/hobbit4.0//data/rrd/foo.bar/netstat.rrd from 10.100.1.2: expected 11 data source readings (got 16) from 1139477899:U:U:0:3117281:3343088:U:U: U:3836150036:803080985:U:784025:10478468:7420058:U:589:... All hobbit clients are HP-UX and Linux clients. I have also deleted the netstat.rrd files, so I am sure they recreated by hobbit. They are recreated but not updated. Any ideas? Chris

2 1

Logfile monitoring - I'd like some comments
by henrik＠hswn.dk 16 Feb '06

16 Feb '06

A few days ago, I mentioned that I would like to do logfile monitoring for the next Hobbit release. I've worked a bit on this and have a prototype solution for it, which you can test with the current snapshots. I'd like some comments on how it works to make sure I haven't overlooked something before committing myself. There are several objectives: - As far as is possible, logfile monitoring must be configured centrally, on the Hobbit server. Having to go to each server to (re)configure what logfiles to check and what to look for simply doesn't work. - The amount of data sent from each client to Hobbit should be small, but it must catch the "important" stuff. - You rarely know in advance what will be in the logs when you need them the most. So the monitor should give you as much of the log entries as possible, not just those lines that match some pre-defined strings or regex'es. - Some systems log messages on multiple lines. The system must be able to show all parts of a log entry. - Logfile entries must appear on the monitor for some time after they show up in the logs, but should also disappear after a while. In other words: The ideal solution would let you have the entire logfile available on the Hobbit server - but that obviously won't work. So the client should - after weeding out the really irrelevant stuff - send us as much of each logfile as possible. My proposed solution is this: - On the Hobbit server, there's a log-monitoring configuration file for the Hobbit clients. This defines which logfiles are monitored for a single client installation, or you can define it for a group of clients. (The idea is to define at least one group for each operating system, since the standard system logs are OS dependant). This configuration lists the log filename, the maximum amount of data to send from this logfile, a regex "noise" filter (i.e. lines that are stripped from the logfile), and *optionally* a regex identifying really interesting stuff in the logfile that should always be reported. - When a client connects to the Hobbit server and sends the normal client message, the Hobbit server will respond with the logfile configuration for this client. So the client has a copy of the central configuration file, but only the part that it needs for itself. The reason for sending this as a response to the client message is to avoid an extra round-trip from client to server; piggy-backing the config push on the client message means that it is almost without any performance cost on the server side. - When the client runs, it uses the local copy of the configuration file to determine what logs to look at. For each logfile, it maintains a "where-was-I-the-last-time" status, so it only looks at the entries made to the logfile during the past 30 minutes. First, the client strips off any "noise" messages. Then, if all of the entries fit into the maximum size that can be reported, it sends all of the log to the Hobbit server. If there is more than will fit, it first checks to see of the regex defining the really interesting stuff is present in the log - if it is, then it drops anything before the interesting text. If there is still more than will fit, it keeps the interesting text + a few lines after that (to allow for multi-line log-entries which some OS'es have), and then sends that together with as much of last part the log as will fit inside the max. message size. This part has been implemented in the Hobbit daemon (hobbitd), and in the clients via a new "logfetch" utility. This utility uses standard regular expressions - not the Perl-compatible ones, because that would require you to install the PCRE library on all of your clients. The standard regex routines are included in all (I think) system libraries used today. The last part is what happens when the log data arrives on the Hobbit server. Currently, there's a simple processing of this data to just dump it into an always-green "msgs" column. What should happen once I get it coded is: - Data from each logfile is matched against a set of strings (regex'es) defined in the hobbit-clients.cfg file. Each string determines the color (red, yellow, green) and sets the color of the msgs column accordingly. When the color has been decided, all of the normal alerting happens automatically. I do plan on making a more fine-grained alert mechanism (for the msgs, procs and disk statuses) so you can direct alerts to different groups depending on exactly which log-message triggered the alert, but that will not be part of this release. So - how does that sound ? Anything I've missed ? Regards, Henrik

7 10

CPU graph is blank
by plardinois＠be.tiauto.com 16 Feb '06

16 Feb '06

Hello, is there anybody who had this kind of issue with the graphs ? Thank you for your support, regards, Pierre Lardinois on behalf of Valéry Guilleaume Int. ICT Infrastructure Team TI Automotive -----Original Message----- From: Lardinois, Pierre Sent: jeudi 9 février 2006 9:08 To: 'hobbit at hswn.dk' Subject: CPU graph is blank Hello, I have a graph problem in Hobbit. My CPU graphs for one type of devices are blank (no value). The la.rrd file is created but contains only "nan" values. I put debug mode into hobbitlaunch.cfg, as follows : [rrdstatus] ENVFILE /home/hobbit/server/etc/hobbitserver.cfg NEEDS hobbitd CMD hobbitd_channel --channel=status --log=$BBSERVERLOGS/rrd-status.log hobbitd_rrd --rrddir=$BBVAR/rrd --debug [rrddata] ENVFILE /home/hobbit/server/etc/hobbitserver.cfg NEEDS hobbitd CMD hobbitd_channel --channel=data --log=$BBSERVERLOGS/rrd-data.log hobbitd_rrd --rrddir=$BBVAR/rrd --debug This gives me these logs (rrd-status.log) : 2006-02-08 15:48:33 hobbitd_rrd: Got message 353149 @@status#353149|1139410113.294949|57.230.48.205||myhost |cpu|1139411913|green||green|1139005636|0||0| 2006-02-08 15:48:33 RRD update param 00: 'rrdupdate' 2006-02-08 15:48:33 RRD update param 01: '/home/hobbit/data/rrd/myhost/la.rrd' 2006-02-08 15:48:33 RRD update param 02: '-t' 2006-02-08 15:48:33 RRD update param 03: 'la' 2006-02-08 15:48:33 RRD update param 04: '1139410113:3' But the file remains empty. Can someone help me please ? Thank you very much for your support, _____________________________ Valéry Guilleaume Int. ICT Infrastructure Team TI Automotive The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

1 0

MRTG for Switches
by Todd.Costa＠state.ma.us 15 Feb '06

15 Feb '06

Hello Hob-sters, I am wondering were I can find some mrtg cfg examples that will let me track port traffic activity on switches? I recently followed the integrating steps for MRTG data into Hobbit. And I now see MRTG in the trends link which is cool. But I now want to watch by ports and generate graphs per port. Can this still be done? I once did this through BB and I remember it being tricky and cumbersome to do. But so far, everything I have tried with hobbit has gotten easier to deal with. I hope its the same with what I am asking now. Any help and input is appreciated. Todd M. Costa Commonwealth of Massachusetts

1 0

[hobbit] Monitor/graph multiple interfaces with Hobbit?
by Jeremy.Worrells＠intermountainmail.org 15 Feb '06

15 Feb '06

Thanks, Henrik. I will look into some custom scripts. One more question: Is is possible to monitor multiple items with a single bulb on the status page? For instance, a firewall with 4 interfaces would have a single status bulb for "interfaces". Jeremy -----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: Friday, February 10, 2006 3:03 PM To: hobbit at hswn.dk Subject: Re: [hobbit] Monitor/graph multiple interfaces with Hobbit? On Fri, Feb 10, 2006 at 10:43:28AM -0700, Jeremy Worrells wrote: > > I am a newcomer to hobbit. I find it to be a very exciting project, > but I cannot figure out how to perform a vital function. We currently > have dozens of RRD databases and CGI scripts creating graphs on those RRDs. > We also run BB for network health monitoring. I would like to combine > the two using hobbit, but I am not sure how to go about it. > > Here's what I want to do: have a "traffic" monitor in hobbit that > tracks any number of interfaces on a firewall or router. It would > alert on a certain traffic threshold and would provide RRD graphs of > the interfaces. I would like to avoid MRTG if at all possible. > > Is this kind of arbitrary RRD graphing/alerting available in hobbit? It's not available "out of the box" - you'll have to write some scripts to collect the data you're after, check it against the thresholds, and sends the result of that check to Hobbit as a status message. This status can then include the raw data which can go into a graph shown by Hobbit. What you're asking for doesn't seem terribly out of the ordinary, so it would make sense to provide this as a standard part of Hobbit. A merge of MRTG's data collection with Hobbit's alerting and graph features would be a pretty powerful setup. I do have plans for Hobbit to trigger alerts based on the data that is reported into the RRD files, which would take care of the alerting part of your scenario. Then there's the SNMP-based data collection; a user from Belgium has done some work on this so there might be something available soon. So - it will happen one day. But it's not there yet. Regards, Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

1 0

alert dependancy
by sblee＠tazmania.org 15 Feb '06

15 Feb '06

Does the feature exist within Hobbit to define an alert dependency such that if router x is down, and/or switch is down, don't alert on the stuff behind it that's failing if they're defined to be dependent on those devices? I've been told that nagios does support this. Sue

2 1

[hobbit] alert dependancy
by Craig_Whilding＠mentor.com 15 Feb '06

15 Feb '06

You can use route:router1,router2 etc so that if a higher level fails the ping of the host will change to yellow instead of red. You would then configure your alerting to only alert on reds. Other tests go white when the ping test fails anyway. Craig -----Original Message----- From: Sue Bauer-Lee [mailto:sblee at tazmania.org] Sent: 15 February 2006 16:45 To: hobbit at hswn.dk Subject: [hobbit] alert dependancy Does the feature exist within Hobbit to define an alert dependency such that if router x is down, and/or switch is down, don't alert on the stuff behind it that's failing if they're defined to be dependent on those devices? I've been told that nagios does support this. Sue To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

1 0

[hobbit] Logfile monitoring - I'd like some comments
by Larry.Sherman＠rbsgc.com 15 Feb '06

15 Feb '06

I have one concern about the amount of logfile data being sent back to the server. Our application logfiles our VERY verbose for compliance reasons, but on a daily basis I don't need 99% of the information. I would rather have the ability to have the client side agent use the regex rule to define what part of the file to send back to the server. IE: #Machine name Gsets001 # LODFILE define $LOG_DIR/some_verbose_app_logfile.log #Rules for logfile define (string match and contex) #COLOR STRING NUMLINESABOVE NUMLINESBELOW RED_STRING /FH DOWN/ 3 4 RED_STRING /BAD Trade/ 10 1 RED_STRING /forced log off from server/ 0 0 $OTHER_LOG_DIR/another_verbose_app_logfile.log RED_STRING /Slow Consumer/ 2 6 Does this make sense to you? Larry -----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: Tuesday, February 14, 2006 4:40 PM To: hobbit at hswn.dk Subject: [hobbit] Logfile monitoring - I'd like some comments A few days ago, I mentioned that I would like to do logfile monitoring for the next Hobbit release. I've worked a bit on this and have a prototype solution for it, which you can test with the current snapshots. I'd like some comments on how it works to make sure I haven't overlooked something before committing myself. There are several objectives: - As far as is possible, logfile monitoring must be configured centrally, on the Hobbit server. Having to go to each server to (re)configure what logfiles to check and what to look for simply doesn't work. - The amount of data sent from each client to Hobbit should be small, but it must catch the "important" stuff. - You rarely know in advance what will be in the logs when you need them the most. So the monitor should give you as much of the log entries as possible, not just those lines that match some pre-defined strings or regex'es. - Some systems log messages on multiple lines. The system must be able to show all parts of a log entry. - Logfile entries must appear on the monitor for some time after they show up in the logs, but should also disappear after a while. In other words: The ideal solution would let you have the entire logfile available on the Hobbit server - but that obviously won't work. So the client should - after weeding out the really irrelevant stuff - send us as much of each logfile as possible. My proposed solution is this: - On the Hobbit server, there's a log-monitoring configuration file for the Hobbit clients. This defines which logfiles are monitored for a single client installation, or you can define it for a group of clients. (The idea is to define at least one group for each operating system, since the standard system logs are OS dependant). This configuration lists the log filename, the maximum amount of data to send from this logfile, a regex "noise" filter (i.e. lines that are stripped from the logfile), and *optionally* a regex identifying really interesting stuff in the logfile that should always be reported. - When a client connects to the Hobbit server and sends the normal client message, the Hobbit server will respond with the logfile configuration for this client. So the client has a copy of the central configuration file, but only the part that it needs for itself. The reason for sending this as a response to the client message is to avoid an extra round-trip from client to server; piggy-backing the config push on the client message means that it is almost without any performance cost on the server side. - When the client runs, it uses the local copy of the configuration file to determine what logs to look at. For each logfile, it maintains a "where-was-I-the-last-time" status, so it only looks at the entries made to the logfile during the past 30 minutes. First, the client strips off any "noise" messages. Then, if all of the entries fit into the maximum size that can be reported, it sends all of the log to the Hobbit server. If there is more than will fit, it first checks to see of the regex defining the really interesting stuff is present in the log - if it is, then it drops anything before the interesting text. If there is still more than will fit, it keeps the interesting text + a few lines after that (to allow for multi-line log-entries which some OS'es have), and then sends that together with as much of last part the log as will fit inside the max. message size. This part has been implemented in the Hobbit daemon (hobbitd), and in the clients via a new "logfetch" utility. This utility uses standard regular expressions - not the Perl-compatible ones, because that would require you to install the PCRE library on all of your clients. The standard regex routines are included in all (I think) system libraries used today. The last part is what happens when the log data arrives on the Hobbit server. Currently, there's a simple processing of this data to just dump it into an always-green "msgs" column. What should happen once I get it coded is: - Data from each logfile is matched against a set of strings (regex'es) defined in the hobbit-clients.cfg file. Each string determines the color (red, yellow, green) and sets the color of the msgs column accordingly. When the color has been decided, all of the normal alerting happens automatically. I do plan on making a more fine-grained alert mechanism (for the msgs, procs and disk statuses) so you can direct alerts to different groups depending on exactly which log-message triggered the alert, but that will not be part of this release. So - how does that sound ? Anything I've missed ? Regards, Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk ----------------------------------------- ******************************************************************* * This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorized to retain, read, copy or disseminate this message or any part of it. ******************************************************************* *

1 0