October 2014 - Xymon - Xymon mailman web

[Devmon] devmon mysterious behaviour
by christian.becker＠rhein-zeitung.net 31 Oct '14

31 Oct '14

Hello Ryan, hm, i should have thought about this by myself already. Your description regarding the concurrent snmp polls sounds reasonable to me. I'll give this a try over the weekend and deactivate devmon in the "old" environment, so that I have devmon activated in the "new" environment only. The issue with the lib paths and sym links is OK since devmon is running in general; further, the "old" environment is 64 Bit too. Thank so far! Regards Christian Becker IT-Services Christian.Becker at rhein-zeitung.net _________________________________ Mittelrhein-Verlag GmbH August-Horch-Straße 28 D-56070 Koblenz Verleger und Geschäftsführer: Walterpeter Twer Reg.-Gericht Koblenz HRB 121 Finanzamt Koblenz Str.Nr. 22 65 10 285 2 www.rhein-zeitung.de -----Ursprüngliche Nachricht----- Von: Ryan Rush [mailto:ryanmrush at gmail.com] Gesendet: Freitag, 31. Oktober 2014 09:16 An: devmon-support at lists.sourceforge.net Cc: xymon at xymon.com Betreff: Re: [Devmon] devmon mysterious behaviour Are there any concurrent snmp polls running? I have noticed that when testing, older Cisco hardware will queue new walks when one is running. If the runtime if the current poll exceeds timeout on the new poll, one might experience the symptoms you are describing. Verify no other polls are occurring, then check your lib paths. I have experienced issues when migrating older code to 64 bit Linux systems, and resolved the problems with sym links after reviewing debugs. On Oct 31, 2014 1:05 AM, "Becker Christian" < christian.becker at rhein-zeitung.net> wrote: > Hello folks, > > we are running a Xymon 4.3.11 environment that persists of a server > running Red Hat Enterprise Linux 6.1 64 Bit. This setup also includes > devmon (0.3.1-beta1). In this environment, devmon works like a charm. > > Now we are in the situation to go away from Red Hat Enterprise Linux > and go ahead to Ubuntu 14.0.4.1 LTS 64 Bit. This is an internal decision. > On this new environment I have set up Xymon 4.3.17, including devmon, > which is the same release as in our "old" environment. > > But here, I have mysterious problem, for which I cannot find an > explanation: > In the "old" environment, there is a Cisco 6506, that is "asked" by devmon. > For any reason, in this environment devmon doesn't get any data out of > this Cisco device. It says "Missing repeater data for primary OID #######" > (the "#######" is just an example....). > > The mysterious thing now is, that in the "new" environment, devmon > (some > times...) extracts data out of this Cisco device, but -and this is the > most confusing thing- every now and then it is changing from "purple" to "clear" > (again saying "Missing repeater data for primary OID ####### ".), and > on any time it changes back to "green" containing current data. > > The devmon logfile doesn't seem to contain any hint on this situation. > > I have really no idea why this could happen. > > Does anybody of you have an idea about this behavior? > > Greetings > Christian > > Christian Becker > IT-Services > > Christian.Becker at rhein-zeitung.net<mailto: > Christian.Becker at rhein-zeitung.net> > _________________________________ > Mittelrhein-Verlag GmbH > August-Horch-Straße 28 > D-56070 Koblenz > Verleger und Geschäftsführer: Walterpeter Twer Reg.-Gericht Koblenz > HRB 121 Finanzamt Koblenz Str.Nr. 22 65 10 285 2 > www.rhein-zeitung.de<http://www.rhein-zeitung.de/> > > > ---------------------------------------------------------------------- > -------- _______________________________________________ > Devmon-support mailing list > Devmon-support at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/devmon-support > ------------------------------------------------------------------------------ _______________________________________________ Devmon-support mailing list Devmon-support at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/devmon-support

1 0

devmon mysterious behaviour
by christian.becker＠rhein-zeitung.net 31 Oct '14

31 Oct '14

Hello folks, we are running a Xymon 4.3.11 environment that persists of a server running Red Hat Enterprise Linux 6.1 64 Bit. This setup also includes devmon (0.3.1-beta1). In this environment, devmon works like a charm. Now we are in the situation to go away from Red Hat Enterprise Linux and go ahead to Ubuntu 14.0.4.1 LTS 64 Bit. This is an internal decision. On this new environment I have set up Xymon 4.3.17, including devmon, which is the same release as in our "old" environment. But here, I have mysterious problem, for which I cannot find an explanation: In the "old" environment, there is a Cisco 6506, that is "asked" by devmon. For any reason, in this environment devmon doesn't get any data out of this Cisco device. It says "Missing repeater data for primary OID #######" (the "#######" is just an example....). The mysterious thing now is, that in the "new" environment, devmon (some times...) extracts data out of this Cisco device, but -and this is the most confusing thing- every now and then it is changing from "purple" to "clear" (again saying "Missing repeater data for primary OID ####### ".), and on any time it changes back to "green" containing current data. The devmon logfile doesn't seem to contain any hint on this situation. I have really no idea why this could happen. Does anybody of you have an idea about this behavior? Greetings Christian Christian Becker IT-Services Christian.Becker at rhein-zeitung.net<mailto:Christian.Becker at rhein-zeitung.net> _________________________________ Mittelrhein-Verlag GmbH August-Horch-Straße 28 D-56070 Koblenz Verleger und Geschäftsführer: Walterpeter Twer Reg.-Gericht Koblenz HRB 121 Finanzamt Koblenz Str.Nr. 22 65 10 285 2 www.rhein-zeitung.de<http://www.rhein-zeitung.de/>

