[ovs-dev] RFC for database statistics interface.
Ben Pfaff
blp at nicira.com
Wed Jun 9 10:43:23 PDT 2010
On Wed, Jun 09, 2010 at 08:05:40AM -0700, Keith Amidon wrote:
> On Tue, 08 Jun 2010 18:43:59 -0700, Jeremy Stribling <strib at nicira.com> wrote:
> > The only use case I know is for the controller to poll the stats at a
> > given interval, but monitor the statistics for delete events (so it can
> > receive the last known value for the statistics). So as long as there's
> > an understanding that the stats provider will update it one last time
> > before deleting, what you propose will be fine.
>
> This is the primary use case I've heard discussed as well. In
> generally, I've been thinking that we need to do everything we can to
> minimize the amount of polling the controllers have to do.
>
> For normal rx/tx stats the monitoring for delete case is probably
> sufficient given 64-bit counters. For error stats however the
> controller may want to know about relatively small changes without
> waiting for what could be a very long polling interval. A monitor with
> a threshold seems like it would solve this problem nicely.
>
> All this is a long-winded way of saying that associating a local polling
> interval with each stat and then using that to trigger monitors is
> something I think we should strongly consider. If the controller could
> set the local polling interval as well as read it (e.g. reduce it from a
> relatively long default) that would be ideal.
It makes sense for ovs-vswitchd to send a statistics update to the
database for an interface if its error counters are increasing. I
hadn't thought about that case. Thank you for bringing it up.
It sounds like a refinement that we could implement without a protocol
change. The vswitch would locally poll the interfaces at a reasonable
rate (once a second, for example). If the error counters have
increases, it sends an update to the database process. No problem.
More information about the dev
mailing list