[ovs-dev] RFC for database statistics interface.

Jeremy Stribling strib at nicira.com
Tue Jun 8 23:58:14 UTC 2010


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