devmon mysterious behaviour
list Becker Christian
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 user-e4a19bfb94c0@xymon.invalid<mailto:user-e4a19bfb94c0@xymon.invalid> 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/>;
list Ryan Rush
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" <
▸
user-e4a19bfb94c0@xymon.invalid> 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
user-e4a19bfb94c0@xymon.invalid<mailto:
user-e4a19bfb94c0@xymon.invalid>
▸
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
user-563e14babad8@xymon.invalid
list Becker Christian
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
▸
user-e4a19bfb94c0@xymon.invalid
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:user-e69930a9d51f@xymon.invalid] Gesendet: Freitag, 31. Oktober 2014 09:16
An: user-563e14babad8@xymon.invalid
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" < user-e4a19bfb94c0@xymon.invalid> 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 user-e4a19bfb94c0@xymon.invalid<mailto: user-e4a19bfb94c0@xymon.invalid> 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 user-563e14babad8@xymon.invalid
list Ian Diddams
I have two centos (6.5) clients with the same xymon client (4.2.3) both reporting to the same xymon server/... one has a green alert for MSGS "No entries in /var/log/messages Full log /var/log/messages" the other a grey alert... "The client did not report any logfile data" Neither of them have any LOG statements in localclient.cfg. The server does have amongst other OS types defined "[redhat] log:/var/log/messages:10240 ignore MARK" in client-local.cfg... but that wouldn't explain why one client is checked and another isn't. Has anyone any ideas as to what is happening here - why one client gets msgs reported and not the other? ian
list Jeremy Laidman
I seem to recall a problem on 64-bit platforms where 64-bit SNMP request IDs were being rejected by libsnmp because it parsed them as 32-bit IDs, but only if the values were large enough. In this situation, I was able to probe the OIDs just fine using snmpget, but devmon failed to get the responses, but only sometimes. Comparing packet captures of failures and successes showed the problem. A previously posted thread might be of some assistance: http://sourceforge.net/p/devmon/mailman/message/30148661/