12 Dec
2014
12 Dec
'14
11:12 a.m.
Allowing the poller to run multiple times solved the problem - so far. Now I just need to find out, why polling of some devices takes a long time.
--
Ole Hansen
> On 11/12/2014, at 12.20, Tom Laermans tom.laermans@powersource.cx wrote:
>
> 1 completely negates the entire advantage of poller-wrapper, being that any one device can not bring your polling to a halt. :/
>
> On 12/11/2014 12:12 PM, Ole Hansen wrote:
>> Ahh.. I was actually only having "1" after poller-wrapper.py - doh! why didn't i start with the performance tuning guide? :-)
>>
>> I'll see if it changes anything.
>>
>> --
>> Ole Hansen
>>
>>
>>
>>
>>> On 11/12/2014, at 00.16, Adam Burgess <adam@qant.com mailto:adam@qant.com> wrote:
>>>
>>> Can you send (to the list) your cron entry for the observium poller please?
>>>
>>> I had a similar issue that turned out to be caused by a single device taking way too long to complete the poll (lots of interfaces - not an issue with the poller itself) and changed my poller-wrapper.py settings to the following:
>>>
>>> 0,5,10,15,20,25,30,35,40,45,50,55 * * * * root /opt/observium/poller-wrapper.py 32 >> /dev/null 2>&1
>>>
>>> Check your config and see if you only have '1' after 'poller-wrapper.py' - it may be worth adjusting as per the notes on http://www.observium.org/wiki/Performance_tuning http://www.observium.org/wiki/Performance_tuning.
>>>
>>> Adam
>>>
>>> ________________________________________
>>> From: observium [observium-bounces@observium.org mailto:observium-bounces@observium.org] on behalf of ecaroh [lists@datenarbeiter.de mailto:lists@datenarbeiter.de]
>>> Sent: Thursday, 11 December 2014 5:41 AM
>>> To: Observium Network Observation System
>>> Subject: Re: [Observium] gaps in graphs
>>>
>>> Hi,
>>>
>>> no, unfortunately not. I can't explain it with disk io. There are to less machines monitored and the vz/kvm host is not overloaded. The only thing i can suspect is, that observium is running as a vz container and this causes problems.
>>>
>>> Before anybody moans, I know that firewalls and monitoring system should stand alone. But cost for power and administrational overhead would be to much for my intended monitoring.
>>>
>>> From other monitoring software i know that this can happen if the collector needs to long for a polling cycle. But i must admit, that i read about "multi" polling in observium. I have to check whether this is active. Another solution would be, to set up a physical test server.
>>>
>>> I did not checked in deep for logs and other stuff, because my main job actually is CEO of a business center and not it staff as a couple of years before. But i will do it when i have some free time.
>>>
>>> At the moment i have " Total time for all devices: 59.73s" for polling. This result does not point to polling problems.
>>>
>>> If i find the solution, i will not keep it for me and post it here.
>>>
>>> --
>>> ecaroh
>>>
>>> PS: I run smokeping on the same machine with integration in observium. There are no gaps.
>>>
>>>
>>>
>>> Am 10.12.2014 um 14:28 schrieb Ole Hansen <oha@netic.dk mailto:oha@netic.dk>:
>>>
>>>> DId you find a solution for this? I'm seeing the same problem - and I'm collecting snmp from the same devices from another server (Zenoss distributed collector) on the same network with no drops in the graphs.
>>>>
>>>> --
>>>> Ole Hansen
>>>>
>>>>
>>>>
>>>>> On 01/12/2014, at 15.33, ecaroh <lists@datenarbeiter.de mailto:lists@datenarbeiter.de> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> i got sporadic dropouts over all my graphs. If this happen most of my graphs have dropouts.
>>>>>
>>>>> The poller runs not longer than a minute.
>>>>>
>>>>> `Total time for all devices: 41.07s 35.17s'
>>>>>
>>>>> Memory usage 200 of 1000 MB RAM. All devices are in the same physical gigabit network. Ping is less than 50 ms to each device. Monitored are only 16 devices. Observium itself runs as a openvz container (turnkeylinux).
>>>>>
>>>>>
>>>>> I searched the web but does not find anything that matches my setup. Does anybody have a hint for me?
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>> ecaroh
>>>>>
>>>>>
>>>>> <observium_gaps-in-graph.png>
>>>>>
>>>>> _______________________________________________
>>>>> observium mailing list
>>>>> observium@observium.org mailto:observium@observium.org
>>>>> http://postman.memetic.org/cgi-bin/mailman/listinfo/observium http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
>>>>
>>>> _______________________________________________
>>>> observium mailing list
>>>> observium@observium.org mailto:observium@observium.org
>>>> http://postman.memetic.org/cgi-bin/mailman/listinfo/observium http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
>>>
>>>
>>> --
>>>
>>> HTH
>>>
>>> ecaroh
>>>
>>> _______________________________________________
>>> observium mailing list
>>> observium@observium.org mailto:observium@observium.org
>>> http://postman.memetic.org/cgi-bin/mailman/listinfo/observium http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
>>> _______________________________________________
>>> observium mailing list
>>> observium@observium.org mailto:observium@observium.org
>>> http://postman.memetic.org/cgi-bin/mailman/listinfo/observium http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
>>
>>
>>
>> _______________________________________________
>> observium mailing list
>> observium@observium.org mailto:observium@observium.org
>> http://postman.memetic.org/cgi-bin/mailman/listinfo/observium http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
>
> _______________________________________________
> observium mailing list
> observium@observium.org
> http://postman.memetic.org/cgi-bin/mailman/listinfo/observium