3 2

DOWNTIME - emails with "disabled"
by bdale＠kitchen-net.com.au 30 Oct '14

30 Oct '14

I have a host, in hosts.cfg I have downtime set like so DOWNTIME=*:2200:0800 What happens is for example say this hosts goes offline at 2130 I get an email saying conn CRITICAL (RED) in the subject , this is what I expect. Then at 22:00 I get an email saying conn disabled in the subject for this host, why am I getting this second email and how do I stop it? Brandon

1 0

Quirky behavior
by turranx＠hotmail.com 30 Oct '14

30 Oct '14

My company is looking to use Xymon in production. It's my job to operationalize it: test it, write about its behavior, document any issues, and create documentation for our run teams. I've found a behavior of the Xymon server's service that I'm trying to understand: It maintains the host name to OSType mapping until the service is restarted. For example: 1. Edit the server's hosts.cfg file. Insert a non-existent server 'server01' and give it a fake/real IP. 2. Edit the server's client-local.cfg file. Create several entries within for different OS types: a. Linux b. Win32 c. AIX d. Etc. 3. Make sure that each section for the OSType contains a unique string or command. You will use this to identify which OSType the Xymon server service identified 'server01' as. 4. Wait for 'server01' to show up on the web site. It won't have any status data to report yet. This is OK. NOTE: Do not restart the Xymon service. 5. Find a computer (real/VM) to pretend to be 'server01'. It doesn't matter which OS the client has, just as long as you are comfortable running custom scripts upon it. 6. From 'server01', issue this command, replacing OSType and HostClass with your favorite values: a. "client server01.<OSType> <HostClass>" 7. If you're lucky, the Xymon server will respond back with the appropriate unique string for your OSType from the client-local.cfg file. 8. Now, change OSType and rerun the command from the same client machine. For example, if you first used "win32", now use "linux" instead. a. "client server01.win32 <HostClass>" b. "client server01.linux <HostClass>" 9. Did the Xymon server respond with the unique string from the new/second OSType? I betcha it didn't. It's still responding with the unique string from the first OSType you used, right? 10. Edit the server's hosts.cfg file. Insert a non-existent server 'server02' and give it a fake/real IP. 11. Wait for 'server02' to appear in the web page. 12. Log on to the server as the user 'xymon' and issue a rename command: a. ./server/bin/xymon 127.0.0.1 "rename server01 server02" 13. Wait for the web page to update, showing status information for 'server02', but not 'server01'. 14. Now, issue the following commands from the client, but use the new/second OSType for both: a. "client server01.<OSType> <HostClass>" b. "client server02.<OSType> <HostClass>" 15. Did the Xymon server respond to 'server01' with the original/first OSType you used? When I performed these steps, I got back the unique string for the original/first OSType, but I was expecting to get back the new/second OSType. 16. Did the Xymon server respond to 'server02' with the new/second OSType you used? When I performed these steps, I got back the unique string for the new/second OSType. 17. Edit the server's hosts.cfg file. Remove 'server01' and 'server02'. 18. Log on to the server as the user 'xymon' and issue a rename commands: a. ./server/bin/xymon 127.0.0.1 "remove server01" b. ./server/bin/xymon 127.0.0.1 "remove server02" 19. Wait for the web site to stop showing server01 and server02. 20. Edit the server's hosts.cfg file. a. Insert a non-existent server 'server01' and give it a fake/real IP. b. Insert a non-existent server 'server02' and give it a fake/real IP. 21. Wait for 'server01' and 'server02' to appear in the web page. 22. Now, issue the following commands from the client, but use the new/second OSType for both: a. "client server01.<OSType> <HostClass>" b. "client server02.<OSType> <HostClass>" 23. Did the Xymon server respond to 'server01' with the original/first OSType you used? When I performed these steps, I got back the unique string for the original/first OSType, but I was expecting to get back the new/second OSType. 24. Did the Xymon server respond to 'server02' with the new/second OSType you used? When I performed these steps, I got back the unique string for the new/second OSType. 25. Log on to the Xymon server and restart the Xymon service. Go back through the steps above, you'll see that after a fresh restart, the Xymon service will parse the "client" string, discover the OSType, and maintain an OSType <--> Hostname association until the service is restarted. Is this the expected behavior? I can see how this behavior would get in the way of architecting and rapid testing of a client-local.cfg file with multiple OSType, HostClass, and Hostname entries.

