On Thu, Feb 19, 2015 at 11:42 AM, Tim Culhane <tim.j.culh...@gmail.com>
wrote:
> Hi,
>
>
>
> Thanks for the response.
>
>
>
> Perhaps I'm not explaining myself properly.
>
>
>
> There will only be ever one instance of the smtpd process we are getting
> the variables from.
>
>
>
> However, the counters are returned with different commands.
>
>
>
> The 'status' command would return status counters. These increase over
> time and show total values since the process was running.
>
>
>
> The performance counters would be returned using a 'performance get'
> command. These counters relate to a counter in a period of time, i.e. ten
> seconds, 1 minute, one hour etc.
>
It doesn't matter how you get the info.
> So, I thought that it would make sense to have a table with each row
> representing a different counter type.
>
>
Columns represent different counter 'types', not rows.
And accessing a specific column/row provides a specific value.
The colunns in the row would hold the values for each counter variable
> returned from the relevant command.
>
If the different commands return different items/concepts, then you would
be populating different columns
not different rows. Again, because its the column that ids the 'thing'.
Rows specify which instance of 'the thing.
> Then, if I want to get the value of all counters I could use snmptable.
>
>
In the end 'snmptable' probably performs individual 'gets' until its
fetched everything,
You can just as easly do a snmpwalk on your part of the OID tree and
accomplish the same thing.
>
>
> If I wanted a specific value I could use snmpget.
>
>
>
> Do you still think that its sensible to use a table to represent the data
> in this way?
>
No. For the reasons I explained.
> If so, can I create an index with a string type and call one 'status' and
> the other 'performance' and then use that when doing a get operation.
>
>
You could, but it would only make sense if the columns, ie. the variables
returned for each
command (status versus performance) were the same things.
Instead, I'd organize it like this then:
1.2.3 razorgate
1.2.3.1 razorgateSmtpStatus
1.2.3.1.1 razorgateSmtpStatusBadHeader
1.2.3.1.2 razorgateSmtpStatusUnsupportedMimeType
1.2.3.1.3 razorgateSmtpStatusMsgTooLong
1.2.3.2 razorgateSmtpPerformance
1.2.3.2.1 razorgateSmtpPerformanceTookTooLong
1.2.3.2.2 razorgateSmtpPerformancePeakSimultaneousMsgs
and that would let you do:
snmpwalk razorgateSmtpStatus to get all the 'status'
snmpwalk razorgateSmtpPerformance to get all the 'performance'
snmpwalk razorgate to get everything
and you can still snmpget the specific items.
and this type of design wouldn't confuse people with a misleading
or unnecessary table.
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
