Clicking on log components (like web server protection, atp, security HB) that are empty in log viewer, blocks log viewer for several minutes

Indeed, could reproduce this with my own appliance. (6C8 Virtual Appliance).

But it loads after ~1 minute. Maybe your appliance is slower, so to speak, it loads longer. But basically this is a issue, i agree. 

This seems to be "new", because i could not reproduce this in my "older" (EAP0) Appliance.  

Any news regarding this issue, LuCar Toni?

Can you check if it is tracked as a bug? I have to close log viewer to check other component logs otherwise troubleshooting is impossible.

Thanks

Hi lferrara,

Thanks for the feedback.

We are working on it .We will get back to you soon with more details.

Thanks,
Rana Sharma

Hi lferrara,

I have tried two different scenario to verify this feedback.

Scenario 1 : SFOS Appliance is loaded with very less log viewer data and then filter component which doesn't have data taking 5-10Sec in my cases

Scenario 2 : SFOS Appliance is loaded with high log viewer data and then filter component which doesn't have data taking 3-4 minutes.

If you try the same case in v17.5.MRx you would get the same results.

Thanks,

Rana Sharma

Hello Rana,

I appreciate that this is something that is happening already in v17 and is mainly due to how the Log Viewer was rapidly entered into v17 GA.

As I expect you know, the log viewer data sources are multiple PGSQL database files that are created everytime one gets too large. Then it operates on a First In First Out methodology to keep the Log Viewer DBs from filling up the disk. So when a search occurs it opens each one sequentially till it has retrieved a set number of lines then stops searching unless the user scrolls far enough when it requests more by re-searching (i presume) from the last log line showing on the screen.

The bigger question is whether the Log Viewer backend is getting an upgrade to a more suitable configuration as the current methodology has caused issues like this regularly but when it is brought up it is responded with that there will be future upgrades to the subsystem.

I cannot accept that Scenario 2 cannot be classified as suitable especially as Sophos is moving to larger markets, it can leave a lot to be desired. It may be a feature working as expected but I have an excellent metaphor regarding "feature is working as expected" if you'd like to hear it.

What is in the current pipeline to upgrade the Log Viewer backend?

Emile

Hello Rana,

I appreciate that this is something that is happening already in v17 and is mainly due to how the Log Viewer was rapidly entered into v17 GA.

As I expect you know, the log viewer data sources are multiple PGSQL database files that are created everytime one gets too large. Then it operates on a First In First Out methodology to keep the Log Viewer DBs from filling up the disk. So when a search occurs it opens each one sequentially till it has retrieved a set number of lines then stops searching unless the user scrolls far enough when it requests more by re-searching (i presume) from the last log line showing on the screen.

The bigger question is whether the Log Viewer backend is getting an upgrade to a more suitable configuration as the current methodology has caused issues like this regularly but when it is brought up it is responded with that there will be future upgrades to the subsystem.

I cannot accept that Scenario 2 cannot be classified as suitable especially as Sophos is moving to larger markets, it can leave a lot to be desired. It may be a feature working as expected but I have an excellent metaphor regarding "feature is working as expected" if you'd like to hear it.

What is in the current pipeline to upgrade the Log Viewer backend?

Emile