How many graphs can cacti handle?
I have like 50 x 24 port cisco switches, 1 x cisco cat 6500 , 4 x cisco router, 1 x Juniper router, 8 x firewalls.
That I need to graph.
This is about 1537 interfaces. Can cacti handlel this, on one machine hardware is not an issue. The question is canl cacti preform that many updates in 5 minutes.
Thanks
Question: How many graphs can cacti handle?
Moderators: Developers, Moderators
Well, this is really a two-fold question.
1) Can the Cacti UI deal with inputting and reporting on that many interfaces?
The answer is that it's really tedious to put lots of sources into Cacti 0.6.x. That's one of the biggest things that Ian and I are working on in 0.8. I won't fill you in on the specifics of how it'll work just yet but I will say that it will be *much* easier to drop 20+ similar pieces of equipment into the system. The "graph viewing" section of Cacti will also be more robust with 'public' graph trees and 'personal' graph trees so people can set up their own pages with only the graphs that they care about.
2) Can the cmd.php poller that comes with Cacti deal with polling that many interfaces?
The answer: No, not really. By all reports on the board, cmd.php is functional but (mostly due to the fact that it's PHP and not threaded C/C++) it isn't efficient enough for high-volume polling. The good news is that we're moving towards being able to kick out an XML-based 'poller config' file that any available poller could use - either by reading that file directly or by using some sort of a middleware script to munge it into a format that the poller can deal with. This stops the poller from having the overhead of sifting throught the DB every polling cycle and also makes Cacti poller-agnostic - use whatever poller you want.
The bad news is that cmd.php would have to be completely rewritten to deal with the changes we're making in the Cacti core. That in mind, I'm more interested in seeing something like Spine (another C-based poller being developed by somebody else on this board) become the 'standard' poller for Cacti. I'd like the Cacti dev team to be able to focus on a kick-ass web front end and not to have to deal with writing a poller too.
As always, comments are welcome.
Rob.
1) Can the Cacti UI deal with inputting and reporting on that many interfaces?
The answer is that it's really tedious to put lots of sources into Cacti 0.6.x. That's one of the biggest things that Ian and I are working on in 0.8. I won't fill you in on the specifics of how it'll work just yet but I will say that it will be *much* easier to drop 20+ similar pieces of equipment into the system. The "graph viewing" section of Cacti will also be more robust with 'public' graph trees and 'personal' graph trees so people can set up their own pages with only the graphs that they care about.
2) Can the cmd.php poller that comes with Cacti deal with polling that many interfaces?
The answer: No, not really. By all reports on the board, cmd.php is functional but (mostly due to the fact that it's PHP and not threaded C/C++) it isn't efficient enough for high-volume polling. The good news is that we're moving towards being able to kick out an XML-based 'poller config' file that any available poller could use - either by reading that file directly or by using some sort of a middleware script to munge it into a format that the poller can deal with. This stops the poller from having the overhead of sifting throught the DB every polling cycle and also makes Cacti poller-agnostic - use whatever poller you want.
The bad news is that cmd.php would have to be completely rewritten to deal with the changes we're making in the Cacti core. That in mind, I'm more interested in seeing something like Spine (another C-based poller being developed by somebody else on this board) become the 'standard' poller for Cacti. I'd like the Cacti dev team to be able to focus on a kick-ass web front end and not to have to deal with writing a poller too.
As always, comments are welcome.
Rob.
-
Newbie
Waiting for multi-threaded poller can take some time so if you are not affraid of a little bit programming I have a solution which may allow for polling all your devices within 5 min or even faster.
I assume that the bottleneck is SNMP get/response pingpong (if I am wrong the disregard all my idea). You are using mostly Cisco devices which support SNMP v.2c protocol. This protocol allows for fetching whole table with one request (snmpbulkget and snmpbulkwalk). Therefore you can easily get ifInOctects and ifOutOctects statistics for all interfaces of the device with only two snmpbulkwalk commands (gives 110 operations for all your Cisco devices).
So I would write a script that gathers every 5 minutes the statistics and puts them to MySQL table. Then you need a small script as a Data Input that can read statistics from that table.
I have similar solution for monitoring QoS elements on Cisco with cacti almost implemented. I monitor the routers over WAN links so the speed gain by using snmpbulkwalk command is huge (60 times faster to fetch 700-element SNMP table).
In LAN environment the speed gain is not so big but still impressive. Look below... I fetched whole ifEntry table (about 800 elements) from my router:
[root@host]# time snmpbulkwalk -v 2c -On 10.1.1.1 public ifEntry > /dev/null
real 0m2.080s
user 0m0.710s
sys 0m0.010s
[root@host]# time snmpwalk -On 10.1.1.1 public ifEntry > /dev/null
real 0m28.708s
user 0m0.830s
sys 0m0.070s
Do you see the difference?
GUI scalability issue however remains but as we know this will be solved by v. 0.8 of cacti (when? when?).
I assume that the bottleneck is SNMP get/response pingpong (if I am wrong the disregard all my idea). You are using mostly Cisco devices which support SNMP v.2c protocol. This protocol allows for fetching whole table with one request (snmpbulkget and snmpbulkwalk). Therefore you can easily get ifInOctects and ifOutOctects statistics for all interfaces of the device with only two snmpbulkwalk commands (gives 110 operations for all your Cisco devices).
So I would write a script that gathers every 5 minutes the statistics and puts them to MySQL table. Then you need a small script as a Data Input that can read statistics from that table.
I have similar solution for monitoring QoS elements on Cisco with cacti almost implemented. I monitor the routers over WAN links so the speed gain by using snmpbulkwalk command is huge (60 times faster to fetch 700-element SNMP table).
In LAN environment the speed gain is not so big but still impressive. Look below... I fetched whole ifEntry table (about 800 elements) from my router:
[root@host]# time snmpbulkwalk -v 2c -On 10.1.1.1 public ifEntry > /dev/null
real 0m2.080s
user 0m0.710s
sys 0m0.010s
[root@host]# time snmpwalk -On 10.1.1.1 public ifEntry > /dev/null
real 0m28.708s
user 0m0.830s
sys 0m0.070s
Do you see the difference?
GUI scalability issue however remains but as we know this will be solved by v. 0.8 of cacti (when? when?
).Who is online
Users browsing this forum: No registered users and 4 guests