Re: XCF-1891 Implement Call Statistics into MRTG implementation

<div>
Damian Krzeminski wrote:
<blockquote cite="mid:g3h16b$3ad$1 <at> ger.gmane.org" type="cite">
  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.

</blockquote>
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" <br>
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.<br>
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<br>
distributed server. What would be the best way to display this? At the
moment, statistics can be displayed for either<br>
primary or distributed server. Probably the best way to display call
statistics is let the admin configure call statistics just for<br>
the primary server, and when these are displayed, we shouldn't let him
choose between hosts.<br>
Is it o.k. to assume that the primary server is
LocationsManager.getLocations()[0]? Because this is the way
MonitoringContext gets<br>
its hosts.<br><blockquote cite="mid:g3h16b$3ad$1 <at> ger.gmane.org" type="cite">

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?

</blockquote>
I guess that ideally, both snmp and mrtg should be managed by
sipXsupervisor, and their configuration should be replicated through
the replication mechanism.<br>
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.<br>
But I'm not that familiar with snmp and I might be wrong.<br><blockquote cite="mid:g3h16b$3ad$1 <at> ger.gmane.org" type="cite">

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.

</blockquote>
Taken from the man snmp_config:<br><p>Applications will read persistent configuration files in the
following order of preference:</p>

    <p>file in SNMP_PERSISTENT_FILE environment variable</p>
    <p>directories in SNMPCONFPATH environment variable</p>
    <p>directory defined by persistentDir snmp.conf variable</p>
    <p>directory in SNMP_PERSISTENT_DIR environment variable</p>
    <p>default /var/net-snmp directory</p>

  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<br>
also a -I switch, specifying which modules should (or should
not) be initialized when the agent starts up. <br>
So I'm guessing that there are a lot of possibilities to make this work
if only we could have snmp managed by sipXsupervisor.<br><br>
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.<br>
I've tested a little and it seems that snmp doesn't complain if a
dynamic module or MIB doesn't exist:<br><blockquote type="cite">snmpget -v 1 -c sipxecs localhost
.1.3.6.1.4.1.7142.100.0.1<br>
Error in packet<br>
Reason: (noSuchName) There is no such variable name in this MIB.<br>
Failed object: SNMPv2-SMI::enterprises.7142.100.0.1<br>
</blockquote>
So telling snmpd to load modules and MIBs that doesn't exist is not a
problem. It seems that it will just ignore them.<br><blockquote cite="mid:g3h16b$3ad$1 <at> ger.gmane.org" type="cite">

What do you think?
D.

</blockquote>
<br>
</div>