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(a)redhat.com&gt;: > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

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(a)redhat.com&gt;: > 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(a)redhat.com&gt; > 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(a)redhat.com&gt;: >> >>> 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev