October 2017 - Xymon - Xymon mailman web

Capture and send data To Elasticsearch and Kibana
by francois.outteryck＠soprasteria.com 27 Sep '22

27 Sep '22

Hi Peter, Examples of task.cfg configuration with status and stachg events : [capture_status] ENVFILE /home/xymon/server/etc/xymonserver.cfg NEED xymond CMD xymond_channel --channel=status /home/xymon/server/ext/capture.sh --log=$XYMONSERVERLOGS/xymond_task_capture.log LOGFILE /var/log/xymon/lunch_capture.log [capture_stachg] ENVFILE /home/xymon/server/etc/xymonserver.cfg NEED xymond CMD xymond_channel --channel=stachg /home/xymon/server/ext/capture.sh --log=$XYMONSERVERLOGS/xymond_task_capture_stachg.log LOGFILE /var/log/xymon/lunch_capture_stachg.log Capture.sh script simple made to call a php script : #!/bin/sh /usr/bin/php /var/www/kibana/capture.php $@ </dev/stdin >>/var/log/xymon/xymond_capture_php.log 2>&1 And capture.php make all job : <?php date_default_timezone_set('Europe/Paris'); $TODO=FALSE; $ARRAY_COLLECTOR=array(); $COLLECTOR=null; while (FALSE !== ($line = fgets(STDIN))) if ($line!='') { $tab=reduce_array($line); if (sizeof($tab)==0) continue; if ($line=="@@\n") { if ($TODO) { $metadata['Message']=implode('',$ARRAY_COLLECTOR); SendData($id,$metadata,$COLLECTOR); $TODO=FALSE; $COLLECTOR=null; } } else if (substr($tab[0],0,8)=='@@stachg') { if ($TODO) { $metadata['Message']=implode('',$ARRAY_COLLECTOR); SendData($id,$metadata,$COLLECTOR); $TODO=FALSE; $COLLECTOR=null; } /* 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 /* @@stachg#seq|timestamp|sender|origin|hostname|testname|expiretime|color|prevcolor|changetime|disabletime|disablemsg|downtimeactive|clienttstamp|modifiers */ $COLLECTOR='stachg'; $metadata=explode('|',$tab[0]); $sender=$metadata[2]; $hostname=$metadata[3]; $metadata=array( 'Collector'=>$COLLECTOR, 'Sender'=>$metadata[2], 'ServerName'=>$metadata[4], 'Type'=>$metadata[5], 'Status'=>$metadata[7], 'PrevStatus'=>$metadata[8], 'LogTime'=>$metadata[1], 'ValidTime'=>$metadata[6], 'LastChange'=>$metadata[9], 'DisableTime'=>$metadata[10], 'DisableMSg'=>$metadata[11], 'Message'=>'' ); $id=$metadata['ServerName'].'_'.$metadata['Type'].'_'.$meta['LastChange']; $ARRAY_COLLECTOR=null; $ARRAY_COLLECTOR=array(); $TODO=TRUE; } else if (substr($tab[0],0,8)=='@@status') { if ($TODO) { $metadata['Message']=implode('',$ARRAY_COLLECTOR); SendData($id,$metadata,$COLLECTOR); $TODO=FALSE; $COLLECTOR=null; } /* 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 /* @@status|timestamp|sender|origin|hostname|testname|expiretime|color|testflags|prevcolor|changetime|ackexpiretime|ackmessage|disableexpiretime|disablemessage|clientmsgtstamp|flapping */ $COLLECTOR='status'; $metadata=explode('|',$tab[0]); $sender=$metadata[2]; $hostname=$metadata[3]; $metadata=array( 'Collector'=>$COLLECTOR, 'Sender'=>$metadata[2], 'ServerName'=>$metadata[4], 'Type'=>$metadata[5], 'Status'=>$metadata[7], 'LogTime'=>$metadata[1], 'ValidTime'=>$metadata[6], 'LastChange'=>$metadata[10], 'DisableTime'=>$metadata[13], 'AckTime'=>$metadata[11], 'DisableMSg'=>$metadata[14], 'Message'=>'' ); $id=$metadata['ServerName'].'.'.$metadata['Type']; $ARRAY_COLLECTOR=null; $ARRAY_COLLECTOR=array(); $TODO=TRUE; } else { if (substr($tab[0],0,2)=='@@') { if ($TODO) { $metadata['Message']=implode('',$ARRAY_COLLECTOR); SendData($id,$metadata,$COLLECTOR); $TODO=FALSE; $COLLECTOR=null; } } if ($TODO) $ARRAY_COLLECTOR[]=$line; } } function CallAPI($method, $url, $data = false) { $curl = curl_init(); switch ($method) { case "POST": curl_setopt($curl, CURLOPT_POST, 1); if ($data) curl_setopt($curl, CURLOPT_POSTFIELDS, $data); break; case "PUT": curl_setopt($curl, CURLOPT_PUT, 1); break; default: if ($data) $url = sprintf("%s?%s", $url, http_build_query($data)); } curl_setopt($curl, CURLOPT_URL, $url); curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1); $result = curl_exec($curl); curl_close($curl); return $result; } function reduce_array($line) { $tab=explode(' ',$line); $nr=array(); for ($i=0;$i<sizeof($tab);$i++) if (trim($tab[$i])!='') $nr[]=trim($tab[$i]); return $nr; } function SendData($id,$cc,$COLLECTOR=null) { if ($COLLECTOR==null) return; $d=new DateTime(); if ($cc['LastChange']!='') {$d->setTimestamp($cc['LastChange']);$cc['LastChange']=$d->format('c');} else {$cc['LastChange']='NaN';} if ($cc['LogTime']!='') {$d->setTimestamp($cc['LogTime']);$cc['LogTime']=$d->format('c');} else {$cc['LogTime']='NaN';} if ($cc['ValidTime']!='') {$d->setTimestamp($cc['ValidTime']);$cc['ValidTime']=$d->format('c');} else {$cc['ValidTime']='NaN';} if (isset($cc['AckTime'])) { if ($cc['AckTime']!='') {$d->setTimestamp($cc['AckTime']);$cc['AckTime']=$d->format('c');} else {$cc['AckTime']='NaN';} } if ($cc['DisableTime']!='') {$d->setTimestamp($cc['DisableTime']);$cc['DisableTime']=$d->format('c'); } else {$cc['DisableTime']='NaN';} $data = json_encode($cc); $data=str_replace('"NaN"','null',$data); echo $id.'=>'.$data."\n"; $url="http://127.0.0.1:9200/xymon/".$COLLECTOR."/".$id; $res=CallAPI("POST",$url,$data); } ?> De : Peter Welter [mailto:peter.welter at gmail.com] Envoyé : vendredi 23 décembre 2016 14:45 À : OUTTERYCK Francois Cc : xymon at xymon.com Objet : Re: [Xymon] Capture and send data To Elasticsearch and Kibana Hi Francois, Looks good, your sample. I am very interested in your integration efforts. How do you select what is going to be inserted in the ELK stack? All status messages that Xymon receives? And could you provide an example of the xymond_channel block in you task.cfg and the capture.sh? Tasks.cfg probably is something like: [es] ... CMD xymond_channel --channel=status /home/xymon/server/ext/capture.sh ... And the capture.sh contains some curl script to the ELK stack? Regards, Peter 2016-12-14 18:15 GMT+01:00 OUTTERYCK Francois <francois.outteryck at soprasteria.com<mailto:francois.outteryck at soprasteria.com>>: Hello, I just do a small work with Xymon in order to send status data to Elasticsearch. And with Kibana reporting is easy. How it work ? Simple : With capture of status message (xymond_channel --channel=status /home/xymon/server/ext/capture.sh ) script encode status message in json and send as document in elasticSearch. Example of Mapping document status in elasticsearch : "status"=> array( "properties"=>array( "ServerName"=> array("type"=> "string"), "Type"=> array("type"=> "string"), "Status"=> array("type"=> "string"), "LastChange"=> array("type"=> "date","format"=> "strict_date_optional_time"), "LogTime"=> array("type"=> "date","format"=> "strict_date_optional_time"), "ValidTime"=> array("type"=> "date","format"=> "strict_date_optional_time"), "AckTime"=> array("type"=> "date","format"=> "strict_date_optional_time"), "DisableTime"=> array("type"=> "date","format"=> "strict_date_optional_time"), "Sender"=> array("type"=> "string"), "DisableMSg"=> array("type"=> "string"), "Message"=> array("type"=> "string") ) ) All is done with a 130 lines script. So simple to integrate in existing environment and so powerfull usage of Xymon/elasticsearch/Kibana For those who don’t know kibana : https://www.elastic.co/products/kibana [cid:image001.png at 01D25EA3.F74489F0] _______________________________________________ Xymon mailing list Xymon at xymon.com<mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon

