Prodware France
T : +33 979 999 000 - F : +33 988 814 001 - ybzahr@prodware.fr
Yeah. We now use a single get request to pull all sensor data. It seems these queries are timing out on that device.
So it's just sitting idle whilst timing out, no CPU impact.
Adam.
Sent from BlueMail
| Youssef BENGELLOUN - ZAHR -
Consultant Expert Prodware France T : +33 979 999 000 - F : +33 988 814 001 - ybzahr@prodware.fr |
|
|
|
Web : prodware.fr
|
On 20 Jul 2017, at 06:13, Youssef BENGELLOUN - ZAHR <ybzahr@prodware.fr> wrote:Ok, good to hear that.
Is this behavior related to something you changed between the last two merges for stable train code ?
Best regards.
Seems to be getting some timeouts when trying to do snmpgets. We might need to limit this on the brocades somehow.
Adam.
Sent from BlueMail
Youssef BENGELLOUN - ZAHR - Consultant Expert
Prodware France
T : +33 979 999 000 - F : +33 988 814 001 - ybzahr@prodware.fr
Web : prodware.fr 
On 19 Jul 2017, at 12:46, Youssef BENGELLOUN - ZAHR < ybzahr@prodware.fr> wrote:I'm sending it directly to you as I'm hitting mail size limitation.
Best regards.
Youssef BENGELLOUN - ZAHR - Consultant Expert
Prodware France
T : +33 979 999 000 - F : +33 988 814 001 - ybzahr@prodware.fr
Web : prodware.fr 
De : observium <observium-bounces@observium.org> de la part de Adam Armstrong <adama@memetic.org>
Envoyé : mercredi 19 juillet 2017 13:29
À : 'Observium'
Cc : 'Observium'
Objet : Re: [Observium] Important polling time increase since upgrade to r8697Lol, that isn't a full poller debug, it's just the device being marked down and then the poller exiting
:D
Adam.
Sent from BlueMailOn 19 Jul 2017, at 10:48, Youssef BENGELLOUN - ZAHR < ybzahr@prodware.fr> wrote:Hi,
Apparently, attachments were too big. Retrying with only one of the devices.
Best regards.
Youssef BENGELLOUN - ZAHR - Consultant Expert
Prodware France
T : +33 979 999 000 - F : +33 988 814 001 - ybzahr@prodware.fr
Web : prodware.fr 
De : Youssef BENGELLOUN - ZAHR <ybzahr@prodware.fr>
Date : mercredi 19 juillet 2017 à 11:38
À : "observium@observium.org" <observium@observium.org>
Objet : RE: [Observium] Important polling time increase since upgrade to r8697
Dear Tom,
Please find a full poller debug for a CER-RT and an MLXe.
Best regards.
De : observium <observium-bounces@observium.org> de la part de Tom Laermans <tom.laermans@powersource.cx>
Envoyé : mercredi 19 juillet 2017 11:28
À : observium@observium.org
Objet : Re: [Observium] Important polling time increase since upgrade to r8697
Hi Youssef,
Run the poller with -d on one of the devices and send the output. If you add "-m sensors" it'll only poll the sensors.
With regards to the SNMP errors, it does look like plenty of them are from a long time ago.
Seems we don't have a housekeeping module for that yet...
Tom
On 07/19/2017 11:22 AM, Youssef BENGELLOUN - ZAHR wrote:
Dear Adam,
How can I do that ?
Also, I’m seeing tons of SNMP errors under Performance Data > MIBs. See attached file for a CER-RT example.
Best regards.
Youssef BENGELLOUN - ZAHR - Consultant Expert
Prodware France
T : +33 979 999 000 - F : +33 988 814 001 - ybzahr@prodware.fr
Web : prodware.fr
De : observium <observium-bounces@observium.org> au nom de Adam Armstrong <adama@memetic.org>
Répondre à : Observium <observium@observium.org>
Date : mercredi 19 juillet 2017 à 11:11
À : 'Observium' <observium@observium.org>
Objet : Re: [Observium] Important polling time increase since upgrade to r8697
How odd.
Seems to be something that only affects one SNMP stack.
Can you see what method it's using to poll these sensors?
Adam.
Sent from BlueMail
On 19 Jul 2017, at 08:08, Youssef BENGELLOUN - ZAHR <ybzahr@prodware.fr> wrote:
Dear Adam,
Previously installed was r8580 on stable train code. No configuration changes or versions upgrades happened in the last weeks. We only upgraded Obserivum.
As for devices that polling time has increased, I have clearly identified 4 devices acting as MPLS PEs :
· 3 Brocade MLXe routers sitting in different cities :
Amsterdam :
Paris 1 :
Paris 2 :
· 1 Brocade CER-RT sitting in Frankfurt :
Looking at poller module stats, I can clearly see BGP and sensors modules are the most time consuming. Sensors is even more time consuming than BGP now. For example, in Frankfurt :
When did sensors become so time consuming ?
Best regards.
Youssef BENGELLOUN - ZAHR - Consultant Expert
Prodware France
T : +33 979 999 000 - F : +33 988 814 001 - ybzahr@prodware.fr
Web : prodware.fr
De : observium <observium-bounces@observium.org> au nom de Adam Armstrong <adama@observium.org>
Répondre à : Observium <observium@observium.org>
Date : mardi 18 juillet 2017 à 19:39
À : "observium@observium.org" <observium@observium.org>
Objet : Re: [Observium] Important polling time increase since upgrade to r8697
Can you see any particular device which has increased?
What was the previous version?
adam.
On 18/07/2017 08:23:37, Youssef BENGELLOUN - ZAHR <ybzahr@prodware.fr> wrote:
Dear Observium community,
I don’t know if I’m the only one noticing this, but polling cycle time has increased 2x fold since I upgraded to r8697 yesterday around 9AM :
I used to be around the 120-150s average, now it’s up to 270-300s.
As you can, no devices or pollers were added. From a system perspective, the box running observium is fine CPU / mem wize).
Best regards.
Youssef BENGELLOUN - ZAHR - Consultant Expert
Prodware France
T : +33 979 999 000 - F : +33 988 814 001 - ybzahr@prodware.fr
Web : prodware.fr
observium mailing listobservium@observium.orghttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
_______________________________________________observium mailing listobservium@observium.orghttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
