August 2015 - Xymon - Xymon mailman web

Unexpected times on "Connection Times" graph
by hobbit＠elyograg.org 25 Aug '15

25 Aug '15

Here is a "connection times" graph from Xymon: https://www.dropbox.com/s/voyqnzfnsqaact9/xymonresponsegraph.png?dl=0 This shows "conn" times in the 40 millisecond rang, and "ssh" times in the 200 microsecond range. What is the source of the "conn" graph? I would have guessed ICMP, but it doesn't make any sense for a ping to take longer than an ssh connection, especially not that much longer. This is what I get if I ping that machine from the xymon server ... it doesn't take anywhere even CLOSE to 40 milliseconds: [root at mcp xymon]# ping palazzo PING palazzo.REDACTED.com (10.100.2.17) 56(84) bytes of data. 64 bytes from palazzo.REDACTED.com (10.100.2.17): icmp_seq=1 ttl=62 time=0.572 ms 64 bytes from palazzo.REDACTED.com (10.100.2.17): icmp_seq=2 ttl=62 time=0.582 ms 64 bytes from palazzo.REDACTED.com (10.100.2.17): icmp_seq=3 ttl=62 time=0.573 ms 64 bytes from palazzo.REDACTED.com (10.100.2.17): icmp_seq=4 ttl=62 time=0.611 ms 64 bytes from palazzo.REDACTED.com (10.100.2.17): icmp_seq=5 ttl=62 time=0.890 ms ^C --- palazzo.REDACTED.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4003ms rtt min/avg/max/mdev = 0.572/0.645/0.890/0.126 ms Can anyone shed light on this? My server config includes the following line: FPING="xymonping" My xymon server is version 4.3.14. Thanks, Shawn

5 6

Xymon Digest, Vol 55, Issue 21
by earle＠isolar.DynDNS.ORG 25 Aug '15

25 Aug '15

> On Aug 25, 2015, at 1:13 PM, Jeremy Laidman wrote: > > You might be right that the message is being clipped. If so, you should > see Xymon log messages to that effect. Thanks Jeremy, where in the logs exactly? Do I grep for "clipped"? :-) > Perhaps add the IGNORE clause to the client-local.cfg message instead. > This will cause the messages to be dropped at the client side. Not only > can you forget about these messages on the Xymon server, but also you're > less likely to have a clipped message. Like so: > > [sunos] > log:/var/adm/messages:10240 > ignore refused connect from itsecurity-scanner.my.do.main Excellent idea - hadn't thought of th... wait, hang on. The only place I have a "client-local.cfg" file is on my *server*, not on any of my clients. On Red Hat I've been using the Terabithia RPMs (where it comes in the main "xymon" RPM, not in the "xymon-client" or "xymon-client-local" RPMs), and on Solaris I built my my own Solaris (built via "./configure --client") package: myorgsun6:1:158 [/var/spool/pkg] # ls -Ll xymon-4.3.21-sol10-sparc-opt.pkg -rw-r--r-- 1 root root 8636416 Aug 17 20:01 xymon-4.3.21-sol10-sparc-opt.pkg The only things that get bundled in to a "make client" side build on Solaris are etc/clientlaunch.cfg, etc/localclient.cfg and etc/xymonclient.cfg. No client-local.cfg to be seen anywhere. Can I just drop one into etc and it'll automatically be picked up upon Xymon restart? If I put it on the client side, will it have any effect if I have the systems set up to play dumb client and not do any client-side processing, just sending all of the data across to the (Red Hat) server? I had the impression that only "xymond" cared about "client-local.cfg". > You could also increase the maximum from 10240. I'll try doubling it. Hopefully that won't affect server-side performance too much. I've got a good fast machine on that end. Cheers, - Greg

2 1

"msgs" alerts, sending 10240 bytes and line-buffering
by earle＠isolar.DynDNS.ORG 25 Aug '15

25 Aug '15

