将 System Logs 转换为可查询的表。
支持两种 RFC 格式的 Syslog,以及导出后的 systemd journal。每一行都会成为一条记录,并包含主机、程序和进程 ID——过去需要打开四个 SSH 会话并使用 grep 才能回答的问题,现在一条语句就能解决。
通过 Database REST API,在 Excel、Google Sheets、AI 工具和您的应用中使用结果。
所有连接器类型均包含在 Free 套餐中。可从 2 个数据源和 1 个代理开始使用。
Query Streams 可将 syslog 文件转换为实时 SQL 表,供 Microsoft Excel、Google Sheets、通过 MCP 接入的 AI 助手、REST API 和 Power BI 读取。支持两种 syslog RFC 格式;systemd journal 只要先导出为文本,也同样支持。每一行都包含来源主机、写入日志的程序以及进程 ID。只需将连接器指向一个收集多台机器日志的文件夹,一条查询就能返回所有机器的数据——无需运行中央日志服务器,无需支付按 GB 计费的摄取费用,也不会上传查询结果以外的任何内容。
- 支持两种 syslog RFC 格式
- 主机、程序和 PID 均为独立列
- 无需中央日志服务器
使用正确的设置连接 System Logs。
通过 Network Agent 保持连接。以下是 System Logs 特有的详细信息。
- 文件夹
- 计算机的日志目录,或用于收集日志的文件夹——本地磁盘或以 \\server\share 格式填写的网络共享(切勿使用映射的驱动器盘符;在 Linux 或 Mac 上,需先挂载);包括子文件夹
- 格式
- 支持两种 RFC 格式的 Syslog,以及导出为文本后的 systemd journal
- 年份处理
- 从日志行中获取,或根据文件的修改时间或文件名推断——一次性选择,而不是逐行猜测
- 轮转
- 支持十种命名轮转模式以及未轮转的普通文件;直接读取压缩归档
- 无法匹配的行
- 原样保存在 events_raw_lines 中,绝不丢弃
- 凭据
- 无需服务器——代理直接读取原位置的文件
- SQL方言
- DuckDB——标准 SQL,无需学习 syslog 专属知识
读取实时 Windows Event Log 是不同的问题——它是结构化通道,而不是由多行文本组成的文件夹——因此应由单独的连接器处理。但如果你已经定期将这些事件导出为文本或 CSV,那么现在就可以读取该文件夹:使用 Custom Logs 连接器描述一次布局,导出的文件就会成为一张表,和这里介绍的其他内容一样。
专为 System Logs 的工作方式打造。
输出内容
- 每行对应一条记录,时间戳、主机、程序、进程 ID 和消息都是独立列,无需之后再从一个字符串中拆解。
- 支持两种 syslog RFC 格式——较旧的 BSD 风格格式和较新的结构化格式——因此即使环境中格式混用,也仍然只需一张表。
- systemd journal 导出为文本后即可使用;journal 自身的二进制格式是数据库,而不是日志文件,因此需要先导出。
- _source_file 标明每一行来自哪个文件,因此收集了五十台机器日志的文件夹也能作为一张表进行查询。
-- 按主机统计警告及以上级别中日志最多的程序
SELECT host, program, COUNT(*) AS lines
FROM fileset.events
WHERE severity <= 4
GROUP BY host, program
ORDER BY lines DESCSyslog 日期与缺失的年份
较旧的 syslog 格式会写入月和日,却不写年份,因此一月份的日志看起来就像发生在未来十一月。日志驱动会有意处理这一问题,而不是擅自假设:如果格式中包含年份,就可以从日志行中获取;也可以根据文件的修改时间或文件名推断。你只需选择一次。
格式与行为详解。
打开所需的 System Logs 参考文档。
一个系统日志文件夹合并成一个表格。
一个系统日志文件夹合并成一个表格。
Query Streams 会读取 rsyslog、syslog-ng 或 systemd 已经写入的文件,固定格式,并提供带类型的列,在每一行旁标明主机名。无需运行采集器,无需维护索引,也无需保留第二份数据——解析器无法读取的日志行也会作为记录保留下来,并注明原因,而不会被悄悄丢弃。
轮转、压缩归档和重新读取的文件——均已妥善处理
选择 主持人、节目、
数数(*) AS 线条
从 文件集.事件
地点 信息 喜欢 '%错误%'
GROUP BY 主持人,节目
ORDER BY 线条 DESC一个结果中包含四台服务器,因为 主持人 是一列
示意数据——展示答案的形式,并非基准测试
两份 RFC 和期刊
两份 RFC 和期刊
每张卡片都会注明 Query Streams 读取的确切文件及其所在位置。无需重新配置 rsyslog 即可使用——选择服务器当前写入的格式即可。
支持的系统日志
3 种格式- 大多数 Linux 服务器上的默认格式——
星期一 日 时:分:秒 主机程序[pid]: 消息 - 主机、程序和进程 ID 会分别成为单独的列。
/var/log/syslog,认证日志,内核日志—消息在 RHEL 上- 周期表
- 标记 -填充词会被声明删除,而不是通过你编写的过滤器删除。 - 附录;标有日期和编号的轮换和
.gz随后
- 现代格式——真正的 ISO 8601 时间戳,无需猜测年份
- 优先级、应用 ID、进程 ID 和消息 ID 各占一列
- 结构化数据块保持完整,而不是被扁平化。
- RFC 中的 nil 值会读取为 null,而不是文本
- - 根据 RFC 标准构建,但尚未经过实战验证。
- 您用以下方式创建的文件
journalctl -o export - 微秒级时间戳,因此即使在繁忙的几秒钟内,订单也能正常处理。
- 单位和运输信息以列的形式显示,而不是以文本的形式显示。
- 其他所有期刊字段都保存在
数据而不是被丢弃。 - 每条记录只有一个条目,无论它跨越多少行。
每次发布代理程序时都会添加新的系统日志格式。由于代理程序会自行更新,因此后续添加的格式无需任何人修改服务器即可出现在连接器中。
一条查询,覆盖您运行的每台机器
一个问题, 你运行的每一台机器
系统日志正是本功能的设计用途。每一行都包含写入它的主机,因此,从四台服务器收集来的文件夹已经可以回答涉及这四台服务器的问题;您添加的每个站点都会运行一个网络代理,在文件所在的位置读取文件,并向 Query Streams 发起连接。对于防火墙来说,这只是普通的出站连接,因此无需开放端口,也无需搭建 VPN。
/var/log/syslog
拨号退出
三个出站连接,一个查询入口——无需入站端口、VPN 或更改防火墙
每个地点一名代理人
一个代理覆盖整个站点,而非单台服务器;从多台主机收集的文件夹树就是一个连接器——每一行都已包含其 主持人。免费计划可运行一个 Agent,付费计划可运行更多。
1 个站点 = 1 个代理 = 多个主机
无需打开
代理只建立一个加密的出站连接,请求和返回的数据行都通过该连接传输。无需入站端口、无需 VPN、无需申请更改防火墙——也无需在已经运行采集程序的服务器上再添加一个采集守护进程。
一个连接,双向
跨区域的一次查询
每个来源 联合查询 每个站点都有自己的代理,因此一条语句就能把一个地区的身份验证日志与另一个地区的日志并列查询,也可以与记录哪些登录重要的应用程序数据库并列查询。Business 和 Enterprise 版本包含此功能。
2 个区域 → 1 个结果集
他们不断更新自己。
代理程序会自动更新,因此后续版本中添加的日志格式无需任何人通过 SSH 连接即可到达所有服务器。正因如此,上面的列表只是一个起点,而非固定不变的清单。
代理人带来了新的格式。
年份、时区和字节
年份、时区和字节
Syslog 是目前仍在日常使用的最古老的格式之一,这一点显而易见。尝试将其作为数据处理时,通常会出现四种错误,而本文通过明确声明而非猜测来解决每一种错误。
该行没有年份
RFC 3164 印章是 9月10日 04:11:07 —只有月、日和时间,没有其他信息。若直接读取,每条归档日志都会被归到当前年份。Query Streams 会根据文件自身的修改时间推断年份,因此,12 月的轮转日志仍会归入 12 月。
Sep 10 04:11:07 → 从文件推断年份
而且也没有时区限制。
旧格式不包含时区偏移量,因此只有结合写入它的机器,时间戳才有意义。系统会将其读取为代理的本地时间,并保留原始文本。RFC 5424 和 journal 都包含真实的 UTC 时间,因此会按 UTC 处理。
RFC 3164 使用本地时间 · RFC 5424 和 journald 使用 UTC
文本文件中的二进制值
journal 导出格式会将任何包含换行符的值写为名称、字节长度,然后是原始字节。Query Streams 会根据声明的长度读取这些值,而不是通过查找结束位置来读取——因此,包含换行符的消息仍会作为一条记录,而不会被拆成多条。
按篇幅阅读,而非按内容阅读
没有任何事会被重复计算。
每个文件都通过其前 4 KB 的数据进行指纹识别,因此即使文件位置发生旋转,系统也会将其识别为同一个文件,而不是从头重新读取。当写入器重放其尾部数据时,滚动重复窗口会捕获重叠部分。
4 KB 前缀哈希 · 20,000 条记录窗口
你实际得到的列
你实际得到的列
它不是旁边带有时间戳的一大块文本。每种格式都会解析为带类型的列,可直接用于筛选、分组和聚合——格式越新,提供的列就越多。
每一行也都承载着 事件时间、读取时的原始时间戳,以及它所属的文件。三种格式共用一个标识列—— 主持人 —这使一条查询可以覆盖文件夹中的所有服务器:两种 syslog 格式从日志行中提取该值,journal 则从其自身的 _HOSTNAME 字段。所有数据都汇总到一个表中。 文件集.事件.
它刻意不做的事情
它刻意不做的事情
先说最重要的一个: 系统日志包含个人数据. 认证日志 记录用户名及其连接所用的 IP 地址;记录电子邮件地址的程序会将其写入消息文本。文件中有什么内容,列中就会有什么内容——不像 Web 服务器日志那样有表头映射可用于排除字段。请像保护文件本身一样谨慎处理生成的表,并考虑与谁共享查询。
它不是实时日志流。查询流会在您运行查询时读取磁盘上的文件,因此,故障服务会以行的形式显示,而不是以您可以监控的流的形式显示。如果您需要对打印的行进行亚秒级告警,日志管道才是合适的工具。
我们不读取二进制日志。systemd配置文件会读取由……写入的文件。 journalctl -o export, 不是 /var/log/journal 直接——因此,导出需要安排执行,而不会自动发生。
规范中有三项内容尚未经过实际文件验证,值得一提:完整的 RFC 5424 规范、rsyslog 和 syslog-ng 可以写入的 ISO-8601 时间戳变体(而非传统时间戳),以及跨多行日志值的处理。这三项内容均已通过测试,但尚未在实际捕获中得到验证。
最后,虽然这个日志系列被称为系统日志,但如今它指的是 Linux 和 Unix 系统。Windows 和 macOS 系统都没有对应的事件日志配置文件。 日志显示 我们更愿意这样描述配置文件,而不是让名称暗示其含义。其余部分遵循常规设计:代理程序连接出站并读取文件,服务器上不安装任何软件,不写回任何内容,且访问权限为只读。此预设的保留期限字段初始值为 60 天,您可以自行更改。
从连接到获取有用结果。
- 在能够访问日志的位置安装 Network Agent——可以是一台机器的 /var/log,也可以是现有采集流程写入的文件夹。
- 将连接器指向该文件夹并选择配置文件。系统内置了两种 syslog RFC 格式,也支持 systemd journal 的导出文本格式。
- 配置文件会固定数据布局,因此首次同步时,主机、程序、进程 ID 和消息就会以命名列的形式呈现。
- 系统能够识别日志轮转,包括压缩归档文件;每次同步只读取新增字节。
- 开始查询。无论一台主机还是五十台,都可以按程序分组、按严重级别筛选——用普通 SQL 代替 ssh 和 grep。
让系统日志查询结果发挥作用。
一个连接即可供您的电子表格、应用和 AI 工具使用。授予他人运行已保存查询的权限;接收者只能看到获准的结果,SQL 和数据源登录信息均会隐藏。
为您的团队、供应商和合作伙伴
将实时系统日志查询结果直接导入工作表,并按需刷新——支持桌面版 Excel、Excel Online 和 Microsoft 365。
了解 Excel从侧边栏运行已保存的系统日志查询,并将数据行插入工作表。共享协作者也可以自行刷新。
了解 Google Sheets用通俗的英语提出问题。Nova 已了解您的系统日志表,会编写并运行 SQL、解释答案并生成图表——无需编写查询,也无需提供凭据。
Nova 的工作原理将实时系统日志查询结果分享给任何人——同事、供应商或合作伙伴——以可添加书签的表格形式呈现。打开时会重新运行查询,手机、平板电脑或桌面设备均可使用。他们只能看到结果,看不到 SQL 或文件。
数据查看器的工作原理对于应用程序和系统
将系统日志查询发布为经过身份验证的 JSON 端点,供任何应用程序调用,并附带 OpenAPI 3.1 规范以及现成的 Postman、Insomnia 和 Hoppscotch 集合。无需开放数据库端口。
了解 REST API将生成的 Power Query M 粘贴到 Power BI 高级编辑器,报表即可通过 HTTPS 读取实时系统日志查询结果——无需 ODBC 驱动程序,也无需开放数据库端口。
了解 Power BI按计划将系统日志数据行同步到 Airtable 数据库,或在 Airtable 自动化脚本中获取这些数据行。
了解 Airtable通过 REST 端点将系统日志数据导入 Baserow 表格——支持自托管版或 Baserow 云端版。
了解 Baserow无需导出文件或暴露数据库,即可让 SeaTable 数据库中的系统日志数据保持最新。
了解 SeaTable将系统日志查询结果推送到 Smartsheet 网格,让计划和报告读取源系统中的数据,而不是上周导出的文件。
了解 Smartsheet通过 REST 端点,让 Anvil Python 应用使用系统日志数据,而不是将数据库凭据嵌入应用中。
了解 Anvil人工智能工具
向 AI 助手提供系统日志的只读访问权限及其编写正确 SQL 所需的架构信息——无需在聊天中提供凭据。
探索 MCP已送达
为 System Logs 查询设置计划,将行数据发送到 Slack、Discord、电子邮件或签名 Webhook;也可以先暂存消息,直到行数、阈值或百分比变化达到你设定的条件。
警报和报告的工作原理将 System Logs 与其余数据联接起来。
将数据库、业务 API、文件和日志纳入一个只读查询。所有连接器都支持联合查询。
指定连接和表名。Query Streams 会处理各数据源的查询并合并结果。
了解联合查询——没有任何复制、合并或安排操作。
选择 c.region,COUNT(*) AS orders,SUM(i.amount_due) AS invoiced
从 syslogfiles.fileset.orders1 f
连接 pg_crm.public.customers2 c ON c.id = f.customer_id
连接 计费.stripe.invoices3 i ON i.customer = c.stripe_id
GROUP BY c.区域
ORDER BY 发票上的描述;请使用您自己的连接、架构、表和列名称。
连接器系列通用功能。
每个日志连接器还会提供
- events——每条解析后的日志行对应一行,包含时间戳、语法定义的字段,以及标明其来源文件的 _source_file。
- events_raw_lines——语法未能匹配的行会原样保留,而不会被丢弃,因此即使遇到意料之外的格式,你仍然可以查询并找到答案。
- files_current 和 files_events——实时文件清单和审计记录:哪些文件出现、哪些发生轮转、哪些消失,以及哪些内容被暂缓处理,并注明文件名和原因。
- 理解轮转,而不是绕过它——支持十种命名轮转模式以及未轮转的普通文件,因此昨天的日志及其压缩归档与今天的日志属于同一张表。
知道这个很有用
- 强制只读——一次只执行一条语句,且仅限 SELECT 等查询。我们绝不会写入、移动、轮转或截断您的日志。
- 不会上传任何内容——日志行在您自己的计算机上、代理旁边进行解析和缓存,并经过加密。只有查询结果会离开您的网络。
- 只读取新增字节——代理会从每个文件上次读取的位置继续,而不会重新读取,因此繁忙的日志不会让成本日复一日增加。
- SQL 方言为 DuckDB — 与您针对任何其他连接器编写的 SQL 相同。
关于 System Logs 的问题
系统日志查询结果可以在哪里使用?
你可以在 Excel、Google Sheets、数据查看器中使用系统日志结果;也可以通过 Database REST API 在自己的应用中使用,或通过 MCP 或 Nova 在 AI 工具中使用。保存的结果还可用于受支持的自动化目标、报告和提醒。目标的可用性及使用额度取决于你的套餐。
使用系统日志需要开放入站端口吗?
不需要。在能够访问系统日志的计算机上安装 Network Agent 即可。该代理会向外连接到 Query Streams;无需开放入站端口,也无需 VPN。你的数据源仍须根据自身访问规则,允许代理所在计算机连接。
我的系统日志文件会被上传吗?
Network Agent 会在文件原位置读取文件,并将缓存保存在代理所在计算机上。源文件不会被上传、移动或重写。只有请求的查询结果会通过加密的出站连接离开你的网络。
连接系统日志需要什么?
文件夹:机器的日志目录,或收集日志的文件夹——可以是本地磁盘,也可以是按 \\server\share 格式填写的网络共享(绝不能使用映射的驱动器号;在 Linux 或 Mac 上,必须先挂载);包括子文件夹。格式:两种 RFC 格式的 Syslog,以及导出为文本后的 systemd journal。年份处理:取自日志行,或根据文件的修改时间或文件名推断——只选择一次,不会逐行猜测。轮转:支持十种命名轮转模式以及未轮转的普通文件;压缩存档可直接读取
我可以将系统日志与其他已连接的数据源联接吗?
可以。联合查询支持所有连接器类型,包括数据库、业务 API、文件和日志。在一个只读查询中指定连接和表名即可。Query Streams 会根据需要转换各数据源对应的查询部分,并合并结果。 了解联合查询的工作方式。
我使用的是哪种格式?
观察一行的开头 /var/log/syslog 或 /var/log/messages。如果它以三字母月份开头 — 9月10日 04:11:07 — 那就是 RFC 3164,也是大多数 Linux 服务器仍默认写入的格式。如果它以尖括号中的数字开头,后面跟着完整的 ISO 8601 时间戳,那就是 RFC 5424。
您无需在开始之前就确定。测试连接会报告它识别出了哪个配置文件以及匹配的文件内容,因此答案来自您的实际文件,而不是猜测。
我需要重新配置rsyslog或syslog-ng吗?
不需要。两种格式都受支持,因此选择服务器当前写入的格式即可——而经典默认格式经过的测试最多。
有一项值得考虑的改动与格式无关:如果你已经将多台机器的日志转发到一个收集器,只需让 Agent 指向该收集器的文件夹,就能在一个连接器中获取所有主机的数据,因为每一行都带有来源主机信息。
如何处理旧系统日志行中缺失的年份?
年份取自文件的修改时间。上次写入时间为 12 月的轮转存档会按 12 月读取,而不是像简单解析器那样把每一行都归入当前年份。
需要了解其限制:如果文件的时间戳已被抹平——例如从未保留时间戳的备份恢复,或以重置时间戳的方式复制——推断结果将依据文件系统报告的信息。原始文本始终与解析后的值一同保留,因此你可以查看日志行中的实际内容。
可以直接读取systemd日志吗?
不,这是人们常常忽略的设置步骤。磁盘上的日志是一个二进制数据库,Query Streams 无法直接打开它。它读取的是导出格式的数据: journalctl -o export > journal.export在任何代理可以读取的文件夹中。
实际操作中,这意味着在服务器上设置一个简单的定时任务——使用计时器或 cron 条目,将导出文件写入 Agent 已在监视的位置。之后的一切都会自动完成,也支持读取 gzip 压缩的导出文件。
Windows 事件日志或 macOS 事件日志呢?
这里没有适用于它们的配置方案。本页介绍的三种格式适用于 Linux 和 Unix;我们宁可明确指出这一缺口,也不愿让“系统日志”一词暗示并不存在的支持范围。
不过,Windows 场景也有可行方案。读取实时 Event Log 与读取文本文件是不同的问题——它是结构化通道,而不是由日志行组成的文件夹——因此应由单独的连接器处理,而非本连接器。但如果你已经定期将这些事件导出为文本或 CSV,那么今天就可以读取该文件夹:只需描述一次布局,并使用 自定义日志 连接器和导出内容会像此页面上的其他内容一样以表格形式显示。
我的日志里有用户名和IP地址。我需要担心吗?
是的,最好在提出问题之前而不是之后考虑这个问题。 认证日志 系统日志记录了谁从哪里连接,这在大多数司法管辖区属于个人数据,而系统日志消息是自由格式文本,可以包含程序选择打印的任何内容。
Query Streams 不会更改文件中的内容,因此准确地说,表会继承文件的敏感级别。有两点可以提供帮助:共享已保存的查询时共享的是结果,而不是连接,因此接收者无法获取完整日志;此外,还可以使用筛选器,将查询范围缩小到对方实际需要的程序,然后再与其共享。
我将多台服务器的日志文件收集到一个文件夹中。这样可以吗?
这正是它最擅长的场景。三种格式都会将主机作为一列——两种 syslog 格式从日志行中读取主机名,journal 导出则从其自身的主机名字段中读取——因此,收集了四十台机器日志的文件夹只需一个连接器,按主机分组也是普通的 GROUP BY.
位于不同建筑物或区域的服务器也能正常工作。每个位置都运行着自己的代理,企业版和高级版套餐可以通过一条语句使用联合查询来读取所有位置的数据。
如果解析器无法读取某一行代码怎么办?
它会被保留,而不是删除。不符合固定格式的行会作为原始行保留,并附带原因说明。因此,格式错误的条目或意外的格式更改会以可见和可查询的形式显示出来,而不是在数据中留下一个无声的空白。
对于格式标记为二进制的日志值,情况也是如此:它会连同原因一起显示在其条目旁边,而不是被猜测,而条目本身则保持完整。

