Skip to content

[Feature] Logs Page#456

Merged
BboyAkers merged 21 commits into
stagefrom
logs-page
Jan 29, 2025
Merged

[Feature] Logs Page#456
BboyAkers merged 21 commits into
stagefrom
logs-page

Conversation

@BboyAkers

@BboyAkers BboyAkers commented Jan 23, 2025

Copy link
Copy Markdown
Member

Ticket

STUDIO-160

Overview

  • Added a /Logs sub-route for instances to view server logs
  • Added filtering capabilities for logs

@BboyAkers
BboyAkers marked this pull request as ready for review January 28, 2025 05:38

@kriszyp kriszyp left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job, this is a huge improvement over the previous log viewer.
I will share some of my own (mostly subjective) preferences for log viewing. First, (maybe a little more objective), reading the body of a log message in log info dialog in dark mode is pretty hard:
image

Generally, the act of log viewing generally involves looking through a large amount of log information and quickly scanning for key bits of information. Consequently, good/mature log viewing tools generally feature high information density, balanced with text legibility. However, in the studio log viewer, much of the screen real estate is "wasted":
image
The first five columns take up most of the horizontal space even though they are small bits of text. The log message is by far the most important part of the log entry, but it receives a minority of the space. The columns should be adjusted so that the Message column uses about 60%-70% of the horizontal space.
Vertically, the space usage is sub-optimal as well, with the actual content often compromising a small amount of the available space, with font size that is probably a little small, and too much line spacing. I would think you typically want the text height to at least be 50% of the line height. Here is an example of typical log viewing from a terminal that I would consider highly efficient:
image
Also, why does the scrollbar have to be so tiny for dragging (scrolling is often the first thing I do when I am looking at logs)?
image

Anyway, some of this is probably beyond the scope of what you were aiming to tackle with this PR, and some might be somewhat preferential. You should probably fix the Log Info dialog in dark mode for this PR, but beyond that, I am fine with merging this PR and doing further log updates at a different time, if you prefer.

Again, this is a great step forward, nice work!

@BboyAkers

Copy link
Copy Markdown
Member Author

Fixed:

  • Log Row column widths/sizing
  • Scrollbar width
  • Increased height of each Log Row to show more of the message.
  • Fixed Log Modal Message text color in dark mode

@kriszyp @mihaiharperdb

@kriszyp

kriszyp commented Jan 29, 2025

Copy link
Copy Markdown
Member

It looks like the rows are fixed size now, taking too much space for small space and overflowing for large messages:
image

@BboyAkers

Copy link
Copy Markdown
Member Author

Update:

  • Log Limit selection issue: Fixed
  • Log Level "Info": Should be fixed as well! If not, DM me @mihaiharperdb and we can hop on a call so we can dive into it and figure it out. 🙂
  • Table Row overflow issue: Fixed
  • datetime-local Input Calendar UI for FireFox: Firefox doesn't support HH:MM:SS in the default calendar UI. It defaults to a text input for that section of the input according to MDN. I can look into importing a Calendar UI dependency in a follow-up PR. I does however work as expected with the full HH:MM:SS UI for:

@sonarqubecloud

Copy link
Copy Markdown

@BboyAkers
BboyAkers merged commit 05a4c64 into stage Jan 29, 2025
@BboyAkers BboyAkers mentioned this pull request Jan 29, 2025
@dawsontoth
dawsontoth deleted the logs-page branch June 20, 2025 20:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants