[Feature] UI enhancements

[Ecostack]

Search before asking

• I had searched in the issues and found no similar feature requirement.

Description

Hey all,

while using Skywalking, I found somethings that can be improved with the UI.

1. It seems like the columns in the Log view cannot be resized. This makes glancing over the logs via the Content column difficult. The current width is just 300px, which might not be enough for some cases.
2. Keep the current UI selection/filter state as part of the URL. With that, the link can easily be shared or re-opened.
3. Save trace view selection (List/Tree/Table) as part of either URL or local storage.
4. Besides give a list of logs, also show an aggregation of logs. In that case, also show how often certain log types appear.

Please let me know of these ideas.

Use case

No response

Related issues

No response

Are you willing to submit a pull request to implement this on your own?

• Yes I am willing to submit a pull request on my own!

Code of Conduct

• I agree to follow this project's Code of Conduct

[wu-sheng]

4. Besides give a list of logs, also show an aggregation of logs. In that case, also show how often certain log types appear.

Could you explain more? Logs are queried on paging, how to aggregated? Usually, we recommend streaming log analysis through LAL.

[Ecostack]

I am thinking similar to what Uptrace is doing:

https://app.uptrace.dev/spans/1/?time_gte=20231101T065000&time_dur=3600&system=log%3Aall&query=group%20by%20.group_id%20%7C%20per_min%28.count%29&sort_by=per_min%28.count%29&sort_desc=true&column=per_min%28.count%29

See the count per minute aggregation:

[Superskyyy]

@Ecostack This is indeed coming as an AI algorithm add-on from the aiops engine side of skywalking, it cannot be achieved using purely UI or backend through aggregation since users otherwise have to manually decide template for possiblly hundreds of unstructured logs each with dynamic variables.

[wu-sheng]

1. It seems like the columns in the Log view cannot be resized. This makes glancing over the logs via the Content column difficult. The current width is just 300px, which might not be enough for some cases.

If the messages are super long, you need a very wide column to read. Could you share your use cases which is inconvenient to read raw logs in the open dialog?

[Ecostack]

In my opinion, the focus of the log view should be on the content column. Giving it the most space.

In my case, the logged content contains also a time stamp, that is blocking the view. It is maybe not the best example but looking at Uptrace, it gives 2-3 times the space for the logged content.

My Skywalking log view:

Uptrace demo:

[wu-sheng]

I just put my conclusion as below, please take a look.

[wu-sheng]

@Fine0830 I would like to recommend enhancing log view page like this

1. Timestamp + Raw log(content) as column one, 70% of the initial table width. No separate timestamp column. The first column should be timestamp - content
2. Service
3. Level tag(key=level)'s value. This could be missed from tags, if so, keep the column as empty.
4. Trace link. If trace ID exists, generate a link to trace. Don't need to put trace ID in the text.
5. Still keep details pop up style.
6. No column resize is required when having <1> - <5>

[Fine0830]

OK

[wu-sheng]

Implementations on apache/skywalking-booster-ui#333