OpenMetrics and OpenCensus
tsloughter opened this issue · 8 comments
It isn't clear what the scope of this project is, so this issue may go beyond the scope but wanted to put a few things out there.
First question is just around if this will be based on existing standards and specs. While https://openmetrics.io/ is about the representation of metrics, and that may be out of scope of this project?, ensuring consistency with what is able to be tracked in the library with what standards like this can represent is important.
OpenCensus will be compatible with OpenMetrics but could be useful for what and how metrics are handled: https://opencensus.io/stats/
Specs related to stats in OpenCensus can be found here https://github.com/census-instrumentation/opencensus-specs/tree/master/stats. One that is definitely in scope of this library is parts of https://github.com/census-instrumentation/opencensus-specs/blob/master/stats/Record.md which talks about units, tags, description, etc.
And has a proto https://github.com/census-instrumentation/opencensus-proto/blob/master/src/opencensus/proto/metrics/v1/metrics.proto meant to illustrate the data that must be tracked by a library, partly explains here https://github.com/census-instrumentation/opencensus-specs/blob/master/metrics/Metrics.md
Second point is, if this library is meant to implement counters and aggregation we should be able to join forces. As in opencensus-erlang could use telemetry_metrics for this functionality. I'll have to pull @deadtrickster in on this to get his thoughts and see if he is on board, but I would think we could use https://github.com/deadtrickster/counters.erl (the library currently used by opencensus-erlang) as a starting point.
Hi @tsloughter! I was personally not familiar with OpenMetrics, so we will take a look at it. To answer your question more directly though, this library is not about collecting metrics, it is just about defining what you want to collect. Then different implementations will receive the metrics from this library as a specification and do what is necessary to collect them.
To further clarify, this lib tells us which measurements we want to aggregate and under which settings. It is similar to views in OpenCensus: https://opencensus.io/stats/view/. How does it relate to OpenMetrics? If OpenMetrics is specifically about how this data is transmitted, then this library absolutely does not care about it. :)
Ah, ok, yes definitely sounds like this is to be like opencensus views. So would definitely suggest taking https://github.com/census-instrumentation/opencensus-specs/blob/master/stats/DataAggregation.md#view into account.
And yea, OpenMetrics is the transmitted format, still likely useful to keep in mind since whatever telemetry_metrics defines for the application to aggregate would need to have the data necessary for input into whatever then serializes and exports as openmetrics data.
@tsloughter This library (if you haven't noticed yet 😄 ) is really heavily based on OpenCensus concepts. We support the same aggregations (here metric types) and also breaking them down by tags.
so why should I use it instead of Opencensus? I noticed similarities, so the question.
@deadtrickster they don t conflict in any way. You still need to use open_census or prometheus or statds or whatever with this library. Think this library is about extracting OpenCensus' views to a separate repository so we could use it to describe aggregrations in an agnostic way. Other libraries, such as telemetry_statds will then convert the definitions in here to something that can actually push to statds. In the same way tleemtry_open_census could use this to push to open census and so on. The code in this lib is almost final, so you can check it out for reference.
@deadtrickster also this library assumes that reporters collect data viaTelemetry events, and not direct API calls. Now that Ecto publishes them, and Phoenix probably will in the future, it will be straightforward to build a set of metrics related to DB queries or HTTP requests.
@tsloughter This library (if you haven't noticed yet smile ) is really heavily based on OpenCensus concepts. We support the same aggregations (here metric types) and also breaking them down by tags.
Ah, very nice :).
And the rest makes sense, smaller scope than I was thinking when opening this :), I'll close this issue.