- Xymon - Xymon mailman web

Invitation to connect on LinkedIn
by alekix＠gmail.com 12 Apr '12

12 Apr '12

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Alessandro Alessandro Menezes M/LWD at Weatherford Aracaju Area, Brazil Confirm that you know Alessandro Menezes: https://www.linkedin.com/e/-l0z2mv-h0y3redg-1q/isd/6656182027/hi0qwC9_/?hs=… -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/-l0z2mv-h0y3redg-1q/vwngLOxQ5U95XrzWHw2r9ep65z/go… (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

1 0

Couple of Add-ons to make life easier
by gudm00＠gmail.com 12 Apr '12

12 Apr '12

http://www.xymonton.org/addons:redboard http://www.xymonton.org/addons:column_overview We use these everyday and find them extremely useful. hope you enjoy them too regards Gudmo

2 4

Include full command line in top output
by lists＠dzpconsulting.com 12 Apr '12

12 Apr '12

I'd like to change the contents of the CPU test details page to include the full command line in the top output. As I don't have my head wrapped fully around how xymon renders this data, I'm not certain where to start. I've modified the client side to include the -c option but it still looks like the client data is truncating on some default width… Any help would be appreciated. -- Michael Hobbs

3 4

Question on filesystem line processing for Windows in do_disk.c for UNC resources
by malcolm.hunter＠gmx.com 12 Apr '12

12 Apr '12

Hi Mark, > ----- Original Message ----- > From: Deiss, Mark > Sent: 04/12/12 02:25 PM > To: xymon at xymon.com > Subject: [Xymon] Question on filesystem line processing for Windows in do_disk.c for UNC resources > > I am not sure about how BBWIN is reporting its Windows client metrics; > MrBig for Windows reports file system usage in the following format: > > > Filesystem 1k-blocks Used Avail Capacity Mounted > C 15727603 8740006 6987597 55.6% /FIXED/C > D 277225672 6502600 270723072 2.3% /FIXED/D > > > Limits: > Drive Yellow Red > D 70.0 80.0 > C 70.0 80.0 > Default 90.0 95.0 > > We have some clustered Windows 2008 servers that are using shared > resources that are only referenced by their UNC paths - they do not have > logical drive assignments. Was wondering whether this would cause any > issues with the processing in do_disk.c section: > > > /* > * Some Unix filesystem reports contain the word > "Filesystem". > * So check if there's a slash in the NT filesystem > letter - if yes, > * then it's really a Unix system after all. > */ > if ( (dsystype == DT_NT) && (*(columns[5])) && > (strchr(columns[0], '/')) ) > dsystype = DT_UNIX; > > > Where the columns[5] would be referring to the "Mounted" column in the > MrBig output, and columns[0] would be referring to the Filesystem > column. The above logic is not being performed as a block step against > the overall client's disk output but rather on a line by line basis of > the disk output. The first occurrence matched will flip the subsequent > data processing flow from Windows based to Unix based even for > subsequent disk lines from the same client. > > My question is whether the presence of UNC only mounts would be > represented with backslashes (\) with the BBWIN/MrBig/whatever Windows > reporting modules or whether they may end up converted to forward > slashes (/) and thus falsely trigger the dsystype switch. The only > affect on the subsequent processing is whether the Filesystem column > (Windows OS) is used for storing the diskname (and generation of the rrd > file name) or the "Mounted on" column is used for the diskname (Unix > OS). > If the UNC representation can cause this false flip, then > initial Windows disk lines that are using logical drive assignments > would be stored and referenced using the one column reference and once a > UNC line is encountered, then it and all subsequent lines (including > logical drive assignment lines) would be using the other column > reference convention. > Things could get busy if the line order varies from time to time > (i.e. addition/removal of a UNC resource); then a logical drive time > stamped data line may go in at times as a "Filesystem" rrd file, other > times as a "Mounted on" rrd file. > > setupfn2("%s%s.rrd", testname, diskname); > > As I don't yet have any clients installed in these clustered Windows > boxes or UNC only mounts on other boxes, I don't know what the "Mounted > on" column output would look like for the UNC resource. If > BBWIN/MrBig/whatever are not reporting on UNC resources then that's > going to be an (separate) issue for us too. > > Possible fix if this is an issue: > > Was wondering if all the Windows clients (BBWIN/MrBig/whatever) all > reliable report the last column with the "Mounted" header tag and > whether all the Unix/Linux/BSD variants report their last column with > the "Mounted on" header tag. If so then maybe a better way to handle > this is to run a check against the overall client disk msg block for the > string pattern of "Mounted on" instead. Change do_disk.c section: > > else if (strstr(msg, "Filesystem")) dsystype = DT_NT; > else dsystype = DT_UNIX; > > to > > else if (strstr(msg, "Filesystem")) dsystype = DT_NT; /* This > will trigger for Windows and Unix/Linux flavors */ > else if (strstr(msg, "Mounted on")) dsystype = DT_UNIX; /* Assuming all > unix/linux/BSD clients report with "Mounted on" and Windows clients only > report with "Mounted" in their header line */ See this update in Subversion trunk: http://xymon.svn.sourceforge.net/viewvc/xymon?view=revision&revision=6708 Malcolm -- BBWin Development - The Windows client for Big Brother and Xymon http://bbwin.sourceforge.net http://xymon.sourceforge.net

