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 <[email protected]> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
