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

Allow unit conversion of numeric fields #172

Closed
tomwhoiscontrary opened this issue Jun 18, 2013 · 2 comments · May be fixed by enterstudio/kibana#83
Closed

Allow unit conversion of numeric fields #172

tomwhoiscontrary opened this issue Jun 18, 2013 · 2 comments · May be fixed by enterstudio/kibana#83

Comments

@tomwhoiscontrary
Copy link

As a Kibana user, i would like to be able to apply unit conversions to fields displayed in the UI (for example, to display a field counting time in milliseconds as minutes and seconds), so that i can present events in a maximally user-friendly form.

I am using Kibana for (amongst many other things!) looking at events recording execution of some scheduled jobs. These scheduled jobs are preparing data for presentation to users. Predictably, one of the fields we send is the time taken to execute the job. There are then further numeric fields containing time values, such as the time elapsed since the previous execution, the delay between scheduled and actual execution time, etc.

We measure these times in milliseconds, because computer. The fields are just integers.

I have realised that it would be really useful to expose these events to our client managers, so they can help users determine if their data is up to date, whether there have been any irregularities, and so on. I do this via a Kibana query i prepare for them.

Client managers don't really like milliseconds. It would be far more useful for them if i could put the time fields in minutes.

@cdeszaq
Copy link

cdeszaq commented Jun 20, 2013

👍 I think this is a good idea to do at the Kibana / Dashboard Spec level, rather than requiring it be done at lower levels in the stack (which would, of course, be the other option). The reason I think it makes sense to do in Kibana is because Kibana is the presentation of the data, which can be less precise than the raw data.

It's a tradeoff, of course, between storing more versions of the same data or calculating it on the fly as needed, so it would be great if both were easily supported (the former already is).

@spalger
Copy link
Contributor

spalger commented Oct 6, 2014

Field formatting is certainly something we want to bring to Kibana 4. Please follow #1543 for status on this feature.

@spalger spalger closed this as completed Oct 6, 2014
spalger pushed a commit to spalger/kibana that referenced this issue Mar 3, 2016
- Closes elastic#173 - Adding significant_terms to KB
- Closes elastic#172 - Adding percentiles to KB
- Closes elastic#171 - Adding cardinality agg to KB
- Closes elastic#176 - Removing custom_score and custom_boost_factor from query for 1.0
- Closes elastic#178 - Add script support to value_count agg
- Closes elastic#180 and Closes elastic#179 - Adding _cat/plugins and _cat/segments endpoints
- Closes elastic#191
harper-carroll pushed a commit to harper-carroll/kibana that referenced this issue Jul 11, 2016
w33ble added a commit to w33ble/kibana that referenced this issue Sep 13, 2018
* fix: globally set the confirm modal font color

* chore: move getId into its own module

* feat: add page duplication

action, reducer, and the UI controls

* fix: middleware to update elements

when duplicating a page, all the elements on that page need to be loaded

* feat: add confirmation to page delete

* chore: bump react dependencies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants