Support discrete events (e.g. annotations) #5
Conversation
When metric type is "docs" (e.g. "raw documents" from Elasticsearch), treat each document as an event, with a given start and end time. Currently hardcoded to use the following fields in the document: begin - start time end - end time desc - name
This will override the "from" range when querying the datasource, causing it to return data from the epoch. This is needed in case an event started before the graph start.
* Show legend entries for each metric (instead of just the first). * Optionally show metric names next to legend. * Use event name for value. * Fix dates in tooltips for events.
|
Options editor:
Colors editor:
Tooltips & Legend (timeseries data):
|
|
nice -- i'll try to look more closely tomorrow. If you make a PR for just:
I will apply that quickly. Whats the story with "Query all data"? Why not just keep the time range out of the metric query? |
This can be used to help the timeline line up with other graphs on the dashboard, to account for axis labels, legends, etc.
|
Opened #6 with the tooltip fix and the config options. The issue with using the panel time range is I want to also show "ongoing" events, that have one or both of start and end dates outside the displayed range. The data source is (most likely) indexed on the start time, so anything earlier wouldn't get included. It's a bit of a hack, but I haven't come up with a better option. |
|
Ahh, i see similar to this issue: I have not used elastic, but in lucene/solr, you can index your dates using a DateRangeField and this solves the issue |
|
Elasticsearch doesn't have a date range field, but even if it did the problem is Grafana includes a range filter against the configured time field in every query. |
|
@retzkek, i'm back from vacation and can take a look... can you get things to merge again? |
|
Sorry @ryantxu, I've had to focus on some other things. I'm still sort of mulling over whether to stick with the "all data" option or go with an elasticearch-specific query. I'm worried what happens if someone has a lot of events... we only have a couple hundred, growing by a couple per week, so it works for our needs, but not a great general solution. |
|
no worries -- for sure i would look into an indexing strategy that lets you do this on the server. The 'all data' option is a bit funky, and I don't get why you can't just do that by removing the time query from the Metric query |
The Elasticsearch datasource always includes a range filter in the query: It also has a fixed size limit of 500: So current solution won't work anyways. |
|
Check grafana/grafana#8098 looks like the concept of a 'region' is coming to annotations (time & timeTo) |
|
Oh neat, thanks for the heads up. That might actually solve the problem I originally set out to solve with this... Although having a separate panel still has its uses. |
|
Thats a really cool feature! Even if grafana has it´s own annotations. regards |
|
@retzkek are you going to merge this with master? or should we close it and open a new issue? |
|
@ryantxu If you're interested in merging I'll take a pass at resolving conflicts. I don't want to spend too much time though due to the issues mentioned above (although we are using it in production...). |
|
Lets see what happens with the range (event) annotations, and then go from there. I'll close this now and we can pick up a new issue if that makes sense |
The primary changes in this PR are to add support for discrete events coming from a datasource like Elasticsearch (I think that's the only one that supports the "docs" type), where each event has a title, start time, and end time. This example shows the same data source being used for annotations and events:
Other changes included (can be cherry-picked or split into separate PRs if desired):
Some of this probably could use some tweaks, but I figured it was good enough to start a dialog.