2 1

Need help with upgrade from 4.3.17 to 4.3.20
by cleaver＠terabithia.org 17 Jul '18

17 Jul '18

Hmm. So far, the only way I've been able to reproduce this is by replacing the ScriptAlias directives with mere Alias's in the xymon.conf apache config. Has there been any change in the path you've used for the CGI directory since the previous version, or is there any chance that another Alias line is taking precedence over the ScriptAlias? Do you see anything in the apache access/error logs that indicates an error? -jc On Tue, May 19, 2015 10:37 am, Cortes, Manny wrote: > Having the same problem after installing 4.3.20 on both Ubuntu server > 14.04 and 15.04. > > Thanks, > > > Manuel A Cortes > > Systems Programmer III > > [IBM_Cert] > > IBM Certified System Administrator AIX 7 > > Information Services > > 321-841-6534 > > Orlandohealth.com > > Facebook.com/orlandohealth > > Youtube.com/orlandohealth > > @orlandohealth on twitter > > > > 1414 Kuhl Avenue.,MP136 > > Orlando, Florida 32806 > > From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Asif Iqbal > Sent: Tuesday, May 19, 2015 12:59 PM > To: J.C. Cleaver > Cc: xymon at xymon.com > Subject: Re: [Xymon] Need help with upgrade from 4.3.17 to 4.3.20 > > > > On Tue, May 19, 2015 at 12:40 PM, J.C. Cleaver > <cleaver at terabithia.org<mailto:cleaver at terabithia.org>> wrote: > Hmm. It seems like it's trying to pass along the binary rather than > actually execute it. Can you > > a) validate the permissions on the various .sh files inside the > /xymon-cgi/ directory. (Wondering if there's a case where make install > doesn't set permissions properly), and > > > /var/lib/xymon/cgi-bin$ ls -al > total 6560 > drwxr-xr-x 2 root root 4096 May 19 10:19 . > drwxr-xr-x 16 xymon xymon 4096 May 19 10:19 .. > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 acknowledgements.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 appfeed-critical.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 appfeed.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 certreport.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 columndoc.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 confreport-critical.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 confreport.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 criticalview.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 csvinfo.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 datepage.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 eventlog.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 findhost.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 ghostlist.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 historylog.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 history.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 hostgraphs.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 hostlist.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 nongreen.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 notifications.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 perfdata.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 reportlog.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 report.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 showgraph.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 snapshot.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 svcstatus.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 topchanges.sh > > > b) verify that the ScriptAlias or ExecCGI options are still present in > apache.conf. > > > grep xymon-cgi /etc/apache2/sites-enabled/xymon-apache.conf > # "/xymon" and "/xymon-cgi" URLs. > ScriptAlias /xymon-cgi/ "/var/lib/xymon/cgi-bin/" > RewriteRule ^/xymon-cgi/bb-hist.sh /xymon-cgi/history.sh [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-eventlog.sh /xymon-cgi/eventlog.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-rep.sh /xymon-cgi/report.sh [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-replog.sh /xymon-cgi/reportlog.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-snapshot.sh /xymon-cgi/snapshot.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-findhost.sh /xymon-cgi/findhost.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-csvinfo.sh /xymon-cgi/csvinfo.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbitcolumn.sh /xymon-cgi/columndoc.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-datepage.sh /xymon-cgi/datepage.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbitgraph.sh /xymon-cgi/showgraph.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-hostsvc.sh /xymon-cgi/svcstatus.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-histlog.sh /xymon-cgi/historylog.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-confreport.sh /xymon-cgi/confreport.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-confreport-critical.sh > /xymon-cgi/confreport-critical.sh [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-nkview.sh /xymon-cgi/criticalview.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-certreport.sh /xymon-cgi/certreport.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-nongreen.sh /xymon-cgi/nongreen.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-hostgraphs.sh /xymon-cgi/hostgraphs.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-ghosts.sh /xymon-cgi/ghostlist.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-notifylog.sh /xymon-cgi/notifications.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-hostlist.sh /xymon-cgi/hostlist.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-perfdata.sh /xymon-cgi/perfdata.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-topchanges.sh /xymon-cgi/topchanges.sh > [R=permanent,L] > > > HTH, > > -jc > > > On Tue, May 19, 2015 7:56 am, Asif Iqbal wrote: >> I am not sure what I need to after the upgrade for the columns to show >> data >> instead of >> something like this >> >> >> ELF ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ï¿½>ï¿½ ï¿½ï¿½ï¿½ >> @ï¿½ï¿½ï¿½ï¿½ï¿½@ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ Ã >> ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½@ï¿½8ï¿½ ï¿½@ï¿½%ï¿½"ï¿½ ï¿½ï¿½ï¿½ >> ï¿½ï¿½ï¿½@ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½@ï¿½@ï¿½ï¿½ï¿½ï¿½ï¿½@ï¿½@ï¿½ï¿½ï¿½ï¿½ï¿½Ã¸ >> ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ã¸ ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ >> ï¿½ï¿½ï¿½8 ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½8 >> @ï¿½ï¿½ï¿½ï¿½ï¿½8 @ï¿½ï¿½ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ >> ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ >> ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½@ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½@ï¿½ï¿½ï¿½ï¿½ï¿½Ã¤Ã¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ã¤Ã¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ >> >> I removed FollowSymLinks from xymon-apache.conf file under /xymon-cgi/ >> and /xymon-seccgi/ and restarted. >> >> I am using ubuntu >> >> -- >> Asif Iqbal >> PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu<http://pgp.mit.edu> >> A: Because it messes up the order in which people normally read text. >> Q: Why is top-posting such a bad thing? >> _______________________________________________ >> Xymon mailing list >> Xymon at xymon.com<mailto:Xymon at xymon.com> >> http://lists.xymon.com/mailman/listinfo/xymon >> > > > > > -- > Asif Iqbal > PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu<http://pgp.mit.edu> > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > > ________________________________ > > This e-mail message and any attached files are confidential and are > intended solely for the use of the addressee(s) named above. If you are > not the intended recipient, any review, use, or distribution of this > e-mail message and any attached files is strictly prohibited. > > This communication may contain material protected by Federal privacy > regulations, attorney-client work product, or other privileges. If you > have received this confidential communication in error, please notify the > sender immediately by reply e-mail message and permanently delete the > original message. To reply to our email administrator directly, send an > email to: postmaster at orlandohealth.com . > > If this e-mail message concerns a contract matter, be advised that no > employee or agent is authorized to conclude any binding agreement on > behalf of Orlando Health by e-mail without express written confirmation by > an officer of the corporation. Any views or opinions presented in this > e-mail are solely those of the author and do not necessarily represent > those of Orlando Health. >

