JSON 和应用程序日志将 Application Logs 转换为可查询的表。
来自 ECS、Serilog、pino 或 Bunyan 的 JSON 行，以及纯时间戳 [LEVEL] logger: message 文本——堆栈跟踪仍会附在触发它的那一行，而不是散落在四十个毫无用处的行中。
通过 Database REST API，在 Excel、Google Sheets、AI 工具和您的应用中使用结果。
所有连接器类型均包含在 Free 套餐中。可从 2 个数据源和 1 个代理开始使用。
Query Streams 将应用程序日志转换为实时 SQL 表，可通过 Microsoft Excel、Google Sheets、MCP 上的 AI 助手、REST API 和 Power BI 读取。结构化 JSON 行（ECS、Serilog、pino、Bunyan）会作为带类型的列导入；纯文本日志则按语法解析。关键区别在于多行处理：堆栈跟踪归属于触发它的那一行，日志驱动程序会将其保留在那里，而不会把一个异常拆成四十条无关行。在 Debian 和 Ubuntu 上，dpkg 和 apt 日志也受支持，因此可以将设备上的变更与应用程序对此的记录一并查询。
- 堆栈跟踪保留在同一行
- ECS、Serilog、pino 和 Bunyan
- 也支持 dpkg 和 apt
使用正确的设置连接 Application Logs。
在 Network Agent 上保持连接。以下是 Application Logs 专属的详细信息。
- 文件夹
- 应用程序的日志目录，或收集日志的文件夹——本地磁盘或以 \\server\share 格式指定的网络共享（不要使用映射的驱动器号；在 Linux 或 Mac 上，需先挂载）
- 格式
- 来自结构化日志记录器的 JSON 行，以及纯时间戳 [LEVEL] logger: message 文本；此外还支持 Debian 和 Ubuntu 上的 dpkg 和 apt
- 多行
- 一条记录在下一个时间戳开始处结束，因此堆栈跟踪和缩进的续行会保留在触发它们的那条记录中
- 轮转
- 支持十种命名轮转模式以及未轮转的普通文件；直接读取压缩归档
- 无法匹配的行
- 原样保存在 events_raw_lines 中，绝不丢弃
- 凭据
- 无需服务器——代理直接读取原位置的文件
- SQL方言
- DuckDB——标准 SQL，无需学习日志记录器专用语法
如果你的日志记录器使用的格式不符合这些配置中的任何一种（内部开发的应用程序经常如此），只需使用 Custom Logs 连接器描述一次，它就会成为同类表格。此页面其余内容都不变；只有列名的来源不同。
专为 Application Logs 的工作方式打造。
堆栈跟踪始终附在原记录上
四十行的堆栈跟踪是一条事件，而不是四十条。所有逐行记录的解析器默认都会处理错误，导致异常文本和触发异常的消息落在不同的行中，彼此毫无关联。
- 记录边界是格式的一部分，因此记录在下一个时间戳开始处结束，而不是在下一个换行符处结束。
- 整段跟踪都会保留在触发它的那条记录中，因此按类型对异常分组只需使用 GROUP BY，无需手动重建数据。
- 结构化日志记录器会保留其字段——level、logger、message 以及 JSON 中的其他内容都会作为列导入，而不是合并成一大段文本。
- 不符合任何语法的行会原样保存在 events_raw_lines 中，因此来自你未预料到的库的日志行不会被悄悄丢弃。
-- 哪些日志记录器在报错，报错频率如何
SELECT logger, level, COUNT(*) AS events
FROM fileset.events
WHERE level IN ('ERROR','FATAL')
GROUP BY logger, level
ORDER BY events DESC以及设备上发生了哪些变更
在 Debian 和 Ubuntu 上，dpkg 和 apt 日志会记录每个软件包的安装、升级或移除操作及其时间戳。这里提供这些日志的配置，是因为它们能回答大多数事故发生后都会追问的问题：应用程序在四点开始出故障——在此之前这台机器上发生了什么变化？
格式与行为详解。
查看 Application Logs 所需的参考文档。
您的日志文件夹将变成一个表格，您可以按表格进行分组。
您的日志文件夹将变成一个表格，您可以按表格进行分组。
不是 grep，也不是日志技术栈。Query Streams 读取应用程序已有的日志文件，固定其格式，并提供带类型的列——因此，“本周哪个日志记录器产生的错误最多”只需一次查询，而不是耗费一整个下午。解析器无法读取的行会连同原因一起保留为记录，而不会被悄悄丢弃。
shopfront-api/app.jsonlJSON
店面工作人员/应用程序日志文本
历史日志易于轮转、压缩归档和重新读取的文件——均已妥善处理
选择 应用程序、日志记录器、
数数(*) AS 错误
从 文件集.事件
地点 级别 = '错误'
GROUP BY 应用程序，日志记录器
ORDER BY 错误 DESC在同一查询中将其连接到您的应用程序数据库
你的应用已经写入的文件，现在可以生成一个表格，用于生成报告。
你的应用会写入两种形状，盒子也会写入两种形状。
你的应用会写入两种形状，盒子也会写入两种形状。
每张卡片都会列出 Query Streams 读取的确切文件，以及你能从中获取什么。无需采用某种日志库，也无需更改格式即可使用——这里支持的都是这些工具默认生成的格式。
支持的应用程序日志
4 种格式
JSON 行ECS、Serilog 紧凑型、pino、Bunyan
- 每行一个 JSON 对象
.jsonl,.ndjson或*-json.log - ECS 字段名称会直接映射——
日志级别,主机名,服务名称 - Serilog compact、pino 和 Bunyan 也读过：相同的键，不同的拼写
- 嵌套对象会扁平化为虚线列；任何未映射的内容都会落在空白处。
数据 - 附录；日期轮换和
.gz随后
文本日志时间戳、级别、日志记录器、消息
- 默认形状：图章、括号内的级别、日志记录器、消息
- 堆栈跟踪会与触发它的行合并——一行，而不是四十行
在……处,原因：和回溯全部内容读作续篇- 阅读
。日志,。出去和。TXT; JSON 文件已通过声明排除在外。 - 毫秒可用逗号或句点表示；本地时间按 Agent 的本地时钟读取
dpkg软件包日志
- 每个包装步骤一行：
安装,升级,消除,配置 包裹,版本和新版本作为他们自己的专栏状态行携带状态 dpkg 将包裹移至/var/log/dpkg.log及其编号.gz旋转- 文件中没有时区；按 Agent 的本地时钟读取
易于历史记录
- 一
键：值每个交易一个区块，区块之间留空行 - 确切的
命令行那次运行，以及它改变了什么。 开始日期是事件发生时间；结束日期它有自己的专栏。- 未完成的交易会等待一段时间，而不是被拆分成两部分。
/var/log/apt/history.log加上它的.gz旋转
每次发布代理程序版本时，都会添加新的应用程序和软件包日志格式。由于代理程序会自行更新，因此后续添加的格式无需任何人修改服务器即可出现在连接器中。
在应用程序运行的位置读取来自各个区域的应用程序日志
来自各个区域的应用程序日志， 看看它运行在哪里
一个应用很少只运行在一台服务器上。API 位于一个云区域，工作进程位于另一个区域，还有一些服务仍运行在办公室的机器上。每个位置都会运行一个 Network Agent，在日志文件所在的位置读取这些文件，并向 Query Streams 发起连接。从防火墙的角度来看，这只是普通的出站连接——无需开放端口、无需搭建 VPN，也无需在应用中添加日志库。
三个出站连接，一个查询入口——无需入站端口、VPN 或更改防火墙
每个地点一名代理人
一个 Agent 覆盖的是整个位置，而不是单个日志：该站点上的 JSON 行日志、文本日志和软件包历史记录，都会在同一个 Agent 上分别成为自己的 File Set 连接器。Free 计划可运行一个 Agent，付费计划则可运行更多。
1 个位置 = 1 个代理 = 多个连接器
无需打开
Agent 会建立一个加密的出站连接，请求和返回的数据行都通过该连接传输。无需入站端口、无需 VPN、无需申请更改防火墙，也无需在应用中添加任何内容即可运行。
一个连接，双向
跨区域的一次查询
每个来源 联合查询 为自己的 Agent 命名，因此一条语句就能将一个区域中 API 的错误与另一个区域中的工作进程并列查询，也可以与说明问题何时开始的软件包历史记录并列查询。Business 和 Enterprise 计划包含此功能。
2 个区域 → 1 个结果集
他们不断更新自己。
代理程序会自动更新，因此后续版本中添加的日志格式无需您自行部署即可覆盖所有位置。正因如此，上面的列表只是一个起点，而非固定不变的清单。
代理人带来了新的格式。
堆栈跟踪、时钟和类似物
堆栈跟踪、时钟和类似物
应用程序日志是服务器上最混乱的文件：一个事件可能跨越四十行，两种不相关的格式可能看起来完全相同，而且其中一半的文件根本没有时区信息。所有这些问题都通过声明而非猜测来处理。
一次活动，而非四十行
不以时间戳开头的行属于其上一行。这样，堆栈跟踪就能始终与引发它的消息保持关联，而不是分裂成数十个彼此独立的片段。 GROUP BY 可以重新组装起来。
续行 → 合并，最多 200 行
两根看起来很像的木头
应用程序的一行 JSON、Docker 封装记录以及 Web 服务器的一行 JSON 访问日志，都属于“包含时间戳的 JSON”。格式取决于该行的内容，因此每种格式都会匹配自己的配置文件，而不是根据文件名进行分支判断。
决定因素是内容，而不是文件名。
一个没有时区的时钟
文本日志、dpkg 和 apt 都会写入主机的本地时间，但不附带时区偏移。与其猜测，不如由这些配置文件声明时间戳为本地时间，并按 Agent 的时区解析——无论如何，原始字符串都会保留在单独的列中。
本地时钟 → 明确声明，绝不推断
交易仍在进行中
apt 会立即写入升级的开始信息，而只有在 dpkg 完成后才会写入结束信息，这可能需要几分钟时间。尚未关闭的代码块会一直等待，而不是被截断并显示为一个没有开头的事件。
等待结束日期，最多 30 分钟
- 事件时间
- 2026-09-08 14:02:11.431
- 等级
- 错误
- 日志记录器
- 支付客户端
- 信息
- 扣款失败 ↵ java.net.SocketTimeoutException: 读取超时 ↵ 位于……
你实际得到的列
你实际得到的列
它不是一团旁边带着时间戳的文本。每种格式都会解析为类型明确的列，可直接用于筛选、分组和聚合；如果应用程序日志采用结构化 JSON，其中的字段也会展开为列。
每一行也都承载着 事件时间读取日志所用的原始时间戳，以及日志来源的文件。您的应用程序日志由以下信息标识： 应用程序 以及两个软件包日志 主持人 — 两者都取自文件所在的文件夹，因此按服务或机器分别建文件夹，就能得到可供分组的清晰列。文本日志采用三列设计是有意为之：自由格式消息并不总能可靠地包含某些字段，因此我们不猜测字段，而是完整保留消息及其中的堆栈跟踪。
它刻意不做的事情
它刻意不做的事情
它不是实时日志流。查询流会在您运行查询时读取磁盘上的文件，因此错误峰值会以行的形式显示，而不是以您可以监控的流的形式显示。如果您需要在打印日志行时立即发出亚秒级警报，日志管道才是合适的工具，我们会这样建议。
应用程序日志包含应用程序打印的所有内容，这一点值得明确说明：如果日志中记录了令牌、客户电子邮件地址或完整请求正文，这些字符串已经存在于文件中，也会出现在列中。与 Web 服务器日志不同，这里没有字段映射可用于排除这些内容。请像保护文件一样谨慎处理生成的表。
软件包日志记录的部分内容是通过形状识别的，而不是通过捕获来验证的。dpkg 文档中记录了配置文件中的一行，并且 清除 和 消失 行动；合适的文件 请求人, 错误, 清除, 重新安装 和 降级。这些内容在构建这些配置文件时参考的日志中都没有出现，因此只是作了声明，并未经过验证——而且这两种软件包日志都不支持基于 RPM 的发行版或 Windows。
与其说是限制，不如说是一个设置细节：标识列取自文件所在的子文件夹，该子文件夹位于您指向的文件夹之下。将连接器指向一个目录，该目录包含每个服务或每台机器一个子文件夹，您就能轻松获得有用的名称；如果直接指向一个包含零散文件的目录，则每一行都将以该目录命名。设置时只需花费三十秒即可完成。
其余部分遵循常规设计。代理程序连接外部网络并读取文件；不会在应用程序旁边安装任何内容，不会写回任何内容，不会附加或检测任何进程，并且访问权限为只读。
从连接到获取有用结果。
- 在能够访问应用程序日志文件夹的位置安装 Network Agent——例如应用服务器、容器主机，或收集日志的共享位置。
- 将连接器指向该位置并选择配置文件：结构化日志记录器使用 JSON 行格式；对于时间戳 [LEVEL] 记录器：消息布局，则使用纯文本配置文件。
- 多行记录由记录边界处理，而不是靠运气——新记录从时间戳开始的位置起始，因此缩进的堆栈跟踪会与其所属的日志行保持在一起。
- 每次同步只读取新增字节，并会跟踪日志轮转，因此即使服务日志量很大，日常成本也不会增加。
- 对日志运行查询。按记录器统计错误率、按类型分组异常，或跨服务追踪同一个请求 ID。
让 Application Logs 查询结果发挥更大作用。
一个连接即可供您的电子表格、应用和 AI 工具使用。授予他人运行已保存查询的权限；接收者只能看到获准的结果，SQL 和数据源登录信息均会隐藏。
为您的团队、供应商和合作伙伴
将实时 Application Logs 查询结果直接载入工作表，并按需刷新——支持桌面版 Excel、Excel Online 和 Microsoft 365。
了解 Excel从侧边栏运行已保存的 Application Logs 查询，并将数据行插入表格。共享协作者也可以自行刷新。
了解 Google Sheets用日常语言提出问题。Nova 已了解你的 Application Logs 表，会编写并运行 SQL、解释答案并生成图表——无需编写查询，也无需提供凭据。
Nova 的工作原理与任何人分享实时 Application Logs 查询结果——同事、供应商或合作伙伴都可以——以可加入书签的网格形式呈现，打开时会重新获取最新数据，支持手机、平板和桌面设备。他们只能看到结果，不会看到 SQL 或文件。
数据查看器的工作原理对于应用程序和系统
将 Application Logs 查询发布为经过身份验证的 JSON 端点，供任何应用程序调用，并提供 OpenAPI 3.1 规范以及现成的 Postman、Insomnia 和 Hoppscotch 集合。无需开放数据库端口。
了解 REST API将生成的 Power Query M 粘贴到 Power BI 高级编辑器中，报表即可通过 HTTPS 读取实时 Application Logs 查询结果——无需 ODBC 驱动程序，也无需开放数据库端口。
了解 Power BI按计划将 Application Logs 数据行同步到 Airtable 数据库，或在 Airtable 自动化脚本中获取数据。
了解 Airtable通过 REST 端点将 Application Logs 数据导入 Baserow 表——自托管或使用 Baserow 云服务均可。
了解 Baserow使用 Application Logs 数据保持 SeaTable 数据库内容最新，无需导出文件或公开数据库。
了解 SeaTable将 Application Logs 查询结果推送到 Smartsheet 网格，让计划和报告直接读取源系统中的数据，而不是上周导出的文件。
了解 Smartsheet通过 REST 端点为 Anvil Python 应用提供 Application Logs 数据，而不是将数据库凭据嵌入应用中。
了解 Anvil人工智能工具
向 AI 助手授予 Application Logs 的只读访问权限，并提供编写正确 SQL 所需的架构信息——无需在聊天中提供凭据。
探索 MCP已送达
按计划运行 Application Logs 查询，并将数据行发送到 Slack、Discord、电子邮件或签名 Webhook——也可以等到行数、阈值或百分比变化超过你设定的界限后，再发送消息。
警报和报告的工作原理将 Application Logs 与其他数据源联接。
将数据库、业务 API、文件和日志纳入一个只读查询。所有连接器都支持联合查询。
指定连接和表名。Query Streams 会处理各数据源的查询并合并结果。
了解联合查询——没有任何复制、合并或安排操作。
选择 c.region，COUNT(*) AS orders，SUM(i.amount_due) AS invoiced
从 应用程序日志.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 相同。
探索相关连接器。
文件系统
CSV文件夹
镶木地板文件夹
Excel文件夹
SQLite文件夹
JSONL文件夹
多记录 CSV
机器日志关于应用程序日志的问题
Application Logs 查询结果可以在哪里使用？
你可以在 Excel、Google Sheets 和 Data Viewer 中使用 Application Logs 结果；也可以通过 Database REST API 在应用中使用，或通过 MCP 或 Nova 在 AI 工具中使用。保存的结果还可以作为受支持的 Automation 目标、报告和警报的数据来源。目标位置的可用性和使用额度取决于你的套餐。
使用 Application Logs 需要开放入站端口吗？
不需要。在能够访问 Application Logs 的计算机上安装 Network Agent 即可。代理会向外连接到 Query Streams；无需开放入站端口，也无需 VPN。你的数据源仍须按照自身的访问规则，允许代理所在计算机连接。
我的 Application Logs 文件会被上传吗？
Network Agent 会在文件原位置读取文件，并将缓存保存在代理所在计算机上。源文件不会被上传、移动或重写。只有请求的查询结果会通过加密的出站连接离开你的网络。
连接 Application Logs 需要什么？
文件夹：应用程序的日志目录，或收集日志的文件夹——可以是本地磁盘，也可以是按 \\server\share 格式填写的网络共享（不能使用映射的驱动器号；在 Linux 或 Mac 上，须先挂载）。格式：结构化日志记录器生成的 JSON 行，以及纯文本时间戳 [LEVEL] 记录器：消息文本；还支持 Debian 和 Ubuntu 上的 dpkg 与 apt。多行记录：记录在下一个时间戳开始处结束，因此堆栈跟踪和缩进行会保留在引发它们的那条记录中。日志轮转：支持十种命名的轮转模式以及未轮转的普通文件；压缩归档会在原位置读取
我可以将 Application Logs 与其他已连接的数据源联接吗？
可以。联合查询支持所有连接器类型，包括数据库、业务 API、文件和日志。在一个只读查询中指定连接和表名即可。Query Streams 会根据需要转换各数据源对应的查询部分，并合并结果。 了解联合查询的工作方式。
我需要使用哪个日志库？
没有特别要求。如果你写入 JSON 行，Elastic Common Schema 字段名称会直接映射；Serilog 的紧凑格式、pino 和 Bunyan 也可以读取，因为它们使用相同的顶层键，只是拼写不同——时间戳会从你的日志行实际携带的常见字段名称中读取。
如果你写的是纯文本，那么普通文本 时间戳 [级别] 日志记录器：消息 shape 本身就是一种受支持的格式。无需采用任何格式，也无需重新配置任何格式。
堆栈跟踪信息究竟会发生什么变化？
它会保留在生成它的错误记录中。记录从以时间戳开头的行开始，之后所有不以时间戳开头的行都会被视为该记录的延续行——这正是 Java、.NET 或 Python 跟踪信息的格式。异常类、 在……处 框架，一个 原因： 链和 Python 回溯 所有标题都被识别为属于上一行。
实际区别在于，统计错误次数只统计错误本身。如果没有统计，一个异常就会使错误总数增加它所打印的帧数，而你真正想读取的信息可能与类名不在同一行。
为什么 dpkg 和 apt 会出现在应用程序日志中？
因为它们能回答你紧接着“这是从什么时候开始出问题的？”之后会问的问题——也就是“发生了什么变化？”。这些是软件包管理器自己的日志，位于同一目录树中，读取方式也相同；它们是错误日志最有用的补充信息。
apt 的历史记录更易于阅读：每笔事务一个区块，其中包含实际运行的确切命令，以及安装、升级或移除的内容。dpkg 日志则更细致，每个软件包操作占一行。结合两者，你就能为某项更改确定日期，而不必试着回忆它是什么时候发生的。
我可以将我的错误与导致这些错误的升级关联起来吗？
是的，但有一点需要注意：连接器只能读取一种格式，因此您的应用程序日志和 /var/log/apt/history.log 这里是两个连接器而不是一个。联合查询会将它们连接成一条语句，这与将日志连接到生产数据库的机制相同。
这正是值得基于这类日志构建的查询——按小时统计错误，并列出当天运行的事务；两者都直接从无需传送到其他地方的文件中读取。
这是实时画面吗？
它是按需读取，而不是流式读取。查询运行时会读取文件的当前内容，因此应用程序写入新行后，文件便会被读取到——这不是固定的夜间计划任务，但也不是实时跟踪。
对于询问过去几周的问题并将答案整理到电子表格或定期报告中，这种方式比堆放原木的方式更实用，而且所需的机械设备也少得多。
我的日志中包含您未列出的字段。这些字段丢失了吗？
不。在 JSON 和 apt 格式中，任何未映射到指定列的内容都会保留在某个位置。 数据 列不会被丢弃，因此您记录的请求 ID、租户或持续时间仍然可以查询。嵌套对象在传入时会被扁平化为带点的名称。
完全不符合指定格式的行也会保留下来——作为附带原因的原始行，这样意外的格式更改就会以可见的形式呈现，而不会让你的统计数据悄然出现缺口。
Red Hat、Fedora 或 Alpine 的软件包历史记录如何？
没有个人资料 未完成, 好吃 或 apk 目前如此，且没有对应的 Windows 版本。这里支持的两种软件包格式是 dpkg 日志和 apt 历史记录，适用于 Debian 和 Ubuntu。
这些都不会影响你自己的应用程序日志——无论它们位于哪个发行版上，JSON 和文本格式都不受影响。如果你不确定自己的某个文件夹会被识别为何种类型，可以使用“测试连接”查看检测结果，再决定是否继续。
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish