Documentation Index
Fetch the complete documentation index at: https://docs.rootprint.io/llms.txt
Use this file to discover all available pages before exploring further.
/var/log/auth.log carries every authentication event a Debian or Ubuntu host produces — SSH attempts, sudo invocations, su, PAM, login. This tutorial sets up Vector as a systemd service that tails the file, parses each line into structured fields (timestamp, severity, source IP, user), and ships the result to Rootprint over OTLP. Records land in otel-logs-v0_9 and become searchable by program, source address, target user, and severity.
Setup
Pick the target index and create an ingest API key
The default index for OTLP traffic is
otel-logs-v0_9 — see Indexes for its
schema. In Settings → API keys, click Create API key, give it a name, pick
otel-logs-v0_9, and choose the Ingest role. The value is shown once — copy it before
clicking Done. API keys are scoped to one index — you cannot reuse one across indexes.Install Vector
Install the Vector package for your platform from the official installation
page. Per-distro instructions (Debian/Ubuntu apt,
RHEL/Fedora dnf, container images) are maintained upstream.
Write the Vector config
Save the following at
/etc/vector/vector.yaml. Replace <your-rootprint> with your Rootprint base
URL and <your-ingest-token> with the API key you copied in step 1.read_from: end skips existing content on first start, so installing Vector against an
existing auth.log does not replay every historical event. Flip it to beginning if you want
a one-time backfill.Restart Vector
active (running) and the most recent log lines should not
contain config-parse or sink-startup errors.Trigger an auth event for the test
The simplest way to write a fresh entry to
auth.log is to force a sudo re-prompt:sudo -k clears the cached credential, and sudo true immediately re-prompts — both write
PAM session records to auth.log.How the parsing works
Tworemap transforms run in sequence. The first, parse_auth, turns each raw syslog line into structured fields. The second, to_otlp, packs those fields into the OTLP wire format that Rootprint’s ingest endpoint expects.
parse_auth runs four extractions:
- Syslog framing — a regex against
.messagepeels offts,hostname,program, and optionalpid, leaving the human-readable text inmsg. The original.messageis replaced with just the message body so downstream queries match against the meaningful part of the line, not the syslog wrapper. - Timestamp —
parse_timestampwith format%+accepts the ISO 8601 timestamps that modern syslog daemons write. If the parse fails,.timestampis left unset andto_otlpfalls back to Vector’s read time. - Severity — the message body is lowercased, then matched against two pattern families. Authentication failure phrases (
failed password,authentication failure,invalid user, brute-force noise) bump the record toWARN(severity 13). Expliciterrororfataltokens push it toERROR(17). Everything else stays atINFO(9). - SSH-specific extractions — three regexes pull out source IP/port and the target username. These only fire on lines that match (for example,
Failed password for root from 1.2.3.4 port 5555); onsudo,su, and PAM lines they leave the fields unset.
to_otlp assembles the OTLP envelope. service.name is derived from the parsed program so SSH events show as service:sshd, sudo as service:sudo, and so on — Rootprint’s service filter will list every auth program separately. Per-event attributes are pushed conditionally inside if exists(...) guards, so the OTLP record never carries empty stringValue attributes for SSH-only fields on a sudo event.
Useful searches
Once Vector has been running for a minute or two against an active host, the parsed fields make these queries possible. Run them in the Rootprint search box againstotel-logs-v0_9.
Everything worth a look — filters out routine session-open/close noise, leaving WARN and ERROR.
sudo invocations — every privilege escalation on the host, success or failure.
sudo, and su. Useful for surfacing brute-force attempts against high-value usernames.
Troubleshooting
permission deniedreading/var/log/auth.log— Vector’svectoruser does not have read access. The cleanest fix on Debian/Ubuntu issudo usermod -aG adm vector(theadmgroup ownsauth.log) followed by a Vector restart. If that’s not available,sudo chmod a+r /var/log/auth.logworks but loosens permissions for every user on the host.- Records arrive but
attributes.process.nameis missing — the syslog regex didn’t match. Most often this means the line is in RFC 5424 format or your daemon emits a non-standard prefix. Inspect the rawbody.messagein Rootprint to see the shape of the line, then adjust the regex in theparse_authtransform. severity_textis alwaysINFOeven for failures — the message-pattern match runs against a lowercased copy, so case is not the issue. Check that the failure phrases your daemon actually writes match one of the alternations in thematch(lower, ...)block; some PAM modules use phrasing the default patterns don’t catch. Add the missing pattern to the alternation.- SSH-specific fields (
source_ip,ssh_user) are missing onsudoor PAM events — by design. Those extractions only fire on SSH log lines. The other fields (process.name,host.name,severity_text) populate for every event. 401,403,415from Rootprint — same response codes as a misconfigured Vector setup of any kind. See Send logs with Vector for full diagnoses.
Related
- Send logs with Vector — general-purpose Vector setup for arbitrary log files.
- OTLP reference — endpoint URL, response codes, body limits.
- Indexes — the
otel-logs-v0_9schema, so you know what you can search.
