🔗 Squid 日志文件
日志是了解 Squid 工作负载和性能的宝贵信息来源。日志不仅记录访问信息,还记录系统配置错误和资源消耗(例如内存、磁盘空间)。Squid 维护着几个日志文件。有些需要在编译时显式激活,而另一些则可以在运行时安全地禁用。
所有日志文件都有一些共同的基本要点。日志文件中记录的时间戳通常是 UTC 秒,除非另有说明。初始时间戳通常包含毫秒扩展。
🔗 cache.log
cache.log 文件包含 Squid 生成的调试和错误消息。如果您使用 -s 命令行选项启动 Squid,一些消息的副本将进入您的 syslog 设施。使用单独的文件来存储 Squid 日志数据是个人偏好的问题。
从自动日志文件分析的角度来看,cache.log 文件提供的帮助不大。通常,当您对 Squid 进行编程、测试新功能或查找可感知到的错误行为的原因时,您会查看此文件以获取自动错误报告。
🔗 Squid 错误消息
错误消息有多种形式。调试跟踪不会在级别 0 或级别 1 记录。这些级别保留给重要的和关键的管理消息。
- FATAL 消息表示一个导致 Squid 进程崩溃的问题。这会影响该 Squid 实例正在提供给所有当前客户端的流量。如果在启动或配置 Squid 组件时出现这些消息,则必须在运行 Squid 之前解决它们。
- ERROR 消息表示一个严重问题,该问题已损坏单个客户端事务,并可能间接影响其他客户端。但并未完全中止所有流量服务。
- 这些消息也可能在启动或配置 Squid 组件时出现。在这种情况下,在问题解决并重新配置 Squid 之前,该组件提供的任何服务都不会发生。
一些从旧版 Squid 继承的日志级别 0 错误消息存在,没有优先级标签。 -
WARNING 消息表示可能导致客户端出现问题,但 Squid 能够自动解决。这些消息通常仅在日志级别 1 及以上显示。
一些从旧版 Squid 继承的日志级别 1 警告消息存在,没有优先级标签。 - SECURITY ERROR 消息表示在处理客户端请求时,与 Squid 配置的安全控件相关的出现问题。需要一个不可能的条件才能通过安全测试。当测试基于未来才能获得的某个回复详细信息来确定是否接受客户端请求时,通常会看到此消息。
-
SECURITY ALERT 消息表示检测到安全攻击问题。这仅用于明确无误的问题。“攻击”签名可能出现在正常流量中,将被记录为常规 WARNING。
- 解决这些问题通常需要修复客户端,这可能是不可能的。
- 管理器的变通方法(额外的防火墙规则等)可以帮助 Squid 减少对网络性能的损害。
- 攻击通知可能看起来相当关键,但在级别 1 出现,因为在所有情况下 Squid 也提供了一些可以执行的变通方法。
- SECURITY NOTICE 消息可能在启动和重新配置期间出现,以指示与配置文件设置相关的安全问题。如果可能,它们会附带更好的配置提示,并指示 Squid 将采取什么措施而不是配置的操作。
一些更常被询问的消息及其含义在知识库中有概述。
🔗 access.log
大多数日志文件分析程序都基于 access.log 中的条目。
Squid 允许管理员以极大的灵活性配置其日志文件格式和日志输出方法。
🔗 Squid 结果码
Squid 结果码由几个标签(以下划线分隔)组成,这些标签描述了发送给客户端的响应。
-
其中一个标签始终存在,用于描述其交付方式
TCP HTTP 端口(通常是 3128)上的请求。 UDP ICP 端口(通常是 3130)或 HTCP 端口(通常是 4128)上的请求。如果使用 log_icp_queries 选项禁用了 ICP 日志记录,则不会记录任何 ICP 回复。 NONE Squid 发送了非正常响应或根本没有响应。此情况与 cachemgr 请求和错误相关,通常在事务在被归类到上述结果之一之前失败时出现。也出现在对 CONNECT 请求的响应中。 -
这些标签是可选的,用于描述执行特定处理的原因或请求的来源
CF 此事务中的至少一个请求被合并。有关请求合并的更多详细信息,请参阅collapsed_forwarding。此标签的支持已添加到 Squid v5 中,于 2018-06-18(提交d2a6dc)。在早期 Squid 版本中可能不可用。 CLIENT 客户端请求设置了影响响应的限制。通常,当客户端发出带有请求的“no-cache”或类似的缓存控制命令时会出现此情况。因此,缓存必须验证对象。 IMS 客户端发送了重新验证(有条件)请求。 ASYNC 该请求是由 Squid 内部生成的。通常这是用于缓存信息交换的后台获取、来自 stale-while-revalidate 缓存控制的后台重新验证,或 ESI 子对象的加载。 SWAPFAIL 对象被认为在缓存中,但无法访问。已请求从服务器获取新副本。 REFRESH 向服务器发送了重新验证(有条件)请求。 SHARED 此标签尚不支持。此请求已通过合并转发与现有事务合并。注意:现有请求未标记为 SHARED。 REPLY 来自服务器或对等方的 HTTP 回复。通常出现在 DENIED 中,因为 http_reply_access ACLs 阻止将服务器的响应对象传递给客户端。 -
这些标签是可选的,用于描述生成的是哪种对象
NEGATIVE 仅在 HIT 响应中看到。表示响应是缓存的错误响应。例如,“404 Not Found” STALE 对象已缓存并且陈旧。这通常是由 stale-while-revalidate 或 stale-if-error 缓存控制引起的。 OFFLINE 在 offline_mode 期间,从缓存中检索了请求的对象。离线模式从不验证任何对象。 INVALID 收到了无效请求。已发送错误响应,指示问题所在。 FAIL 仅在 REFRESH 中看到,用于指示重新验证请求失败。响应对象可能是服务器提供的网络错误,或者是正在重新验证的陈旧对象,具体取决于 stale-if-error 缓存控制。 MODIFIED 仅在 REFRESH 响应中看到,用于指示重新验证产生了新的已修改对象。 UNMODIFIED 仅在 REFRESH 响应中看到,用于指示重新验证产生了 304 (Not Modified) 状态。客户端根据客户端请求和其他详细信息,获取 200 (OK) 的完整响应、304 (Not Modified) 响应,或(理论上)其他响应。 REDIRECT Squid 为此请求生成了 HTTP 重定向响应。 -
这些标签是可选的,用于描述响应是从缓存、网络还是其他地方加载的
HIT 提供的响应对象是本地缓存对象。 MEM 附加标签,指示响应对象来自内存缓存,避免了磁盘访问。仅在 HIT 响应中看到。 MISS 提供的响应对象是网络响应对象。 DENIED 请求被访问控制拒绝。 NOFETCH ICP 特定的类型。指示服务可用,但此请求不应使用。在“-Y”启动期间,或在频繁失败期间发送,仅命中模式下的缓存将返回 UDP_HIT 或 UDP_MISS_NOFETCH。因此,邻居只会获取命中。 TUNNEL 为此事务建立了二进制隧道。 -
这些标签是可选的,用于描述在响应交付过程中发生的任何错误情况(如果有)
ABORTED 客户端到 Squid 或 Squid 到服务器的连接意外关闭,通常是由于 I/O 错误或在某个高级协议消息/协商过程中断开传输连接。在 Squid v6 之前,此标签主要在客户端在 Squid 交付整个响应之前关闭与 Squid 的连接时出现。自 Squid v6 起,当 Squid 与源服务器或 cache_peer 的通信不可能(例如,服务器拒绝 TCP 连接)或被中止(例如,在分块 HTTP 响应体传输过程中发生 EOF)时,也会出现此标签。 TIMEOUT 由于连接超时,响应未完成。 IGNORED 在重新验证先前缓存的响应 A 时,Squid 收到了一个比 A旧的响应 B(由 Date 标头字段确定)。Squid 忽略了响应 B(并尝试使用 A)。这种“忽略旧响应”的逻辑符合 RFC 7234 第 4 节的要求:缓存必须使用最新响应(由 Date 标头字段确定)。
🔗 HTTP 状态码
这些代码取自 RFC 1945 (HTTP/1.0)、2616 (HTTP/1.1) 并针对 Squid 进行了验证。Squid 使用几乎所有代码,除了 416 (Request Range Not Satisfiable)。Squid 日志中使用的额外代码(但不在实时流量中)包括 000 表示结果码不可用,以及 600 表示无效头、代理错误。此外,还添加了一些定义,如 RFC 2518 和 4918 (WebDAV)。是的,状态码 424 确实有两个条目。
| 状态 | 描述 | RFC(s) |
|---|---|---|
| 000 | 主要用于 UDP 流量。 | 不适用 |
| 信息性 | ||
| 100 | 继续 | 2616 |
| 101 | 切换协议 | 2616 |
| 102 | 处理中 | 2518 |
| 成功事务 | ||
| 200 | OK | 1945, 2616 |
| 201 | 已创建 | 1945, 2616 |
| 202 | 已接受 | 1945, 2616 |
| 203 | 非权威信息 | 2616 |
| 204 | 无内容 | 1945, 2616, 4918 |
| 205 | 重置内容 | 2616 |
| 206 | 部分内容 | 2616 |
| 207 | 多重状态 | 2518, 4918 |
| 重定向 | ||
| 300 | 多项选择 | 1945, 2616, 4918 |
| 301 | 永久移动 | 1945, 2616, 4918 |
| 302 | 临时移动 | 1945, 2616, 4918 |
| 303 | 参见其他 | 2616, 4918 |
| 304 | 未修改 | 1945, 2616 |
| 305 | 使用代理 | 2616, 4918 |
| 307 | 临时重定向 | 2616, 4918 |
| 客户端错误 | ||
| 400 | 错误请求 | 1945, 2616, 4918 |
| 401 | 未授权 | 1945, 2616 |
| 402 | 需要付款 | 2616 |
| 403 | 禁止 | 1945, 2616, 4918 |
| 404 | 未找到 | 1945, 2616 |
| 405 | 不允许的方法 | 2616 |
| 406 | 不可接受 | 2616 |
| 407 | 需要代理身份验证 | 2616 |
| 408 | 请求超时 | 2616 |
| 409 | 冲突 | 2616, 4918 |
| 410 | 已消失 | 2616 |
| 411 | 需要长度 | 2616 |
| 412 | 前提条件失败 | 2616, 4918 |
| 413 | 请求实体过大 | 2616 |
| 414 | 请求 URI 过大 | 2616, 4918 |
| 415 | 不支持的媒体类型 | 2616 |
| 416 | 无法满足请求的范围 | 2616 |
| 417 | 期望失败 | 2616 |
| 422 | 无法处理的实体 | 2518, 4918 |
| 424 | 已锁定 | (损坏的 WebDAV 实现??) |
| 424 | 失败的依赖 | 2518, 4918 |
| 433 | 无法处理的实体 | |
| 服务器错误 | ||
| 500 | 内部服务器错误 | 1945, 2616 |
| 501 | 未实现 | 1945, 2616 |
| 502 | 错误的网关 | 1945, 2616 |
| 503 | 服务不可用 | 1945, 2616 |
| 504 | 网关超时 | 2616 |
| 505 | 不支持 HTTP 版本 | 2616 |
| 507 | 存储不足 | 2518, 4918 |
| 损坏的服务器软件 | ||
| 600 | Squid: 头解析错误 | |
| 601 | Squid: 解析时检测到头大小溢出 | |
| 601 | roundcube: 软件配置错误 | |
| 603 | roundcube: 无效的授权 |
🔗 请求方法
Squid 识别 RFC 2616 和 RFC 2518 “分布式创作的 HTTP 扩展 – WEBDAV”扩展中定义的几种请求方法。
method defined cachabil. meaning
--------- ---------- ---------- -------------------------------------------
GET HTTP/0.9 possibly object retrieval and simple searches.
HEAD HTTP/1.0 possibly metadata retrieval.
POST HTTP/1.0 CC or Exp. submit data (to a program).
PUT HTTP/1.1 never upload data (e.g. to a file).
DELETE HTTP/1.1 never remove resource (e.g. file).
TRACE HTTP/1.1 never appl. layer trace of request route.
OPTIONS HTTP/1.1 never request available comm. options.
CONNECT HTTP/1.1r3 never tunnel SSL connection.
ICP_QUERY Squid never used for ICP based exchanges.
PURGE Squid never remove object from cache.
PROPFIND rfc2518 ? retrieve properties of an object.
PROPATCH rfc2518 ? change properties of an object.
MKCOL rfc2518 never create a new collection.
COPY rfc2518 never create a duplicate of src in dst.
MOVE rfc2518 never atomically move src to dst.
LOCK rfc2518 never lock an object against modifications.
UNLOCK rfc2518 never unlock an object.
请注意,自 Squid 3.1 起,此处未列出的方法(如 PATCH)已“开箱即用”支持。
🔗 层级代码
- NONE 对于 TCP HIT、TCP 故障、cachemgr 请求和所有 UDP 请求,没有层级信息。
- DIRECT 对象从源服务器获取。
- SIBLING_HIT 对象从回复 UDP_HIT 的同级缓存获取。
- PARENT_HIT 对象已从回复 UDP_HIT 的父缓存请求。
- DEFAULT_PARENT 未发送 ICP 查询。选择此父级是因为它在配置文件中被标记为“默认”。
- SINGLE_PARENT 对象已从适用于给定 URL 的唯一父级请求。
- FIRST_UP_PARENT 对象已从父级列表中的第一个父级获取。
- NO_PARENT_DIRECT 对象从源服务器获取,因为对于给定的 URL 没有父级。
- FIRST_PARENT_MISS 对象已从具有最快(可能是加权)往返时间的父级获取。
- CLOSEST_PARENT_MISS 选择此父级,因为它包含了到源服务器的最低 RTT 测量值。另请参阅 closest-only 对等方配置选项。
- CLOSEST_PARENT 父级选择基于我们自己的 RTT 测量。
- CLOSEST_DIRECT 我们自己的 RTT 测量返回的时间比任何父级都短。
- NO_DIRECT_FAIL 由于防火墙配置(请参阅 never_direct 和相关材料)且没有可用的父级,因此无法请求对象。
- SOURCE_FASTEST 选择源站点,因为源 ping 最快。
- ROUNDROBIN_PARENT 未收到来自任何父级的 ICP 回复。选择此父级是因为它在配置文件中标记为轮循,并且使用次数最少。
- CACHE_DIGEST_HIT 选择该对等方,因为缓存摘要预测了命中。此选项后来被替换,以区分父级和同级。
- CD_PARENT_HIT 选择该父级,因为缓存摘要预测了命中。
- CD_SIBLING_HIT 选择该同级,因为缓存摘要预测了命中。
- NO_CACHE_DIGEST_DIRECT 此输出似乎未被使用?
- CARP 对等方由 CARP 选择。
- PINNED 服务器连接因 NTLM 或 Negotiate 身份验证要求而被固定。
- ORIGINAL_DST 服务器连接被限制为客户端提供的目标 IP。这发生在拦截代理中,当启用了主机安全,或启用了 client_dst_passthru 透明度时。
- ANY_OLD_PARENT(以前的 ANY_PARENT?)Squid 使用了第一个被认为是活动的父级。这种情况发生在没有启用特定的父级缓存选择算法(例如,userhash 或 carp)时,所有启用的算法都未能找到合适的父级,或者这些算法找到的所有合适父级在 Squid 尝试转发请求给它们时失败了。
- INVALID CODE src/peer_select.c:hier_strings[] 的一部分。
几乎任何一个都可以被 'TIMEOUT_' 前缀,如果默认的(两秒)超时发生,等待来自邻居的所有 ICP 回复到达,另请参阅 icp_query_timeout 配置选项。
以下层级代码已从 Squid-2 中移除
code meaning
-------------------- -------------------------------------------------
PARENT_UDP_HIT_OBJ hit objects are not longer available.
SIBLING_UDP_HIT_OBJ hit objects are not longer available.
SSL_PARENT_MISS SSL can now be handled by squid.
FIREWALL_IP_DIRECT No special logging for hosts inside the firewall.
LOCAL_IP_DIRECT No special logging for local networks.
🔗 store.log
此文件涵盖了当前存储在磁盘上的对象或已删除的对象。作为一种事务日志(或期刊),它通常用于调试目的。只有在分析了完整的日志文件后,才能确定一个对象是否驻留在您的磁盘上。对象被释放(删除)的时间可能比交换出(保存到磁盘)的时间晚。
store.log 文件可能对分析磁盘上的对象及其停留时间,或热对象被访问的次数感兴趣。后者也可能由另一个日志文件覆盖。通过了解 cache_dir 配置选项,此日志文件可以在不递归扫描缓存磁盘的情况下实现 URL 到文件名映射。然而,Squid 开发人员建议将 store.log 主要视为调试文件,您也应该如此,除非您知道自己在做什么。
存储日志条目(一行)的打印格式由 13 个空格分隔的列组成,请与文件 src/store_log.c 中的 storeLog() 函数进行比较。
9ld.%03d %-7s %02d %08X %s %4d %9ld %9ld %9ld %s %ld/%ld %s %s
- time 日志记录该行的 UTC 时间戳,带有毫秒部分。
-
action 对象被提交的操作,请与 src/store_log.c 进行比较。
- CREATE 似乎未使用。
- RELEASE 对象已从缓存中移除(另请参阅下面的文件编号)。
- SWAPOUT 对象已保存到磁盘。
- SWAPIN 对象存在于磁盘上并被读入内存。
- dir number 对象存储到的 cache_dir 编号,从 0 开始,对应您的第一个 cache_dir 行。
- file number 对象存储文件的文件编号。请注意,该文件的路径是根据您的 cache_dir 配置计算的。文件编号 FFFFFFFF 表示“仅内存”对象。任何针对此类文件编号的操作代码都指代一个仅存在于内存中而不在磁盘上的对象。例如,如果一个 RELEASE 代码用文件编号 FFFFFFFF 记录,则该对象仅存在于内存中,并从内存中释放。
- hash 用于在缓存中索引对象的哈希值。Squid 目前使用 MD5 作为哈希值。
- status HTTP 回复状态码。
- datehdr HTTP Date 回复头的值。
- lastmod HTTP Last-Modified 回复头的值。
- expires HTTP “Expires: “ 回复头的值。
- type HTTP Content-Type 的主要值,如果无法确定则为“unknown”。
-
sizes 此列包含两个斜杠分隔的字段
- HTTP Content-Length 回复头中的广告内容长度。
- 实际读取的大小。
- 如果广告(或预期)长度缺失,则设置为零。如果广告长度不为零,但与实际长度不相等,则对象将从缓存中释放。
- method 对象的请求方法,例如 GET。
-
key 对象的键,通常是 URL。
- datehdr、lastmod 和 expires 值均以 UTC 秒表示。实际值从 HTTP 回复头中解析。无法解析的头用 -1 表示,缺失的头用 -2 表示。
🔗 swap.state
此文件有着一段不幸的历史,导致它经常被称为交换日志。实际上,它是缓存索引的期刊,记录了写入磁盘的每一个缓存对象。Squid 启动时会读取它以“重新加载”缓存。
如果在 Squid未运行时删除此文件,您将有效地清除缓存内容索引。Squid 可以从原始文件中重建它,但这可能需要很长时间,因为缓存中的每个文件都必须完全扫描元数据。
如果在 Squid正在运行时删除此文件,您可以轻松地重新创建它。最安全的方法是简单地关闭正在运行的进程。
% squid -k shutdown
这将中断服务,但至少您会找回您的交换日志。或者,您可以告诉 Squid 轮换其日志文件。这也会生成一个干净的交换日志。
% squid -k rotate
默认情况下,swap.state 文件存储在每个 cache_dir 的顶级目录中。您可以使用 cache_swap_state 选项将日志移动到其他位置。
该文件是二进制格式,包含 MD5 校验和和 StoreEntry 字段。请参阅程序员指南,了解有关该文件内容和格式的信息。
🔗 squid.out
如果您使用 RunCache 脚本运行 Squid,squid.out 文件将包含 Squid 的启动时间以及所有致命错误,例如由 assert() 失败产生的错误。如果您不使用 RunCache,则看不到此文件。
RunCache 自 Squid-2.6 起已废弃。现代 Squid 作为守护进程运行通常会将此输出记录到系统 syslog 设施,或者如果手动运行,则记录到操作主守护进程进程的帐户的标准输出。
🔗 useragent.log
从 Squid-3.2 开始,此日志已成为默认的access.log 格式之一,并且始终可用。它不再是一个特殊的独立日志文件。
🔗 哪些日志文件可以安全删除?
在 Squid 运行时,切勿删除 access.log、store.log 或 cache.log。在 Unix 系统中,当进程打开文件时,您可以删除该文件。但是,直到进程关闭文件后,文件系统空间才会被回收。
如果您在 Squid 运行时意外删除了 swap.state,您可以按照前面问题的说明进行恢复。如果您在 Squid 运行时删除了其他文件,则无法恢复它们。
维护日志文件的正确方法是使用 Squid 的“轮换”功能。您应该至少每天轮换一次日志文件。当前的日志文件将被关闭,然后重命名为数字扩展名(.0、.1 等)。如果您愿意,可以编写自己的脚本来归档或删除旧的日志文件。否则,Squid 只会保留最多 logfile_rotate 个版本的每个日志文件。日志文件轮换过程还会写入一个干净的 swap.state 文件,但不会保留旧文件的编号版本。
如果将 logfile_rotate 设置为 0,Squid 只会关闭并重新打开日志。这允许第三方日志文件管理系统(如 newsyslog)维护日志文件。
要轮换 Squid 的日志,只需使用此命令
squid -k rotate
例如,使用此 cron 条目在午夜轮换日志
0 0 * * * /usr/local/squid/bin/squid -k rotate
🔗 如何禁用 Squid 的日志文件?
禁用 access.log
access_log none
禁用 store.log
cache_store_log none
禁用 cache.log
cache_log /dev/null
禁用 cache.log 是个坏主意,因为此文件包含许多重要的状态和调试消息。但是,如果您确实想这样做,可以
如果为任何上述日志文件指定了 /dev/null,则必须也将 logfile_rotate 设置为 0,否则将冒着 Squid 轮换掉 /dev/null,将其变成一个普通日志文件的风险。
与其禁用日志文件,不如建议为 logfile_rotate 设置一个较小的值,并在您的 cron 中正确轮换 Squid 的日志文件。这样,您的日志文件将更易于控制并由您的系统自行维护。
🔗 access.log 的最大大小是多少?
Squid 对其日志文件的大小没有限制。但是,某些操作系统对文件大小有限制。如果 Squid 日志文件超过操作系统的文件大小限制,Squid 将收到写入错误并关闭。您应该定期轮换 Squid 的日志文件,以防止它们变得非常大。
日志记录对 Squid 非常重要。事实上,它非常重要,以至于如果无法写入其日志文件,它将自行关闭。这包括日志磁盘已满或日志文件过大的情况。
🔗 我的日志文件变得很大!
您需要使用 cron 作业来轮换您的日志文件。例如
0 0 * * * /usr/local/squid/bin/squid -k rotate
当将调试信息记录到 cache.log 时,它很容易变得非常大,并且当需要长期的 access.log 流量历史记录时(例如某些国家/地区的法律要求),存储如此大的 cache.log 是不合理的。从 Squid-3.2 开始,可以使用 debug_options 的 rotate=N 选项为 cache.log 设置单独的上限,以存储更少的大文件备份(.0 到 .N 系列)。默认是存储与 access.log 相同的数量,并在 logfile_rotate 指令中设置。
🔗 我想使用另一个工具来维护日志文件。
如果您将 logfile_rotate 设置为 0,Squid 只会关闭并重新打开日志。这允许第三方日志文件管理系统,如 newsyslog 或 logrotate,来维护日志文件。
🔗 管理日志文件
用于分析的首选日志文件是原生格式的 access.log 文件。对于长期评估,应定期获取日志文件。Squid 提供了一个易于使用的 API 来轮换日志文件,以便在不干扰正在进行的缓存操作的情况下移动(或删除)它们。前面已经描述了这些过程。
根据为日志文件存储分配的磁盘空间,建议设置一个 cron 作业,每 24、12 或 8 小时轮换一次日志文件。您需要将 logfile_rotate 设置为一个足够大的数字。在一段空闲时间,您可以安全地将日志文件一次性传输到您的分析主机。
传输前,日志文件可以在非高峰时段压缩。在分析主机上,日志文件将被连接成一个文件,因此每天产生一个文件。此外,当启用 log_icp_queries 时,在一个繁忙的缓存上,每天可能会有大约 1 GB 的未压缩日志信息。查看您的缓存管理器信息页面,可以对日志文件的大小进行估算。
处理和处理日志文件时应遵守的一些基本建议
- 在发布结果时,请尊重您的客户的隐私。
- 除非匿名化,否则请保持日志不可用。大多数国家/地区都有隐私保护法,有些甚至规定了您可以合法保留某些类型信息的期限。
- 每天至少轮换和处理一次日志文件。即使您不处理日志文件,它们也会变得相当大,请参阅上面的我的日志文件变得很大。如果您依赖于处理日志文件,请为日志文件保留足够大的分区。
- 处理时请牢记大小。处理日志文件可能比生成日志文件需要更长的时间!
- 将自己限制在您感兴趣的数字范围内。您的日志文件中提供了超乎您想象的数据,有些很明显,有些则可以通过不同视角的组合来获得。以下是一些要关注的数字示例:
- 使用您缓存的主机。
- HTTP 请求的经过时间 - 这是用户看到的延迟。通常,您需要区分 HIT 和 MISS 的整体时间。此外,中位数比平均值更受欢迎。
- 每隔一段时间(例如,秒、分钟或小时)处理的请求数。
🔗 为什么我经常收到 ERR_NO_CLIENTS_BIG_OBJ 消息?
此消息表示请求的对象处于“延迟删除”模式,并且用户中止了传输。如果一个对象出现以下情况,它将进入“延迟删除”模式:
- 它的大小超过 maximum_object_size
- 它正在从设置了 proxy-only 选项的邻居节点获取
🔗 ERR_LIFETIME_EXP 是什么意思?
这意味着对象在传输过程中发生了超时。最有可能的原因是获取该对象的速度非常慢(或者在完成之前停滞了),并且用户中止了请求。然而,根据您对 quick_abort 的设置,Squid 可能已经继续尝试获取该对象。Squid 对所有打开的套接字都设置了最大超时时间,因此在一定时间后,停滞的请求将被中止并记录为 ERR_LIFETIME_EXP 消息。
🔗 从缓存中恢复“丢失”的文件
“有人要求我恢复一个在源端意外损坏的对象用于恢复。那么,我该如何找出这些文件在哪里,以便我可以将它们复制出来并剥离头部?”
以下方法仅适用于 Squid-1.1 版本
使用 grep 在 cache.log 文件中查找命名对象(URL)。该文件中的第一个字段是整数 文件编号。
然后,从 Squid 源发行版的“scripts”目录中找到文件 fileno-to-pathname.pl。其用法如下:
perl fileno-to-pathname.pl [-c squid.conf]
文件编号将从标准输入读取,路径名将打印到标准输出。
🔗 我可以使用 store.log 来判断一个响应是否可缓存吗?
某种程度上可以。您可以使用 store.log 来了解某个特定的响应是否被 缓存 了。
缓存的响应会用 SWAPOUT 标签记录。未缓存的响应会用 RELEASE 标签记录。
但是,您的分析还必须考虑到,当一个缓存的响应从缓存中被移除时(例如,由于缓存替换),它也会在 store.log 中用 RELEASE 标签记录。为了区分这两种情况,您可以查看文件编号(第 3 个)字段。当一个不可缓存的响应被释放时,文件编号是 FFFFFFFF (-1)。任何其他文件编号都表示一个缓存的响应被释放了。
🔗 我可以将 squid access.log 直接管道化吗?
许多人询问过这个问题,通常是为了将日志输入某种外部数据库,或者实时分析它们。
答案是:否。嗯,可以,有点。直接使用管道会带来很多潜在的问题。
日志记录对 Squid 非常重要。事实上,它非常重要,以至于如果无法写入日志文件,它就会自行关闭。
有几种替代方案,设置和使用起来更安全。基本功能包括:
有关设置守护进程或其他输出模块的技术细节,请参阅 日志模块功能。
回到 FAQ 索引
导航: 网站搜索、网站页面、分类、🔼 向上