nginx、Apache、IIS 新
连接 Web服务器日志 到 Excel、Sheets 和 AI
您的访问日志已经是一个表——开始查询它吧。nginx、Apache、Caddy 和 IIS 会将每个请求以一种几十年来一直稳定的格式写入磁盘——但几乎没有人查询它。将查询流指向日志文件夹，这些文件就会变成 SQL 表：状态码、响应时间、客户端 IP、路径、用户代理。轮换和 .gz 包含档案，中间没有日志运输商。
日志文件夹会变成一个可以分组和连接的表格。
查询流读取您的 Web 服务器已写入的文件，固定文件格式，并提供类型化的列。无需在服务器上部署代理，无需构建传输管道，也无需维护索引——解析器无法读取的行会被保留为一行，并附带原因，而不是被默默丢弃。
访问日志球童
访问日志 2.gznginx
u_ex260909.log信息系统轮换、压缩存档和重读文件——已处理
选择 小路，
数数(*) AS 热门歌曲
圆形的(平均值（持续时间秒数）* 1000） AS 多发性硬化症
从 文件集.事件
地点 状态 >= 500
GROUP BY 小路
ORDER BY 点击量 DESC在同一查询中将其连接到您的应用程序数据库
服务器已写入的文件，现在可以生成一个可用于生成报告的表格。
四台服务器，四种格式，无需配置
每张卡片都列出了查询流在该服务器上读取的确切文件及其所在位置。您无需更改日志配置即可实现此功能——默认格式即为受支持的格式。
支持的 Web 服务器日志
4 种格式 · 4 台服务器
nginx访问和错误
访问日志默认组合格式错误日志级别、进程 ID、连接和消息- 通常
/var/log/nginx - 附加；按编号轮次进行。
Apache HTTP 服务器访问
访问日志组合和通用格式- 一个解析器即可同时支持 Apache 和 nginx——访问格式相同。
/var/log/apache2，或httpd在 RHEL 上- 附加；按编号轮次进行。
球童Caddy 2 JSON
访问日志每个请求一个 JSON 对象- 包含 TLS 服务器名称、版本和会话恢复信息
- 响应持续时间精确到微秒
- 滚动到
访问-<时间戳>.log.gz每个成员阅读一次
微软 IISW3C扩展
u_ex*.logW3C 扩展格式- 这
#字段：表头决定列，因此字段选择将遵循表头指示。 C:\inetpub\logs\LogFiles\W3SVC<站点>- 每天生成一个新文件，文件名称不会更改。
每次发布代理程序时，都会添加新的 Web 服务器和代理日志格式。由于代理程序会自行更新，因此即使服务器未发生任何更改，后续添加的格式也会立即出现在您的连接器中。
来自每个边缘的访问日志 看看它们落在哪里
请求并非总是两次到达同一个大陆。您的边缘服务器位于一个区域，源服务器位于另一个区域，而办公室里可能还在运行着一些较旧的设备。每个位置都运行着一个网络代理，它会读取日志文件并将其发送到查询流。对您的防火墙而言，这只是一个普通的出站连接——无需打开任何端口，无需建立 VPN，也无需维护日志传输器。
.gz 档案
拨号退出
三个出站连接，只需一个查询点——无需入站端口、无需 VPN、无需更改防火墙。
每个地点一名代理人
代理程序覆盖整个位置，而不是单个日志文件；在一个位置内，包含多个主机的文件夹树就是一个连接器——每一行都承载着它的信息。 地点免费套餐运行单个代理，更高套餐运行多个代理。
1 个区域 = 1 个代理 = 多台主机
无需打开
代理程序会建立一个加密的出站连接，所有出站请求和返回的数据都通过该连接传输。无需设置入站端口，无需使用 VPN，也无需更改防火墙设置——更不会将您的日志转发给任何第三方。
一个连接，双向
跨区域的一次查询
每个来源 联合查询 它会指定自己的代理，因此只需一条语句即可将一个区域中的边放置在另一个区域的原点旁边，或者将它们中的任何一个连接到您的应用程序数据库。包含在 Business 和 Enterprise 版本中。
2 个区域 → 1 个结果集
他们不断更新自己。
代理程序会自动更新，因此后续版本中添加的日志格式无需您自行部署即可覆盖所有区域。正因如此，上面的列表只是一个起点，而非固定不变的清单。
代理人带来了新的格式。
旋转是这不仅仅是 CSV 导入的原因。
网络日志并非静止不变。它们会在你不知不觉中轮换、重命名、压缩和重新创建。如何正确处理这些变化——确保日志完整无缺，避免重复计数——才是工作的核心所在。
编号旋转
经典的日志轮换机制：今天的文件保留原名，昨天的文件则向下移动一位。查询流遵循的是内容，而不是文件名。
access.log → access.log.1 → access.log.2.gz
按日期命名的文件名
IIS 从不重命名任何文件——它每天都会创建一个新文件，文件名中包含日期。旧文件保持不变，因此它们只会被读取一次，然后就不再修改。
u_ex260909.log · u_ex260910.log
压缩文件
轮换后的日志通常会被压缩。查询流读取 .gz 成员已就位——您无需先解压缩任何内容或将其移动到其他地方。
access-2026-09-08T03-00-00.000.log.gz
没有任何事会被重复计算。
每个文件都通过其前 4 KB 的数据进行指纹识别，因此重命名后的文件会被识别为同一个文件。当写入器重放文件尾部时，滚动重复窗口会捕获重叠部分。
4 KB 前缀哈希 · 20,000 条记录窗口
你实际得到的列
并非只是一串带有时间戳的文本。每种格式都会被解析成可直接进行筛选、分组和聚合的类型化列。
每一行也都承载着 事件时间 和 地点因此，一个查询可以跨越多个主机，并且永远不会怀疑它来自哪个文件。
您的 Web 服务器日志数据可以保存在哪里
日志文件并非无解之谜。只需连接一次文件夹，同一个只读连接即可为 Query Streams 支持的所有接口提供数据——无需二次设置，无需二次复制数据，处理方式与数据库连接器完全相同。
Web 服务器日志记录到 Excel
微软 Excel · Excel 加载项
将实时 Web 服务器日志结果直接提取到工作表中，并按需刷新——支持桌面版 Excel、Excel Online 和 Microsoft 365。
Excel 的工作原理
网络服务器日志同步到 Google 表格
表格插件
从侧边栏运行已保存的 Web 服务器日志查询，并将结果行拖放到工作表中。共享协作者可以自行刷新该工作表。
Google 表格的工作原理
Web 服务器日志 MCP 服务器
Claude、Cursor 和 MCP 客户端 · MCP 服务器
赋予 AI 助手对 Web 服务器日志的只读访问权限，并提供它编写正确 SQL 所需的架构——聊天中无需提供凭据。
MCP 的工作原理
Web 服务器日志 REST API
HTTP 端点
将 Web 服务器日志查询发布为任何应用程序都可以调用的已认证 JSON 端点，符合 OpenAPI 3.1 规范，并预置了 Postman、Insomnia 和 Hoppscotch 集合。无需打开数据库端口。
REST API 的工作原理
Web 服务器日志记录到 Airtable
自动化平台
按计划将 Web 服务器日志行同步到 Airtable，或者在 Airtable 自动化脚本中获取它们。
Airtable 的工作原理
Web 服务器日志记录到 Baserow
自动化平台
通过 REST 端点从 Web 服务器日志向 Baserow 表提供数据——无论是自托管还是 Baserow 云。
Baserow 的工作原理
Web 服务器日志记录到 SeaTable
自动化平台
使用 Web 服务器日志数据保持 SeaTable 数据库的最新状态，而无需导出文件或暴露数据库。
SeaTable 的工作原理
Web 服务器日志记录到 Smartsheet
自动化平台
将 Web 服务器日志结果推送到 Smartsheet 网格中，以便计划和报告能够从源系统读取数据，而不是从上周的导出数据读取数据。
Smartsheet 的工作原理
Web 服务器日志记录到 Anvil
Anvil Works · 应用平台
通过 REST 端点向 Anvil Python 应用程序提供 Web 服务器日志，而不是将数据库凭据嵌入到应用程序中。
Anvil 的工作原理
Web 服务器日志记录到 Power BI
Power Query M
将生成的 Power Query M 粘贴到 Power BI 高级编辑器中，报表将通过 HTTPS 读取实时 Web 服务器日志结果——无需 ODBC 驱动程序，也无需打开数据库端口。
Power BI 的工作原理
Web 服务器日志警报和报告
Slack · Discord · 电子邮件 · Webhook
将 Web 服务器日志查询设置为定时执行，并将查询结果发送到 Slack、Discord、电子邮件或签名 webhook，或者等到行数、阈值或百分比变化超过您设定的阈值时才发送消息。
警报和报告的工作原理我们故意不读的内容
生产环境访问日志包含的信息可能比您希望在报告表中呈现的信息要多。Caddy 的 JSON 格式会记录完整的请求和响应标头映射，其中通常包含会话 cookie 和 bearer token。Caddy 配置会排除这些信息。 请求头 和 resp_headers 这些字段是通过声明的方式设置的，而不是通过需要手动开启的过滤器，也不是事后添加的。这些字段永远不会被解析，因此它们永远不会出现在表格、导出文件或电子表格中。
其余设计也遵循相同的原则。代理程序连接外部网络并读取文件；Web 服务器上不安装任何软件，也不向服务器写入任何数据，并且访问权限为只读。
工作原理
只需三步，就不会在 Web 服务器上安装任何东西。
指向日志文件夹
赋予查询流代理对服务器已记录日志的文件夹的读取权限 — /var/log/nginx, /var/log/caddy一个 IIS 日志文件 目录，或者您同步到的共享目录。
它能识别这种格式
查询流通过行内容（而不是文件名）来识别格式——因此，即使文件名很奇怪，文件仍然可以读取；而与固定格式不匹配的文件会被暂时搁置，并给出相应的理由，而不是破坏表。
查询它，或者连接它
从门户网站运行 SQL，将其实时导入 Microsoft Excel 或 Google Sheets，或者使用联合查询将请求日志与应用程序数据库中的用户和订单连接起来——只需一条语句即可完成。
网站服务器日志常见问题解答
我需要更改日志记录配置吗？
不。每种受支持的格式都是该服务器的默认格式：nginx 和 Apache 使用合并的访问日志，Caddy 2 使用 JSON 访问日志，IIS 使用 W3C 扩展格式。如果您从未更改过日志格式，则您使用的已经是受支持的格式。
IIS 是一个比较灵活的案例，而且处理得当—— #字段： W3C 文件顶部的指令会为其列命名，因此无论你在 IIS 管理器中选择哪些字段，你都会得到相应的列。
这是实时画面吗？
它采用的是按需服务，而非流媒体服务。查询流会在您运行查询时直接读取磁盘上的文件，因此，新的请求会在服务器写入文件并读取文件时立即出现——并非按照固定的夜间时间表，但也并非实时跟踪。
如果你需要对正在发生的请求进行亚秒级告警，日志管道是合适的工具。但如果你只是想查询过去几周的流量数据，并在电子表格中得到结果，那么这种方法就显得简单得多。
旋转和压缩后的日志会发生什么变化？
它们已被读取。查询流理解这些服务器使用的三种轮换方式——logrotate 的编号轮换、IIS 的每日更新日期文件轮换和 Caddy 的时间戳轮换——并读取它们。 .gz 无需解压缩即可直接保存存档。
文件匹配是通过其前 4 KB 的哈希值而非文件名进行的，因此轮换后的文件会被识别为已识别的文件。这可以防止轮换导致丢失一天或重复计数。
我的日志文件分布在多台服务器上，我可以同时查询它们吗？
是的。每一行都包含一个 地点 这样，一个查询就可以跨越多个主机，并按您关心的任何类别进行分组。您可以为每个环境或每个区域部署一个代理，它们都会在同一个列表中显示各自的文件夹。
因为它是普通的 SQL，所以你可以更进一步，将请求日志连接到真正的数据库——将 500 错误峰值与部署表进行匹配，或者将缓慢的结账请求与它们所属的订单进行匹配。
它会读取 cookie 还是授权标头？
不。Caddy 的 JSON 格式是这四种格式中唯一会记录标头映射的格式，而且该配置文件排除了…… 请求头 和 resp_headers 由于是声明式的，所以它们永远不会被解析到列中。组合格式、错误格式和 W3C 格式本身就不包含标题。
解析客户端 IP 地址和用户代理，因为它们是访问日志的关键所在——对待生成的表格要像对待它所来自的日志文件一样谨慎。
如果解析器无法读取某一行代码怎么办？
它会被保留，而不是删除。不符合固定格式的行会作为原始行保留，并附带原因说明。因此，格式错误的条目或意外的格式更改会以可见和可查询的形式显示出来，而不是在数据中留下一个无声的空白。
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish