The IT Blog

Tag: Logging

  • How to configure LogRetention with journald

    Whenever you have a regular process, you definitely want to have some proper logging. But the very next thought after mentioning “logging” should be “LogRetention”. Especially when the process is executed automatically. No matter how often — as soon as the execution isn’t a one off, log rotation & log retention are a topic.

    LogRotate

    Especially on linux, it’s just so easy: use logrotate for example. Just one simple config file /settings and you’re set up with log rotation, compression and retention.

    journald & journalctl

    On my miniPC, I tried to avoid writing a lot of own log files but whent with journald and piped all logs into it. And never thought about retention. – Until today.

    I just set up another process and during testing, I noticed that I had more than 2.5gb of log files (journalctl --disk-usage) … dating back until very long. A quick check of the /etc/systemd/journald.conf confirmed that I missed some settings.

    journald has quite an elaborate set of options, just check the man page. Without big evaluation, I’ guess I’m fine with:

    Compress=yes
SystemMaxUse=100M
SystemMaxFileSize=5M
MaxRetentionSec=1month

    Also, don’t forget to reload …

    sudo systemctl restart systemd-journald

    And don’t spend a second thinking about overflowing logs any more…

    Fediverse Reactions

  • An introduction to the Logging framework (a.k.a. System.out.println is evil)

    Motivation

    One of the first lines a programmer will write in a new language is surely “Hello World”. In Java you can write to the console or to the error stream quite easy with a simple System.out.println("Hello World") or System.err.println("Hello Error"). Great! When the code grows, bugs creep into the code and make live a bit harder. At this point programmers should definately start a deep and loving relationship with the debugger that is delivered with the IDE instead of using System.out/err.println() as debug method. Nevertheless – there are at cases, where a Debugger cannot (or hardly) be applied:

    1. The code runs in the IDE but not if startet directly. – What the hell’s going wrong?
    2. Handling of exceptions. An exception indicates a state that should not have happened and therefore it might be considered to be logged.
    3. The code is deployed to someone else and you cannot attach the debugger to his/her machine.

    At either point, beginners tend to use System.out/err.println() to trace the execution path. While this might be okay if the onlyone that is using the code is the programmer alone, this can be very annoying if you are working in a team: If you forget to remove the debug messages, you’re polluting someone elses console output. Even worse: if the code is deployed to a client which reports an error, you cannot raise/lower debug levels or just enable/disable debugging. Do you really want to send a “debug version”? (No you wouldn’t.)

    (more…)