Request for feedback: Server logs

Questions
1

Another thread calling for feedback! The focus of this thread is the Server Logs tab (within Logs).

What are some frustrations with it? What are examples of questions / debugging investigations you’ve tried to do but which the server logs don’t facilitate? Happy to listen to any and all ideas.

(I’ve read through past forum threads on this topic that I’ve been able to find, but feel free to re-raise points, or just link to other threads.)

Thanks!
Allen

1 Like
2

Would be great to export as .txt file.
…or at the vert least be able to copy and paste.
“zoom in on wf” doesn’t seem to do anything.

Those are my frustrations. :slight_smile:

2 Likes
3

Hi

+1 for “zoom on this workflow”

If it works, can someone tell me how? Like in continuous loop

4

Would love to be able to ‘tail -f’ the log (as in Unix), so we can see the lastest entries without having to scroll down.

1 Like
5

Agree that zoom on this workflow is a bit confusing.

One thing that I’d like to do is to click a workflow and see logs of its runs (“see run logs of this wf” option), instead of trying to find its runs by time and user.
That way I’d easily debug something.

2 Likes
6

Export feature, because they are only available for 14 days on any plan, while IT departments of corporate clients ask usually for more (~6 months).

6 Likes
7

Better yet: automated exporting! :smile:
My app can email me every day those logs and I won’t mind. I think that if done through the app’s email key then it won’t burden bubble’s mainframe.

2 Likes
8

@vini_brito +1 on this!

9

Just popping in to say - thank you for all the feedback!

(If people have further feedback, please feel free to continue sharing here)

10

@allenyang Scrolling up/down within the logs just takes way too long and sometimes just doesn’t work. If the logs section is built on Bubble as a extended vertical scrolling repeating group, then that may not be the best choice. It’s so painful to scroll, wait for a chunk of entries to load, scroll, wait for another chunk, etc. And again, sometimes it just won’t load the next chunk no matter what you do.

2 Likes
11

Ability to write to log would be great. For example, there could be an action step in workflows (client and API workflow) that would write a text to the log (and the category of the log -debug, info, error…-, this way we could set the minimum category to display in logs at an app setting)

Regards.

1 Like
12

More useful (I think) things for the logs:

  • Ability to view ‘read’ action steps. Right now it seems that we can only see ‘write’ action steps. This way we can see how fast or slow our read queries are.

  • Add milliseconds to the time. In web development, milliseconds are very meaningful.

Regards.

1 Like
13

Thinking a bit more about what would be helpful in logs …

  1. Always have ability to select text from log body area. This is currently inconsistent. Use case: I want to copy a uniqueid from the logs and paste it into a view search to investigate, but I cannot. So I have to type it out manually.
  2. Some other basic operators, for example “does not contain” and the ability to add booleans
  3. Filter by specific workflow
  4. Filter by app page active when the log was generated
  5. Filter between two specific time periods or relative time periods (>= 12/1/19 and <=12/2/19, or, >= 3 days ago and <=2 days ago)
  6. Display full, wrapped, ideally non-minified http responses/errors (and again make sure these are text-selectable)
  7. Include user agent metadata where available
  8. Ability to aggregate and count, something like SQL capability
  9. Break out log metadata fields (name, email, id, timestamp) into columns and be able to quick sort/filter by those.
  10. Add log entries that “show the work” that went into calculations, similar to how you can trace back a result in the debugger. Right now the logs only show the results of a calculation. This is generally not an issue for workflows executed on page because of the debugger, but it’s tough to debug API workflows without being able to see where a calculation may have gone wrong.

I’ll stop there, but I’m sure there are more … in short: Better logs = Better apps!

-Ed

1 Like
14

Hi @allenyang,

  1. If you can make the log downloadable into csv or txt, so that I can perform searches on the data within excel or text editor
  2. Make “contains” work when you type a value into search. For example, when I type a unique ID in contains, I never receive any results and always have to go in and find my record manually.

Thank you!!
Gilles

15

Also,

  • Field names and option set names are not shown correctly - some other version of the name, probably the underlying field id is shown - but that is unhelpful as it’s unknown to the user, making it hard (and sometimes impossible) to decipher.
  • It’s not always clear what the workflow and step are. Would be much better if these were explicit, especially considering processing is not sequential.
  • Would second what others have said in respect of searching (it’s hopeless), zooming in (it’s useless) and scrolling & filtering.

Any update on when logs might see some improvements would be appreciated.

Many thanks.

16

+1

Also +1 for filtering a date range - If I identify something happened say 48 hours earlier do you know how many logs I have to scroll through in some apps to find the issue - even when using the search by user email. And then when the elements etc don’t reflect the names they currently have in the app. Very hard.

17

@allenyang @emmanuel @josh

In return for all the feedback that’s been provided, any chance we can get an update on when logs might see some basic improvements? They currently provide a pretty appalling user experience and are the source of much unnecessary frustration. There are several easy fixes that would make everyone’s lives much easier so it’s a bit hard to understand why these haven’t been done. How is it that logs still use field names and option set names that are unrecognisable to the user and log entries can’t be identified with workflow steps? Please help us out here and let us know what’s happening in this area? Understand you guys have a lot of ground to cover but as apps become more complex, the issues with the logs make debugging a nightmare, so this really needs some attention.

Many thanks, Stuart

18

We appreciate all this feedback! We have a running doc aggregating all the ideas we’d love to tackle with the Server Logs and what specific users have said relating to each idea.

To give a folks a peek into why this hasn’t been done yet: our logs system is quite complicated - logs are powered by Elastic, ie it’s a unique system versus, say, your app’s database. Most ideas that would meaningfully improve the Server Logs experience would require corresponding changes to how we store the data in Elastic. E.g. it’s not as simple as just adding a dropdown with all the workflows in your app to filter by. So all these ideas are on our radar, but they’re slightly bigger investments for us to weigh against other meaty investments, like our performance improvement projects. This is something we hope to get to in the near- or medium-term future though.