Cacti

Allow me to clarify as the post is not inaccurate, you just misunderstood it. My post above was referring to the info in /proc that the scripts called by cmd.php use to collect data. As BSD doesn't have as complete a /proc as Linux does, you need to be running the Linux compat for several of the sto...

...Is like saying cars *might* be on the road this weekend. Seriously, folks, 0.8 is in no condition to be used at all yet. Lots of the guts of it have been completely changed from previous versions so there are quite a few things that need to be rehacked (not the least of which is a poller - Anybod...

Actually, I think we had decided to put off the ability to create ad-hoc graphs based on existing graphs until after 0.8. We've got our hands full with the changes that are already planned and you've got to draw the 'feature' line somewhere or you'll never release. :) But yes, that capability is one...

Personally, I prefer to hand-roll my Apache and PHP on any machine that's not Debian Linux (blatant plug). Debian seems to have just about everything available either as a module or statically compiled. Lots 'o packages. I haven't seen any other distro, BSD, or Solaris with so many pre-packaged buil...

Wow, easy ones for a change. :) a) Linux compat is only required if you want to use the included scripts to return info on the local box because (to my knowledge) *BSD doesn't have all the /proc/* stuff that the included scripts use. For polling other devices, BSD is fine w/out compat. b) I haven't ...

Also, keep in mind that bulk gets can be faster when you're pulling several OID's but it's overkill to just get one or two. Ideally, the poller would have some configurable thresholds that it uses to decide when do to bulk gets versus individual gets.

Rob.

Actually, the plan at the moment is to NOT implement the gets in Cacti at all. When you're talking about that, you really mean that you'd like snmpbulkget implemented in cmd.php. Rather than trying to develop a good poller in addition to the Cacti interface, the plan is to be able to output an XML-b...

Two problems with that approach: 1) http is *much* higher overhead than a single UDP packet (which is what RRDD uses) 2) The point of having Apache and PHP on the remote boxes is so that if your central server blows up, not only do you have a backup of the data on the remote servers but you can also...

Sounds fine to me but I think you're putting the cart before the horse.

Rob.

Well, we could do that but I could just as easily code a poller in Perl if we wanted a quick kludge. And that just gets us a poller that runs, not one that runs efficiently enough to take advantage of the enhancements we're coding into Cacti for larger enterprises. While I agree that some poller is ...

As far as Jeff's code is concerned, I don't have anything. No docs, no design stuff, no code - only what's been posted here on the boards. If anybody has any additional Spine info, please foward it along to the group so somebody can take over Spine development (even temporarily) or we may end up wit...

Well, yeah, I meant 'as Cacti comes'. With hacking you can make it do robust, distributed polling. Hmm.....

Rob.

As a note, I don't think that the current version of Cacti deals with polling intervals != 5 minutes.

But never fear - the new version will (assuming that we can get Spine development rolling again).

Rob.

If you've got further thoughts on it, please reply here.

http://www.raxnet.net/board/viewtopic.php?p=1764#1764

Actually, it looks like we'll be going with a slightly more robust solution than the one you're describing. Today I've implemented 'Poller Zones' into Cacti. This is still a rough concept of how it would work but the idea is: - You define your zones and as you add hosts to poll, you set which zone t...