[Hawkular-dev] Fwd: [hawkular-dev] Grafana querying usability

Wed Jan 18 05:07:39 EST 2017

Ok, my idea was rather to show the metric text field and tags fields side
by side. If tags can be used to refine the list of suggested metrics (and I
think it would really be an important feature to avoid navigating in a flat
list of hundreds (thousands?) of metrics) - then we must keep them
separated.

Heiko also suggested to allow both freestyle and guided mode for tag
queries. Just checked the influx ds, I agree we could do something similar.
The query builder can be inspired from influx' one.

On Wed, Jan 18, 2017 at 10:53 AM, Thomas Segismont <tsegismo at redhat.com>
wrote:

> No, I really meant 1/. With a single text field mixing tag filters and
> names. Or did I misunderstood the idea?
>
> It might be worth taking a look at InfluxDB's datasource code. IIRC, they
> let you switch between guided (with many specific text fields) and
> freestyle (query language) mode.
>
> 2017-01-18 10:29 GMT+01:00 Joel Takvorian <jtakvori at redhat.com>:
>
>> Thomas, I think you mean the "2b" proposal? (with a simple text field to
>> type custom query in). I can't see how to provide auto-completion with
>> that. I think if we go this way, we loose auto-completion.
>>
>> On Wed, Jan 18, 2017 at 10:25 AM, Thomas Segismont <tsegismo at redhat.com>
>> wrote:
>>
>>> 1/ sounds best to me, as it would give users the power of a query
>>> language. But auto-completion could be quite a challenge there, couldn't it?
>>>
>>> 2017-01-18 9:54 GMT+01:00 Joel Takvorian <jtakvori at redhat.com>:
>>>
>>>> Hi everybody,
>>>>
>>>> I would like to get some opinions on the hawkular-grafana-datasource
>>>> querying usability, especially if you had the opportunity to create
>>>> dashboards recently and had to juggle with querying by metric name and by
>>>> tag.
>>>>
>>>> Currently the panel displays different elements depending on you're
>>>> querying by metric name (see picture: https://raw.githubusercontent.
>>>> com/hawkular/hawkular-grafana-datasource/master/docs/images/
>>>> search-by-name.png )
>>>>
>>>> Querying by name is quite straightforward, but it can be cumbersome
>>>> when there's a lot of available metrics and you have to scroll among
>>>> suggestions to find the one you want.
>>>> 
>>>>
>>>> Or by tag  (see picture: https://raw.githubusercontent.
>>>> com/hawkular/hawkular-grafana-datasource/master/docs/images/
>>>> search-by-tag.png )
>>>>
>>>> 
>>>> The "query by tag" interface is not very intuitive IMO (you define a
>>>> list of key-value pairs), moreover to this date there is no auto-completion
>>>> on tag name.
>>>>
>>>> There's been some features in metrics recently that, I think, can
>>>> enable a better UI on Grafana side. First, there is Micke's feature "Allow
>>>> fetching of available tagNames" [1] that enables suggestions
>>>> (auto-completion) on tag name. And most importantly there's the new "tag
>>>> query language" that could (should) have its place in Grafana.
>>>>
>>>>
>>>> So I would have several suggestions for improving the UI and queries.
>>>>
>>>> *1*: First of all I think we can remove the "Search by name" / "Search
>>>> by tag" selector, and allow searching by name AND by tag at the same time:
>>>> providing tags would refine the available metrics in the metrics text field
>>>> suggestions (auto-completion). If this text field is left blank, all
>>>> available metrics are displayed.
>>>>
>>>> Then, there's several scenarios to take advantage of the new hawkular
>>>> metrics features:
>>>>
>>>> *2a*: keep current key/value pairs system, but improve with adding
>>>> suggestion on tag names.
>>>>
>>>> *2b*: replace key-value pairs with the new tags query, via a simple
>>>> text field:
>>>>
>>>>
>>>> We may or may not include syntax validation here. We must provide some
>>>> documentation on that.
>>>>
>>>> *2c*: replace key-value pairs with the new tags query, with a
>>>> dedicated "builder" UI:
>>>>
>>>> Each of these boxes in tags query would have a contextual
>>>> auto-completion feature:
>>>> - suggestions on 1: list of tag keys
>>>> - suggestions on 2: list of operators (=, !=, IN, NOT IN)
>>>> - suggestions on 3: list of tag values for the given key (with some
>>>> slights differences on brackets if it's the first element or not; closing
>>>> bracket as a choice if it's not the first element)
>>>> - suggestions on 4: operators AND / OR
>>>> 
>>>>
>>>> The 2b option is obviously simpler, very fast to implement. It has the
>>>> downside of loosing all auto-completion capabilities, even compared to the
>>>> current version.
>>>>
>>>> 2c looks nicer and more intuitive in its usage, people won't have to
>>>> read the doc to use it. However there's several downsides:
>>>>   - Need to implement the logic => need for time for development, adds
>>>> complexity to our grafana plugin.
>>>>   - Introduces a dependency to the language on server side. When the
>>>> language evolves, we'll have to maintain this as well.
>>>>
>>>>
>>>> Ideas & thoughts? I think it's preferable to proceed in several steps.
>>>> In a first time I could implement *1* and *2a*, and later (and maybe
>>>> giving some time to the language to be "stabilized") going with *2c*.
>>>>
>>>> [1] https://issues.jboss.org/browse/HWKMETRICS-532
>>>>
>>>> Thanks
>>>> Joel
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> hawkular-dev mailing list
>>>> hawkular-dev at lists.jboss.org
>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> 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/20170118/462eef89/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-grafana-search-with-builder.png
Type: image/png
Size: 39806 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170118/462eef89/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-grafana-search.png
Type: image/png
Size: 38020 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170118/462eef89/attachment-0003.png 