All heroic query "features" can the turned on or off at query time(use a - to turn off a default on feature):

"features": ["com.spotify.heroic.distributed_aggregations","-com.spotify.heroic.shift_range"]

We should support enabling/disabling these in grafana (perhaps under some advances-options section, defaulted to the state heroic has them in by default?)

Using strings as events is deprecated and will be removed in future versions of Grafana.

When selecting the $key filter, the tags dropdown does not populate results.

in grafana 6 i use heatmap panel with this query:

average by f
from points
where
$key = "orfees"
and st = "i"
and host = "rsdb"

everithing seems good except for Y: the y axes is not sorted by f (average by f)

Datasource is missing support for regex filtering in Heroic:
https://spotify.github.io/heroic/docs/query_language

• Make the text box bigger so you can see the whole query while you type
• Preserve the current complex filter so you can edit it when you click on the text box. Currently it clears the whole box to provide suggestions, but there are none.

Perhaps we can make this a freeform text box to improve both of the above.

When adding an alert on a percentage threshold, the value needs to be entered divided by 100 since the input isn't read as a percent, which can be confusing to end users. Some may expect the value should be entered as the % value since the panel is already "using % units".

For example, entering 0.1 is 10%

this will give an indication to the user if they are hitting a quota.

Similar to #58 it would be helpful when building a query if you can drag the aggregations around to change the order.

With a standard query, the JSONified version is stored in Grafana and can be returned from the Grafana API when fetching a dashboard under .dashboard.panels[].targets[].query. If the panel uses a complex filter, however, this field will be empty and the calling application will need to fully construct the query from the various parts - filters, complex filter, aggregation, time range, features, and dashboard variables.

This makes it difficult to use the Grafana API when a complex filter was used. We should construct the full query in the datasource and store it the same way that simple queries are stored.

when I upgrade to grafana 7 I get this error:
Unrecognized token 'queries': was expecting ('true', 'false' or 'null')

When trying to create a variable from a query, the UI throws:

Templating Template variables could not be initialized: this.metricFindQuery(...).then is not a function

and the query builder is just a simple text box, not the normal Heroic query builder.

Certain tags like what are not being showing up in the suggestions. It would be good if we could artificially boost the more common tags if they exist.

With alien we always show the below suggestions when starting from nothing.

This may be an issue with Grafana itself (had a hard time confirming in their docs) but you currently cannot use a variable in a complex filter. I tried the various formats suggested here: https://grafana.com/docs/grafana/latest/variables/syntax/

Validate and improve the README.

DOD: Assignee has sat with someone who hasn't worked with the new Grafana plugin before and watched them go through the process of setting it up for local development to catch any gotchas and update the README based on them. Also, README has production installation instructions.

The feature already supported by Heroic codebase but never being exposed or documented.

• If the resolution is larger than the alert query range show an error. Not sure how this will work when resolution could be a variable.
• If the alert query range is smaller than the duration (for) show an error.

grunt-typescript is a dead project, it hasn't been updated in 4 years. As is tradition there are other JS projects that do the same thing. We should move to one of them - grunt-ts looks pretty well mantained.

When building a query it's useful to know how many unique values of a given tag there are.

Spotify is slowly moving over to Circl CI as the primary open source build tool. We should see if it makes sense for this project, and if so migrate.

Fully test features/integrations and scope out the work needed to be done to support version 7.0.0 - 7.0.3.

DOD: If possible, when adding a dashboard variable by query (i.e., select tags for this timeseries), we support some portion of the query builder we use for dashboards and annotations so users do not have to input raw JSON filters.

For a nicer UX perhaps we can have a fixed list of resource identifiers or get the list of RI's returned by the query to populate the dropdown.

When a query is made to heroic, it should add context to the request around what dashboard and graph is sending the query.

Alien does something like...

As part of the query payload clientContext can be added to achieve this. Heroic accepts arbitrary json fields.

Adding this to the plugin makes it easier to discovery where potential "bad" queries are being made, as clientContext gets added to the heroic query logs.

Currently the ad-hoc filter variable doesn't support heroic's complex filter syntax.

Users of this plugin would like to set filter for things like role = foo or role = bar.

We need to investigate more into how the ad-hoc filter variable works and potentially work with Grafana in extending this (or maybe its poorly documented and actually implemented). Or use a different type of variable (custom variable?) and use that in our plugin.

Grafana refreshes when tags are added/changed.

DoD: Query should only refresh when reordering an aggregation or manually refreshing.

the readme should have documentation on how to make a release and upload to Grafana.

-- plugin datasource public repo should have this info

might need to make a grafana.com account to make changes?

Currently when you set an aggregation like max for-each you cannot change max to something else. This requires you to delete the aggregation and then add it again. If you have many aggregations you have to delete them all since you cannot click and drag the aggregations around.

Right now the key is not displayed with the other tags which can lead to confusion where metrics are coming from.

This just came up with someone wondering where the heartbeat metric was coming from.

DOD: display the key along with the other tags.

Currently the Heroic Datasource does not support "Explore" in grafana. Should be supported and functional for Grafana 7.x

Currently when a global filter is used, it is appended to the query filter instead of replacing the value if one exists. This causes the query not to match any timeseries.

Aggregation limits (and possibly errors) are ignored when navigating to a panel from a dashboard. The graph will show No data points without any error message, which is very confusing.

Changing the resolution or refreshing the dashboard will cause the error to appear. Navigating directly to the panel by the URL will also make the error message appear.

In Grafana 6.6 and above, hidding a query with the Heroic datasource no longer "runs" the query. When using the metaQuery plugin, users frequently hide queries to only show the resulting series.

GoshPosh/grafana-meta-queries#80

This plugin should become the official one and replace https://grafana.com/plugins/udoprog-heroic-datasource

might be related to template treating these are strings instead of integers in filters

When building a query its hard to know what you are looking for. The query builder should show tag suggestions along with how many unique values there are for a given tag.

• Display a warning if there is a tag in a panel's query with an unreasonably high amount of values.

This happens regardless of whether any changes have been made to the dashboard.

In Firefox: This page is asking you to confirm that you want to leave - data you have entered may not be saved.

When building a complex filter often it errors out and can cause the filter not to be added correctly.

When setting $key in the query builder, all operations are available - =, !=, ^, and !^. However, setting it to anything other than = does not parse correctly.

For example, setting the builder to $key != apollo will build a JSON query of ["key", "apollo"] without wrapping it in a not filter. Other tag/value pairs work as expected, its just $key with the issue.

The query builder will obscure error warning if a query raises multiple warnings.

Similar to: grafana/grafana#9447

For server side rendered images grafana-server needs to be able to access the url you specified in data source settings.