报告错误

Varnish可能是一个很难调试的野兽，可能会有数千个线程挤在几个数据结构中，这有助于 interesting 核心转储。

实际上，让我重新表述一下，不带讽刺意味：你厌倦了“不，也不是438，那么让我们看看439……”动作真的很快。

因此，如果您遇到错误，花一点时间收集正确的信息，帮助我们修复错误，这一点很重要。

你能给我们的最有价值的信息是 always 如何触发和重现问题。如果你能告诉我们，我们几乎不需要任何其他东西来解决它。需要注意的是，我们没有办法模拟真实生活中的高水平网络流量，所以告诉我们“一次有10.000个客户端被点击”并不能真正让我们重现。

要报告错误，请按照文档(上面)的“故障票证”部分中所述的建议步骤进行操作。

我们使用Varnish将错误大致分类为三种错误(如下所述)。我们调试它们所需的信息取决于我们面临的是哪种错误。

Varnish崩塌

简单明了： boom

Varnish被分成两个进程，经理和孩子。所有的工作都是由孩子来做的，如果它崩溃了，经理会在附近徘徊，让它复活。

因此，如果您看到Varnish崩溃，首先要做的是检查syslog，看看以前是否发生过这种情况。(有传言称，有一个网站每10分钟重新启动一次Varnish， still 提供比他们的CMS系统更好的服务。)

当它崩溃时，Varnish将发出一个崩溃转储文件，如下所示：

Child (32619) died signal=6 (core dumped)
Child (32619) Panic message: Assert error in ccf_panic(), cache_cli.c line 153:
  Condition(!strcmp("", "You asked for it")) not true.
errno = 9 (Bad file descriptor)
thread = (cache-main)
ident = FreeBSD,9.0-CURRENT,amd64,-sfile,-hcritbit,kqueue
Backtrace:
  0x42bce1: pan_ic+171
  0x4196af: ccf_panic+4f
  0x8006b3ef2: _end+80013339a
  0x8006b4307: _end+8001337af
  0x8006b8b76: _end+80013801e
  0x8006b8d84: _end+80013822c
  0x8006b51c1: _end+800134669
  0x4193f6: CLI_Run+86
  0x429f8b: child_main+14b
  0x43ef68: start_child+3f8
[...]

如果您能将该信息提供给我们，我们通常能够准确地看到哪里出了问题，这将大大加快错误修复的速度。

除此之外，崩溃转储中还会有更多信息，在将其全部发送给我们之前，您应该隐藏任何敏感/机密数据/cookie/密码/IP#等。请确保在这样做时保持上下文，即：不要将所有IP#更改为“X.X”，而是将每个IP#更改为某些唯一的东西，否则我们可能会更困惑而不是知情。

最重要的一句话是“恐慌信息”，一般有两种形式：

“中缺少错误处理代码...”

这是一种我们可以设想Varnish结束的情况，我们(还没有)为它编写填充框错误处理代码。

最有可能的原因是您需要一个更大的工作区来存放HTTP头和Cookie。

请在报告错误之前尝试此操作。

“断言错误...”

这是一件永远不应该发生的坏事，而且几乎可以肯定，错误报告是正确的。一如既往，如果有疑问，请在开票前向我们咨询IRC。

在您的系统日志中，它们可能都连接到一行中，但如果您可以重现崩溃，请在运行时执行此操作 华而不实 手动：

varnishd -d <your other arguments> |& tee /tmp/_catch_bug

这将把整个恐慌消息保存到一个文件中。

(记得要打字 start 要启动工作进程，在以下情况下不是自动的 -d 已使用。)

Varnish去度假

这种错误很难调试，因为通常情况下，人们倾向于终止进程并向我们发送一封电子邮件，上面写着“Varnish挂起，我重新启动了它”，这只给我们提供了大约1.01比特的可用调试信息。

我们这里需要的是您可以从您的操作系统中挤出的所有信息 before 你就扼杀了瓦尼什进程。

最有价值的信息之一是，如果所有Varnish的线程都在等待某个东西，或者其中一个线程在某个徒劳的条件下疯狂旋转。

命令，如 top -H 或 ps -Haxlw 或 ps -efH 应该能够弄清楚这一点。

如果一个或多个线程正在旋转，请使用 strace 或 ktrace 或 truss (或您的操作系统提供的任何其他功能)以跟踪哪个系统调用了Varnish进程问题。请注意，这可能会生成大量非常重复的数据，通常一秒钟的数据就绰绰有余。

此外，还可以运行 Varnishlog 一秒钟，并为我们收集输出，如果 Varnish状态 显示任何活动，也将其捕获。

当你做完这件事，杀了瓦尼什 child 进程，并让 master 进程重新启动它。记住告诉我们这是否有效。如果没有，请终止所有Varnish进程，然后从头开始。如果这也不起作用，告诉我们，那意味着我们已经把你的内核塞进去了。

Varnish做错了事

以下是简单的错误：通常我们只需要您记录的相关交易 Varnishlog 以及你对瓦尼什所作所为的错误之处的解释。

请注意，Varnish通常完全按照您的要求行事，而不是按您的意图行事。如果它听起来像是一个错误，会绊倒其他所有人，花点时间通读一下你的VCL，看看它是否真的像你认为的那样。

您也可以尝试将 vsl_mask=+VCL_trace 参数(或使用 varnishadm param.set vsl_mask +VCL_trace 在运行的实例上)，这将为您的VCL程序中执行的每个语句生成带有LIKE和字符号的日志记录。