I'm having an issue on my Solaris clients running an older Xymon 4.3.12. (I have a test build of 4.3.21 waiting in the wings.) We constantly get scanned by our IT Security people, resulting in "/var/adm/messages" entries like Aug 24 09:23:39 myorgsun6 nrpe[15035]: [ID 808958 daemon.warning] refused \ connect from itsecurity-scanner.my.do.main (access denied) I put an IGNORE entry into "analysis.cfg" to ignore any lines with "itsecurity-scanner.my.do.main" but I keep getting them - they often look like this: -- red Mon Aug 24 09:55:37 PDT 2015 - Log files NOT ok &red Critical entries in <a href="/xymon-cgi/svcstatus.sh?CLIENT=myorgsun6&SECTION=msgs:/var/adm/messages">/var/adm/messages</a> &red ess denied) -- As you can see the "messages" entry has been clipped off leading to the raw "denied" string which triggered the alert. It's random - sometimes it's clipped down to "do.main access denied", for example. I'm using a bog-standard [sunos] log:/var/adm/messages:10240 entry in client-local.cfg. My theory is that by sending 10240 bytes of the "messages" file across, it leaves things open to the possibility of sending "clipped" lines - leading to partial lines that avoid my IGNORE string as a result. Am I correct? Is there anything in the newer releases that addresses this? - Greg

2 1

python variables in Xymon
by AAJOSE＠telmex.com 25 Aug '15

25 Aug '15

Hello, could help me, I find a way to display information generated in python output to the monitoring system big-brother. Example: if os.environ.has_key ('BB'): os.environ command = ['BB'] + "" + os.environ ['BBDISP'] + "\" status "+ os.environ ['MACHINE'] +." interface "+" "+ COLOR +" "+ TIME + pStatus + '"' DEBUGMODE if == 1: print command os.system (command) else: sys.stderr.write ("ERROR: set BB, BBDISP and MACHINE Variable environment to point to your installation \ n") sys.exit (1) Generates output information but only in the log file defined in the configuration file: clientlaunch.cfg Thanks for the support. José Trinidad Álvarez Aguilar Av. Epigmenio Gonzalez No. 2, Col. Parques Industriales, C:P.76150 Santiago de Querétaro, Qro. Tel. 101-82-36 [cid:image002.jpg at 01CE728C.FAF3C270] Infinitum, la mejor conexión. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail message including attachments, if any, is intended only for the person or entity to which it is addressed and may contain confidential and /or privileged material. Any review, use, disclosure or distribution of such confidential information without the written authorization of Teléfonos de México is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. By receiving this e-mail you acknowledge that any breach by you and/or your representatives of the above provisions may entitle Teléfonos de México to seek for damages. AVISO DE CONFIDENCIALIDAD: Este correo electrónico, incluyendo en su caso, los archivos adjuntos al mismo, pueden contener información de carácter confidencial y/o privilegiada, y se envían a la atención única y exclusivamente de la persona y/o entidad a quien va dirigido. La copia, revisión, uso, revelación y/o distribución de dicha información confidencial sin la autorización por escrito de Teléfonos de México está prohibida. Si usted no es el destinatario a quien se dirige el presente correo, favor de contactar al remitente respondiendo al presente correo y eliminar el correo original incluyendo sus archivos, así como cualesquiera copia del mismo. Mediante la recepción del presente correo usted reconoce y acepta que en caso de incumplimiento de su parte y/o de sus representantes a los términos antes mencionados, Teléfonos de México tendrá derecho a los daños y perjuicios que esto le cause.

2 3

Anyone get Magma addon to work?
by Russell.Blumenthal＠stonybrookmedicine.edu 24 Aug '15

24 Aug '15