4 5

Logfile not accessible
by jlaidman＠rebel-it.com.au 29 Oct '14

29 Oct '14

Every 3 minutes is a bit peculiar because the client message with the log entries gets sent every 5 minutes. Could it be that there are two client processes running at the same time? Permissions on the file look OK, but it could be that permissions on directory tree are not sufficient. J On 30/10/2014 1:15 AM, "usa ims via Xymon" <xymon at xymon.com> wrote: > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon > > > ---------- Forwarded message ---------- > From: usa ims <usaims at yahoo.com> > To: xymon at xymon.com > Cc: > Date: Wed, 29 Oct 2014 07:08:55 -0700 > Subject: Logfile not accessible > Greetings everybody, > > I have this one log file that is going from yellow to green back to yellow > every 3 minutes. > The xymon-client is installed on a MySQL server. > > When the BB Display goes to yellow it indicates: > > Warnings in /opt/mysql/log-error/zzzzzz-error.log > yellow Logfile not accessible > > But I see activity in the log. > > However, the log file does exists there with the proper permissions for > everyone to read. > -rw-r--r-- 1 mysql mysql 44143540 Oct 29 10:02 zzzzzz-error.log > > When it turns green, it indicates: > No entries in /opt/mysql/log-error/zzzzzz-error.log > Full log /opt/mysql/log-error/zzzzzz-error.log > > But I see activity in the log. > > What could be causing this flopping from green to yellow and back to green? > Thanks in advance. > > usaims > >

1 0

Graphing non-NCV data
by dave＠collegenet.com 29 Oct '14

29 Oct '14

Hi everyone, I'm trying to graph data that is not in NCV format. I was able to do this in BB, but I'm having trouble finding documentation on how it's done in Xymon. The documentation at "/help/howtograph.html" seems to assume data is always in NCV format. Is there a way to parse it as it comes in along with the disk, cpu, and other tests, or should I be getting data from disk. If I'm getting it off the disk, does that mean I should enable "bbstatus" and "hostdata" in hobbitlaunch.cfg? Is it recommended to run a data collection script as an ext script, or just straight out of cron. Am I forgetting something? Is there documentation out there that I just failed to find? FYI, I'm running version 4.3.0~beta2.dfsg-9.1 from Debian 7 (wheezy). Thanks, Dave Fogarty -- Senior System Administrator CollegeNET.com

3 3

Logfile not accessible
by usaims＠yahoo.com 29 Oct '14

29 Oct '14

Greetings everybody, I have this one log file that is going from yellow to green back to yellow every 3 minutes. The xymon-client is installed on a MySQL server. When the BB Display goes to yellow it indicates: Warnings in /opt/mysql/log-error/zzzzzz-error.log yellow Logfile not accessible But I see activity in the log. However, the log file does exists there with the proper permissions for everyone to read. -rw-r--r-- 1 mysql mysql 44143540 Oct 29 10:02 zzzzzz-error.log When it turns green, it indicates: No entries in /opt/mysql/log-error/zzzzzz-error.log Full log /opt/mysql/log-error/zzzzzz-error.log But I see activity in the log. What could be causing this flopping from green to yellow and back to green? Thanks in advance. usaims

1 0

duration of MSG red status
by nskyrca＠syr.edu 29 Oct '14

29 Oct '14

Hello, I think this has been asked before, but it was a long time ago and I wondered if something changed since then. How long will the status of MSGS stay red? We just setup monitoring recently and it seems like it stays red for about 30 minutes. Is that normal? Is this configurable? We are running Xymon server 4.2.3. Thanks, Nicole

5 8

monitor runtime of processes
by martin.flemming＠desy.de 28 Oct '14

28 Oct '14

Hi ! Unfortunatley i didn't found a solution for my problem except these threads, which are not really a soluton :-( http://lists.xymon.com/archive/2008-February/017554.html http://lists.xymon.com/archive/2013-July/037868.html The question is, if anybody has a idea, how i can monitor the runtime for certain processes, preferably with his pid ? My real problem is, that my backup-system runs at beginning of the months maybe more than 2 days ... but in the normal way it's runs 2-4 hours ... So, i want to have a yellow alert after 24 hours and a red alert after 48 hours .. is this possible ? Thanks & Cheers Martin

4 6

cpu2.sh
by AAJOSE＠telmex.com 28 Oct '14

28 Oct '14

Hi good afternoon, I have a problem with the script cpu2.sh I cpu2.log mistake is setting configured in the file path: / export / home / xymoncli / client / logs tells me: 21/10/2014 19:21: 51 Could not start task cpu2 using command '/export/home/xymoncli/client/ext/bb-cpu2.sh': No such file or directory is an external script developed for big brother but not if it works now for Xymon, could help me please. Thank you. 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:image001.jpg at 01CFED66.4863F070] ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 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 1