Description
Summary
This is a proposal to add the UI capability to temporarily show log entries that have been hidden by the filter.
Rationale
It is a common workflow during investigations to narrow down the set of log entries by a particular criterion (such as log level or presence of a term in the message) and, once a log entry of interest has been found, to inspect other log entries in close temporal proximity. While the first part of that workflow is easily supported by the query bar in the Logs UI, the second part is more difficult.
This proposal aims to improve that second part of the workflow by displaying the presence of filtered-out log entries in a very condensed form with the option of incrementally expanding these filtered-out log entries for the purpose of investigating the context.
Showing the presence of filtered-out log entries
To mark the presence of filtered-out log entries, a small sign could be placed at the left edge of the stream. In order to not take up too much space, that sign could be overlayed on the edge between two adjacent log entries without influencing the vertical flow. An interaction like clicking on the marker could trigger expansion into a segment of fully rendered log entries (see below).
Showing the filtered-out log entries
When interacted with, the markers could expand into a segment that shows (some of) the intermediate log entries that were hidden by the filter. That segment could be marked in some way (e.g. a different background) to signal the fact that the entries therein don't match the filter criteria.
Since there could be an arbitrarily large number of log entries in that segment, they need to be loaded incrementally. At which edge of the segment interval the log entries are loaded (old, new, both) could depend on the scrolling position or on the specific user interaction.
The segment of filtered-out log entries could be collapsible again to continue the workflow on the filtered set of log entries.
Querying for filtered-out log entries
The queries required to determine the number of filtered-out entries and to fetch the entries themselves have a performance cost, because the tiebreaker field _doc (or in the future _seq_no) is not available for filtering in the query. A safe timestamp range filter in combination with a (timestamp, tiebreaker) search_after will probably be required. To mitigate the impact on the website performance, these could be performed incrementally after the shown log entries have been loaded.
Mockups
