Log module is capable of reading, processing, and uploading entries from systemd-journald, a Linux-based centralized logging system service. Events/logs are usually stored in files located in the /var/log/journal/'machine-id'/ directory, where machine-id is a long string of digits identifying the machine. These files are kept in a binary, compressed format, maintained by the systemd-journald engine to manage size per file and overall, retention, rotation, etc., according to its settings.
To avoid the problems of manually tracking the files, such as rotation, decompression, or parsing, Log module uses system API calls to access the entire functionality. This is achieved by opening the system library, libsystemd.so and its dependencies, mapping selected functions from the library, and creating a context object, to communicate with the Journald system. This way, Log module becomes a client of Journald and can use a variety of its exposed functions.
At the beginning, Log module opens a handler at the default location of the Journald context. No specific path is used, allowing the handler to open its well-known location. Then the agent reads the entries one by one, keeping track of the current position.
To enable Journald log detection, follow the steps below:
Enabling the feature flag is required to opt-in. Without it, even with configured ingest rules, Journald logs will not appear in Dynatrace.
You can enable log ingestion from Journald by either configuring the default Journald ingest rule, or by configuring the tenant storage upload, for example kubelet.service as Journald.unit from Journald.
For new accounts, the default Journald ingest rule is enabled by default, and the configuration described in this section is not needed.
Follow the steps below to configure the default Journald ingest rule:
Follow the steps below to configure the tenat storage upload for kubelet.service logs from Journad:
kubelet.service.Each entry is processed to gain the following attributes:
Semantic attribute name
Description
Timestamp
Retrieved by direct API call for timestamp, results in microseconds since epoch converted to agent’s timestamp domain resolution
Content
The extracted value of the API call for data with the MESSAGE field as a selector
Journald.unit
The extracted value of the API call for data with the UNIT field as a selector As an alternative, the SYSTEMD_UNIT field is searched. It may happen that none of the fields are found.
LogEntryLevel
The extracted value of the API call for data with the PRIORITY field as a selector, priority. Consult the table below for the definitions of the priority levels.
Journald priority codes are used to mark the importance of a message. The following table shows how these priorities translate into Dynatrace severity:
Value
Severity
Description
0
Emergency
System is unusable
1
Alert
Should be corrected immediately
2
Critical
Critical conditions
3
Error
Error conditions
4
Warn
May indicate that an error will occur if action is not taken
5
Notice
Events that are unusual, but not error conditions
6
Info
Normal operational messages that require no action
7
Debug
Messages which may need to be enabled first, only useful for debugging