[Hawkular-dev] A convention for metrics (short) name

[Jay Shaughnessy]

No, that is not what I meant.  All I am saying is yes, I agree that we 
should have a convention for a simple name tag, but also that adding 
many tags representing the "path components" of the metrics' owning 
resource is a good idea. Prometheus' query power comes from it's ability 
to quickly slice and dice TS based on labels.  Our mode is not the same 
but there can still be a lot of power in tagQuery given robust tagging.

On 8/9/2017 9:56 AM, Joel Takvorian wrote:
> I think going toward prom's label, ie. each possible value of a label 
> IS actually a different metric, would really be a huge change for us 
> and on the other hand we would miss our current "tags as meta-data" 
> feature, that prom is lacking afaik...
>
> But maybe that was not what you meant? I know "_name" is like a 
> reserved label in prometheus but for them it has really a lot of 
> implications.
>
>
> On Wed, Aug 9, 2017 at 3:32 PM, Jay Shaughnessy <jshaughn at redhat.com 
> <mailto:jshaughn at redhat.com>> wrote:
>
>
>     I'm fairly sure the Agent already has a "name" tag or something
>     similar.  We definitely need a convention for this, if not an
>     actual requirement.  The metricName is way too tedious, our use of
>     tags should work towards Prometheus's use of labels.
>
>
>     On 8/9/2017 5:27 AM, Thomas Heute wrote:
>>     We definitely need to solve that usability issue, I definitely
>>     experienced it in Grafana.
>>
>>     For Grafana in particular, I know Prometheus driver has a "label
>>     name" that is defined in Grafana and can be templatized with
>>     metrics labels. It's purely on Grafana side and only works for
>>     Grafana.
>>
>>     Having a convention is a quick solution, do we see it used by
>>     Metrics internals or only by agents and UIs ? Does it need to
>>     support templating with other tags or do we expect the client to
>>     be smarter to tags value change ?
>>
>>     I would also suggest displayName (or display_name or else) rather
>>     than just name, I think it's clearer that it's for UI and can change.
>>
>>
>>
>>
>>     On Wed, Aug 9, 2017 at 10:53 AM, Heiko Rupp <hrupp at redhat.com
>>     <mailto:hrupp at redhat.com>> wrote:
>>
>>         On 9 Aug 2017, at 8:41, Joel Takvorian wrote:
>>
>>         > What would you say about having a convention of a special
>>         tag (let's
>>         > say "_name") that would point to a (short) intelligible
>>         name for a
>>         > metric. That convention wouldn't be mandatory in any case
>>         of course,
>>         > but the UI could check if that tag exists and use that
>>         name, instead
>>         > of the full metric id, for better display.
>>
>>         Makes sense to me.
>>         We had a displayName in RHQ.
>>         _______________________________________________
>>         hawkular-dev mailing list
>>         hawkular-dev at lists.jboss.org
>>         <mailto:hawkular-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>         <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>>
>>
>>
>>
>>     _______________________________________________
>>     hawkular-dev mailing list
>>     hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>     <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>
>
>     _______________________________________________
>     hawkular-dev mailing list
>     hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hawkular-dev
>     <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170809/058b7683/attachment.html