> For the complete documentation index, see [llms.txt](https://www.axisnow.io/zh/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.axisnow.io/zh/docs/edge/insight/log-explorer.md).
# 日志检索
访问日志的请求级检索：条件、模板、结果趋势、日志明细与耗时瀑布的读法
**洞察 › 日志检索**查的是边缘的访问日志，一条日志对应一个请求，字段含义见[日志字段](/zh/docs/edge/insight/log-fields.md)，用它定位问题的常用做法见[日志检索技巧](/zh/docs/edge/insight/log-explorer-tips.md)。默认时间范围最近 30 分钟；切换时间范围会自动重新查询，改动条件后要点**查询**。
{% hint style="info" %}
访问日志可能被采样：访问日志插件开启采样，或请求量过大时系统自动降级采样。采样只影响这里的明细，部分请求查不到；流量、请求数等聚合指标不受影响。
{% endhint %}
## 查询条件
* 在结果趋势图上框选一段时间，整页按这段时间重新查询。
* **常用问题定位条件**是排错场景的快捷查询，一键填入对应的条件组合，例如「客户端收到 5xx」「源站响应慢」「回源失败」，填入后可以再叠加其他条件。
## 查询结果
趋势图的两条线分别是回源与边缘直接响应的请求数。列表每批加载 30 条，一次查询最多取 10000 条，导出 CSV 同样以 10000 条为限；超过时收窄时间范围或加条件。
展开一条日志可以看到链路拓扑、耗时瀑布和日志详情。
**耗时瀑布**把一次请求的总耗时拆到客户端、边缘、源站三方，哪一段最长，问题就在谁那里。「边缘处理」包含全部插件的耗时，边缘有没有拖慢看这一段；「源站处理」是等待源站首字节的时间，推理、查询这类慢在业务上的请求都落在这里。客户端 TLS 握手和等待发请求两段只在连接的首个请求上出现。
**日志详情**里各插件对这条请求的处置记录在 `extras` 下，如 `extras.rate_limit.action_methods`、`extras.general_acl.action_methods`、`extras.authn_authz`。按命中规则筛选时，展开的日志会附上命中当时的规则配置，规则后来改过或删掉也能看到当时的版本。
## 读数注意
* 处于 IP 封禁期内的来源不进入请求处理，没有日志；封禁本身在速率控制或通用访问控制的 IP 封禁记录里。
* 日志里不记录请求头中的凭据，定位一个调用方用客户端 IP 加请求路径，或者用用户报来的请求 ID 直接检索，它就是响应头 [`X-Request-ID`](/zh/docs/edge/edge/headers-and-cookies.md) 的值。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://www.axisnow.io/zh/docs/edge/insight/log-explorer.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.