You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Logs files name with a better operator visibility.
Actual behavior
Current default is
log_filename: 'postgresql-%w_%H%M.log'
That's allowing a weekly rotation which we don't really want by default anyway (it's really short on production if there isn't any external logging involved).
Files are really hard to walk by this way, I would prefer a consolidated daily or, if you have a strong opinion about this, hourly, log rotation.
Logrotate configuration should take care of the pruning of old log files and also help with space with compression mechanism.
Versions
Operating system: Ubuntu 22.04.5 LTS
Juju CLI: 3.6.2-ubuntu-amd64
Juju agent: 3.1.8
Charm revision: 14/candidate rev 331
Additional context
Stumbled across the lack of visibility of obvious issues with max_connections because of the log file naming.
I get that a mere cat postgresql-%w* | less give me the same result but that seems an unnecessary step.
What I'm more worried about is the weekly log overwrite it implies, given not everybody (ahem) has logging export and storage and that it can cause a really weird mix of logs like this:
$ sudo ls -lart /var/snap/charmed-postgresql/common/var/log/postgresql/postgresql-1_063*
-rw------- 1 snap_daemon snap_daemon 6815 Jan 13 06:34 /var/snap/charmed-postgresql/common/var/log/postgresql/postgresql-1_0634.log
-rw------- 1 snap_daemon snap_daemon 6235 Jan 13 06:35 /var/snap/charmed-postgresql/common/var/log/postgresql/postgresql-1_0635.log
-rw------- 1 snap_daemon snap_daemon 6380 Jan 13 06:36 /var/snap/charmed-postgresql/common/var/log/postgresql/postgresql-1_0636.log
-rw------- 1 snap_daemon snap_daemon 6525 Jan 13 06:37 /var/snap/charmed-postgresql/common/var/log/postgresql/postgresql-1_0637.log
-rw------- 1 snap_daemon snap_daemon 6380 Jan 13 06:38 /var/snap/charmed-postgresql/common/var/log/postgresql/postgresql-1_0638.log
-rw------- 1 snap_daemon snap_daemon 6525 Jan 20 06:30 /var/snap/charmed-postgresql/common/var/log/postgresql/postgresql-1_0630.log
-rw------- 1 snap_daemon snap_daemon 6525 Jan 20 06:31 /var/snap/charmed-postgresql/common/var/log/postgresql/postgresql-1_0631.log
-rw------- 1 snap_daemon snap_daemon 3770 Jan 20 06:32 /var/snap/charmed-postgresql/common/var/log/postgresql/postgresql-1_0632.log
-rw------- 1 snap_daemon snap_daemon 17255 Jan 20 06:38 /var/snap/charmed-postgresql/common/var/log/postgresql/postgresql-1_0633.log
-rw------- 1 snap_daemon snap_daemon 5800 Jan 20 06:39 /var/snap/charmed-postgresql/common/var/log/postgresql/postgresql-1_0639.log
You can see here that we have a mix of logs for this week, and on the few minutes were no logs were written, still the logs from the previous week.
The text was updated successfully, but these errors were encountered:
Steps to reproduce
Expected behavior
Logs files name with a better operator visibility.
Actual behavior
Current default is
That's allowing a weekly rotation which we don't really want by default anyway (it's really short on production if there isn't any external logging involved).
Files are really hard to walk by this way, I would prefer a consolidated daily or, if you have a strong opinion about this, hourly, log rotation.
Logrotate configuration should take care of the pruning of old log files and also help with space with compression mechanism.
Versions
Operating system: Ubuntu 22.04.5 LTS
Juju CLI: 3.6.2-ubuntu-amd64
Juju agent: 3.1.8
Charm revision: 14/candidate rev 331
Additional context
Stumbled across the lack of visibility of obvious issues with max_connections because of the log file naming.
I get that a mere
cat postgresql-%w* | less
give me the same result but that seems an unnecessary step.What I'm more worried about is the weekly log overwrite it implies, given not everybody (ahem) has logging export and storage and that it can cause a really weird mix of logs like this:
You can see here that we have a mix of logs for this week, and on the few minutes were no logs were written, still the logs from the previous week.
The text was updated successfully, but these errors were encountered: