It supports it from the very beginning, you just need to configure max_no_bytes (by default set to infinity) and max_no_files (by default set to 0).
hauleth
0
derek-zhou
From the erlang 21 doc on logger_std_h:
Notice that the standard handler does not have support for circular logging. Use the disk_log handler,
logger_disk_log_h, for this.
I checked the document I installed locally and it said the same. If you know more please share it. I can only refer to the official documentation.
0
Maxximiliann
hauleth
I stand corrected.
I cannot find information about that in the change log, neither in the docs. It seems like it was public from OTP 21.3.
Assume that you have files:
log.0log.1log.2
If you use logger_disk_log_h you need to check out which file is currently used by logger via checking their last change timestamp (as these will be used in circular fashion, “wrapping” as it is defined by disk_log). If you use logger_std_h then log.0 is always the newest one (as it works more like logrotate). In general disk_log isn’t very good thing to work with, especially if you use it with external format.
0
derek-zhou
I was referring to this sentence in the changelog. Probably “internal” does not mean non-public:
The standard logger handler, logger_std_h, now has a new internal feature for log rotation.
As for filename rotation, I prefer the scheme of svlogd from runit, which is somewhere between the two:
- lastest file name is fixed
- old files are not renamed
On one hand I want the latest file easily identifiable. On the other hand, I prefer old files just stay what they are. If something went wrong and the log files are rotating fast it is very frustrating to pin down the one file that has the log entries you want to analysis.
1
hauleth
It meant how it is implemented, not about “publicity” of an API.
It seems like more reasonable approach, indeed. However changing it now would be a breaking change. However I hope that logger_olp and logger_sup will became public API in near future, which mean that there will be a way to implement such feature directly in Erlang. However personally I still prefer to use syslog or journal for logging, and do not bother with rotation within the application itself. In that way, there is no problem with rotation or “where will logs land” as you have centralised place to manage everything.
1