1 0

Bug and patch - directory name not displayed in error message
by john.horne＠plymouth.ac.uk 11 Apr '12

11 Apr '12

Hello, Using Xymon 4.3.7 I see in my /var/log/xymon/xymonlaunch.log log file the following error: =================================== 2012-03-12 16:07:57 Loading tasklist configuration from /home/xymon/server/etc/tasks.cfg 2012-03-12 16:07:57 Cannot open directory =================================== This isn't too much use since it doesn't say what directory it is trying to open. It seems the problem is in the file lib/stackio.c (around line 338). A patch to fix this is here: ========================================== --- lib/stackio.c.orig 2011-07-31 22:01:52.000000000 +0100 +++ lib/stackio.c 2012-03-12 16:07:34.619479967 +0000 @@ -338,7 +338,7 @@ if (*dirname == '/') strcpy(dirfn, dirname); else sprintf(dirfn, "%s/%s", stackfd_base, dirname); if ((dirfd = opendir(dirfn)) == NULL) { - errprintf("Cannot open directory %s\n", fn); + errprintf("Cannot open directory %s\n", dirfn); return; } ========================================== (Sorry about the line wrapping.) John. -- John Horne Tel: +44 (0)1752 587287 Plymouth University, UK Fax: +44 (0)1752 587001

2 1

useradm.c - possible bug
by john.horne＠plymouth.ac.uk 11 Apr '12

11 Apr '12

Hello, In Xymon 4.3.7 the useradm.c file around line 126 shows: ================================ cmd = (char *)malloc(1024 + strlen(passfile) + strlen(adduser_name) + strlen(adduser_password)); sprintf(cmd, "htpasswd -b '%s' '%s' '%s'", passfile, adduser_name, adduser_password); n = system(cmd); n = system(cmd); ret = WEXITSTATUS(n); ================================ Just wondering why 'n = system(cmd)' is run twice? John. -- John Horne Tel: +44 (0)1752 587287 Plymouth University, UK Fax: +44 (0)1752 587001

2 1

Bug report for RRD graphs generated from devmon.
by KK1051＠att.com 11 Apr '12

11 Apr '12

I have found that RRD graphs that are generated from Devmon test that have a Note or other text after the "TABLE:rrd(DS:ds0:ifInEps:GAUGE)" section get counded as a line to link to a graph. Here is a sample:  Note: Error rates are per second, averaged over a 60 second interval. EEM errors match up with triggers set in EEM scripts using the inInErrors delta counter. The EEM script on the routers watch the counter and triggers the script when it crosses 10 errors. Then it holds the path out of OSPF till the error count drops back to Zero. This test will go yellow when one error is counted then turn red at 10. This is so we can see events leading up to the script triggering then monitor till it clears. When the script runs to build the page it finds the " line. I was getting 7 extra links to graphs for every host. If you see my Note: is 7 lines. I removed this and no longer get the extra links. I confirmed further checking the web page source and could see that the <-- linecount= was exactly 7 more than the lines before the --> of the RRD section. Kevin H. King Engineer V Implementations AT&T 404-444-0410 "You can not please everyone everyday, But everyday please everyone you can" -me

1 0

autofixing
by lebarber＠gmail.com 11 Apr '12

11 Apr '12

