journald(8) is for collecting log output from processes and textual output from services started by systemd(1).

As is usual for things involving systemd, there's some controversy surrounding it, because of some technical decisions and it being a mandatory component in systems that use systemd(1).

The main concern is that it will replace the venerable syslog, because journald(8) takes over the /dev/log socket used by the syslog(3) logging protocol. However, this does not actually force you to use the Journal, as rsyslogd(8) can read information out of the journal.

The other concern with journald(8) is that it saves logs in a binary format requiring it to be read out with journalctl(1), as opposed to syslog, which saves logs as a text file, so can be processed by other tools.

The source of concern is that the Journal may change to an incompatible format, and there wouldn't be any way to read the logs out, but this can be mitigated by installing rsyslogd(8) in case it ever happens, and the systemd developers have been careful about keeping it backwards compatible.

The reason for the journal storing logs in a binary format, is for performance when searching, as the journal contains more logging information than syslog used to handle.

By default, the Journal stores the standard output and standard error of services in addition to syslog(3) output. This is usually sufficient, but applications can send messages directly too with the sd-journal(3) library.

There is not a great deal of configuration required to use journald(8), but reading messages is possible with the journalctl(1) tool.

I find the most useful option to journalctl(1) is --unit, which most recently saved me a lot of time when debugging service start-up issues, as it allowed me to deduce why things were failing to work properly.