Support for tagged measurements

[chancefeick]

Add support for /v1/measurements endpoint to retrieve and submit tagged measurements.

Tagged measurements contain tags, which are a set of name=value tag pairs that describe the particular data stream. Tags are equivalent to source in the previous data model.

Retrieving

Retrieving tagged metric series:

#get_series

query = {
  resolution: 1,
  duration: 3600,
  group_by: "environment",
  group_by_function: "sum",
  tags_search: "environment=prod*"
}
Librato::Metrics.get_series :exceptions, query
# => [{"tags"=>{"environment"=>"production"}, "measurements"=>[{"time"=>1472241220, "value"=>10.0}]}]

Submitting

There are multiple ways to submit and manage tags for measurements on Queue and Aggregator. Here are a few examples:

Initialization

queue = Librato::Metrics::Queue.new(tags: { region: “us-east-1” })
queue.add test: 1
queue.submit

Arguments

aggregator = Librato::Metrics::Aggregator.new
aggregator.add test: { value: 1, tags: { hostname: “metrics-web-stg-1” } }
aggregator.submit

README and code documentation will be updated in a separate PR.

[nextmat]

client = Librato::Metrics::Client.new(tags: { region: "us-east-1" })
queue = Librato::Metrics::Queue.new(client: client)
queue.add_tags hostname: "metrics-web-stg-2"

Two questions about this:

• If I'm reading this correctly you are thinking to support cascading tag sets including at the client level?
• is #add_tags equivalent to adding tags in the constructor of Queue just for later use?

[chancefeick]

you are thinking to support cascading tag sets including at the client level?

Yes, tag management (add, remove) is currently handled by the Client.

is #add_tags equivalent to adding tags in the constructor of Queue just for later use?

#add_tags is delegated to the Queue's client instance, which would then be applied to all measurements.

After second thought, makes sense to remove tag management from Client entirely and allow Queue and Aggregator to handle it instead.

[nextmat]

After second thought, makes sense to remove tag management from Client entirely and allow Queue and Aggregator to handle it instead.

Yeah, :+1: this, I think you'll definitely run into race issues otherwise.

[chancefeick]

@nextmat addressed feedback, PTAL

[nextmat]

LGTM

[jderrett]

@chancefeick @nextmat are we going to include README changes which explain the new API (similar to the PR description) as well as documenting the fact that this will continue to work with /v1/metrics and is not making the library "tags only" etc?

[chancefeick]

@jderrett it was suggested offline to update README after GA to avoid any confusion. will update in a separate PR that custom success can point beta users to

[chancefeick]

Going to release as 2.1.0.beta.