8 25

Recovery notifications not generated when test goes red->yellow->green?
by hobbit＠elyograg.org 13 Dec '17

13 Dec '17

It appears that if a test goes from the red state, to the yellow state, and then to the green state, no recovery notification is sent. If it goes directly from red to green, then we get a notification. Initial notifications are only sent on RED and PURPLE. We have recovery notifications configured for most tests. Xymon server is 4.3.21, built using makerpm.sh and installed with yum on CentOS 6. I do not know whether our previous version (4.3.14) behaved similarly. It was almost an accident that I discovered the problem at all. Is this expected behavior? If it is, can I change it? Thanks, Shawn

4 3

Alert transition yellow -> red with repeat problem
by john.r.rothlisberger＠accenture.com 27 Nov '17

27 Nov '17

This problem contributed to an outage last night - something is wrong. Last night we had a disk that was in the warning state - warning email sent. That disk then went into an alert state and an alert email was triggered (right away as the DURATION value took into account the time it was yellow) and then again 15 minutes later as designed. THEN - another disk on that server went yellow. It did NOT trigger any emails (as expected we should continue to focus on the alerts) but it somehow interfered with the REPEAT time of the alerts and those STOPPED. There is a bug somewhere. Thanks, John Upcoming PTO: _____________________________________________________________________ John Rothlisberger IT Strategy, Infrastructure & Security - Technology Growth Platform TGP for Business Process Outsourcing Accenture 312.693.3136 office _____________________________________________________________________ From: Rothlisberger, John R. Sent: Tuesday, April 11, 2017 7:49 AM To: 'xymon >> xymon at xymon.com' <xymon at xymon.com> Subject: Alert transition yellow -> red with repeat problem This is a problem I have seen for a long long time and have actually brought it up on the list before. Xymon 4.3.21 Ubuntu 14.04LTS The problem I have (in this instance) a warning which is to be repeated daily suddenly goes red and triggers a single alert but doesn't repeat again until the repeat time of the warning has passed. >From the notification.log: Tue Mar 28 05:31:28 2017 ServerA.disk (IP) disk_warn 1490697082 100 <- warning sets a repeat time of 1 day Tue Mar 28 05:53:32 2017 ServerA.disk (IP) disk_alert 1490698405 100 <- minutes later it goes red (red repeat time is 15 minutes but no further alerts are generated) Next alert comes out 1 day after the above warning: Wed Mar 29 05:31:31 2017 ServerA.disk (IP) disk_alert 1490783486 100 <- 1 day after previous warning. This should have been repeated every 15 minutes. Wed Mar 29 05:46:40 2017 ServerA.disk (IP) disk_alert 1490784394 100 <- now, the repeat time is 15 minutes ... <- and continues every 15 minutes. This alert went a full 24 hours with only a single notification. :( I have seen this before (not always) where the repeat time in a warning overrides a follow up alert until the warning repeat time has expired. Alert rules: SCRIPT /home/xymon/server/ext/pg/exwarn_SCRIPT disk_warn DURATION>30 REPEAT=1d COLOR=yellow SERVICE=disk FORMAT=TEXT UNMATCHED SCRIPT /home/xymon/server/ext/pg/exalert_SCRIPT disk_alert DURATION>20 REPEAT=15 COLOR=red SERVICE=disk FORMAT=TEXT UNMATCHED Ideas/thoughts? Thanks, John Upcoming PTO: 4/3 _____________________________________________________________________ John Rothlisberger IT Strategy, Infrastructure & Security - Technology Growth Platform TGP for Business Process Outsourcing Accenture 312.693.3136 office _____________________________________________________________________ ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com

