Skip to content

Latest commit

 

History

History
84 lines (51 loc) · 3.81 KB

grafana.adoc

File metadata and controls

84 lines (51 loc) · 3.81 KB
Raw

Visualizing time-data statistics with Grafana

Writing time-data statistics to InfluxDB, by itself, is not that helpful. You need the means to visualize what’s happening. The purpose of Grafana is to make that happen.

This page shows examples of what you can get from dhcperfcli time-data.

Grafana configuration

First you need to configure a datasource for your InfluxDB.

For example:

  • Name: InfluxDB-dpc

  • HTTP / URL: http://10.11.12.84:8086

  • Auth: as appropriate for your Influx setup

  • InfluxDB Details / Database: dpc

Dashboard examples

Packets (Discover, Offer, Request, Ack)

The following dashboard gets data from the packet table.

It is composed of four queries:

SELECT sum("sent") FROM "packet" WHERE ("type" = 'Discover') AND $timeFilter GROUP BY time(1s) fill(null)
SELECT sum("recv") FROM "packet" WHERE ("type" = 'Offer') AND $timeFilter GROUP BY time(1s) fill(null)
SELECT sum("sent") FROM "packet" WHERE ("type" = 'Request') AND $timeFilter GROUP BY time(1s) fill(null)
SELECT sum("recv") FROM "packet" WHERE ("type" = 'Ack') AND $timeFilter GROUP BY time(1s) fill(null)

The example is from a 5 minutes DORA benchmark, composed of two segments: the first with a rate of 500 DORA/s, and the second a rate of 1000 DORA/s.

Notice that there are four curves in this graph (which correspond to the Grafana queries), but they all are all exactly superimposed (Discover.sent and Ack.recv are currently selected, but Offer and Request are just the same). This is what is expected in nominal case, with one client and one server: each Discover sent is replied with an Offer, and each Request with an Ack.

packet DORA example


This is just an example. Other types of packets can be graphed, if needed. Just add more queries to handle them, perhaps also new dashboards to avoid clutter.

Transactions response time

The following dashboard gets data from the transaction table.

It is composed of the following query:

SELECT mean("rtt.avg") AS "rtt.avg" FROM "transaction" WHERE $timeFilter GROUP BY time(1s), "type" fill(null)

The example is from a 5 minutes benchmark, sending DHCP Discover to two servers (Kea, and a dummy FreeRADIUS DHCP server) at the same rate for each.

The resulting graph allows to easily compare response times (shown in milliseconds).

Notice that even though we provided only one query, there are two graphs shown. This is achieved through a "GROUP BY type" which allows to automatically display all types found in the selected time range.

transaction RTT example


Sessions and target rate

The following dashboard gets data from the session table.

It is composed of the following queries:

SELECT sum("num") FROM "session" WHERE $timeFilter GROUP BY time(1s), "input" fill(null)
SELECT sum("target") AS "target" FROM "session" WHERE $timeFilter GROUP BY time(1s), "input" fill(null)
SELECT sum("target") FROM "session" WHERE $timeFilter GROUP BY time(1s) fill(null)
  ALIAS BY session.target.all

The example is from a 5 minutes Discover benchmark, composed of five segments with increasing intended (target) rate: 8k Discover/s, then 10k, 12k, 14k and 16k.

The graphs shows the target rate, which is what dhcperfcli expects, and the sad reality of a DHCP server that is unable to keep up beyond about 12k Discover/s.

session with input segments


Note: the curve session.target.all would be useful if there were more than a single input. In this example, it is the same as session.target for that lone input.