Support metric timestamps

[santiagordguez]

Hi,

I'm using client_ruby to create/set counter and gauge metrics but i don't see in the prometheus library an option to specify a timestamp.

Is this not possibly?

[brian-brazil]

Any such implementation is currently dependent on prometheus/prometheus#398

[NitinRanjan]

any update ?
I see prometheus/prometheus#398 is closed

[dmagliola]

Hi @srodriguezOPT. Sorry for the late response to this...
I'd like to understand this request better.

Is this a method that sets a gauge to Time.now.to_i (as suggested by the set_to_current_time method in the best practices doc )?
Or have I misunderstood the issue?

[gerhard]

We've just hit this with @carlhoerberg. We want the metrics exposed to set the timestamp, as captured in the exposition formats doc:

metric_name [
  "{" label_name "=" `"` label_value `"` { "," label_name "=" `"` label_value `"` } [ "," ] "}"
] value [ timestamp ]

Are you open to PRs?

[brian-brazil]

It doesn't make sense to add this until this client supports custom collectors, as there's no valid use cases for it with just direct instrumentation. You can use Go/Java/Python if you need this.

[gerhard]

This functionality does make sense for our use-case. Maybe we are doing it wrong. How would you recommend we do the following in Ruby?

Given an internal telemetry system, we need a proxy that translates and exposes a subset of telemetry metrics via a public HTTP API, in Prometheus exposition format. The requirement is to expose the original metric timestamp, as recorded in this internal telemetry system.

As a short-term solution, we are using the following metric: last_updated_at 1573654301

Can you think of a better approach?

[brian-brazil]

I'd recommend not using Ruby, as the client library isn't in a place to support that. You should use a different language, the influxdb/graphite/collectd exporters should provide inspiration.

[gerhard]

This looks good @carlhoerberg

[dmagliola]

@brian-brazil I'd like to understand better this concept of Custom Collectors...
The way I understand this, you'd do this by basically subclassic either Metric, and implementing a values method that does whatever it needs to do to get the values that you want to report, correct?

Am I missing something? I feel like I don't fully understand this conversation, and the "we need Custom Collectors" comment comes up a lot...

[brian-brazil]

In theory, however it looks like this client library currently very tightly binds exposition to direct instrumentation (not an uncommon thing) and thus custom collectors aren't possible currently.

[dmagliola]

Could you expand a little bit on what that means, please?

[brian-brazil]

This client library only supports the metric types that it comes with, not generic collectors that can return multiple different types of metric which you need to write an exporter.