3 5

CLASS not working as expected
by steve＠opendium.com 07 Nov '17

07 Nov '17

Under Xymon 4.3.25, I'm trying to use the class attribute to group hosts together by what monitoring and alerting they need. So for each host I have a hosts.cfg line like: 192.0.2.1 somehost.example.com # CLASS:Foo trace ssh Then in analysis.cfg I have: CLASS=Foo PROC this PROC that And alerts.cfg has: CLASS=Foo SCRIPT=blah However, the tests in analysis.cfg are not being applied. If I replace CLASS=Foo with HOST=somehost.example.com they work as expected. Also, CLASS=linux seems to work, which implies that the CLASS: directive in the hosts.cfg is being ignored. As far as I can tell, the messages on xymon's "client" channel don't contain the class name that was specified in hosts.cfg, so xymond_client is using the class that the client sent instead. Other channels, such as "status" do include the class name that was specified in hosts.cfg. Am I misunderstanding how the class is supposed to be used, or is this a bug? -- - Steve Hill Technical Director Opendium Limited http://www.opendium.com Direct contacts: Instant messager: xmpp:steve at opendium.com Email: steve at opendium.com Phone: sip:steve at opendium.com Sales / enquiries contacts: Email: sales at opendium.com Phone: +44-1792-824568 / sip:sales at opendium.com Support contacts: Email: support at opendium.com Phone: +44-1792-825748 / sip:support at opendium.com

