Custom metric aggregation plugin

Elastic Stack Kibana
1

I want to develop a simple custom metric aggregation plugin for Kibana. Let's say a clone of the average metric aggregation.

As far as I can see, I need to

  1. Clone existing avg.js
  2. Update the aggs.metrics in agg_types/index.js with the new metric aggregation
  3. ...

Can I create a plugin for Kibana that does that?

Thanks.

2

Is there [quote="mrvincnezo, post:1, topic:70072"]
As far as I can see, I need to

  1. Clone existing avg.js
  2. Update the aggs.metrics in agg_types/index.js with the new metric aggregation
    [/quote]

I was able to implement the above and piggyback the custom metric "registration" to another custom visualization plugin I have . As a result, the custom metric was added to all existing visualizations. I want to filter it out from all default Kibana's visualizations via the visualizations' aggFilter property.

Is there a hook (via custom plugin) that I can plug to that occurs after all Kibana's visualization were loaded? I want to iterate over all existing visualization and update the aggFilter to exclude the custom metric.

3

I need to update the aggs.metrics... Can I create a plugin for Kibana that does that?

I believe so. Take a look at the existing metrics as a guide for creating your own. Usually there is a registry of some kind that we use to allow plugins to register new things, but I don't see that for metrics currently. Maybe I'm missing it. However, src/ui/public/agg_types/index.js is where they are all built, and it just exports an IndexedArray, which extends the Array prototype, so you should be able to push a new metric definition onto it. It's pretty hacky, but it should work...

Sounds like you got it working though, did you do something different?

I want to iterate over all existing visualization and update the aggFilter to exclude the custom metric.

Well, you should be able to access all of the visualizations through the vis_types registry, which I believe will allow you to mutate the records. See src/ui/public/vislib_vis_type/vislib_vis_type.js for how those objects work. This, again, is kind of hacky, but I believe it will work.

1 Like
4

That's exactly what I did.

That's what I want. The question is when.

I am pushing my custom metric to the IndexedArray in the export default function of my custom visualization (the one that needs the custom metric). This is too soon and the vis_types registry may not have been fully populated yet.

5

Ah, good point, the timing is going to matter.

I don't see any sort of event you can listen for, or properties you can check. You could do it via a hack, since that is loaded on page load, and you can watch for things to start rendering or something.

This is really starting to turn into an ugly collection of hacky patches though... some of these extension points should definitely be added to Kibana properly. Can I ask why you want to make the metric unavailable on the other visualizations?

6

My custom visualization is a CDF (Cumulative Distribution Function) line chart that is based on the stock line chart. The main difference between my chart and the line chart is the responseConverter in which all the magic happens. My custom CDF vis is restricted to the 'Count' metric only. The drawback with 'Count' is the default 'Count' label and the 'number' formatting.

I wanted to duplicate the 'Count' metric and override the default label and the formatting (make it use 'percent' formatting instead of 'number').

This metric is very specific and has no meaning to other visualizations.

7

Gotcha, that makes sense. That's definitely a case we hadn't taken into account, a custom metric that shouldn't be available on many of the visualization types. Unfortunately, since the aggFilter can be both inclusive or exclusive, that becomes kind of tricky to add too. Maybe it's something we should allow the metric itself to specify, just a filter by name would probably do it.

8

Sounds good.

Having more extension points you mentioned earlier would be great also.

Formalizing custom mertic addition mechanism (similar to existing visTypes and fieldFormatters) could be just wonderful.

9

I've opened up https://github.com/elastic/kibana/issues/9669 to request and track this issue.

If there's anything I've gotten wrong or missed there, feel free to add to it.

1 Like
10

Thanks!

11

@Joe_Fleming Eventually I ended up adding a delayed (1 second delay) vis_types registry update in the default function of my custom plugin. It is hacky but it works well.

Since I have only a single metric right now, I don't mind doing the metric registration and the vis_types registry update in the default function of my custom plugin. But I am expecting more metrics to come.

I wonder if there is a better place in existing Kibana 5.x builds for the custom metric registration and vis_types registry update (for the aggFilter update). Maybe a Kibana's plugin that is not 'visTypes' and not 'fieldFormats'...

1 Like
12

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.