[ovs-dev] RFC for database statistics interface.
Ben Pfaff
blp at nicira.com
Wed Jun 9 00:19:47 UTC 2010
I'm not sure that monitoring statistics columns is a great idea most of
the time. But supposing that a client does so, then I was planning to
just have it receive updates whenever something else causes the column
to be updated. That is, the presence or absence of a monitor doesn't in
itself cause columns to be updated.
I thought about a few other possibilities. One is that a monitor gets
updates as fast as they can be generated. I didn't seriously consider
that at all; I can't see any upsides. Another is that a monitor
specifies a maximum update frequency for statistics columns. There
might be some value in that, but the idea behind a statistics column is
that it changes very frequently, so there might not be any benefit over
polling to using a monitor for this purpose, since it would not reduce
the bandwidth required very much.
Do you have a use case that requires something smarter than what I have
in mind? There's no code yet, just documentation, so it's the perfect
time to change things.
Thanks,
Ben.
On Tue, Jun 08, 2010 at 04:58:14PM -0700, Jeremy Stribling wrote:
> This looks ok to me, but how would this interact with monitoring?
> Will the client monitoring a particular statistics column only get
> an update after a client queries the stat? Is it the responsibility
> of the stats provider to update it every once in a while for the
> benefit of monitoring clients? Or maybe it doesn't make sense to
> monitor these statistics, and only query them occasionally.
>
> Ben Pfaff wrote:
> >I'm working on adding support for various kinds of statistics to the
> >OVS configuration database. I'm sending this patch out as a proposal
> >for the schema for statistics and for comments on how they would be
> >handled by the wire protocol for database access.
> >
> >Comments?
> >
> >---
> > ovsdb/SPECS | 185 +++++++++++++++++++++++++++++++++++++++++++-
> > vswitchd/vswitch.ovsschema | 8 ++-
> > vswitchd/vswitch.xml | 67 ++++++++++++++++
> > 3 files changed, 258 insertions(+), 2 deletions(-)
> >
> >diff --git a/ovsdb/SPECS b/ovsdb/SPECS
> >index cbd69de..3584996 100644
> >--- a/ovsdb/SPECS
> >+++ b/ovsdb/SPECS
> >@@ -2,6 +2,7 @@
> > Open vSwitch Configuration Database Specification
> > ===================================================
> >+
> > Basic Notation
> > --------------
> >@@ -77,6 +78,7 @@ values. Additional notation is presented later.
> > more detail. This document does not specify the names or values
> > of these members.
> >+
> > Schema Format
> > -------------
> >@@ -234,6 +236,7 @@ is represented by <database-schema>, as described below.
> > One of the strings "integer", "real", "boolean", "string", or
> > "uuid", representing the specified scalar type.
> >+
> > Wire Protocol
> > -------------
> >@@ -253,7 +256,12 @@ over HTTP, for these reasons:
> > We are using TCP port 6632 for the database JSON-RPC connection.
> >-The database wire protocol consists of the following JSON-RPC methods:
> >+The database wire protocol consists of the JSON-RPC calls listed in
> >+the following sections.
> >+
> >+
> >+Wire Protocol: Database Information
> >+-----------------------------------
> > list_dbs
> > ........
> >@@ -292,6 +300,10 @@ Response object members:
> > This operation retrieves a <database-schema> that describes hosted
> > database <db-name>.
> >+
> >+Wire Protocol: Transactions
> >+---------------------------
> >+
> > transact
> > ........
> >@@ -416,6 +428,10 @@ form:
> > The "cancel" notification itself has no reply.
> >+
> >+Wire Protocol: Table Monitoring and Replication
> >+-----------------------------------------------
> >+
> > monitor
> > .......
> >@@ -544,6 +560,172 @@ Cancels the ongoing table monitor request, identified by the
> > ongoing "monitor" request. No more "update" messages will be sent for
> > this table monitor.
> >+
> >+Wire Protocol: On-Demand Statistics
> >+-----------------------------------
> >+
> >+OVSDB tables can contain columns whose values would change very often
> >+if they were always kept up-to-date. A table might, for example,
> >+contain a column that represents the number of packets that have been
> >+received on a network interface. It wastes CPU time for an OVSDB
> >+client to update these columns frequently if no clients are reading
> >+the updates.
> >+
> >+These OVSDB wire protocols provide a solution. A client that is able
> >+to update a statistical column registers itself as a "stats provider"
> >+with the "stats_register" request. Afterward, when another client
> >+requests the value of that column, the database server checks whether
> >+the column has been updated recently. If not, the database server
> >+postpones its reply and sends a "stats_refresh" request to the stats
> >+provider. The stats provider then updates the column and replies to
> >+the "stats_refresh" request. The database server replies to the
> >+original request.
> >+
> >+The following diagram shows the order and direction of requests and
> >+replies in such a scenario:
> >+
> >+
> >+ stats provider ovsdb-server other client
> >+ | | |
> >+ | "stats_register" request | |
> >+ | -----------------------> | |
> >+ | | |
> >+ | | |
> >+ | "stats_register" reply | |
> >+ | <----------------------- | |
> >+
> >+ . . .
> >+ . . .
> >+ . . .
> >+ "transact" request
> >+ | | to query stats column |
> >+ | | <---------------------- |
> >+ | | |
> >+ | "stats_refresh" request | |
> >+ | <----------------------- | |
> >+ | "transact" request | |
> >+ | to update stats column | |
> >+ | -----------------------> | |
> >+ | | |
> >+ | "transact" reply | |
> >+ | <----------------------- | |
> >+ | | |
> >+ | "stats_refresh" reply | |
> >+ | -----------------------> | |
> >+ | | |
> >+ | | "transact" reply |
> >+ | | ----------------------> |
> >+ | | |
> >+
> >+
> >+On-demand statistics introduce possibilities for livelock and deadlock
> >+among clients in certain situations. An OVSDB server should use
> >+timeouts and heuristics to mitigate or avoid these problems.
> >+
> >+stats_register
> >+..............
> >+
> >+Request object members:
> >+
> >+ "method": "stats_register" required
> >+ "params": [<provide-request>] required
> >+ "id": <nonnull-json-value> required
> >+
> >+<provide-request> is an object with the following members:
> >+
> >+ "stat-id": <json-value> required
> >+ "db": <db-name> required
> >+ "table": <table> required
> >+ "columns": [<column>, ...] required
> >+ "min-aging": <integer> required
> >+
> >+Response object members:
> >+
> >+ "result": {}
> >+ "error": null
> >+ "id": the request "id" member
> >+
> >+An OVSDB client sends this JSON-RPC request to the server to indicate
> >+its ability to update the values of a column on demand. The client
> >+specifies the database, table, and columns that may be updated as the
> >+"db", "table", and "columns" members of <provide-request>.
> >+
> >+The "stat-id" in <provide-request> must be unique among the set of
> >+registered statistics within this JSON-RPC session. It is used in
> >+"stats_unregister" and "stats_refresh" calls to identify this
> >+registration.
> >+
> >+"min-aging" in <provide-request> must be a nonnegative integer. The
> >+database server will not send a "stats_refresh" request for a column
> >+that has been updated more recently than "min-aging" milliseconds ago.
> >+
> >+If the statistical column is successfully registered, the OVSDB server
> >+returns an empty object as its response.
> >+
> >+stats_unregister
> >+................
> >+
> >+Request object members:
> >+
> >+ "method": "stats_unregister" required
> >+ "params": [<json-value>] required
> >+ "id": <nonnull-json-value> required
> >+
> >+Response object members:
> >+
> >+ "result": {}
> >+ "error": null
> >+ "id": the request "id" member
> >+
> >+An OVSDB client sends this request to an OVSDB server to cancel the
> >+statistics registration that was registered with <json-value> as its
> >+"stat-id". After the server sends its response, it will not send any
> >+more "stats_refresh" messages for the given "stat-id".
> >+
> >+stats_refresh
> >+.............
> >+
> >+Request object members:
> >+
> >+ "method": "stats_refresh" required
> >+ "params": [<stats-refresh-request>] required
> >+ "id": <nonnull-json-value> required
> >+
> >+<stats-refresh-request> is an object with the following members:
> >+
> >+ "stat-id": <json-value> required
> >+ "table": <table> required
> >+ "columns": [<column>, ...] required
> >+ "rows": [<uuid>*] required
> >+
> >+Response object members:
> >+
> >+ "result": {}
> >+ "error": null
> >+ "id": the request "id" member
> >+
> >+An OVSDB server sends this request to an OVSDB client to ask it to
> >+update the values of one or more statistical columns registered with
> >+"stats_register". The <stats-refresh-request> contains: +
> >+ - "stat-id": The "stat-id" from the "stats_register" request.
> >+
> >+ - "table": The "table" from the "stats_register" request.
> >+
> >+ - "columns": One or more of the "columns" from the request,
> >+ requesting that those columns be updated.
> >+
> >+ - "rows": Zero or more UUIDs of rows to be updated. If no rows
> >+ are listed, the client should update every row.
> >+
> >+The client should update the requested rows and columns (using one or
> >+more "transact" requests) and only then send its reply. The OVSDB
> >+client does not need to update rows and columns whose values have not
> >+actually changed.
> >+
> >+Wire Protocol: Testing
> >+----------------------
> >+
> > echo
> > ....
> >@@ -790,6 +972,7 @@ Notation for the Wire Protocol
> > One of "+=", "-=", "*=", "/=", "%=", "insert", "delete".
> >+
> > Operations
> > ----------
> >diff --git a/vswitchd/vswitch.ovsschema b/vswitchd/vswitch.ovsschema
> >index 9e3573f..d14737e 100644
> >--- a/vswitchd/vswitch.ovsschema
> >+++ b/vswitchd/vswitch.ovsschema
> >@@ -22,7 +22,10 @@
> > "next_cfg": {
> > "type": "integer"},
> > "cur_cfg": {
> >- "type": "integer"}},
> >+ "type": "integer"},
> >+ "statistics": {
> >+ "type": {"key": "string", "value": "integer", "min": 0, "max": "unlimited"},
> >+ "ephemeral": true}},
> > "maxRows": 1},
> > "Bridge": {
> > "columns": {
> >@@ -116,6 +119,9 @@
> > "type": {"key": "string", "value": "string", "min": 0, "max": "unlimited"}},
> > "ofport": {
> > "type": {"key": "integer", "min": 0, "max": 1},
> >+ "ephemeral": true},
> >+ "statistics": {
> >+ "type": {"key": "string", "value": "integer", "min": 0, "max": "unlimited"},
> > "ephemeral": true}}},
> > "Mirror": {
> > "columns": {
> >diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
> >index 345744e..dad347f 100644
> >--- a/vswitchd/vswitch.xml
> >+++ b/vswitchd/vswitch.xml
> >@@ -56,6 +56,25 @@
> > <ref column="next_cfg"/> after it finishes applying a set of
> > configuration changes.
> > </column>
> >+
> >+ <column name="statistics">
> >+ <p>
> >+ Key-value pairs that report statistics about a running Open_vSwitch
> >+ daemon. These statistics counters are updated when they are queried
> >+ (e.g. using an OVSDB <code>select</code> operation). They may also
> >+ be updated at other times, but they are not updated at any regular
> >+ interval.</p>
> >+ <p>
> >+ The currently defined key-value pairs are listed below. Some Open
> >+ vSwitch implementations may not support some statistics, in which
> >+ case those key-value pairs are omitted.</p>
> >+ <dl>
> >+ <dt><code>load-average</code></dt>
> >+ <dd>
> >+ System load average multiplied by 100 and rounded to the nearest
> >+ integer.</dd>
> >+ </dl>
> >+ </column>
> > </group>
> > </table>
> >@@ -503,6 +522,54 @@
> > field in the VIF record for this interface.</dd>
> > </dl>
> > </column>
> >+
> >+ <column name="statistics">
> >+ <p>
> >+ Key-value pairs that report interface statistics. Interface
> >+ statistical counters are updated when a interface is created and when
> >+ they are queried (e.g. using an OVSDB <code>select</code> operation).
> >+ Open vSwitch also updates them just before an interface is deleted
> >+ due to virtual interface hot-unplug or VM shutdown. Statistics may
> >+ also be updated at other times, but they are not updated at any
> >+ regular interval.</p>
> >+ <p>
> >+ The currently defined key-value pairs are listed below. These are
> >+ the same statistics reported by OpenFlow in its <code>struct
> >+ ofp_port_stats</code> structure. If an interface does not support a
> >+ given statistic, then that pair is omitted.</p>
> >+ <dl>
> >+ <dt><code>rx_packets</code></dt>
> >+ <dd>Number of received packets.</dd>
> >+ <dt><code>tx_packets</code></dt>
> >+ <dd>Number of transmitted packets.</dd>
> >+ <dt><code>rx_bytes</code></dt>
> >+ <dd>Number of received bytes.</dd>
> >+ <dt><code>tx_bytes</code></dt>
> >+ <dd>Number of transmitted bytes.</dd>
> >+ <dt><code>rx_dropped</code></dt>
> >+ <dd>Number of packets dropped by RX.</dd>
> >+ <dt><code>tx_dropped</code></dt>
> >+ <dd>Number of packets dropped by TX.</dd>
> >+ <dt><code>rx_errors</code></dt>
> >+ <dd>
> >+ Number of receive errors. This is a super-set of receive errors
> >+ and should be great than or equal to the sum of
> >+ <code>rx_frame_err</code>, <code>rx_over_err</code>, and
> >+ <code>rx_crc_err</code>.</dd>
> >+ <dt><code>tx_errors</code></dt>
> >+ <dd>
> >+ Number of transmit errors. This is a super-set of transmit
> >+ errors.</dd>
> >+ <dt><code>rx_frame_err</code></dt>
> >+ <dd>Number of frame alignment errors.</dd>
> >+ <dt><code>rx_over_err</code></dt>
> >+ <dd>Number of packets with RX overrun.</dd>
> >+ <dt><code>rx_crc_err</code></dt>
> >+ <dd>Number of CRC errors.</dd>
> >+ <dt><code>collisions</code></dt>
> >+ <dd>Number of collisions.</dd>
> >+ </dl>
> >+ </column>
> > </group>
> > </table>
>
More information about the dev
mailing list