EX4200/4550 VC - Port Polling ~200 Seconds
Testing Observium, I've noticed that polling an EX4200/4550 with Observium takes about 200 seconds. There are around 300 ports, and I've noticed that Observium polls the logical interfaces as separate from the physical interfaces. I considered disabling logical interface polling, but the logical interfaces are used for a lot of port correlations, etc.
Cacti with Spine takes 13 seconds to poll everything in our network, and Cacti with the PHP poller takes maybe 2 minutes to poll everything in our network.
Because of Cacti's ability to handle this particular device (even with its PHP poller), I'm pretty convinced that the issue isn't the device.
I've checked interface, memory, and CPU utilization on the Observium server as well as the device and the network in-between. Everything is fine. I've also turned Cacti off to ensure there was no strange clash. I also turned polling off for all ports that were in a "down" state and disabled those ports in the switch as well.
It almost seems that Observium's poller walks one OID at a time in serial, or otherwise does some ridiculously complex discovery on every poll that it doesn't need to do. Cacti does bulk requests, so it gets around 50 OIDs per request to the switch stack.
Is it possible that I'm missing something in the Observium configuration?
Thanks!
--Tyler
On Sun, Oct 13, 2013 at 06:20:50PM -0400, Tyler Christiansen tylerc@beatsmusic.com wrote:
Testing Observium, I've noticed that polling an EX4200/4550 with Observium takes about 200 seconds. There are around 300 ports, and I've noticed that
Hi Tyler, I've just added about 4000 ports in EX stacks and I can correlate your findings.
Polling with a full 7 member stack of 48 port switches means polling takes around 1500-2000 seconds.
I don't have cacti installed, can you take a tcpdump or debug and share your finding in how it is polling every port? We can then compare it to ./poller.php -d -r -h $foo
C.
Charlie-
After reading the ports poller module in Observium, I've found it to be very inefficient. I don't need to do any tcpdump of Cacti's poller to see what the problem is, although I could certainly provide it if you were truly itching for it. Instead, I'll describe what the issue with the Observium poller is below.
I tried explaining the issue via Twitter to @observium, but the individual behind the account insisted that I didn't actually read the code and that Observium was more advanced than Cacti.
Regardless, here's why it takes so long:
Observium polls the entire ifEntry and ifXEntry MIBs on devices. This results in grabbing results from 11 OIDs that don't need to be polled for each device.
The reasoning behind this is that those 11 MIBs are duplicates either within the same MIB or between the two MIBs--except that one is a 32-bit counter and one is a 64-bit counter.
This is an expensive operation--in my tests, polling the 11 MIBs in question took about 2 minutes on average using snmpbulkwalk. My stack has grown a bit since those tests and has resulted in total polling time taking longer than five minutes.
I also suggested that the OIDs should be polled in parallel, but the individual behind @observium also seemed to feel that it's a bad idea to poll a device for multiple OIDs in parallel. To be honest, I don't know of any basis for that. Unless you have a very bad network (over-utilized, underpowered), parallel polling a single device via SNMP does not hurt the device or your network in any way. It doesn't hurt your server, either, unless you're trying to use old hardware--which Observium doesn't seem to work well with anyway. This is, of course, based on my own experience in the past working for a national ISP operating across 46 U.S. states and in both ILEC and CLEC markets and my current employer where many devices are polled simultaneously by many different diagnostic utilities for overall health management.
If you'd like to see my test results, feel free. My system and network performance is here: http://sprunge.us/jNBQ. It shows sustained bandwidth capacity of ~800Mbps, no packet loss, excellent cross-country latency, and almost no CPU, memory, or I/O load.
The results of the actual SNMP tests are here http://sprunge.us/RjKT.
I will be testing the removal of the duplicate OIDs and polling only the 64-bit OIDs as I have no equipment that is so old that it does not support them. I suspect that this will significantly reduce poll time, at least to moderately acceptable levels.
On Oct 26, 2013, at 8:58 PM, Charlie Allom charlie@evilforbeginners.com wrote:
On Sun, Oct 13, 2013 at 06:20:50PM -0400, Tyler Christiansen tylerc@beatsmusic.com wrote:
Testing Observium, I've noticed that polling an EX4200/4550 with Observium takes about 200 seconds. There are around 300 ports, and I've noticed that
Hi Tyler, I've just added about 4000 ports in EX stacks and I can correlate your findings.
Polling with a full 7 member stack of 48 port switches means polling takes around 1500-2000 seconds.
I don't have cacti installed, can you take a tcpdump or debug and share your finding in how it is polling every port? We can then compare it to ./poller.php -d -r -h $foo
C.
0x8486EDA8 http://spodder.com/ _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Hi Tyler
On 27/10/13 05:30, Tyler Christiansen wrote:
Observium polls the entire ifEntry and ifXEntry MIBs on devices. This results in grabbing results from 11 OIDs that don't need to be polled for each device.
I have also observed this.
The reasoning behind this is that those 11 MIBs are duplicates either within the same MIB or between the two MIBs--except that one is a 32-bit counter and one is a 64-bit counter.
This is an expensive operation--in my tests, polling the 11 MIBs in question took about 2 minutes on average using snmpbulkwalk. My stack has grown a bit since those tests and has resulted in total polling time taking longer than five minutes.
Proably there should be a detection in the discovery process if the system has 32 or 64 bit counters. Unfortunately there are still relatively new devices which only have 32bit counters and can only speak snmpv1.
I also suggested that the OIDs should be polled in parallel, but the individual behind @observium also seemed to feel that it's a bad idea to poll a device for multiple OIDs in parallel. To be honest, I don't know of any basis for that. Unless you have a very bad network (over-utilized, underpowered), parallel polling a single device via SNMP does not hurt the device or your network in any way. It doesn't hurt your server, either, unless you're trying to use old hardware--which Observium doesn't seem to work well with anyway. This is, of course, based on my own experience in the past working for a national ISP operating across 46 U.S. states and in both ILEC and CLEC markets and my current employer where many devices are polled simultaneously by many different diagnostic utilities for overall health management.
This is very critical. I've seen devices going crazy when they get several parallel snmp queries. Even with the actual snmp poller of obervium some devices have high cpu load. No, i don's speak of 10 year old devices, they are simply badly engineered.
Regards
Matthias
Hi, Matthias.
On Oct 26, 2013, at 11:40 PM, Matthias Cramer matthias.cramer@iway.ch wrote:
Hi Tyler
On 27/10/13 05:30, Tyler Christiansen wrote:
Observium polls the entire ifEntry and ifXEntry MIBs on devices. This results in grabbing results from 11 OIDs that don't need to be polled for each device.
I have also observed this.
The reasoning behind this is that those 11 MIBs are duplicates either within the same MIB or between the two MIBs--except that one is a 32-bit counter and one is a 64-bit counter.
This is an expensive operation--in my tests, polling the 11 MIBs in question took about 2 minutes on average using snmpbulkwalk. My stack has grown a bit since those tests and has resulted in total polling time taking longer than five minutes.
Proably there should be a detection in the discovery process if the system has 32 or 64 bit counters. Unfortunately there are still relatively new devices which only have 32bit counters and can only speak snmpv1
I would be interested in which vendors are guilty of this and which software versions are present. "Relative" is obviously relative (I'm good at stating the obvious), but I'd still be curious.
Somewhere in the code is an abstraction layer for 32-bit vs 64-bit OIDs as information is all presented the same way to the end-user. It therefore stands to reason that this sort of functionality should be (relatively) trivial to implement.
I also suggested that the OIDs should be polled in parallel, but the individual behind @observium also seemed to feel that it's a bad idea to poll a device for multiple OIDs in parallel. To be honest, I don't know of any basis for that. Unless you have a very bad network (over-utilized, underpowered), parallel polling a single device via SNMP does not hurt the device or your network in any way. It doesn't hurt your server, either, unless you're trying to use old hardware--which Observium doesn't seem to work well with anyway. This is, of course, based on my own experience in the past working for a national ISP operating across 46 U.S. states and in both ILEC and CLEC markets and my current employer where many devices are polled simultaneously by many different diagnostic utilities for overall health management.
This is very critical. I've seen devices going crazy when they get several parallel snmp queries. Even with the actual snmp poller of obervium some devices have high cpu load. No, i don's speak of 10 year old devices, they are simply badly engineered.
I would also be interested in more detail on this. I've even seen old gear from major vendors get hammered with SNMP queries with no issues. Mostly interested so I know what to stay away from. :)
Regardless, a way to poll multiple OIDs in parallel would be a nice per-device option to have, if nothing else.
--Tyler
Regards
Matthias
-- Matthias Cramer / mc322-ripe Senior Network & Security Engineer iway AG Phone +41 43 500 1111 Badenerstrasse 569 Fax +41 44 271 3535 CH-8048 Zurich http://www.iway.ch/ GnuPG 1024D/2D208250 = DBC6 65B6 7083 1029 781E 3959 B62F DF1C 2D20 8250
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
For anyone who's interested-
By modifying the ports polling module, I've reduced total poll time from ~350 seconds to ~225 seconds. I haven't done extensive testing, but so far there has been no loss of functionality on any of my devices. I feel pretty confident that I could get this number down even further by going through the rest of the ports module (I only [closely] examined one line of code and changed only that line) or by rewriting parts of polling code to allow for parallel polling of OIDs in the ports module, I don't really have the time for that right now.
Hopefully this will be enlightening for someone on the dev team, and hopefully that person will care enough to actually examine and rewrite the ports module properly.
On Oct 26, 2013, at 9:30 PM, Tyler Christiansen tylerc@beatsmusic.com wrote:
Charlie-
After reading the ports poller module in Observium, I've found it to be very inefficient. I don't need to do any tcpdump of Cacti's poller to see what the problem is, although I could certainly provide it if you were truly itching for it. Instead, I'll describe what the issue with the Observium poller is below.
I tried explaining the issue via Twitter to @observium, but the individual behind the account insisted that I didn't actually read the code and that Observium was more advanced than Cacti.
Regardless, here's why it takes so long:
Observium polls the entire ifEntry and ifXEntry MIBs on devices. This results in grabbing results from 11 OIDs that don't need to be polled for each device.
The reasoning behind this is that those 11 MIBs are duplicates either within the same MIB or between the two MIBs--except that one is a 32-bit counter and one is a 64-bit counter.
This is an expensive operation--in my tests, polling the 11 MIBs in question took about 2 minutes on average using snmpbulkwalk. My stack has grown a bit since those tests and has resulted in total polling time taking longer than five minutes.
I also suggested that the OIDs should be polled in parallel, but the individual behind @observium also seemed to feel that it's a bad idea to poll a device for multiple OIDs in parallel. To be honest, I don't know of any basis for that. Unless you have a very bad network (over-utilized, underpowered), parallel polling a single device via SNMP does not hurt the device or your network in any way. It doesn't hurt your server, either, unless you're trying to use old hardware--which Observium doesn't seem to work well with anyway. This is, of course, based on my own experience in the past working for a national ISP operating across 46 U.S. states and in both ILEC and CLEC markets and my current employer where many devices are polled simultaneously by many different diagnostic utilities for overall health management.
If you'd like to see my test results, feel free. My system and network performance is here: http://sprunge.us/jNBQ. It shows sustained bandwidth capacity of ~800Mbps, no packet loss, excellent cross-country latency, and almost no CPU, memory, or I/O load.
The results of the actual SNMP tests are here http://sprunge.us/RjKT.
I will be testing the removal of the duplicate OIDs and polling only the 64-bit OIDs as I have no equipment that is so old that it does not support them. I suspect that this will significantly reduce poll time, at least to moderately acceptable levels.
On Oct 26, 2013, at 8:58 PM, Charlie Allom charlie@evilforbeginners.com wrote:
On Sun, Oct 13, 2013 at 06:20:50PM -0400, Tyler Christiansen tylerc@beatsmusic.com wrote:
Testing Observium, I've noticed that polling an EX4200/4550 with Observium takes about 200 seconds. There are around 300 ports, and I've noticed that
Hi Tyler, I've just added about 4000 ports in EX stacks and I can correlate your findings.
Polling with a full 7 member stack of 48 port switches means polling takes around 1500-2000 seconds.
I don't have cacti installed, can you take a tcpdump or debug and share your finding in how it is polling every port? We can then compare it to ./poller.php -d -r -h $foo
C.
0x8486EDA8 http://spodder.com/ _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
On 2013-10-27 04:30, Tyler Christiansen wrote:
I also suggested that the OIDs should be polled in parallel, but the individual behind @observium also seemed to feel that it's a bad idea to poll a device for multiple OIDs in parallel. To be honest, I don't know of any basis for that.
There is no threading in PHP, now fuck off.
adam.
T
On 27.10.2013 19:35, Adam Armstrong wrote:
On 2013-10-27 04:30, Tyler Christiansen wrote:
I also suggested that the OIDs should be polled in parallel, but the individual behind @observium also seemed to feel that it's a bad idea to poll a device for multiple OIDs in parallel. To be honest, I don't know of any basis for that.
There is no threading in PHP, now fuck off.
Actually threading is not only what stooping doing that. Most network devices already do their best when you snmpwalk them (using all available idle cpu). So basically doing that in parallel make it slower and worse for some devices.
On Oct 27, 2013, at 8:35 AM, Adam Armstrong adama@memetic.org wrote:
There is no threading in PHP, now fuck off.
No, but there is threading in any number of other languages that polling logic could be moved to.
Also, is this how you treat customers and potential customers? Telling them to fuck off and then removing them from your list when they offer feedback that can help you improve your product?
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
One thing you will discover (if you haven't already) is that Adam et. al develop Observium based on their own requirements or that of their (large-ish?) sponsors, not those of their general user base (but I don't know how much say us paying users have since the pro version has been rolled out; I've never asked).
They don't have a need for efficient polling of Juniper devices do it's very unlikely that it will ever make it into the code.
It's the way it is around here. The observium team isn't trying to design a product for everyone. They are designing a product for themselves and those who are willing to use it as-is are welcome to do so.
Sent from my iPhone
On Oct 27, 2013, at 12:25 PM, Tyler Christiansen tylerc@beatsmusic.com wrote:
On Oct 27, 2013, at 8:35 AM, Adam Armstrong adama@memetic.org wrote:
There is no threading in PHP, now fuck off.
No, but there is threading in any number of other languages that polling logic could be moved to.
Also, is this how you treat customers and potential customers? Telling them to fuck off and then removing them from your list when they offer feedback that can help you improve your product?
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
On Oct 27, 2013, at 9:49 AM, Jason Lixfeld jason@lixfeld.ca wrote:
One thing you will discover (if you haven't already) is that Adam et. al develop Observium based on their own requirements or that of their (large-ish?) sponsors, not those of their general user base (but I don't know how much say us paying users have since the pro version has been rolled out; I've never asked).
Whether they're interested in supporting feature requests of their general user base or not isn't really what I'm getting at. I didn't say "help, I'm completely clueless." I offered helpful feedback. I identified an issue with the code. I showed how it could be improved by examining the OIDs from the RFCs, and I proved that it could be improved through a series of tests and by writing a patch for my own installation. In return, I was told to "fuck off" and removed from the list.
If they aren't interested in my patch or in performance issues being identified--fine. There's not really a reason to tell someone who offered feedback to "fuck off" and then remove them from a mailing list.
They don't have a need for efficient polling of Juniper devices do it's very unlikely that it will ever make it into the code.
I am actually curious if it's a Juniper-only issue. Does anyone have anything with around 300 or 400 ports on a _single_ device that they are polling over a respectable distance? If so, what are your poll times like?
It's the way it is around here. The observium team isn't trying to design a product for everyone. They are designing a product for themselves and those who are willing to use it as-is are welcome to do so.
Again, that's fine, but the response was a bit…excessive, particularly considering I am only trying to point out ways that the product can be improved. I actually like Observium.
Sent from my iPhone
On Oct 27, 2013, at 12:25 PM, Tyler Christiansen tylerc@beatsmusic.com wrote:
On Oct 27, 2013, at 8:35 AM, Adam Armstrong adama@memetic.org wrote:
There is no threading in PHP, now fuck off.
No, but there is threading in any number of other languages that polling logic could be moved to.
Also, is this how you treat customers and potential customers? Telling them to fuck off and then removing them from your list when they offer feedback that can help you improve your product?
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
On 2013-10-27 17:10, Tyler Christiansen wrote:
On Oct 27, 2013, at 9:49 AM, Jason Lixfeld jason@lixfeld.ca wrote:
One thing you will discover (if you haven't already) is that Adam et. al develop Observium based on their own requirements or that of their (large-ish?) sponsors, not those of their general user base (but I don't know how much say us paying users have since the pro version has been rolled out; I've never asked).
Whether they're interested in supporting feature requests of their general user base or not isn't really what I'm getting at. I didn't say "help, I'm completely clueless." I offered helpful feedback. I identified an issue with the code. I showed how it could be improved by examining the OIDs from the RFCs, and I proved that it could be improved through a series of tests and by writing a patch for my own installation. In return, I was told to "fuck off" and removed from the list.
No you didn't, you made a bunch of incorrect assumptions and then proceeded to screech about them repeatedly. We've already been through all of this, you just seem to want to be right about something, anything.
We're quite well aware of what the MIBs contain and which parts are useful. You're not offering anything helpful beyond a lot of moaning and finger pointing, you're wasting everyone's time.
If they aren't interested in my patch or in performance issues being identified--fine. There's not really a reason to tell someone who offered feedback to "fuck off" and then remove them from a mailing list.
You've been told before that you're wrong, but you're still harping on about it, trying a different avenue to find people who'll make you feel clever. You're not, you're wrong.
I'm quite certain that all you've done is stopped the poller walking if[In|Out][Octets|UPkts|NUPkts] and have declared yourself victorious, of course completely ignorant to the fact that you've broken polling for anyone who's devices don't return 64-bit values for certain types of ports.
There are performance improvements that can be made to the ports poller, we know where they are and how to do them, we just haven't gotten around to fixing them yet.
They don't have a need for efficient polling of Juniper devices do it's very unlikely that it will ever make it into the code.
I am actually curious if it's a Juniper-only issue. Does anyone have anything with around 300 or 400 ports on a _single_ device that they are polling over a respectable distance? If so, what are your poll times like?
I've rarely monitored devices with less than 400 ports.
You've proved in a number of emails that you're only interested in ranting and being right, without actually bothering to look at the code at all. In your first email you didn't even seem to know that we use bulkwalk! In later emails you don't seem to have worked out how we do 32/64 bit decision, despite having claimed to have read and optimised the code.
I think you're an unhelpful timewasting bullshitter, and I'd much prefer if you went back to Cacti and stopped wasting our time.
It's the way it is around here. The observium team isn't trying to design a product for everyone. They are designing a product for themselves and those who are willing to use it as-is are welcome to do so.
Again, that's fine, but the response was a bit…excessive, particularly considering I am only trying to point out ways that the product can be improved. I actually like Observium.
Observium doesn't like you. Shoo.
adam.
On Oct 27, 2013, at 11:22 AM, Adam Armstrong adama@memetic.org wrote:
On 2013-10-27 17:10, Tyler Christiansen wrote:
On Oct 27, 2013, at 9:49 AM, Jason Lixfeld jason@lixfeld.ca wrote: One thing you will discover (if you haven't already) is that Adam et. al develop Observium based on their own requirements or that of their (large-ish?) sponsors, not those of their general user base (but I don't know how much say us paying users have since the pro version has been rolled out; I've never asked). Whether they're interested in supporting feature requests of their general user base or not isn't really what I'm getting at. I didn't say "help, I'm completely clueless." I offered helpful feedback. I identified an issue with the code. I showed how it could be improved by examining the OIDs from the RFCs, and I proved that it could be improved through a series of tests and by writing a patch for my own installation. In return, I was told to "fuck off" and removed from the list.
No you didn't, you made a bunch of incorrect assumptions and then proceeded to screech about them repeatedly. We've already been through all of this, you just seem to want to be right about something, anything.
We're quite well aware of what the MIBs contain and which parts are useful. You're not offering anything helpful beyond a lot of moaning and finger pointing, you're wasting everyone's time.
If they aren't interested in my patch or in performance issues being identified--fine. There's not really a reason to tell someone who offered feedback to "fuck off" and then remove them from a mailing list.
You've been told before that you're wrong, but you're still harping on about it, trying a different avenue to find people who'll make you feel clever. You're not, you're wrong.
I'm quite certain that all you've done is stopped the poller walking if[In|Out][Octets|UPkts|NUPkts] and have declared yourself victorious, of course completely ignorant to the fact that you've broken polling for anyone who's devices don't return 64-bit values for certain types of ports.
I removed more than those 6 MIBs, and I'm well aware that it breaks polling for users whose devices don't support 64-bit counters, which is why I haven't offered it as an official solution or patch. And no, it hasn't broken anything in my installation.
The point of this was tests showing how much time is wasted on any given device, not to say "I know how to do this better than you."
There are performance improvements that can be made to the ports poller, we know where they are and how to do them, we just haven't gotten around to fixing them yet.
They don't have a need for efficient polling of Juniper devices do it's very unlikely that it will ever make it into the code. I am actually curious if it's a Juniper-only issue. Does anyone have anything with around 300 or 400 ports on a _single_ device that they are polling over a respectable distance? If so, what are your poll times like?
I've rarely monitored devices with less than 400 ports.
You've proved in a number of emails that you're only interested in ranting and being right, without actually bothering to look at the code at all. In your first email you didn't even seem to know that we use bulkwalk! In later emails you don't seem to have worked out how we do 32/64 bit decision, despite having claimed to have read and optimised the code.
I'm also aware that you use bulkwalk. All of my tests used bulkwalk. I never suggested that you didn't, only that you request OIDs in serial instead of in parallel. The use of bulkwalk doesn't change the fact that it's still polled in serial for a single device.
Regarding the 32- and 64-bit decision, it's not a very good decision when you're still polling both 32- and 64-bit for devices.
I think you're an unhelpful timewasting bullshitter, and I'd much prefer if you went back to Cacti and stopped wasting our time.
It's the way it is around here. The observium team isn't trying to design a product for everyone. They are designing a product for themselves and those who are willing to use it as-is are welcome to do so. Again, that's fine, but the response was a bit…excessive, particularly considering I am only trying to point out ways that the product can be improved. I actually like Observium.
Observium doesn't like you. Shoo.
I was considering a subscription, but I think I'll pass.
I'll "shoo," but not because Observium doesn't like me. I'll "shoo" because I don't like you and your obscenely unprofessional attitude.
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
On 2013-10-27 18:33, Tyler Christiansen wrote:
Observium doesn't like you. Shoo.
I was considering a subscription, but I think I'll pass.
I'd have refused and refunded you.
I'll "shoo," but not because Observium doesn't like me. I'll "shoo" because I don't like you and your obscenely unprofessional attitude.
Damn right...
On 2013-10-27 16:49, Jason Lixfeld wrote:
One thing you will discover (if you haven't already) is that Adam et. al develop Observium based on their own requirements or that of their (large-ish?) sponsors, not those of their general user base (but I don't know how much say us paying users have since the pro version has been rolled out; I've never asked).
You are witnessing, first hand, the kind of people who made us decide that the Open Source world can go fuck itself.
These people, not content with getting things not only for free, but with all of their ideologically-twisted 'freedoms', seem to like to insist that you fix things which affect them IMMEDIATELY, preferably using the half-arsed and badly thought up solutions they've come up with, regardless of how many other users it may negatively impact.
And just for the record, this guy hasn't paid us shit, yet he still feels he has the right to repeatedly waste our time via multiple media. All the bullshit he's spewing here he's already done via Twitter, and I've already explained to him why he's wrong.
We already know where the ports poller can be improved and have done for a while, but that's the largest and most complex poller, so going anywhere near it is a major time investment.
They don't have a need for efficient polling of Juniper devices do it's very unlikely that it will ever make it into the code.
This isn't really a Juniper thing. But in any event, Tom uses Juniper stuff :)
It's the way it is around here. The observium team isn't trying to design a product for everyone. They are designing a product for themselves and those who are willing to use it as-is are welcome to do so.
That's not entirely the case since the split, we've now a little more impetus to work on things of use to the wider user-base, but indeed, no one with a single license has much of a say in anything (and certainly not non-contributing douchetards) :)
adam.
On 27/10/2013 19:31, Adam Armstrong wrote:
And just for the record, this guy hasn't paid us shit, yet he still feels he has the right to repeatedly waste our time via multiple media. All the bullshit he's spewing here he's already done via Twitter, and I've already explained to him why he's wrong.
I tried to stay out of the discussion, but got a bit ticked off by the following: - "The individual behind Observium kept ..." - maybe it's just me, but I find that a little condescending. - "Move the poller to another language". Sure, know-it-all, not going to happen, feel free to start your own. - Cacti does it faster. Sure, but cacti doesn't poll everything we do.
Of course Adam can be an asshole, and he probably was, but never without a reason ;-) As most people realise though, once you've ticked him off you can forget him changing his mind about you before a cooldown period of ... undefined.
We're all pretty allergic to reiterating the same thing over and over again for no reason though.
They don't have a need for efficient polling of Juniper devices do it's very unlikely that it will ever make it into the code.
This isn't really a Juniper thing. But in any event, Tom uses Juniper stuff :)
Yup, but no switch stacks right now.
In any case I'd contact Juniper to fix their shit, because a simple 7x52 Dell Powerconnect stack takes 80 seconds to poll, and that's more than "300 ports" in the J-example taking 300+ seconds.
Shaving 1/3 off of shit by disabling 32bit counter bulkwalks doesnt make it less shit. 200 seconds is ridiculous.
Either way, a lot of BS in my mailbox that is wasting people's time for little gain or benefit.
Parallel polling is not possible in PHP, nor does it help in most cases, usually it hurts.
The strength, and in this case maybe partial weakness, of Observium is the intelligence and walking it uses to get data from devices; it's not a static list of OIDs fired off at a device using spined or whatever, like Cacti does. If you like the latter better, Adam told you where to go ;-)
I would be interested in which vendors are guilty of this and which
software versions are present.
Nice one, our code works very, very fast with Cisco switches with 1000s of ports (yay for bulkwalk, max-rep, etc), so I'd say Juniper is one that comes to mind ;-) (max-rep actually slows it down)
Tom
participants (7)
-
Adam Armstrong -
Charlie Allom -
Jason Lixfeld -
Matthias Cramer -
Nikolay Shopik -
Tom Laermans -
Tyler Christiansen