Please make it possible to read from the Systemd journal.

[rnhurt]

Currently, the only way to get logging information out of Systemd services is to port the information to (r)syslog or use something like Datadog's Vector product. However, it would be great if we could reference Systemd journal just like we do with log files.

I propose that you add a new "logs" section named, systemd, as an addition to the existing files and windows_events sections.

[lwoggardner]

possibly related question. Has anyone tried reading from journald using a named pipe to a journalctl process?

Either multiple named pipes for different subsets of the journal, or just one and use filtering on the cloudwatch agent side?

[MioG777829]

Important reference point - the Elastic Beanstalk AMIs which use AL2023 have rsyslog installed to create logs in the file system as it was before. The EB team is working around this by keeping legacy configuration in place. There is no firm AWS strategy (that is visible) to upgrade these approaches to extract information directly from systemd journal.

[rdkls]

I would've thought this would be very important feature for the agent; would think one of the most common use cases is someone spinning up an ec2 instance (now AL3 which uses only default journald) and wanting to easily get logs into CW. Is there a reason it's not?

[andreaswittig]

Would be so cool to be able to collect metrics from Amazon Linux 2023 with amazon-cloudwatch-agent as well.

[ozbillwang]

fixed with below commands,

To AWS Developers who maintain the CloudWatch Agent:

please make sure, when install CloudWatch Agent, it sets ACL on the related folder , subfolders and files under the target folders.

set ACL to existing files and sub-folders

setfacl -R -m u:cwagent:rx /var/log

and add ACL on folder /var/log, for any new files and subfolders created under it.

sudo setfacl -R -d u:cwagent:rx /var/log

Not sure, why they can't be run with together with -d and -m.

So now you can check the ACL if they are set properly

# getfacl /var/log
getfacl: Removing leading '/' from absolute path names
# file: var/log
# owner: root
# group: root
user::rwx
user:cwagent:r-x
user:splunk:r-x
group::r-x
mask::r-x
other::r-x
default:user::rwx
default:user:cwagent:r-x
default:user:splunk:r--
default:group::r-x
default:mask::r-x
default:other::r-x

# getfacl /var/log/messages
getfacl: Removing leading '/' from absolute path names
# file: var/log/messages
# owner: root
# group: root
user::rw-
user:cwagent:r-x
user:splunk:r--
group::---
mask::r-x
other::---

Notes

Splunk agent, for your reference, seems to know this issue, it automatically set ACL on /var/log properly after installation