[zeromq-dev] Last call for Extensible Statistics Transmission Protocol (ESTP) v1.0

[Schmurfy]

I started implementing it and I have some comments:

the types as defined in RRD are not that great we seem to agree on that
since you renamed one already so why not going a step further ?
Here is some thoughts about the current types:

GAUGE: not much to say about this one, it is pretty self explanatory.
COUNTER: the value sent can only grows and will never reset (except on
overflow), fine too

DERIVE: that's were I am getting skeptical, once we agree that the type
used at the end of the chain (you advice using DERIVE RRD type to store
counters)
  (say RRD) is not the one used in the protocol is there really any reason
to have a DERIVE type in the protocol ? Would a client send the derive
computed by
  itself or send the raw value and let the server do this ? In the later
case this is just a counter.

DELTA: what is the difference between GAUGE and DELTA ?

Here is something to think about on types, say I have a probe sending the
number of bytes sent by the network card to my central server,
now what I want to graph is:
- the speed at which data are sent
- the total number of bytes sent (say I want to check how much I will pay
at the end of the month)

For this I would prefer having my client sending one metric which is the
number of bytes sent and then let the server store the data, one metric
received
could lead to storing two, three or maybe more RRD metrics (if used) but
why the client should care about that ?

I may be completely wrong on the goal of the types but for me they should
just define what the client is sending and not how
the data will be ultimately stored on disk if we want something flexible.
So are the current types a definition of what is sent or an indication of
how to store the data ?


On 11 June 2012 22:59, Paul Colomiets <paul at colomiets.name> wrote:

> Hi,
>
> I'm going to pronounce protocol version v1.0, as its now complete, and
> most issues discussed here are fixed. Now it's an opportunity to find
> last issues, before freezing the specification.
>
>
> The last changes are:
>
> * Type is denoted by colon and english letter, instead of cryptic character
>
> * There is "x" type marker that allows experimental types
>
>
> Spec is now in github organization, which should aggregate projects
> using the protocol:
>
> https://github.com/estp/estp/blob/master/specification.rst
>
> I'll be happy if someone could fix grammar, as I'm not native English
> speaker (We are not at IETF yet, so will fix grammar later if needed,
> but now is a better time).
>
>
> There is also collectd plugin implementation (it supports v0.2 proto
> at the time of writing, but will be updated soon):
>
> https://github.com/estp/collectd-zeromq-estp
>
>
> After protocol is declared stable, the following steps will be next:
>
> * Define collectd extension, which allows to transfer data losslessly
> between collectd instances (and implement it in plugin)
>
> * Implement collectd plugin for crossroads (mostly same as zeromq one)
>
> * Define a recommendation for the metric names to use for various
> application classes and propose to their communities, HTTP servers
> being the first in my plan
>
> --
> Paul
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120614/3d626a64/attachment.htm>