ddelemeny
commented
4 months ago Possible follow ups
- Configurable query defaults : I think it would be nice to allow users to tailor the default fragments used to initialize a query to their use-case. This would require substantial modifications to the query editor initialization, and a dedicated UX.
- Make the consequences of limits louder : find a way to alert the user of the possible log-skipping consequences of query limits and recommended workarounds
Issues #88 & #89 showcase bad UX of the current log query limit.
Grafana's pagination components may fail up to v10.3, v10.4 should fix issues with the "older logs" button not working -> Won't fix, wait for next release, maybe document the issue ?
Timestamp resolution matters, as grafana paginates on timestamp only and at the moment doesn't provide any hint about the data already fetched when issuing a page query. Too many records with the same timestamp will cause data to be skipped between pages. If this issue arises, using a finer timestamp resolution and raised query limits are the solution. -> Raise default query limits to 1000, partially fixes #88 ?
Chronological exploration of logs is a use case where the limit can cause frustration, because the current behavior only returns the log tail. -> Add a query setting to allow querying the log head (within the defined time range), fixes #89
Bonus refactoring
QueryEditorSpecialMetricRow and QueryEditorRow shared the same layout code, rename and refactor.