Resending to the list, Gmail seems to be hiding the "reply to all". Thanks, Larry Barber On Fri, Apr 6, 2012 at 4:28 PM, Larry Barber <lebarber at gmail.com> wrote: > The kind of things that you can automate should be handled routinely, not > be triggered by an alert from your monitoring tool. If you have logs > growing to fast that they are filling up you file system you should find > out what is filling them up and why and then fix that. Automatic log > rotation and compression should be done by a tool like logrotate, not Xymon > or any other monitoring tool. You shouldn't be using a monitoring tool to > trigger routine maintenance, it simply causes unnecessary alerts that cause > problems in other areas. > > Thanks, > Larry Barber > > > On Fri, Apr 6, 2012 at 4:06 PM, KING, KEVIN <KK1051 at att.com> wrote: > >> Larry,**** >> >> ** ** >> >> Some auto correcting is not bad. Back in the Big brother days I had a >> datacenter and team of folks. We managed to the “yellow” alerts. I had >> folks correct and build scripts to address the things that brought on the >> yellow so we never saw the red. This made it so very little red was ever >> seen.**** >> >> ** ** >> >> Now the things you can automate are the disk full kind of things. If that >> happens you can run a script to clean logs compress and that stuff. This >> was usually handled by managing the yellow. There would be a script in >> place to keep the space to below the yellow trigger. So if you got a red it >> was usually a bug temp file or something that would get cleaned shortly. So >> say on the red alert you could have it run the cleanup script rather than >> waiting for your cron to do the normal cleanup.**** >> >> ** ** >> >> Now on other issues it really depends on what the alert is about. You >> cannot automate everything economically. At some point it is cheaper and >> faster to put a human in the loop. I did have a script that would take the >> e-mail response from the alert and we could have it parse the message and >> do the work. This was back in the day with the RIM pagers. So you got an >> alert you replied to the alert with “run clean script on host” The reply >> e-mail was parsed in by the same script we were using to acknowledge the >> alert. It would parse and run a clean script. This let my admins be able to >> work issues while away from a PC or network connection.**** >> >> ** ** >> >> I do hear and agree with your concerns. A blanket statement from managers >> that do not have a full understanding of all the elements is a ruff thing >> to swallow. But there heart is in the right spot J **** >> >> ** ** >> >> I guess in a rather long rambling way I am saying that you learn and tune >> your systems. Address re-occurring issues so they do not. Then watch for >> the next thing to be addressed.**** >> >> ** ** >> >> ** ** >> >> -Kevin**** >> >> ** ** >> >> ** ** >> >> *From:* xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] *On >> Behalf Of *Larry Barber >> *Sent:* Friday, April 06, 2012 1:43 PM >> *To:* xymon at xymon.com >> *Subject:* [Xymon] autofixing**** >> >> ** ** >> >> My management has gotten the idea that we should be automating the repair >> processes on our servers. They want things set up so that when a fault is >> detected a script is run that attempts to repair it. I've tried to convince >> them that this is a profoundly wrong-headed idea, but I'm not having much >> luck. Do any of you know of any articles or resources that might help >> convince them? >> >> Thanks, >> Larry Barber**** >> > >

6 6

Feature - NTP stratum too high - test shows yellow
by john.horne＠plymouth.ac.uk 11 Apr '12

11 Apr '12

Hello, Using Xymon 4.3.7 the NTP test currently shows a green result if the NTP daemon is running, and red if not. However, what we want to know is if the NTP daemon is running, but not synchronised to any high stratum clock. When this happens the NTP daemon will return time based on the servers own local clock (if so configured), and this will usually be a low stratum value (on RHEL/CentOS this is stratum 10). We don't want this, and want to be warned if it happens. Attached is a patch which will allow admins to specify at what stratum level the 'ntp' test should turn yellow. If the returned stratum value (from 'ntpdate') is greater than or equal to the given value, then the 'ntp' test will show yellow. If the stratum is not specified, then the ntp test uses the default behaviour (that is, no test of the stratum value). This does not work if sntp is used. I had a look at this, but it seems that older versions of sntp did not return the stratum value. New versions do, but as far as I can gather sntp is not usually supplied because of licensing problems. John. -- John Horne Tel: +44 (0)1752 587287 Plymouth University, UK Fax: +44 (0)1752 587001

5 9

Question on rrd parsing of disk report
by Mark.Deiss＠acs-inc.com 11 Apr '12

11 Apr '12

It looks like I need to spend time with the xymond/rrd/do_disk.c source code. I can see where the code would have an issue handling the BB test variant. Have not figured out why the xymonclient df report section would also be acting up. -----Original Message----- From: Deiss, Mark Sent: Wednesday, April 11, 2012 10:51 AM To: xymon at xymon.com Subject: Question on rrd parsing of disk report I am running into an issue with my 4.33 and 4.37 Xymon servers with the received disk test results. I am running cases of either the BB df test or the Xymonclient module that reports df results. In both cases, the header line from the df output is being processed into an rrd database file and into graph entries (on 4.33 and 4.37 servers). I am not seeing this bahaviour with the Xymon demo site; the df header line is appearing in the disk detail web page; the graphs look fine there. Which file(s) should I be looking at where the df header line should be suppressed for rrd purposes? I thought maybe this would be defined in one of the configuration files but now am thinking it may be explicitly handled in of the C binaries. Googling around I see where there is mention of special filters required for usage with custom scripts but no mention on how the standard tests are being massaged to eliminate chaff lines.

1 0