Hi Fulko,
Not sure if yo had a chance to look at my questions below.
Am I right that you are suggesting that I implement my counters as a series
of scalar objects below the razorgateStatusCounters oid?
Would I then use the mib2c.scalar.conf configuration file to generate the
required code for my shared object?
Thanks,
Tim
From: Tim Culhane [mailto:tim.j.culh...@gmail.com]
Sent: 20 February 2015 09:01
To: 'Fulko Hew'
Cc: 'Net-SNMP Coders'
Subject: RE: accessing a specific row in a mib table
Hi Fulko,
Ok, I sort of understand.
I've modified the oid names slightly in my below example:
So, in a mib definition I would have:
1.2.3 razorgate
razorgate OBJECT IDENTIFIER
::= { owmRgMib 301 }
1.2.3.1 razorgateSmtpStatusCounters
razorgateSmtpStatusCounters OBJECT IDENTIFIER
::= { razorgate 1 }
1.2.3.2 razorgateSmtpPerformanceCounters
razorgateSmtpPerformanceCounters OBJECT IDENTIFIER
::= { razorgate 2 }
But then how do I define the actual counter values below these oid
For example we have:
1.2.3.1.1 razorgateSmtpStatusBadHeader
They are not defined in a table, but don't they need to be listed somewhere
and then actually defined, i.e. their type, whether they are accessible etc?
Lastly, I was using mib2c to produce my skeleton shared object. Since my
shared object was using a table I used the mib2c.mfd.conf configuration
file.
What configuration file should I use for the layout of the mib that you are
suggesting?
Thanks,
Tim
From: Fulko Hew [mailto:fulko....@gmail.com]
Sent: 19 February 2015 17:06
To: Tim Culhane
Cc: Net-SNMP Coders
Subject: Re: accessing a specific row in a mib table
On Thu, Feb 19, 2015 at 11:42 AM, Tim Culhane <tim.j.culh...@gmail.com
<mailto: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