Has anyone gotten this Magma addon (http://www.squidworks.net/software-projects/magma/) to work with any of the recent versions of Xymon? I would love to get some sort of web management so that the rest of IT don't rely on me to add new hosts, etc. Thanks This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by e-mail and destroy all copies of the original.

2 1

Email alerts
by NMaharaj＠tcta.co.za 24 Aug '15

24 Aug '15

2 1

notification.log when using a script
by Paul.Root＠CenturyLink.com 20 Aug '15

20 Aug '15

Never mind. It does go in there. I was parsing wrong. From: Root, Paul T Sent: Thursday, August 20, 2015 1:37 PM To: 'xymon' Subject: notification.log when using a script Hi, We recently change from directly paging to a script that interfaces with our corporate notification and escalation service. It looks like a script being called isn't logged in notifications.log. Which I parsed daily to see what kind of pages we got. Is there a way to have a script inject a message into notifications.log? Paul. Paul Root Lead Engineer CenturyLink Network Reliability Operations Center 390 Commerce Dr Woodbury, MN 55125 Direct: (651)312-5207 Paul.Root at centurylink.com<mailto:Paul.Root at centurylink.com> This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

1 0

notification.log when using a script
by Paul.Root＠CenturyLink.com 20 Aug '15

20 Aug '15

Hi, We recently change from directly paging to a script that interfaces with our corporate notification and escalation service. It looks like a script being called isn't logged in notifications.log. Which I parsed daily to see what kind of pages we got. Is there a way to have a script inject a message into notifications.log? Paul. Paul Root Lead Engineer CenturyLink Network Reliability Operations Center 390 Commerce Dr Woodbury, MN 55125 Direct: (651)312-5207 Paul.Root at centurylink.com This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

1 0

Disk Only Yellow?
by Nick＠pettefar.com 20 Aug '15

20 Aug '15

Hi, is it possible to just have a Yellow alert from a DISK filesystem alert? No Red at all - I don't want to be woken in the middle of the night by a non-critical disk filling up but still want to know about it when I read e-mails and view the Xymon web page. Regards, Nick Pettefar

4 5

Compiling xymon-4.3.19 on Solaris 10
by earle＠isolar.DynDNS.ORG 18 Aug '15

18 Aug '15

> On Aug 17, 2015, at 4:14 PM, Scott.Rebman at hhsc.state.tx.us wrote: > > Jeremy, > > Thanks for the info provided. > > This is the output of crle with no options: > > Default configuration file (/var/ld/ld.config) not found > Platform: 32-bit MSB SPARC > Default Library Path (ELF): /lib:/usr/lib (system default) > Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system default) > > I will try the other methods and let you know what worked out. Why build 4.3.19 when 4.3.21 is out? You should definitely use "crle" to create a "/var/ld/ld.config" so you can pick up those PCRE libraries. I just built 4.3.21 on a Solaris 10 1/13 box yesterday with -- sol10testmule:1:1001 [/] # crle Configuration file [version 4]: /var/ld/ld.config Default Library Path (ELF): /lib:/usr/lib:/usr/sfw/lib:/opt/mysql/lib/mysql:/usr/local/lib Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system default) Command line: crle -c /var/ld/ld.config -l /lib:/usr/lib:/usr/sfw/lib:/opt/mysql/lib/mysql:/usr/local/lib -- If you run something similar with "/usr/local/lib" in the argument list, it should pick up libpcre.so.0 after that. You could even throw your RRD path path (i.e. /usr/local/rrdtool-1.2.19/lib) in there as well, for good measure. Speaking of Solaris, make sure "/usr/bin" is at the front of $PATH when you do the build. Xymon unfortunately in a couple of places hard-codes the direct use of "sed" and "tr" (without making them be settable variables e.g. "${SED}"/"${TR}"), and the only pair that work properly are the ones in "/usr/bin". (For example, if you put "/usr/xpg4/bin" in front, then "sed" will work - but "tr" does not. If you have "/usr/ucb" in front, the "sed" it will pick up won't work. "/usr/bin/sed" and "/usr/bin/tr" both work properly.) - Greg

1 0