Spec proposal suggestion

[Steven Le Roux]

Hi, 

Great initiative !

I propose a similar spec ( https://github.com/StevenLeRoux/TimeSeries_Format_Specification ) about TimeSeries.

From the metrics20 spec, I disagree that unit should be present. It can be, but making it mandatory makes you loose some flexibility. Imagine that you have a metrics for a service that is failing, you could set it to a Boolean value like "F" for False. If it recovers, the value could be set to the measured value. You don't what the user wants to do, so set a constraint is not a good thing.

The proposed spec only convers *time* series and does not cover *geo*timeseries.

This is why I suggest the following format : 

Timeseries : timestamp// key{tags} value

GeoTimeseries : timestamp/lat:lon/alt key{tags} value

[Dieter Plaetinck]

Hi Steven,
the idea is that the unit is a fundamental property of the metric.  I.e. you can't change the unit of an existing timeseries, otherwise you'd need to change all values. 
The key that points to a timeseries (i.e. the metric) is all the information that intrinsically describes the data within that timeseries.
So the unit is such a fundamental property of the actual data, that if you would want to track the same "thing", but in a different unit, you would use a new timeseries with a different metric (key) for it.

Your example didn't specify what the "measured value" would be, but I assume something like a response time.
You actually can use a numeric value (in say, unit=ms) as the value, and also none/unknown as a value, in case the service is down.

As for geo coordinates, I think there's 3 scenarios:
* lat/long is always intrinsic to the metric -> include lat/long as tags in the metric, so that different values of lat/long mean a different timeseries
* lat long is always extrinsic to the metric -> include lat/long as metadata tags in the metric, so that we keep using the same metric & timeseries but update the metadata for new lat/long values.
* intrinsic or extrinsic is hard to say, or may change over time, or is use case (information need) dependent -> instead of using timeseries metrics, doing this as logs where every tag field is always explicit in every record, is a model that maps cleaner to these use cases, and you can do analytics over your logs in a way that maps to the given information need.

[Steven Le Roux]

Hi Dieter,

Using tags to store geo properties means you could use tags to store the timestamp. It doesn't make sense if you want to achieve good performance for huge dataset.

I understand it depends on the backend you're using, but if you set first class properties of a serie, like its coordinates in time and geo, and treat them differently (some are tags, others are not), it will lose the differenciation from the processing. In backends, timestamp are not stored/processed like tags. I think it's not a good thing to treat one dimension in a way and others in another.

When you say that different lat:lon implies a different serie, you're wrong here. why would it be a différent one ? If the serie is the current speed of a boat. Time changes, coordinates change, but it represents the same serie.

Regards, 

[Dieter Plaetinck]

On Monday, 28 April 2014 05:32:21 UTC-4, Steven Le Roux wrote:

When you say that different lat:lon implies a different serie, you're wrong here. why would it be a différent one ? If the serie is the current speed of a boat. Time changes, coordinates change, but it represents the same serie.

I didn't say this.  I said it's use case dependent, and up to the user to make the decision of whether location is intrinsic or extrinsic to the metric.  A case where it would be intrinsic is for example when you have a bunch of access points of the same type in different locations.  In this case location is a great way to seperate them from each other, especially when you can't easily come up with a uniform naming scheme.