[bug] Logging at :error level is too noisy #602

Open
opened 2023-07-24 15:21:10 +00:00 by fedward · 3 comments

Your setup

From source

Extra details

FreeBSD 13.2

Version

3.9.3

PostgreSQL version

14

What were you trying to do?

While diagnosing a problem I turned logging on at the error level.

What did you expect to happen?

Syslog seems like a place you'd want serious system errors only if your log level is set to :error, both to make the actual errors stand out and so as not to make syslog seem useless for anything that isn't Akkoma.

What actually happened?

When logging is enabled at the :error level, the log is constantly spammed with messages of two types that seem like maybe they should be less severe than :error.

Logs

Could not fetch user [URL], {nil, {:error, {"Object has been deleted", "[URL]", 410}}}

Could not decode featured collection at fetch [URL], {:error, {"Object has been deleted", "[URL]", 410}}

Severity

I cannot use it as easily as I'd like

Have you searched for this issue?

  • I have double-checked and have not found this issue mentioned anywhere.
### Your setup From source ### Extra details FreeBSD 13.2 ### Version 3.9.3 ### PostgreSQL version 14 ### What were you trying to do? While diagnosing a problem I turned logging on at the error level. ### What did you expect to happen? Syslog seems like a place you'd want serious system errors only if your log level is set to :error, both to make the actual errors stand out and so as not to make syslog seem useless for anything that isn't Akkoma. ### What actually happened? When logging is enabled at the :error level, the log is constantly spammed with messages of two types that seem like maybe they should be less severe than :error. ### Logs ```shell Could not fetch user [URL], {nil, {:error, {"Object has been deleted", "[URL]", 410}}} Could not decode featured collection at fetch [URL], {:error, {"Object has been deleted", "[URL]", 410}} ``` ### Severity I cannot use it as easily as I'd like ### Have you searched for this issue? - [ ] I have double-checked and have not found this issue mentioned anywhere.
fedward added the
bug
label 2023-07-24 15:21:10 +00:00
Author

As an experiment I've set those two things to Logger.warning instead of Logger.error on my own instance while I'm trying to diagnose the actual problem with my server, and I realize this may be an Extremely Stupid Idea for reasons I'm an unbelievable jackass for not knowing, but I thought I'd at least ask and see if anybody else agrees with me.

As an experiment I've set those two things to `Logger.warning` instead of `Logger.error` on my own instance while I'm trying to diagnose the actual problem with my server, and I realize this may be an Extremely Stupid Idea for reasons I'm an unbelievable jackass for not knowing, but I thought I'd at least ask and see if anybody else agrees with me.

I have the same thing happening and the same thoughts. @fedward , can you share how you implemented the workaround of setting certain messages to warn?

I have the same thing happening and the same thoughts. @fedward , can you share how you implemented the workaround of setting certain messages to warn?
Contributor

I agree, those messages appears a lot in my logs too. But in general, debugging from production is hard in fedi softwares given the amount of activities generated by other instances.

Personally, in order to debug, I dump my db and run a local akkoma on it so i'm the only user there and since my local instance does not federate, I can easily reproduce issues

I agree, those messages appears a lot in my logs too. But in general, debugging from production is hard in fedi softwares given the amount of activities generated by other instances. Personally, in order to debug, I dump my db and run a local akkoma on it so i'm the only user there and since my local instance does not federate, I can easily reproduce issues
Sign in to join this conversation.
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#602
No description provided.