Logs cluttered by errors

1

Still using Chirpstack v3. This might not be relevant to v4.

I don’t think I ever changed anything to the default log config and I realized recently that chirpstack logs took a lot of space, in fact much more than the DB that actually stores the data.

This applies to both network and application server.

I found config tips in the docs

Those are not in the default configuration.

I modified the network and application server configs as indicated, setting warning as log level:

[general]
# Log level
#
# debug=5, info=4, warning=3, error=2, fatal=1, panic=0
log_level=3

# Log to syslog.
#
# When set to true, log messages are being written to syslog.
log_to_syslog=false

The change has been taken into account after restart because I now only get messages of level >= warning.

However, those are still logged in syslog. I wonder why.

Also, I get a lot of those errors:

  • get device-session error: object does not exist
  • get device-session error: frame-counter did not increment

I’m not sure exactly why and as soon as all my applications work I assume this is noise. In any case, and unless I’m totally mistaken, those are not errors from the server perspective, those are client errors, like misconfigured devices. Shouldn’t those be info level, rather than error? Like, rejecting a user due to auth error, for instance, would be at most info level from server perspective. The point of setting to error is to limit the log to server errors.

My suggestion would be to make those info at most.

Sorry about bringing up questions about v3. I intend to migrate but there are things we still need to figure out.

2

In v4 a lot of log-improvements have been added. In general, I try to only log error logs in case a sys-admin action is required. User-related “errors” are logged as warn as these might require attention, but might not always be within the scope of a sysadmin to fix.

3

Thanks for answering. Yes, this makes total sense.

I try to only log error logs in case a sys-admin action is required

Exactly.

User-related “errors” are logged as warn as these might require attention, but might not always be within the scope of a sysadmin to fix

Yes. In fact, IIUC, noise from unknown sensors reaching our gateways could even be downgraded to info since this is not something we can and want to act upon. My rule of thumb here is that “no warning” should be feasible. If a warning can’t be avoided, then maybe it shouldn’t be a warning.

Anyway, that’s much better already.

The other part of my question was about log_to_syslog=false which doesn’t seem to work.

I guess all of this should be fixed or obsolete when migrating to v4 so feel free to ignore.