July 2014 - Xymon - Xymon mailman web

system reboot email alert
by Sue.Bauer-Lee＠Multiplan.com 12 Jul '14

12 Jul '14

Hello All! Times have changed a bit in the infrastructure environment such that many have a large contingent of virtual machines and blades. These hosts tend to reboot rather quickly, hence connectivity failures tend to not get noticed. I have a request on the table to send an email alert with a specific subject line to indicate that a host has rebooted. I've seen a few posts over the years regarding requests to alert for system reboots. I also saw a post or two about adding a dynamic column capability. Some responses suggested an external script to accomplish the task of emailing an alert. I'm asking the question again because as I peruse the analysis.cfg and review the rules, I know I can issue an email alert for PROC and DISK. That begs the question of 'why can't I issue an email alert for UP'? I'm fine with the 'yellow' on CPU test for recent reboot, but since it also includes load changes, I'm not interested in a generic email for either one when they occur. If I already can, how?? And if not, suggestions for a simple approach? I'm not exactly getting the desired results server-wide with an external script that should just send an email for a CPU status color=yellow without interfering with our other configured alerts. :( Is someone already successfully conquering this task? NOTICE OF CONFIDENTIALITY: This message and any attachments contains confidential information belonging to the sender intended only for the use of the individual or entity named above. If you are not the intended recipient, be advised that copying, disclosure or reliance upon the contents is strictly prohibited. If you have received this message in error please notify the sender immediately. ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________

5 8

Can client extension scripts use client-local.cfg data passed back to client?
by rlhamil2＠gmail.com 11 Jul '14

11 Jul '14

I'm gathering that said data ends up in $XYMONCLIENTHOME/tmp/logfetch.$MACHINEDOTS.cfg. Would it hurt anything to put (on the server) data in addition to the lines defined in the man page? Would it make it back to the above file? And if so, can a naming convention be recommended for user-defined lines that should avoid conflict with any future official lines? (maybe names that begin with site_ or something like that?) And if that's not all crazy...it would be cool if the library module to fetch the client-local.cfg for a host could check the timestamp on the file, and if changed, reload it (freeing all the old data structures first, so as not to leak memory, of course!) That way, without restarting the server, one could replace the client-local.cfg file on the server and have client log, file, and extension script behavior altered accordingly. Having used Big Brother for many years, the ability of Xymon to pass updates and _some_ client control information to the client, without one inventing one's own backchannel (using ssh or whatever), sounds like it could make life _much_ simpler in terms of centralizing the control of clients and server alike. So naturally I want to take that to its logical extreme. :-) But so far, I haven't read enough of the code to really have a good handle on just what might be possible, let alone normal enough not to be too fragile.

3 2

stop monitoring memory
by didds3＠yahoo.co.uk 10 Jul '14

10 Jul '14

Hobbit version 4.2.3 in both server and client. client has the MEMORY checks commented out of localclient.cfg - memory alerts/info was still showing on the server. Then a bit iof dgiiging showed that vmstat was still being run in hobbitclient-linux.sh, so the appropriate ;ines were commented out. vmstat is no longer being run on the client. But the server ( after "drop ,<client> memory" ) still report memory from this client. what else may be reporting this then? i am assuming some server side thing but I can;t see where from? didds

2 4

stop monitoring memory
by didds3＠yahoo.co.uk 10 Jul '14

10 Jul '14

thanks jeremy... server OS is CentOS release 5.5 client OS is CentOS release 6.4 I did find some gumf about uising a bb-hosts entry XXX.XXX.XXX.XXX client # NOCOLUMNS:memory to at least avoid showing the reports/monitor but that made absolutely zero difference so i have no idea what on earth that is about :-) cheers ian ________________________________ From: Jeremy Laidman <jlaidman at rebel-it.com.au> To: Ian Diddams <didds3 at yahoo.co.uk> Cc: "xymon at xymon.com" <xymon at xymon.com> Sent: Thursday, 10 July 2014, 4:48 Subject: Re: [Xymon] stop monitoring memory On 9 July 2014 20:43, Ian Diddams <didds3 at yahoo.co.uk> wrote: Oh - as I understand this is in local mode. > My understanding is that in local mode, the memory data is analysed and sent by xymond_client. Perhaps you could run this with the "--debug" switch to see what's going on. Also, you could use a xymond_channel command on the server to watch the memory status messages come in, to check whether they're coming from the client. Something like: xymond_channel --channel=status --filter='name-of-host.*\|memory\|' cat As far as I can tell from reviewing the code, the xymond_client program gets its memory numbers from the client data, but it uses different section names depending on the OS. For Linux, it looks only in [free], for FreeBSD it looks in [meminfo] and [swapinfo], and for Solaris it looks in [memory], [swap] and [swaplist]. What OS are you using? Cheers Jeremy

1 0

alerts
by NMaharaj＠tcta.co.za 10 Jul '14

10 Jul '14

<html><body>Hi, Im not receiving emails. This is the configuration in the alerts.cfg file. Please advise. HOST=* SERVICE=cpu,conn,disk,svcs,http,smtp,dns MAIL techsupport at xxxx.xx.xx DURATION>5 REPEAT=60 RECOVERED Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and automatically archived by Mimecast SA (Pty) Ltd, an innovator in Software as a Service (SaaS) for business. Mimecast Unified Email Management (UEM) offers email continuity, security, archiving and compliance with all current legislation. To find out more, visit http://www.mimecast.co.za/uem.</body></html>

3 7

alert IGNORE
by sidiney＠redix.com.br 10 Jul '14

10 Jul '14

Hello, I need to ignore a message on xymon Critical entries in /var/log/secure red -> error='' On server log: Jun 25 09:21:14 mailserver saslauthd[28318]: zmpost: url=' https://mailserver.domain.com.br:7071/service/admin/soap/' returned buffer->data='<soap:Envelope xmlns:soap=" http://www.w3.org/2003/05/soap-envelope"><soap:Header><context xmlns="urn:zimbra"><change token="30213"/></context></soap:Header><soap:Body><AuthResponse xmlns="urn:zimbraAccount"><authToken>0_b4e7e2ade952b00a8028cf4e80d489c2b0138b8e_69643d33363a36666134643163352d626664302d343239352d626234302d3837306532346138336662353b6578703d31333a313430333837313637343034363b76763d313a303b747970653d363a7a696d6272613b</authToken><lifetime>172800000</lifetime><skin>serenity</skin></AuthResponse></soap:Body></soap:Envelope>', hti->error='' Sentinela configuration: /usr/lib/xymon/server/etc/client-local.cfg log:/var/log/secure:10240 ignore saslauthd.*\[.*\]:.* ignore .*hti.*error.* ignore .*hti.* ignore ti->error.* But even so the messages are still appearing, there is something more that should be done?

2 2

custom graphs
by Paul.Root＠CenturyLink.com 09 Jul '14

09 Jul '14

Hi, This is one of my least favorite things of xymon. It really shouldn't be this hard. I've had a script that pulls the %mem of certain processes on various machines. Right now, I have 3 separate groups of machines with different processes being watched. The purpose is to track memory leaks. Previously, I had the script just put out a ps -eo 'pid,%mem,cmd' for the desired processes. Then others wanted a graph, so I've reformatted the output to be just a keyword (either the process name or a significant field of the arguments of the command). I get something that looks like this now: Process Memory Usage SA: 6.5 MBIM: 2.4 OI: 4.1 Process' alert levels are defined in /usr/local/etc/procmem.cfg When levels are exceeded, restarting of the process to free memory is recommended xymProcMem,v 1.7 2014/07/07 20:37:17 ptroot Exp ptroot $ My first iteration, I used <br> to separate the lines. That was a mistake, the source of the html showed them all on one line. I've changed to \n, and that to me should provide the proper output. However, looking at the rrd dump, I only get the first one: <rrd> <version> 0003 </version> <step> 300 </step>  <lastupdate> 1404828303 </lastupdate>  <ds> <name> SA </name> <type> GAUGE </type> <minimal_heartbeat> 600 </minimal_heartbeat> <min> NaN </min> <max> NaN </max>  <last_ds> 6.5 </last_ds> <value> NaN </value> <unknown_sec> 3 </unknown_sec> </ds> <ds> <name> xymProcMemv16201407 </name> <type> DERIVE </type> <minimal_heartbeat> 600 </minimal_heartbeat> <min> NaN </min> <max> NaN </max>  <last_ds> 50 </last_ds> <value> NaN </value> <unknown_sec> 3 </unknown_sec> </ds> My TEST2RRD looks like: TEST2RRD="cpu=la,disk,inode,...,nfmsgw=ncv,hpnasnapshot=ncv,ProcMemory=ncv" And the NCV definitions: NCV_hpnasnapshot="TotaldevicesinDB:GAUGE,Totalactivedevicesi:GAUGE,Totalinactivedevice:GAUGE,Totaldeviceswithout:GAUGE,Pctactive:GAUGE,Pctinactive:GAUGE,Pctnodriver:GAUGE,Activeattemptedsucc:GAUGE,Activeattemptedunsu:GAUGE,Activebutnotattempt:GAUGE,PctAttemptedsuccess:GAUGE,PctAttemptedunsucce:GAUGE,PctActivebutnotatte:GAUGE" NCV_ProcMemory="SA:GAUGE,MBIM:GAUGE,OI:GAUGE,MNS1:GAUGE,NMS1:GAUGE,NMS2:GAUGE,NMS11:GAUGE,NMS12:GAUGE,NMS13:GAUGE,NMS14:GAUGE,NMS15:GAUGE,TCMgmtEngine:GAUGE,TCTFTP:GAUGE,TCSyslog:GAUGE,SWIM:GAUGE" The hpnasnapshot graph works. I've been using it as an example. Obviously, without all the data in the rrd, there is no point in trying to get a graph to show. Any ideas from anyone? Thanks, Paul. Paul Root Lead Engineer CenturyLink Network Reliability Operations Center 600 Stinson Blvd, N.E. Flr 2N Minneapolis, MN 55413 Direct: (651)312-5207 Paul.Root at centurylink.com

3 3

[PATCH] configure: error on unknown arg
by kdreyer＠usgs.gov 09 Jul '14

09 Jul '14

Prior to this commit, if a user ran configure with an unrecognized argument, the configure script would silently fail. Handle the case of unknown arguments by printing an error and exiting with a non-zero exit code. --- configure | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/configure b/configure index 9173658..4b97fed 100755 --- a/configure +++ b/configure @@ -15,15 +15,22 @@ chmod 755 $BASEDIR/configure* $BASEDIR/build/*.sh $BASEDIR/client/*.sh case "$TARGET" in "--client") $BASEDIR/configure.client $* + exit 0 ;; "--server"|"") $BASEDIR/configure.server $* + exit 0 ;; "--help") echo "To configure a Xymon server: $0 --server" echo "To configure a Xymon client: $0 --client" + exit 0 + ;; + *) + echo "unrecognized $0 target $TARGET" + exit 1 ;; esac -- 1.9.0

1 2

mainframe monitoring
by Thomas.S.Sutch＠BNYMellon.com 08 Jul '14

08 Jul '14

Does anyone know if there is a client for the mainframe, or some way to monitor when a mainframe is up and the status besides a basic ping test? The information contained in this e-mail, and any attachment, is confidential and is intended solely for the use of the intended recipient. Access, copying or re-use of the e-mail or any attachment, or any information contained therein, by any other person is not authorized. If you are not the intended recipient please return the e-mail to the sender and delete it from your computer. Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses. Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures relating to European legal entities.

3 2

xymond core dumping (probably more for JC) Address out of bounds
by sean.clark＠twcable.com 08 Jul '14

08 Jul '14

JC – I installed the trunk version of xymond from terabithia – that fixed my core dump in all the deployments I had but one This one, it’s core dumping every 1-2 minutes (same OS/libraries/kernels as all the other hosts – CentOS 5.10, latest kernel) It dumps here: #6 0x0805619c in do_message (msg=0x3099c5c8, origin=0x8073d92 “", can_respond=1) at xymond.c:4025 ( response = newstrbuffer(lastboardsize); ) Here are all the symbols I could get: #6 0x0805619c in do_message (msg=0x3099c5c8, origin=0x8073d92 "", can_respond=1) at xymond.c:4025 hosthandle = <value optimized out> lwalk = <value optimized out> firstlog = <value optimized out> trendstest = {name = 0x7b <Address 0x7b out of bounds>, clientsave = 5} infotest = {name = 0x1e1000 "", clientsave = 131080} logfields = 0x3052f888 havehostfilter = 0 fields = 0x18068567 "hostname,testname" response = <value optimized out> infologrec = {host = 0x2bbe58a0, test = 0xbff1b6f0, origin = 0x0, color = 0, oldcolor = 0, activealert = 0, histsynced = 0, downtimeactive = 0, flapping = 0, oldflapcolor = 0, currflapcolor = 0, testflags = 0x0, grouplist = 0x0, sender = '\000' <repeats 15 times>, lastchange = 0x2afffbd8, logtime = 0, validtime = 0, enabletime = 0, acktime = 0, redstart = 0, yellowstart = 0, maxackedcolor = 0, message = 0x8073d92 "", msgsz = 0, dismsg = 0x0, ackmsg = 0x0, cookie = 0x0, cookieexpires = 0, metas = 0x0, modifiers = 0x0, acklist = 0xb0ada5, statuschangecount = 0, next = 0xb0ada5} rrdlogrec = {host = 0x2bbe58a0, test = 0xbff1b6f8, origin = 0x0, color = 0, oldcolor = 0, activealert = 0, histsynced = 0, downtimeactive = 0, flapping = 0, oldflapcolor = 0, currflapcolor = 0, testflags = 0x0, grouplist = 0x0, sender = '\000' <repeats 15 times>, lastchange = 0x2afffbd8, logtime = 0, validtime = 0, enabletime = 0, acktime = 0, redstart = 0, yellowstart = 0, maxackedcolor = 0, message = 0x8073d92 "", msgsz = 0, dismsg = 0x0, ackmsg = 0x0, cookie = 0x0, cookieexpires = 0, metas = 0x0, modifiers = 0x0, acklist = 0x0, statuschangecount = 0, next = 0xbff1b58c} logfilter = 0x3099c5a8 acklevel = -1 h = <value optimized out> t = <value optimized out> log = <value optimized out> color = <value optimized out> downcause = <value optimized out> sender = "10.25.9.133\000\000\000\000" grouplist = <value optimized out> now = 1404413120 timeroffset = <value optimized out> nesting = 1 lastboardsize = 25771930 lastboardsize = 0 lastboardsize = 490 #7 0x0805ac98 in main (argc=12, argv=0x3) at xymond.c:5825 seltmo = {tv_sec = 0, tv_usec = 50000} fdread = {__fds_bits = {529408, 0 <repeats 31 times>}} maxfd = <value optimized out> backfeeddata = <value optimized out> fdwrite = {__fds_bits = {0 <repeats 32 times>}} n = 0 childstat = 10534789 bfqexiting = <value optimized out> cwalk = 0x3099c5c8 now = 1404413120 connhead = 0x172d7a18 conntail = 0x3099c5c8 listenip = 0x8073eb7 "0.0.0.0" listenport = 1984 hostsfn = 0x83ad660 "!/etc/xymon/hosts.cfg" restartfn = 0x83ad5b0 "\003" logfn = 0x83ad600 "/var/log/xymon/xymond.log" checkpointinterval = 300 do_purples = 1 nextpurpleupdate = 1404413457 laddr = {sin_family = 2, sin_port = 49159, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"} lsocket = 3 opt = 1 listenq = 8192 argi = 12 tv = {tv_sec = 1404412785, tv_usec = 794754} tz = {tz_minuteswest = 240, tz_dsttime = 0} daemonize = 0 pidfile = 0x83ad560 "/var/log/xymon/xymond.pid" sa = {__sigaction_handler = {sa_handler = 0x8049c80 <sig_handler>, sa_sigaction = 0x8049c80 <sig_handler>}, sa_mask = {__val = {0 <repeats 32 times>}}, sa_flags = 0, sa_restorer = 0} conn_timeout = 30 envarea = 0x0 create_backfeedqueue = 0 nexttcpcheck = 1404413121 tcpcheckinterval = 1 Any ideas on what I should try next for this guy? -Sean ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

2 2