Kibana Control Visualization Missing Values

Xadiq · April 16, 2022, 10:11am

Hi All,

I am facing issue with Kibana Control Visualization. I have field which shows month/year. The index has data from 2014 to 2021 but still the drop down is not showing some values like 12/2021. However if apply the same filet in discover tab - it produces hits.

Can you please assist where I am going wrong.

Thanks in Advance.

Marius_Dragomir · April 21, 2022, 12:13am

Hello,
There are a few common issues that will make that happen and you can find them in the Kibana repo:

github.com/elastic/kibana

Incomplete results when using a Controls Visualization

opened 10:41AM - 23 Apr 20 UTC

rfer

Feature:Input Control enhancement Team:Presentation

**Kibana version**: 7.0.0 **Elasticsearch version**: 7.0.0 **Server OS ver…sion**: CentOS **Browser version**: Chrome 80.0.3987.163 **Browser OS version**: MacOS **Original install method (e.g. download page, yum, from source, etc.)**: download page **Description of the problem including expected versus actual behavior**: The query produced by a Controls visualization adds, by default, two parameters: `rest_total_hits_as_int=true` and `terminate_after` This combination of parameters results in the query returning different numbers of results. The same query, with `terminate_after` *but without* `rest_total_hits_as_int=true` returns all the expected results. I'm also getting the expected number of results when the query has `rest_total_hits_as_int=true` *but doesn't have* `terminate_after`. It seems that the combination of these two options causes the query to terminate earlier: Results with `rest_total_hits_as_int=true` *and* `terminate_after`: ``` { "took" : 9, "timed_out" : false, "terminated_early" : true, "_shards" : { "total" : 22, "successful" : 22, "skipped" : 0, "failed" : 0 }, ``` Notice the `terminated_early: true` on the result above. Compared to the results *without* `rest_total_hits_as_int=true` but with `terminate_after`: ``` { "took" : 4, "timed_out" : false, "_shards" : { "total" : 22, "successful" : 22, "skipped" : 0, "failed" : 0 }, ``` **Steps to reproduce**: 1. Create a Controls visualization 2. Check the query the is issued by Kibana 3. Try the same query with the mentioned above combination of parameters. **Provide logs and/or server output (if relevant)**: I should note that there's nothing relevant on the logs.

github.com/elastic/kibana

Add configs for terminate_after

elastic:master ← flash1293:feature/terminate_after

opened 12:07PM - 31 May 19 UTC

flash1293

+166 -60

## Summary This PR adds yml settings for the terminate_after and timeout para…meters of requests for autocompletion (dropdowns in input control visualizations and suggestions in KQL bar). <img width="379" alt="Screenshot 2019-05-31 at 13 54 04" src="https://user-images.githubusercontent.com/1508364/58704288-c2a8cf00-83ab-11e9-8ed4-1dc88b481db0.png"> Related: https://github.com/elastic/kibana/issues/17388 If a request actually terminates early, a warning symbol is shown in the input control visualization: <img width="1335" alt="Screenshot 2019-05-31 at 13 56 27" src="https://user-images.githubusercontent.com/1508364/58704335-e9670580-83ab-11e9-90ad-3aba85880183.png"> ### Unclear points * _Location / name of the setting variables_: Currently, the settings are in the `kibana` namespace, because they are consumed in multiple plugins (currently kibana itself and input_control_vis). The kibana plugin however is split up into multiple self-containing components and it's not clear where this setting should live * _Wording of the warning message_: Is copied from an old take on the issue, but might not be ideal * _Warnings for suggestion list_: If the list of suggestions terminates early, there is no visual indication. The current API of suggestions is not easily extensible (just a simple array of string, no room to carry meta information about the request itself). Is this important? If yes, a separate issue should be created for that. * _Timeout setting_: It seems like at least under some circumstances, the timeout setting of a request isn't respected but overwritten by the global request timeout of per default 30 seconds. Is a separate timeout for autocomplete requests even necessary? ### Checklist Use ~~strikethroughs~~ to remove checklist items you don't feel are applicable to this PR. - [ ] This was checked for cross-browser compatibility, [including a check against IE11](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#cross-browser-compatibility) - [ ] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/master/packages/kbn-i18n/README.md) - [ ] [Documentation](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#writing-documentation) was added for features that require explanation or tutorials - [ ] [Unit or functional tests](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#cross-browser-compatibility) were updated or added to match the most common scenarios - [ ] This was checked for [keyboard-only and screenreader accessibility](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Accessibility_testing_checklist) ### For maintainers - [ ] This was checked for breaking API changes and was [labeled appropriately](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#release-notes-process) - [ ] This includes a feature addition or change that requires a release note and was [labeled appropriately](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#release-notes-process)

system · May 19, 2022, 12:14am

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