Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Annotations on graphs (aka drawAsInfinite) #343

Open
yarpowsky opened this issue Nov 20, 2014 · 5 comments
Open

Annotations on graphs (aka drawAsInfinite) #343

yarpowsky opened this issue Nov 20, 2014 · 5 comments

Comments

@yarpowsky
Copy link

Hi,
what do you think about adding annotations? I think that would be great way to display events like deployments, new version, new campaign and see the effect on graphs. Something similiar to this: http://grafana.org/docs/features/annotations/ , even based on metric ( straigh line if > 0). Is it possible right now?

best regards,

@yarpowsky
Copy link
Author

or probably support for graphite events would be enough

@aalpern
Copy link
Member

aalpern commented Nov 20, 2014

Yes, support for rendering metrics as vertical lines (I.e like 'drawAsInfinite', but working for interactive renderers too) is coming.

@aalpern
Copy link
Member

aalpern commented Nov 20, 2014

Although because its an option that applies per data-series, rather than per-graph, it may take a while, as support for that needs a bunch of work.

@aalpern
Copy link
Member

aalpern commented Feb 28, 2015

Adding in some notes from my local repo:

drawAsInfinite

Graphite's drawAsInfinite function can be used for plotting events - any value > 0 draws as a vertical line in a PNG. Unfortunately, it's just a rendering instruction, and is completely lost in the data series returned if you ask for JSON data.

All of tessera's chart options so far apply to the entire chart. drawAsInfinite is specific to a particular data series - unfortunately, we don't know what the data series are until we evaluate the query.

Evaluation/item options

Before being able to set per-series options, we have to evaluate the data query. Fortunately, this happens every time you edit a query. The edit mode will have to look at the resulting data series and keep a { series-name -> options } map map in the dashboard item.

I believe this is basically the same approach Grafana takes.

So - dashboard items need an additional data_series_options member, in addition to the existing options. data_series_options is a dictionary, where the keys are the name of the data series, and the value is another dictionary with the per-series options to apply.

Open question: Should this be set per-dashboard item, or per-query? Leaning towards supporting both, merging the options (with dashboard-item per-series options overriding those from the query). Having it on the query will be useful when we implement reusable queries.

Editing

  • So. Build a single-page detailed query editor? Leave in-line simple query editor in place, add an "Advanced..." menu item, and move to a full-page editor that has more complex editing options plus a graph preview?
  • Or do the same for charts? Shoe-horning it into the existing property sheet UI will be awkward and difficult.

Renderer Support

Unfortunately, there's no way to handle setting that option consistently for static PNG rendering as well as for JSON-based renderers. For the former, you have to set the option as part of the query, on the originating graphite expression. For the latter, you have to set it on the resulting data series name, which may or may not have any obvious relation.

More reason to set interactive+flot as the default.

@aalpern aalpern changed the title Annotations on graphs Annotations on graphs (aka drawAsInfinite) Feb 28, 2015
@filippog
Copy link

hi @aalpern !
what do you think about annotations coming from an external source instead? e.g. an annotation API. For static rendering this could be a problem though, a possible hack would be to still load the PNG rendering and append target=alias(drawasinfinite(<datapoints>), <name>) for each name/value annotation.

Such annotation API can look like the approach PromDash takes and doesn't require parsing the graphite query, possibly with a sample implementation provided by tessera.
re: per-dashboard vs per-query, IME events are a show/hide type of thing so per-dashboard seems less confusing (following the example above you could say 'show me all annotations matching these tags')

thanks,
filippo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants