Bandwidth Monitoring

[Karl]

Hi Guys,

I know we've discussed this in private about ways of doing this, but I have a feeling some of the methods will break on upgrades etc.

What I propose, is that each node runs an SNMPD process as standard (or it can be turned off), that can provide us with raw stats if we need them - but also that the controller, collects these stats and provides them via SNMP as well - Along with computed summaries i.e. App XYZ-1 is doing 10240bit/s out of public interfaces and 102400bit/s on the back end and it'd also tell us what XYZ:main.web1 is doing, XYZ:main.db1 is doing etc. etc.

Also CPU, memory, disk stats for the nodes themselves and possibly for the virtual machines.

Cheers,

[tmart]

I agree that standardizing on SNMP exposure of statistics would be very helpful.

I would add one feature, however: Each running component should be told about its "quota" for resource allocation so that we might also know what percentage of allocated resources is being consumed. For example, it is misleading to show that a given component is talking to the network at a sustained rate of 9MB/sec if the total network resources for that component are limited to 10MB/sec.

Perhaps there's an easier way to do this, but it seems like the resource allocations for each component could be passed in as envars just as properties are passed in. Or are the resource allocation figures available elsewhere?

[Karl]

Hi,

Sorry to bump, any thoughts on this guys?

Cheers,

[PeterNic]

Yup - after the controller failover; seeing you also posted on that one, I trust you will agree.

Looks like the agentX way of extending SNMP seems most appropriate, as does SNMPv3 as a version of the protocol (secure auth and encrypted data seems like a good way to go, even though for now SNMP support is planned to be read-only). We have also registered an enterprise MIB number for 3Tera, so the extensions will be easy to code. All dashboard messages will generate traps.

For now, the best mechanism is by running your favorite SNMP agent inside the gateway appliances (or custom appliances with external interfaces); this allows easy hookup of MRTG or whatever you are using. It works and it is tamper-proof as long as you don't provide root access to customers on these appliances. This doesn't cover all cases but we have many customers who are using it.

Bandwidth monitoring will probably first become available through the metering system; we will work with the engineering team to make the SNMP support available either concurrently with it or shortly thereafter (this will give you real-time data).

Regards,
-- Peter

[Karl]

Read only SNMPv3 is great by me. We're more concerned about monitoring it in a simple VDS type setup TBH and calculating it in to GB transfered, although obviously being able to monitor it for individual appliances would be fantastic.

Thanks,

[Warren.Moxley]

All dashboard messages will generate traps.


Sorry to bump thread. Was this ever implemented?

[PeterNic]

Bandwidth metering has been implemented; it will be part of the standard AppLogic metering (e.g., resources and appliances), not via SNMP. Release date and more information to follow...

[PeterNic]

@Warren.Moxley: SNMPv3 support is in the backlog; I don't believe it is in any scheduled release so far.

I think a customer had implemented a simple e-mail-to-SNMP-trap gateway, which is one way to get that functionality today. The simplest approach I see is to use something like Perl's Net::SNMP::Server inside a WEB5 appliance.

Best regards,
- Peter