Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loki datasource reading from subprocess stdout #2718

Open
sysvinit opened this issue Feb 13, 2025 · 0 comments
Open

Loki datasource reading from subprocess stdout #2718

sysvinit opened this issue Feb 13, 2025 · 0 comments
Labels
enhancement New feature or request

Comments

@sysvinit
Copy link

Request

I would like a new Loki data source which allows reading log data from the standard output of a subprocess. When such a source is configured, Alloy should spawn the program given in the configuration as a subprocess, and then forward lines read from the subprocess's standard output to other Loki receivers in the Alloy configuration.

Use case

Concretely, in order to process kernel audit logs received from go-audit. I've written about this previously in the community Discourse: https://community.grafana.com/t/bringing-logs-from-linux-audit-subsystem-into-loki/138209. These logs are potentially quite sensitive, and I'd like to get them into a Loki server as directly as possible, without passing them through intermediaries such as systemd-journald or saving them in a file on disk first (which isn't 100% tamper-proof).

Thus far in my demo environment I've been using go-audit's GELF writer and a GELF listener in Alloy bound to the loopback interface, but an open port on the loopback network interface is tricky to secure against other applications sending fake log data to Alloy and potentially poisoning the logs. Extending go-audit with a writer for the Loki push API would be relatively easy at surface level, but more difficult to make robust from a distributed systems perspective – and this is functionality which already exists in Alloy, which would be a duplication of effort.

More generally, this would be a useful feature in cases where the interface to a given log source is a dedicated reader process (kernel interfaces in particular come to mind) where it's undesired for these logs to be handled in the regular system logging pipeline (journal/syslog/etc), but which should still be collected and aggregated for central analysis.

Having looked at how the other Loki sources in Alloy are implemented I would be interested in drafting up an implementation of this idea, but I unfortunately don't have the spare time presently to put any work into that.

@sysvinit sysvinit added the enhancement New feature or request label Feb 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant