syslog & journaldTurn System Logs into queryable tables.
Syslog in either RFC, and the systemd journal once exported. Every line becomes a row carrying the host, the program and the process id — so a question that meant four SSH sessions and grep becomes one statement.
Use the results in Excel, Google Sheets, AI tools and your apps through the Database REST API.
Every connector type is on Free. Start with 2 data sources and 1 agent.
Read, organize and query on your machine.
Read-only queries · outbound connectionSource files stay in place. Your tools receive query results.
Query Streams turns syslog files into live SQL tables readable from Microsoft Excel, Google Sheets, AI assistants over MCP, the REST API and Power BI. Both syslog RFCs are covered, as is the systemd journal once you have exported it to text, and each row carries the host it came from, the program that wrote it and the process id. Point the connector at a folder collecting logs from many machines and one query answers for all of them - no central log server to run, no per-gigabyte ingest bill, and nothing uploaded beyond the result of the query.
- Both syslog RFCs
- Host, program and pid as columns
- No central log server needed
Connect System Logs with the right settings.
Keep the connection on the Network Agent. These are the details specific to System Logs.
- Folder
- A machine's log directory, or a folder logs are collected to - local disk or a network share typed as \\server\share (never a mapped drive letter; on Linux or a Mac, mounted first); subfolders included
- Formats
- Syslog in both RFCs, and the systemd journal once exported to text
- Year handling
- Taken from the line, or inferred from the file's modified time or its filename - chosen once, not guessed per row
- Rotation
- Ten named rotation patterns plus plain unrotated files; compressed archives are read in place
- Unmatched lines
- Kept verbatim in events_raw_lines, never dropped
- Credentials
- None - there is no server; the agent reads the files in place
- SQL dialect
- DuckDB - standard SQL, nothing syslog-specific to learn
Reading the live Windows Event Log is a different problem - a structured channel rather than a folder of lines - and belongs to a separate connector. But if you already export those events to text or CSV on a schedule, that folder is readable today: describe the layout once with the Custom Logs connector and the exports become a table like anything else here.
Built for how System Logs works.
What comes out
- One row per line, with the timestamp, host, program, process id and message as real columns rather than one string to pick apart later.
- Both syslog RFCs are covered - the older BSD-style format and the newer structured one - so a mixed estate is still one table.
- The systemd journal is supported once exported to text; the journal's own binary format is a database rather than a log file, so it is exported first.
- _source_file names the file each row came from, which is what makes a folder collecting fifty machines answer as one table.
-- Noisiest programs, by host, at warning and above
SELECT host, program, COUNT(*) AS lines
FROM fileset.events
WHERE severity <= 4
GROUP BY host, program
ORDER BY lines DESCSyslog dates and the missing year
The older syslog format writes the month and day but not the year, which is how a January log ends up looking like it happened eleven months in the future. The log driver resolves that deliberately rather than assuming: the year can be taken from the line where the format carries it, or inferred from the file's modified time or its filename. You choose which, once.
The formats and behavior, in detail.
Open the reference you need for System Logs.
A folder of system logs becomes one table.
A folder of system logs becomes one table.
Query Streams reads the files rsyslog, syslog-ng or systemd already wrote, pins the format, and gives you typed columns with the host named beside every row. No collector to run, no index to maintain, no second copy of the data — and a line the parser cannot read is kept as a row with a reason rather than silently dropped.
syslogRFC 3164auth.log.2.gzrotated
journal.exportjournaldRotations, compressed archives and re-read files — handled
SELECT host,
program,
count(*) AS lines
FROM fileset.events
WHERE message LIKE '%error%'
GROUP BY host, program
ORDER BY lines DESCFour servers in one result, because host is a column
Illustrative figures — the shape of the answer, not a benchmark
Two RFCs and the journal
Two RFCs and the journal
Each card names the exact files Query Streams reads and where they live. You do not reconfigure rsyslog to make this work — whichever format your server already writes is the one to pick.
Supported system logs
3 formats
SyslogRFC 3164, the BSD file format
- The default on most Linux servers —
Mon DD HH:MM:SS host program[pid]: message - Host, program and process id become their own columns
/var/log/syslog,auth.log,kern.log—messageson RHEL- The periodic
-- MARK --filler is dropped by declaration, not by a filter you write - Appends; dated and numbered rotations and
.gzfollowed
SyslogRFC 5424, the structured one
- The modern format — a real ISO 8601 stamp, so no year to guess
- Priority, app, process id and message id each get a column
- The structured-data block is kept whole rather than flattened away
- The RFC’s nil value is read as null, not as the text
- - Built to the RFC, not yet proven against a real capture
systemd journaljournalctl -o export
- Files you made with
journalctl -o export - Microsecond timestamps, so ordering survives a busy second
- The unit and the transport come through as columns, not as text
- Every other journal field is kept in
datarather than discarded - One entry per record, however many lines it spans
New system log formats are added with each Agent release. Because Agents keep themselves up to date, a format added later shows up in your connector without anyone touching a server.
One query, every machine you run
One query, every machine you run
System logs are the case this was built for. Every row carries the host that wrote it, so a folder collected from four servers already answers questions across all four — and each site you add runs a Network Agent that reads the files where they are and dials out to Query Streams. As far as your firewall is concerned that is an ordinary outbound connection, so there is nothing to open and no VPN to build.
/var/log/syslog
dials out
Three outbound connections, one place to query them — no inbound port, no VPN, no firewall change
One Agent per location
An Agent covers a whole site rather than a single server, and a folder tree collected from many hosts is one connector — every row already carries its host. The Free plan runs a single Agent and paid plans run more.
1 site = 1 Agent = many hosts
Nothing to open
The Agent makes one encrypted outbound connection, and the request out and the rows back both travel over it. No inbound port, no VPN, no firewall change to go and ask for — and no collector daemon added to a server that is already running one.
one connection, both directions
One query across regions
Every source in a federated query names its own Agent, so a single statement can put one region’s auth log beside another’s — or beside the application database that says which of those logins mattered. Included on Business and Enterprise.
2 regions → 1 result set
They keep themselves current
Agents update themselves, so a log format added in a later release reaches every server without anyone doing a round of SSH. That is what makes the wall above a starting point rather than a fixed list.
new formats arrive with the Agent
The year, the timezone and the bytes
The year, the timezone and the bytes
Syslog is one of the oldest formats still in daily use, and it shows. Four things routinely go wrong when you try to treat one as data, and each is handled here by declaration rather than by guesswork.
The line has no year
An RFC 3164 stamp is Sep 10 04:11:07 — month, day, time, and nothing else. Read naively that puts every archived line in the current year. Query Streams infers the year from the file’s own modification time instead, so a rotation from December still lands in December.
Sep 10 04:11:07 → year from the file
And no timezone either
The old format carries no offset, so a stamp is only meaningful next to the machine that wrote it. It is read as the Agent’s local time and the raw text is kept beside it. RFC 5424 and the journal both carry real UTC, and are treated as such.
RFC 3164 local · RFC 5424 and journald UTC
Binary values in a text file
The journal export format writes any value containing a newline as a name, a byte length, then the raw bytes. Query Streams reads those by their declared length rather than by looking for the end — so a message with a newline in it stays one entry instead of becoming several.
read by length, never by content
Nothing counted twice
Each file is fingerprinted by its first 4 KB, so a rotated file is recognised as the same file rather than read again from the top. A rolling duplicate window catches the overlap when a writer replays its tail.
4 KB prefix hash · 20,000-record window
The columns you actually get
The columns you actually get
Not a blob of text with a timestamp beside it. Each format is parsed into typed columns you can filter, group and aggregate on directly — and the newer the format, the more of them there are.
Every row also carries event_time, the raw stamp it was read from, and the file it came from. All three formats share one identity column — host — which is what lets a single query span every server in the folder: the two syslog formats take it from the line, the journal from its own _HOSTNAME field. Everything lands in one table, fileset.events.
What this deliberately does not do
What this deliberately does not do
Say the biggest one first: system logs contain personal data. auth.log records usernames and the IP addresses they connected from; a program that logs an email address puts it in the message text. Whatever is in the file is what lands in the column — there is no header map to exclude fields the way there is for a web server log. Treat the resulting table with exactly the care you would treat the file, and think about who you share a query with.
It is not a live tail. Query Streams reads the files as they are on disk when you run the query, so a failing service shows up as rows rather than as a stream you watch. If you need sub-second alerting on a line as it is printed, a log pipeline is the right tool for that job.
We do not read the binary journal. The systemd profile reads files written by journalctl -o export, not /var/log/journal directly — so exporting is a step you schedule, not something that happens by itself.
Three things are written to the specification rather than proven against a real file, and they are worth naming: the whole RFC 5424 profile, the ISO-8601 stamp variant that rsyslog and syslog-ng can write instead of the classic one, and the handling of a journal value that spans several lines. All three are covered by tests. None has met a real capture yet.
Finally, the family is called System logs but today it means Linux and Unix. There is no Windows Event Log profile and no macOS log show profile, and we would rather say that than let the name imply them. The rest follows the usual design: the Agent connects outbound and reads files, nothing is installed on the server, nothing is written back, and access is read-only. The retention field starts at 60 days for this preset and is yours to change.
From connection to useful results.
- Install the Network Agent where it can see the logs - one machine's /var/log, or the folder your existing collection already writes to.
- Point the connector at that folder and pick the profile. Both syslog RFCs ship, and so does the systemd journal's exported text form.
- The profile pins the layout, so host, program, process id and message arrive as named columns on the first sync.
- Rotation is understood, including the compressed archives, and only new bytes are read on each sync.
- Query it. One host or fifty, grouped by program, filtered by severity - ordinary SQL instead of ssh and grep.
Put your System Logs results to work.
One connection serves your spreadsheets, apps and AI tools. Share permission to run a saved query; recipients see the allowed results, with the SQL and source login hidden.
For your team, vendors and partners
Pull live System Logs results straight into a worksheet and refresh them on demand — desktop Excel, Excel Online, Microsoft 365.
Explore ExcelRun a saved System Logs query from the sidebar and drop the rows into the sheet. Shared collaborators can refresh it themselves.
Explore Google SheetsAsk a question in plain English. Nova already knows your System Logs tables, writes and runs the SQL, explains the answer and charts it — no query to write, no credentials to hand over.
How Nova worksShare a live System Logs result with anyone — a colleague, a vendor, a partner — as a bookmarkable grid that re-runs fresh when opened, on a phone, a tablet or a desktop. They see the results, never the SQL or the files.
How the Data Viewer worksFor apps and systems
Publish a System Logs query as an authenticated JSON endpoint any application can call, with an OpenAPI 3.1 spec and ready-made Postman, Insomnia and Hoppscotch collections. No database port is opened.
Explore REST APIPaste the generated Power Query M into the Power BI Advanced Editor and the report reads live System Logs results over HTTPS — no ODBC driver, no database port opened.
Explore Power BISync System Logs rows into an Airtable base on a schedule, or fetch them inside an Airtable automation script.
Explore AirtableFeed a Baserow table from System Logs over the REST endpoint — self-hosted or Baserow cloud.
Explore BaserowKeep a SeaTable base current with System Logs data without exporting a file or exposing the database.
Explore SeaTablePush System Logs results into a Smartsheet grid so plans and reports read from the source system, not last week's export.
Explore SmartsheetBack an Anvil Python app with System Logs through the REST endpoint instead of embedding database credentials in the app.
Explore AnvilFor AI tools
Give an AI assistant read-only access to System Logs with the schema it needs to write correct SQL — no credentials in the chat.
Explore MCPDelivered to people
Put a System Logs query on a schedule and have the rows delivered to Slack, Discord, email or a signed webhook — or hold the message until a row count, threshold or percentage change crosses the line you set.
How alerts and reports workJoin System Logs to the rest of your data.
Bring databases, business APIs, files and logs into one read-only query. Every connector supports Federated Queries.
Name the connections and tables. Query Streams handles the source queries and combines the results.
Explore Federated Queries-- nothing copied, nothing merged, nothing scheduled
SELECT c.region, COUNT(*) AS orders, SUM(i.amount_due) AS invoiced
FROM syslogfiles.fileset.orders1 f
JOIN pg_crm.public.customers2 c ON c.id = f.customer_id
JOIN billing.stripe.invoices3 i ON i.customer = c.stripe_id
GROUP BY c.region
ORDER BY invoiced DESC;Use your own connection, schema, table and column names.
Shared across the connector family.
Every log connector also gives you
- events — one row per parsed line, with the timestamp, the fields the grammar named, and _source_file naming the file it came from.
- events_raw_lines — lines the grammar did not match, kept verbatim rather than dropped, so a format you did not anticipate is a question you can still answer.
- files_current and files_events — the live inventory and the audit trail: what appeared, what rotated, what vanished, and anything held back, with the filename and the reason.
- Rotation is understood, not worked around — ten named rotation patterns plus plain unrotated files, so yesterday's log and its compressed archive are the same table as today's.
Good to know
- Read-only, enforced — one statement at a time, SELECT and friends only. Your logs are never written, moved, rotated or truncated by us.
- Nothing is uploaded — lines are parsed and cached, encrypted, on your own machine beside the agent. Only the result of a query leaves your network.
- Only new bytes are read — the agent resumes where it left off in each file rather than re-reading it, so a busy log does not cost more every day.
- The SQL dialect is DuckDB — the same SQL you would write against any other connector.
Explore related connectors.
File System
CSV Folder
Parquet Folder
Excel Folder
SQLite Folder
JSONL Folder
Multi-record CSV
Machine LogsQuestions about System Logs
Where can I use System Logs query results?
Use System Logs results in Excel, Google Sheets, the Data Viewer, your apps through the Database REST API, and AI tools through MCP or Nova. Saved results also feed supported Automation destinations, reports and alerts. Destination availability and allowances depend on your plan.
Do I need to open an inbound port for System Logs?
No. Install the Network Agent on a machine that can reach System Logs. The agent connects outward to Query Streams; no inbound port or VPN is needed. Your source must still allow the agent machine to connect under its own access rules.
Are my System Logs files uploaded?
The Network Agent reads files where they are and keeps its cache on the agent machine. Source files are not uploaded, moved or rewritten. Only requested query results leave your network over the outbound encrypted connection.
What do I need to connect System Logs?
Folder: A machine's log directory, or a folder logs are collected to - local disk or a network share typed as \\server\share (never a mapped drive letter; on Linux or a Mac, mounted first); subfolders included. Formats: Syslog in both RFCs, and the systemd journal once exported to text. Year handling: Taken from the line, or inferred from the file's modified time or its filename - chosen once, not guessed per row. Rotation: Ten named rotation patterns plus plain unrotated files; compressed archives are read in place
Can I join System Logs to other connected sources?
Yes. Federated Queries support every connector type, including databases, business APIs, files and logs. Name the connections and tables in one read-only query. Query Streams translates the source portions as needed and combines their results. See how Federated Queries work.
Which format do I have?
Look at the start of a line in /var/log/syslog or /var/log/messages. If it begins with a three-letter month — Sep 10 04:11:07 — that is RFC 3164, and it is what most Linux servers still write by default. If it begins with a number in angle brackets followed by a full ISO 8601 timestamp, that is RFC 5424.
You do not have to be sure before you start. Test connection reports which profile it recognised and how much of the file matched, so the answer comes from your actual files rather than from a guess.
Do I have to reconfigure rsyslog or syslog-ng?
No. Both formats are supported, so whichever your server already writes is the one to pick — and the classic default is the format with the most testing behind it.
The one change worth considering is unrelated to the format: if you already forward logs from several machines to one collector, point the Agent at that collector’s folder and you get every host in a single connector, because each row carries the host it came from.
How do you handle the missing year in an old syslog line?
The year is taken from the file’s modification time. A rotated archive last written in December is read as December, rather than every line being dropped into the current year the way a naive parser would.
The limit is worth knowing: if a file’s timestamps have been flattened — restored from a backup that did not preserve them, or copied in a way that reset them — the inference works from what the filesystem says. The original text is always kept beside the parsed value, so you can see what was actually on the line.
Can you read the systemd journal directly?
No, and this is the setup step people miss. The journal on disk is a binary database, and Query Streams does not open it. What it reads is the export format: journalctl -o export > journal.export, in any folder the Agent can read.
In practice that means a small scheduled job on the server — a timer or a cron entry that writes the export somewhere the Agent already looks. Everything after that is automatic, and gzipped exports are read too.
What about Windows Event Log or macOS?
Neither has a profile here. The three formats on this page are Linux and Unix, and we would rather name that gap than let the words “system logs” imply coverage that is not there.
There is a route for the Windows case, though. Reading the live Event Log is a different problem from reading a text file — it is a structured channel rather than a folder of lines — and it belongs to a separate connector rather than this one. But if you already export those events to text or CSV on a schedule, that folder is readable today: describe the layout once with a custom log connector and the exports become a table like anything else on this page.
My logs have usernames and IP addresses in them. Should I worry?
Yes, and it is worth thinking about before you share a query rather than after. auth.log is a record of who connected from where, which is personal data in most jurisdictions, and a syslog message is freeform text that can contain anything a program chose to print.
Query Streams does not change what is in the file, so the honest framing is that the table inherits the file’s sensitivity. Two things help: a saved query shares a result, not the connection, so a recipient never gets the whole log; and filters let you narrow a query to the programs someone actually needs before you share it with them.
I collect logs from many servers into one folder. Does that work?
That is the case this is best at. All three formats carry the host as a column — the two syslog formats read it out of the line, and the journal export takes it from its own hostname field — so a folder collected from forty machines is one connector, and grouping by host is an ordinary GROUP BY.
Servers in different buildings or regions work too. Each location runs its own Agent, and a federated query can read across them in a single statement on Business and Enterprise plans.
What about a line the parser cannot read?
It is kept, not dropped. A line that does not match the pinned format is retained as a raw row with a reason attached, so a malformed entry or an unexpected format change shows up as something you can see and query rather than as a silent gap in your numbers.
The same applies to a journal value the format marks as binary: it is parked beside its entry with a reason rather than being guessed at, and the entry itself stays whole.
Put System Logs where the work happens.
Start with Free: every connector type, 2 data sources and 1 Network Agent. Add plan allowances as your needs grow.
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish