Re: [j-nsp] open source packages to monitor ex2200/vc

2016-09-02 Thread raf

Le 02/09/2016 à 10:02, Paul S. a écrit :

Are you ok with putting your patches on something like github?



Yep I have to take the time to do it next week :)

--
Raphael Mazelier

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] open source packages to monitor ex2200/vc

2016-08-21 Thread raf

Le 19/08/2016 à 17:38, William a écrit :

My chat with jtac ended with blaming the monitoring SW, guys at check mk
blamed juniper thou someone would look at the problem if we paid!




Jtac answer doesn't surprise me. There are no quick fixes apart 
completely rewrite/rethink the way of snmp is implemented on junos. 
(which it obviously buggy)


Answer from check_mk community is more frustrating. I ve got the same 
style of answer from the Obversium author (fix your s***y hardware).
While they are right in some way, they refused to saw how bad their 
softs was as polling snmp, specially interface MIBs.


The right way of polling slow network devices ( ):
- caching the the oid of interfaces
- caching the relatively static information (speed, duplex, etc..., 
after all the are not intended to change everytime)

- do targeted get

Implementing quick patches this way in the poller code of Observium 
have decreased the polling time by 300%. (and mainly leave my EXs alive 
when they are polled).




--
Raphael Mazelier
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] open source packages to monitor ex2200/vc

2016-08-17 Thread raf

Le 17/08/2016 à 17:28, Catalin Dominte a écrit :

I usually create a snmp filter to avoid polling interfaces ending in .0. If you 
poll an ex2200 / 3300 / 4200 it spends a long time polling the ifTable and 
ifxTable. The polling time is reduced considerably if .0 interfaces are dropped 
and I can poll the device every 5 minutes.



Yes snmp request can kill the control plane of EXs. For example 
Observium was killing my ex4550 (causing ldp sessions to drop and so 
on). I still consider that completely ridiculous...


With correct snmp filter the situation is less worse, but I still have 
to patch the Observium poller to let some breathes to my ex(s).
OK the Observium poller is quite aggressive (or stupid depend of the 
point of view :).




What is everyone using to monitor their EX2200/VC stacks?



I've made some ugly scripts in python to check via ssh the output of 
"show virtual-chassis".



We are using check_mk to monitor our network which is great, however due to
the way it polls or due to the low power of the ex2200 I'm unable to
monitor all the individual interfaces.


Check-mk is great, but do lot of snmpwalk to check network devices. (If 
I had time I will take a look to patch and make it use an interfaces cache)


--
Raphael Mazelier


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] open source packages to monitor ex2200/vc

2016-08-17 Thread Chuck Anderson
Okay, attachments don't come through the list, so I've done what I
should have done long ago and put this on github:

https://github.com/cranderson/nagios-plugins

On Wed, Aug 17, 2016 at 11:12:12AM -0400, Chuck Anderson wrote:
> (trying again with gzipped code to make message small enough)
> 
> For Juniper hardware/software fault monitoring, we use Nagios with the
> check_snmp_environment plugin, extended with more Juniper checks.
> I've attached the one we use here.  I'd like to improve this further
> by removing duplicate alerts (often the Component State and FRU states
> are identical, so we get alert messages with the same alerts printed
> twice, but I didn't know that when I wrote it originally and wanted to
> not miss anything).
> 
> For interface statistics and historical graphing/trending, we use
> AKiPS.  AKiPS can also do threshold and fault alerting if you'd rather
> have a single solution that does everything.  The nice thing about
> AKiPS is that it has pretty comprehensive support for many vendors of
> not just networking gear, but also servers, power systems, wireless,
> etc.  It also has a syslog and NetFlow collector.  They also add new
> functionality pretty rapidly.
> 
> On Wed, Aug 17, 2016 at 12:15:12PM +0100, William wrote:
> > Hi list,
> > 
> > What is everyone using to monitor their EX2200/VC stacks?
> > 
> > We are using check_mk to monitor our network which is great, however due to
> > the way it polls or due to the low power of the ex2200 I'm unable to
> > monitor all the individual interfaces.
> > 
> > Cheers,
> > 
> > Will
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] open source packages to monitor ex2200/vc

2016-08-17 Thread Catalin Dominte
I usually create a snmp filter to avoid polling interfaces ending in .0. If you 
poll an ex2200 / 3300 / 4200 it spends a long time polling the ifTable and 
ifxTable. The polling time is reduced considerably if .0 interfaces are dropped 
and I can poll the device every 5 minutes.

Catalin

Sent from my mobile device

> On 17 Aug 2016, at 12:15, William  wrote:
> 
> Hi list,
> 
> What is everyone using to monitor their EX2200/VC stacks?
> 
> We are using check_mk to monitor our network which is great, however due to
> the way it polls or due to the low power of the ex2200 I'm unable to
> monitor all the individual interfaces.
> 
> Cheers,
> 
> Will
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] open source packages to monitor ex2200/vc

2016-08-17 Thread Chuck Anderson
(trying again with gzipped code to make message small enough)

For Juniper hardware/software fault monitoring, we use Nagios with the
check_snmp_environment plugin, extended with more Juniper checks.
I've attached the one we use here.  I'd like to improve this further
by removing duplicate alerts (often the Component State and FRU states
are identical, so we get alert messages with the same alerts printed
twice, but I didn't know that when I wrote it originally and wanted to
not miss anything).

For interface statistics and historical graphing/trending, we use
AKiPS.  AKiPS can also do threshold and fault alerting if you'd rather
have a single solution that does everything.  The nice thing about
AKiPS is that it has pretty comprehensive support for many vendors of
not just networking gear, but also servers, power systems, wireless,
etc.  It also has a syslog and NetFlow collector.  They also add new
functionality pretty rapidly.

On Wed, Aug 17, 2016 at 12:15:12PM +0100, William wrote:
> Hi list,
> 
> What is everyone using to monitor their EX2200/VC stacks?
> 
> We are using check_mk to monitor our network which is great, however due to
> the way it polls or due to the low power of the ex2200 I'm unable to
> monitor all the individual interfaces.
> 
> Cheers,
> 
> Will
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


[j-nsp] open source packages to monitor ex2200/vc

2016-08-17 Thread William
Hi list,

What is everyone using to monitor their EX2200/VC stacks?

We are using check_mk to monitor our network which is great, however due to
the way it polls or due to the low power of the ex2200 I'm unable to
monitor all the individual interfaces.

Cheers,

Will
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp