36 lines
1.8 KiB
Markdown
36 lines
1.8 KiB
Markdown
# Logging Package Options
|
|
|
|
This agent already uses a library approach for journald (`github.com/coreos/go-systemd/v22/sdjournal`) and does not shell out to `journalctl` in normal collection paths.
|
|
|
|
## Current (keep)
|
|
|
|
- `github.com/coreos/go-systemd/v22/sdjournal`
|
|
- Direct journal access from Go.
|
|
- Cursor-based reads map well to incremental shipping.
|
|
- `github.com/coreos/go-systemd/v22/dbus` (candidate add-on)
|
|
- Read systemd unit state/metadata (`ListUnitsByNames`, unit properties) for richer service context.
|
|
|
|
## Good external collectors (if we want hardened third-party gathering)
|
|
|
|
- Fluent Bit
|
|
- `systemd` input plugin for journald, plus mature filtering/parsing/routing outputs.
|
|
- Strong choice when we want a small footprint daemon dedicated to log forwarding.
|
|
- Vector
|
|
- `journald` source + transforms (VRL) for compact line formatting before shipping.
|
|
- Good if we want expressive local transforms and multiple downstream sinks.
|
|
- OpenTelemetry Collector distributions with journald receiver support (for example Splunk OTel distro)
|
|
- Useful if we want logs + metrics + traces through one pipeline.
|
|
|
|
## Parser packages (when we need deeper line parsing)
|
|
|
|
- `github.com/influxdata/go-syslog/v3`
|
|
- RFC3164/RFC5424 syslog parsing for file or stream logs.
|
|
- `github.com/elastic/go-grok`
|
|
- Pattern-based parsing when message formats vary by service.
|
|
|
|
## Practical direction
|
|
|
|
1. Keep `go-systemd` for now and add optional `dbus` lookups for service status enrichment.
|
|
2. If we need host-agnostic, independently hardened collection, run Fluent Bit or Vector and ingest normalized JSON lines in the agent/server.
|
|
3. Reserve heavier parsing packages (`go-syslog`, `go-grok`) for specific source formats that require structured extraction beyond current compact line ingestion.
|