Damian Krzeminski wrote:

Andrei: I had a quick look at the patch. I think I can apply it after rebase (see attached), but I am not sure it that would be correct. After splitting SNMP and MRTG configuration we assume that SNMP is run on all servers in the cluster while MRTG only on the primary server (the one where sipXconfig is running). Your patch exposes call statistics through SNMP, but call statistics is internally provided by call resolver which only runs on a primary server.

You're right. Somehow I didn't think about this. I actually tested this back when I made this feature by putting a new entry in "topology.xml"
witch pointed to another server. But I didn't realize that the distributed server in the real world would not have any database or call resolver.
I'm not quite sure how to handle this from sipXconfig. Call statistics are general for the whole system, and cannot be split into call statistics for primary and call statistics for
distributed server. What would be the best way to display this? At the moment, statistics can be displayed for either
primary or distributed server. Probably the best way to display call statistics is let the admin configure call statistics just for
the primary server, and when these are displayed, we shouldn't let him choose between hosts.
Is it o.k. to assume that the primary server is LocationsManager.getLocations()[0]? Because this is the way MonitoringContext gets
its hosts.

I rebased your patch and move snmp initialization to a newly created sipx-snmp-init, but I am not sure if that's the right thing to do. Ideally sipXagentX would be responsible for configuring SNMP agent, right?

I guess that ideally, both snmp and mrtg should be managed by sipXsupervisor, and their configuration should be replicated through the replication mechanism.
After reading a bit about snmp, it seems that this could be possible, and it could be possible to have more than on instance of snmp agent running on different ports.
But I'm not that familiar with snmp and I might be wrong.

Do you have any suggestions on how to proceed? I was thinking that one possible solution would be asking every service to install its own part of snmp configuration. If snmpd does not support natively reading the configuration from multiple files we could add the functionality that assembles a single file (since we already have sipxconfig-snmp module that changes that file). That would allow sipXagentX to install its own MIBs only on the primary server.

Taken from the man snmp_config:

Applications will read persistent configuration files in the following order of preference:

file in SNMP_PERSISTENT_FILE environment variable

directories in SNMPCONFPATH environment variable

directory defined by persistentDir snmp.conf variable

directory in SNMP_PERSISTENT_DIR environment variable

default /var/net-snmp directory

But I haven't found what would happen if the configuration files contradict themselves. snmpd can also be started with a -c FILES switch to specify configuration files separated by commas. There is
also a -I switch, specifying which modules should (or should not) be initialized when the agent starts up.
So I'm guessing that there are a lot of possibilities to make this work if only we could have snmp managed by sipXsupervisor.

But this is in the long range. For the moment, I guess that a temporary solution is to have snmpd.conf installed in the same way on both servers.
I've tested a little and it seems that snmp doesn't complain if a dynamic module or MIB doesn't exist:

snmpget -v 1 -c sipxecs localhost .1.3.6.1.4.1.7142.100.0.1
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-SMI::enterprises.7142.100.0.1

So telling snmpd to load modules and MIBs that doesn't exist is not a problem. It seems that it will just ignore them.

What do you think? D.