get does not accept composite metrics

[edechter]

The (get method)[https://github.com/librato/python-librato/blob/master/librato/init.py#L187] does not accept the compose parameter, because it requires a name argument.

I could provide a patch but the api doesn't specify what to expect in the response to a compose request so I don't know how to set up Guage or Counter object given such a response.

[nextmat]

@edechter Thanks for the report. We should address this.

@jderrett or @drio have any time to take a look at this?

[jderrett]

Yep, I'll take a look.

On Sunday, June 15, 2014, Matt Sanders notifications@github.com wrote:

@edechter https://github.com/edechter Thanks for the report. We should
address this.

@jderrett https://github.com/jderrett or @drio https://github.com/drio
have any time to take a look at this?

—
Reply to this email directly or view it on GitHub
#57 (comment)
.

[drio]

@jderrett Feel free to send a PR if you want some code review.

[jderrett]

Still trying to wrap my head around how we should implement (and test) composite metrics here. A possible workaround might be to "borrow" the list_metrics method to do this:

>>> resp = conn.list_metrics(start_time=1403215408, compose='s("a*", "*")', resolution=60)
>>> resp['measurements'][0]['metric']
{u'display_name': None, u'description': None, u'period': 600, u'attributes': {u'summarize_function': u'average', u'display_units_short': u'F', u'created_by_ua': u'librato-metrics/1.3.0 (ruby; 1.9.3p0; x86_64-linux) direct-faraday/0.8.9', u'display_stacked': False, u'display_max': 120, u'color': u'#bc2a2a', u'gap_detection': True, u'aggregate': True, u'display_min': 20, u'display_units_long': u'Deg F'}, u'type': u'gauge', u'name': u'apparent_temperature'}
# values from the first stream
>>> map(lambda v: v['value'], resp['measurements'][0]['series'])
[95.62, 93.65, 94.07, 93.9, 93.71]

[drio]

👍. Perhaps we could have a dedicated method in connection for dealing with compose metrics .compose?

As for the testing, we could write a couple of test cases that exercise the new method and mock the behaviour in mock_connection.py for a very simple composition function?

[nextmat]

Does it make sense to generalize the object generated by the response into something like TimeSeries instead for all requests that are fetching time series?

[jderrett]

I've started work on this here: https://github.com/librato/python-librato/tree/feature/composites let me know what you guys think.

[mauricioborges]

@jderrett , are you still working on it? In fact i'd like to GET and POST composite instruments. I'll work on it a bit depending on your status. Thanks in advance!

[jderrett]

@mauricioborges sorry, this has been stalled for a while, and it'll be a week or so before I'm back online. I may simplify this API a bit to allow a simple GET, and then move to support for "persisted composites" which is essentially a new metric type. Also, I'm not sure about POSTing to instruments - if the stream properties are set using composite_function it may already work? (but I have yet to test this)

[mauricioborges]

@jderrett, maybe I'm being a bit cranky, sorry: I created PR #77 just to allow me creating a stream without metric name = None

[jderrett]

@mauricioborges no problem, but this issue doesn't actually address setting up instruments with composite streams. This is referring to querying data back as a composite. So, #77 doesn't close this issue - we'll treat it separately.