6 7

Bogus hosts filling up alert.log
by cleaver＠terabithia.org 01 Nov '17

01 Nov '17

On 10/31/2017 2:49 PM, Mills,David (HHSC Contractor) wrote: > Amendment: Eventually, Xymon did see the bogus entry for 0FS_96_192_168_22_1__export_ and it did stop appearing in the alert.cfg > > It's another data point, but this is kind of expected behavior and now I have just this bogus artifact hanging around. > > 'Any ideas where the alerts daemon gets its list of host names to check against? > > ;-) If there had been a previous alert for the virtual/fake host, it would have been stored in memory, and frozen out into the alerts.chk file (probably in /var/lib/xymon/tmp/ during restarts). The general reason for the alert is that xymond(_alert) is getting a report about something it doesn't (yet) know about. Usually, this clears a few minutes later as soon as xymond next checks hosts.cfg for changes, since typically that's the action pending to be taken. Similarly, when a host is removed from hosts.cfg (or a drop command), that message is passed to xymond_alert to clear its record of the alert as well. Adding the host to hosts.cfg and then dropping it should work for clearing out the errant alert. Alternatively, you can stop xymon (or at least xymond_alert, by adding DISABLED into tasks.cfg), grep out the line for the alert in alerts.chk manually (it's just a normal single-line-record text file, and then bring it back up. HTH, -jc

2 1

xymon "hostinfo" does not honour tags set by `.default.`
by thomas.eckert＠it-eckert.de 31 Oct '17

31 Oct '17

Brothers, I found that the information returned by `xymon 127.0.0.1 "hostinfo"` does not honour tags by `.default.`. Steps to reproduce: root at pi3:/etc/xymon# egrep -i 'default|pi3' hosts.cfg 0.0.0.0 .default. # nosslcert 127.0.0.1 pi3 # bbd http://pi3/ root at pi3:/etc/xymon# xymon 127.0.0.1:1984 "hostinfo host=^pi3" pi3|127.0.0.1|bbd|http://pi3/ (note the missing `nosslcert`-tag) Not using `.default.` the correct set of tags is returned: root at pi3:/etc/xymon# egrep -i 'default|pi3' hosts.cfg 127.0.0.1 pi3 # bbd http://pi3/ nosslcert root at pi3:/etc/xymon# xymon 127.0.0.1:1984 "hostinfo host=^pi3" pi3|127.0.0.1|bbd|http://pi3/|nosslcert This makes `hostinfo` not a usable source for getting the monitoring configuration for hosts or prevents the use of `.default.`. All the best Thomas

3 2

Bogus hosts filling up alert.log
by David.Mills＠hhsc.state.tx.us 31 Oct '17

31 Oct '17

Hi, all! I have recently set up a new Xymon (Xymon 4.3.28-1.el6.terabithia<http://xymon.sourceforge.net/>) server on RHEL 6.7 that, for the most part, is doing just fine. However, I've discovered that my /var/log/xymon/alert.log file is growing at a crazy rate to the point it periodically needs to zero'd-out or it will swamp the file system. The problem is every 15 seconds the /var/log/xymon/alert.log file receives a flurry of log entries like this: ... 2017-10-31 14:53:55 Checking criteria for host '0FS_94_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_94_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_94_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_94_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_94_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_94_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_94_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_94_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_95_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_95_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_95_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_95_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_95_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_95_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_95_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_95_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_96_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_96_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_96_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_96_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_96_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_96_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_96_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire 2017-10-31 14:53:55 Checking criteria for host '0FS_96_192_168_22_1__export_', which is not yet defined; some alerts may not immediately fire ... The '0FS_96_192_168_22_1__export_' is actually the name of a host I've defined in the past, but is no longer in xymon's memory (AFAIK!!) I have reduced the alerts.cfg down to a minimal stub, commenting out the "directory /etc/xymon/alerts.d/..." directive, "rm -r"'d any reference to this host (and others similar to it) under the data files directories (e.g. rrd/, hist/, histlogs/, hostdata/, etc.). I have gone as far as running "find /etc/xymon -type f | xargs egrep 0FS_" looking for "surprises". I've also stopped / restarted the server and scanned what's active in memory via "xymon localhost xymondboard | egrep 0FS_". This "host" is not a real client host but an artifact I've created on the server side to represent a file system I'm monitoring in a server-side ext script, so I know it is not announcing it's presence over port 1984. For the life of me I can't figure out where the alerts daemon is running across this hostname. Help? ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~ David Mills Systems Administrator Northrop Grumman (512) 595-1238 (mobile)

2 5

[XYMON] agents with pulldata - xymonfetch and ssh tunelling
by pierre.lapha＠gmail.com 31 Oct '17

31 Oct '17

Hello, I am trying to set up xymonfetch/msgcache with ssh tunnelling (because security does not want to open flows on port 1984). I have enabled xymonfetch (in tasks.cfg) and added pulldata (in hosts.cfg) on server side and also msgcache (in clientlaunch.cfg) and XYMSRV=127.0.0.1 (in xymonclient.cfg). I have done a ssh tunnel (ssh -L 1234:127.0.0.1:1984 IP_of_the_client) from the xymon server. My tunnel is ok but xymon logs still show that nothing happens, no pulldata. Is there something else I should do to enable this function? Any help would be appreciated. Thank you! Pierre

3 2

Graphing Question
by dl1025＠att.com 27 Oct '17

27 Oct '17

I was hoping you can give me some advice in regard to graphing data. I have data coming in that is posted in xymon with HTML tags. I need to parse the data out and post it into rrdtool then display it on the status page. I am fairly new to xymon, in BB I used bb-larrd.pl to parse the data and post it into rrd. What is the best way of doing it in xymon? I think there are several ways of accomplishing this in xymon if I am not mistaken: 1. As the data comes into xymon and displays on the status message, I can parse out the data that I need and send it through the rrd channel 2. I could also within the script that generates the data include an rrd module that will create the rrd file and post the results that I need directly to the rrdtool, but then I need to include it where so it can appear on the status page Any suggestions will be greatly appreciated. Here is an example of the data that I want to graph. This is how it appears on the status page. Orders in DF staging table by Process Flag Org Creation Date Process Flag Reqs with no Orders [red]FDC 10/19/17 P 458 [red]MDC 10/19/17 P 3249

2 1