Workaround for non-UTC indexes #1163
Conversation
Indexes of elasticsearch are supposed to be in UTC, but at least, rsyslog can only use local time to generate index name. Kibana first finds indexes to query based on UTC time. So for east timezone, there are a few hours, kibana will miss new created index(es) and no new data is displayed during these hours. This patch workarounds this issue. In most cases, there should be no indexes for future time, so this just works without any harm. Even if indexes for future time do exist, the real search query will limit time range before now.
|
This seems like a reasonable workaround given the minimal overhead. Can you make sure you've signed the CLA? |
|
Yes, I have signed CLA. |
… regularly grabbing empty data sets causes some visual oddities
|
I see. When search in old time range, the +12 adjustment will lead to extra existed indexes being hit, that will introduce noticeable overhead. But I am not sure what "grabbing empty data sets causes some visual oddities" means, can you elaborate on this more? I will rework the patch. Sorry for my unthoughtfulness. |
|
On the table panel, the entire table will go blank since the first reply from the server contains no hits. The table will only be populated by the 2nd request. On dashboards with a lot of panels, this ends up being a lot of extra http calls. I'm not entirely sure of a good way around that. It probably wouldn't happen often in production since the "in the future" index wouldn't usually exist, but if it does, it causes issues. |
|
The crux of the problem is that we don't know what timezone the index name generated in. If we know it, we only offset with proper value (e.g minus for western timezone). A hack is naming index like [prefix_Z+0000-]YYYY.MM.DD, which provides timezhone information. Kibana can respect this convention. How about this idea? |
|
Ok, I did simple test. Index name must be in lower case, so it's [prefix_z+0000-]YYYY.MM.DD. In rsyslogd side, '+' may be replaced with '%2b', I am not sure A.T.M. |
…to_v3.1.0 * commit 'c19105cf3f2dbefe7aa41caebca5bcf40efff3b7': (51 commits) Fixed spurious version too low message when elasticsearch is unreachable Update module.js fixed typo preventing filters from being applied to topN queries Removing console.log message Remove apply, update version to 3.1.0 Add panel height params back in to fix column panel sizing. Closes elastic#1146 Closes elastic#1206. Fix share url in firefox Fix box-sizing in firefox, fix spinner pushing down panel-extra-container, closes elastic#1218 Fix column panel after 430d7fa. Add jsonpath to license file Reverting elastic#1163, the overhead is larger than I anticipated and regularly grabbing empty data sets causes some visual oddities Add margin to bottom of error Add ignore_unmapped to sorts, closes elastic#1153 Simplify docs, add tooltip, clean up editor Use a field filter instead of terms filter so that analysis is done on the value. Closes elastic#1166. Closes elastic#1142 Send render whenever window size changes or a panel is resized Simplify kibanaPanel directive, fix css that stopped overflow:scroll from working on the table panel Fix for possibility of partial spans remove commented out less Add drag to resize panel widths. Closes elastic#329 ...
Indexes of elasticsearch are supposed to be in UTC, but at least, rsyslog
can only use local time to generate index name.
Kibana first finds indexes to query based on UTC time. So for east timezone,
there are a few hours, kibana will miss new created index(es) and no new data
is displayed during these hours.
This patch workarounds this issue. In most cases, there should be no indexes
for future time, so this just works without any harm. Even if indexes for
future time do exist, the real search query will limit time range before now.