[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