Opened 8 years ago

Closed 8 years ago

#1448 closed task (complete)

document basic design of stats snmp interface

Reported by: naokikambe Owned by: UnAssigned
Priority: medium Milestone: Sprint-20120320
Component: statistics Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket: SNMP stats
Estimated Difficulty: 5 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description (last modified by naokikambe)

document basic design of stats snmp interface like the wikipage StatsModule according to the prototype of #916

Subtickets

Change History (12)

comment:1 Changed 8 years ago by naokikambe

  • Description modified (diff)

comment:2 Changed 8 years ago by jelte

  • Estimated Difficulty changed from 0 to 5

comment:3 Changed 8 years ago by jelte

  • Milestone changed from Next-Sprint-Proposed to Sprint-20111220

comment:4 Changed 8 years ago by shane

  • Feature Depending on Ticket set to SNMP stats

comment:5 Changed 8 years ago by naokikambe

  • Owner set to naokikambe
  • Status changed from new to accepted

comment:6 Changed 8 years ago by naokikambe

  • Owner changed from naokikambe to UnAssigned
  • Status changed from accepted to reviewing

The wikipage StatsModule#StatsSnmp is ready for reviewing. I wrote the document about the SNMP interface in the existent StatsModule page. I also changed widely other parts of the page which are not related directly to this ticket. But such changes are indentation, typo fixing, addition of introduction, and so on.

comment:7 follow-up: Changed 8 years ago by jelte

Not really about the snmp part, but I was wondering if we should make this a pull-protocol instead of a push one. I.E. instead of letting each module send their statistics at a regular interval, letting the main stats module request them at that interval. The result would be that modules would not have to take any action should stats module not run (and/or there is only one place where we need a timer for statistics, and we can make a command for stats module 'collect now'.

One way to do this would be to let all modules automatically subscribe to some Stats channel on the msgq, and if a SendStats? command appears, each one does what it currently does when it sends stats.

comment:8 in reply to: ↑ 7 ; follow-up: Changed 8 years ago by naokikambe

Replying to jelte:
Hello,

IMO in this pull-protocol a non-stats module doesn't have to take care about the timing to push its statistics to the stats. the timing doesn't need to be periodical exactly. The non-stats module can be free to throw its statistics.
OTOH in push-protocol it's high cost for a non-stats module to wait for a request from stats. Especially for a usual busy module like auth, it might be truly high cost. Besides, in order to migrate to the push-protocol, we should implement each non-stats module to wait for the stats and should implement stats to request to each non-stats module.
BTW as another approach: each non-stats module stores its statistics somewhere in the SQLite database, and then stats module reads there periodically. Such statistics saved in the sqlite might be permanent even if the bind 10 reboots. But after the bind10 starts, each module may have to take care about consistency of statistics data between in database and in itself.
Anyway I don't think we should discuss here about these protocols.

Best,

comment:9 in reply to: ↑ 8 Changed 8 years ago by jinmei

Replying to naokikambe:

BTW as another approach: each non-stats module stores its statistics somewhere in the SQLite database, and then stats module reads there periodically. Such statistics saved in the sqlite might be permanent even if the bind 10 reboots. But after the bind10 starts, each module may have to take care about consistency of statistics data between in database and in itself.

I've been thinking about the same idea, especially in the context of
handling a huge amount of statistics information (e.g., for an auth
server managing millions of zones and collecting statistics per
zone). Whether it's push or pull, it would be just unrealistic to
exchange the counters via a msgq (or its successor). Using a
permanent database storage as a shared placeholder of statistics would
be one possible solution in that scenario.

Anyway...

Anyway I don't think we should discuss here about these protocols.

...that's right. This should go to a separate ticket (and/or
perhaps a biweekly call topic)

comment:10 Changed 8 years ago by naokikambe

  • Owner changed from UnAssigned to naokikambe

comment:11 Changed 8 years ago by naokikambe

  • Owner changed from naokikambe to UnAssigned

Some quick comments sent to bind10-dev list:
https://lists.isc.org/pipermail/bind10-dev/2012-February/003011.html

My thoughts to these comments are:

1) I think they discuss it later on but I think you probably want to try
and arrange things so that other SNMP engines can be used. For
people running our code in "free" settings they are likely to use
NET-SNMP. For people putting our code into devices for sale
they might choose one of the other SNMP engines available. It
would be good to try and make it easy for them to do so. We
probably don't want to write the code to connect the engine to
our code but making the information easily available would be nice.

Of course, I don't think we would finish implementation of the SNMP feature dependent on NET-SNMP. I think we might consider the independent daemon for the stats SNMP in next Y4. I thought my idea written in that document would be a temporary thing which we could make in Y3. I understand many issues on the stats SNMP.

2) We should use our own enterprise number as the root for the
OIDs. If we don't have one we should get one. We probably want
to put some thought into the arrangement of the tree to support
bind10, dhcp10 and potentially other products.

I think things about the enterprise OID would be out of scope in that document. I think the SNMP would be used for the purpose to collect statistics in that document. So I think we might make the SNMP feature on BIND 10 disabled as a default setting. Because I imagine there might be some users who don't really want to use it.

3) In conjunction with (2) we also may need/want to provide space
for configuring things via SNMP. Has the Bind10 team thought about
this? I wouldn't be surprised if you decided to only provide stats
level information, but a small number of configuration options
(on, off, etc) might be useful. When last I was involved with SNMP
it tended to be more used for monitoring than configuring and I don't
think that has really changed. However there were exceptions cable
modems and US DOD being the two big ones.

I think the SNMP-GET would be used only for SNMP interface for the statistics collection as well as the XML/HTTP interface in that document. Of course, I know that we could change some configurations of BIND 10 if we additionally introduce the SNMP-SET. We might fully redesign the SNMP interface if we get to collect another information. But I don't think that now.

4) I'm a little iffy about the auto-generation stuff. It is fine to
start with
but we need to make sure that the MIB OIDs don't change after they
have been published. We will need to publish a MIB to allow SNMP
managers to gather and interpret the data. Once we do this we can't
change the existing relationships. We can deprecate them and add
new ones but we can't change old ones. (This is also why we want
to put some thought into the layout of the OIDs.)

Yes, I know that auto-generation is inappropriate approach. We'll resolve this issue in #1544.

I'm going to leave the ticket reviewing again. But unless we have further comments/opinions about that document, I'd like to close this ticket and ask whether we should continue to develop the SNMP stats according to the document.

comment:12 Changed 8 years ago by jelte

  • Resolution set to complete
  • Status changed from reviewing to closed

I think it's pretty safe to assume there won't be any more comments here until we start building or have something to complain about ;) So I'm closing this ticket.

Note: See TracTickets for help on using tickets.