<div dir="ltr">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?</div><div class="gmail_extra"><br><div class="gmail_quote">2017-01-18 9:54 GMT+01:00 Joel Takvorian <span dir="ltr"><<a href="mailto:jtakvori@redhat.com" target="_blank">jtakvori@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">Hi everybody,<div><br></div><div>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.</div><div><br></div><div>Currently the panel displays different elements depending on you're querying by metric name (see picture: <a href="https://raw.githubusercontent.com/hawkular/hawkular-grafana-datasource/master/docs/images/search-by-name.png" target="_blank">https://raw.githubusercontent.<wbr>com/hawkular/hawkular-grafana-<wbr>datasource/master/docs/images/<wbr>search-by-name.png</a> )</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>Or by tag (see picture: <a href="https://raw.githubusercontent.com/hawkular/hawkular-grafana-datasource/master/docs/images/search-by-tag.png" target="_blank">https://raw.githubusercontent.<wbr>com/hawkular/hawkular-grafana-<wbr>datasource/master/docs/images/<wbr>search-by-tag.png</a> )</div><div><br><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div><br></div><div>So I would have several suggestions for improving the UI and queries.</div><div><br></div><div><b>1</b>: 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.</div><div><br></div><div>Then, there's several scenarios to take advantage of the new hawkular metrics features:</div><div><br></div><div><b>2a</b>: keep current key/value pairs system, but improve with adding suggestion on tag names.</div><div><br></div><div><b>2b</b>: replace key-value pairs with the new tags query, via a simple text field:</div><div><img src="cid:ii_iy2otrcc2_159b0b23058b516d" width="544" height="149"><br></div><div><br></div><div>We may or may not include syntax validation here. We must provide some documentation on that.</div><div><br></div><div><b>2c</b>: replace key-value pairs with the new tags query, with a dedicated "builder" UI:</div><div><img src="cid:ii_iy2owamu3_159b0b3ff1738246" width="544" height="149"><br>Each of these boxes in tags query would have a contextual auto-completion feature:<br></div><div>- suggestions on 1: list of tag keys</div><div>- suggestions on 2: list of operators (=, !=, IN, NOT IN)<br></div><div>- 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)</div><div>- suggestions on 4: operators AND / OR</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>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:</div><div> - Need to implement the logic => need for time for development, adds complexity to our grafana plugin.</div><div> - Introduces a dependency to the language on server side. When the language evolves, we'll have to maintain this as well.</div><div><br></div><div><br></div><div>Ideas & thoughts? I think it's preferable to proceed in several steps. In a first time I could implement <b>1</b> and <b>2a</b>, and later (and maybe giving some time to the language to be "stabilized") going with <b>2c</b>.<br></div><div><br></div><div>[1] <a href="https://issues.jboss.org/browse/HWKMETRICS-532" target="_blank">https://issues.jboss.org/b<wbr>rowse/HWKMETRICS-532</a></div><div><br></div><div>Thanks</div><span class="HOEnZb"><font color="#888888"><span class="m_-3045647773605345933gmail-HOEnZb"><font color="#888888"><div>Joel</div><div><br></div></font></span></font></span></div>
</div><br></div>
<br>______________________________<wbr>_________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
<br></blockquote></div><br></div>