# Systemd journal ingestion? **URL:** \ **Category:** Graylog Central (peer support)\ **Created:** [August 8, 2026, 9:27pm UTC](https://community.graylog.org/t/systemd-journal-ingestion/37493 "2026-08-08T21:27:02Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![richardm1](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/richardm1/32/6355_2.png) [@richardm1](https://community.graylog.org/u/richardm1)\ **Post date:** [August 8, 2026, 9:27pm UTC](https://community.graylog.org/t/systemd-journal-ingestion/37493/1 "2026-08-08T21:27:02Z")
I have a very small use case for something like graylog: Power it up; ingest a system’s entire [systemd] journal for search, analysis, and troubleshooting of a specific problem. Shut down graylog when done. Fire it up next time it’s needed and have ingestion _pick up from where it last left off_. I simply don’t need a full-time log archiving+management solution but having powerful search features would be nice once in a while. I could simply ingest `journalctl` `json` output but the “pick up where it left off” part is puzzling. I didn’t see a marketplace product specific to `systemd-journald` so I’m wondering if this kind of thing exists. My other thought is to have a log agent installed and ready-to-go on the target system (I know these can be intelligent about bookmarking, log rolls, etc) and use it to feed a graylog instance. Thanks for any advice… **Edit** : I may already have something for this.. `rsyslog` is installed on this system, configured with `StateFile="imjournal.state"` for cursor bookmarking. I could leverage `omfwd` with a large disk queue to handle forwarding to an intermittent receiver, infinite retries, and a reasonably long retry interval. I suspect this will work… ---
**Author:** ![Alex2](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@Alex2](https://community.graylog.org/u/Alex2)\ **Post date:** [August 18, 2026, 4:04pm UTC](https://community.graylog.org/t/systemd-journal-ingestion/37493/2 "2026-08-18T16:04:29Z")
I have used filebeat with the journald input configuration, and it works great [Journald input | Filebeat Reference [8.19] | Elastic](https://www.elastic.co/guide/en/beats/filebeat/8.19/filebeat-input-journald.html) Filebeat is a log shipping agent in the Elasticsearch suite of products – runs as a daemon on the origin host, and is lightweight and reliable in my experience. With the usual package install on linux you have a systemd unit and manage the process with systemctl. You can enable/disable or run in on a schedule or whatever. It keeps a local metadata store and the default behavior is to “pick up where it left off” – so you get a continuous log stream (eventually) even if flow is interrupted. You can blow away the metadata to re-start from scratch. This might be a good fit for your use case. ---
**Author:** ![Alex2](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@Alex2](https://community.graylog.org/u/Alex2)\ **Post date:** [August 18, 2026, 4:07pm UTC](https://community.graylog.org/t/systemd-journal-ingestion/37493/3 "2026-08-18T16:07:45Z")
Also meant to say, you definitely could do this with rsyslog but based on my experience that’ll be a lot more painful to get working. I’ve used rsyslog at times for various purposes when it’s impossible or difficult to use filebeat or a similar agent. ---
**Author:** ![system](https://us1.discourse-cdn.com/flex016/uploads/graylog/original/3X/c/7/c7c09c6b5099570133d6502b83f50ba4430de5b6.png) [@system](https://community.graylog.org/u/system)\ **Post date:** [September 1, 2026, 4:08pm UTC](https://community.graylog.org/t/systemd-journal-ingestion/37493/4 "2026-09-01T16:08:00Z")
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.