On 08/12/2014 02:09 PM, William Cohen wrote:
> Hi All,
>
> I have been experimenting with the systmetap mmv support David Smith
> has been developing in the dsmith/mmv branch of systemtap. The
> attached script is a work-in-progress to measure the amount of time
> packets take from getting placed in the queue to the time that the are
> actually transmitted. The list of network devices needs to be passed
> into the systemtap script so that it can set up instances for each of
> the network devices. There is probably a better way of getting the
> device names to the script, but that is done to keep things simple.
>
> The script creates two metrics for each device: number of packets and
> the sum of the latency. The systemtap script provides these basic
> metrics from the start so that the pmda could compute various rate
> on different times scale easily using the following formula for a device
> instance at two times (t1 and t2):
>
> current_latency/packet = (latency[t2]-latency[t1])/(count[t2]-count[t1])
>
>
> Rather than looking up the value identifies with mmv_lookup_value()
> the value identifiers are cached in a couple of associative arrays.
> However, I don't know whether the overhead is a real issue with that.
>
> Next step will be to write the mmv pmda to read this information and
> make it available.
>
> Any comments about the current code would be appreciated.
Sigh.
I've looked at your script. There is nothing really wrong with it in
itself, I'm now just wondering about the whole approach. The whole mmv
interface looks clunky when expressed this way in systemtap. Once we get
past the setup stuff in the begin probe, the update logic in do_update()
is just sad. (Once again this isn't really a critique of your script,
just the interface itself.) The way your script is forced to do updates
doesn't really work - the only way this stuff will work as designed is
that you actually keep the values in metric values, not copy stuff from
systemtap variables into mmv values. Otherwise we're increasing the
problem of inconsistent values between metric values.
With enough work, we could add some systemtap translator support and
make this less clunky. However, I'm not sure that still solves the real
problem here. This real script (as opposed to the fake script I've been
using to develop) has really pointed out the problems here.
Perhaps I'm being too pessimistic here.
If I was looking at what you are really trying to do here, here's a
couple of ideas:
- Use systemtap's procfs interface and write/modify a PCP PMDA to
collect data from it. The advantage here is that PCP can ask to read the
data at whatever interval it wants (1 second, 5 seconds, 1 hour, etc.)
and the data wouldn't be computed until then (and the data would always
be consistent).
- A full-blown event exporter (JSON?) from systemtap. I believe Nathan
has outlined this in the past.
--
David Smith
dsmith@xxxxxxxxxx
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
|