The logger(1) command has been around for quite a while. Hopefully by now people are preferring logger when sending messages to syslog instead of creating random log files all over system. While the basic idea of logger has not been changed, in the last few months the command has got couple of new features.
It is now possible to send structured messages to journald that is a system facility. A journal entry can multiple fields that look a lot like key value pairs. Here is a simple example of a journal entry.
$ echo 'MESSAGE_ID=86184c3b1aa444f58ebe7b30fec1438b DOGS=bark CARAVAN=goes on' | logger --journald
Assuming above example was logged one should find the message with.
$ journalctl --output=json-pretty DOGS=bark
The point of journal support is to allow structured data to be logged. This will permit easy finding, grouping, and analysis of messages. In journal entries MESSAGE_ID field is recommended as it is an excellent key to group or differentiate messages.
See also manual pages journalctl(1) and systemd.journal-fields(7) before taking the logger --journald in use.
In cases in which syslog messages need to be sent to remote syslogd or in which the users want to stick with the traditional local syslog message format the journal structured messages cannot be used. In these cases --id=$$ will make the message analysis easier.
Traditionally logger --id has printed a process id (pid) of the logger command that varies at each execution of the command in a message. Assuming that a script has several logger invocations and multiple parallel scripts running at the same time it is not easy to figure out which of the runs inform which.
Printing a parent process id, --id=$$ will mean that the pid field in syslog message will be the script's process id that does not change in between consecutive logger messages when sent from a single script session. This makes the streams of messages trivial.
The logger has used RFC3164 protocol to log remotely for a long time. The old protocol does not fully support the qualified hostname field in the syslog message header, and in some cases the stamp is not accurate. The new protocol sends messages that will look like this
Aug 9 09:56:36 192.168.1.10 1 2014-08-09T09:56:36,346136+0100 hostname.example.com tag - [timeQuality tzKnown="1" isSynced="1" syncAccuracy="362834"] message test here
The first time stamp tells when the syslog deamon both received and wrote the message. The IP address is the source address where the communication came from.
The number in the front of the second time stamp is the priority and it is untouched. After it comes the time stamp that tells when the message was sent using ISO-8601 format. The message has the maximum accuracy of RFC5424. The hostname will be exactly the same than what the gethostname(2) function returns. The tag field is what it has always been - followed by RFC defined separator hyphen.
The timeQuality is structured data in RFC5424 terms. The field tzKnown tells if the time zone in client side time stamp is known. This is assumed to be true in a linux system. If the clock is synchronized with ntp the isSynced is 1. When the clock is not synchronized with ntp the the isSynced is 0. The syncAccuracy informs maximum value how much the time stamp might be off in milliseconds.
All three new fields, the client side time stamp, the hostname, and the time quality, can be switched off by using --rfc5424=notime,nohost,notq option arguments. For users who prefer the old protocol there is --rfc3164 option.
The RFC3164 implementations has added the hostname to the syslog header. The standard dictates that the hostname must be in a short format. If the gethostname(2) returns a fully qualified name, such as a hostname.example.com, the domain is cut out from the first dot leaving only the hostname in place.
An example of a RFC3164 messages format.
<5>Aug 9 09:56:36 hostname tag[2502]: message test here
This page was published 2014-08-20T15:17:27+0300 and most recent update is from 2014-12-24T00:04:34+0000