Log Filter and Update

[henfri]

Hello,

when updating a log, the log jumps to page 1 and to line 1.
In most cases, the user will not want to reload and see the (most likely unchanged) line 1.

Furthermore, when filtering, the pages/line numbers are not updated.

Example: One filters for a line that appears once in the log only.
After applying the filter, the output is empty. Only after jumping to the page on which the filtered content is (there should be one only, when considering, that the filtered output is one line), the output is shown.

This should be changed. The user filters, because he does not know if/on which page a line appears. this way, he would have to still search through all the pages.

Regards,
Hendrik

[msinn]

I don‘t think it should be changed. Automatically jumping to the end of the log could render the admin interface unresponsive for several seconds on large Logs.

If you want to jump to the end, just press the corresponding button after reload.

[psilo909]

But what about the filtering? If he is right filtering gets nearly useless

[henfri]

Hello,

@msinn: there is no point staying on page 1 after a reload, as the first page -if there is more than one- will onchange, right?

@psilo909 you are right.

Greetings,
Hendrik

[msinn]

But there is not point in jumping to the last page either...

The only thing that would make sense would be to jump to the page with the first new entry. But with the way logging works (the file has to be re-read from disk on reload) and the REST api being stateless (the server has no idea which client has received which part of the log) that's no simple task to accomplish.

In regard to filtering: The filtering is done on the client side to be act fast on the chunk read, when changing the filter (otherwise the filter has to be applied on the server, re-reading the file). Probably it would be best to reset the filter when reloading the log.

Maybe (if there is enough need) we could introduce a server-side filtering as an option in a later release. For the time being, there is one parameter which could ease your problems with filtering. The configuration of the admin module has a parameter log_chunksize, which controls how many log entries are transferred to the client. The default is 1000 log entries, You could increase this parameter.

[Morg42]

I thought about this a bit. Large file operations aside, the server could save a "last displayed"-value per logfile, either as line number or as chunk = page. As long as the log file isn't rewritten, it could load the n-th page (or line) for the next display.
Actually, I'm not sure if this is worth the effort. While I understand (and wished) the ability to continue where I left off, honestly the log display might be sufficient for a quick check. For proper log file analysis the web interface is too sluggish and missing more advanced features.

[msinn]

the server could save a "last displayed"-value per logfile

but for which client? and remember: The connections are stateless, so it is not possible to remember states for a specific client even while it is online.

I agree: For a deeper log analysis the log file should be downloaded and inspected with tools adequat for the purpose.

[henfri]

Hello,

lets not overcomplicate things. Mostly, there will be one User only. That will allow to just safe the 'last' one.

For me, the most usual use-case is that I want to monitor the last, incoming log entries. So today, I usually must do a tail -f ... That is a pitty, as there is this nice admin interface.

Is it different for you? Is the log-section in the admin interface useful for you as it is?
Do you really usually want to see the beginning of the logfile?

Regards,
Hendrik