Отчёт об ошибках

Отладка Varnish может быть сложной задачей, так как потенциально тысячи потоков могут перегружать несколько структур данных, что приводит к интересным дампам ядра.

На самом деле, позвольте перефразировать это без иронии: вы быстро устаёте от рутинного процесса «нет, и поток 438 тоже не подходит, давайте посмотрим на 439…».

Поэтому, если вы столкнулись с ошибкой, важно потратить немного времени на сбор необходимой информации, чтобы помочь нам исправить ошибку.

Самая ценная информация, которую вы можете нам предоставить, — это всегда способ воспроизведения проблемы. Если вы сможете это объяснить, нам в редких случаях потребуется что-то ещё, чтобы её решить. Исключением является то, что у нас нет возможности имитировать высокие уровни реального веб-трафика, поэтому указание «нагрузить 10 000 клиентов одновременно» не позволяет нам воспроизвести ошибку.

Чтобы сообщить об ошибке, следуйте предложенной процедуре, описанной в разделе «Тикеты проблем» документации (выше).

В Varnish ошибки грубо можно разделить на три типа (описаны ниже). Необходимая информация для их отладки зависит от типа ошибки.

Сбои Varnish

Простая и понятная ситуация: взрыв

Varnish разделен на два процесса: менеджер и дочерний процесс. Дочерний процесс выполняет всю работу, а менеджер находится в ожидании, чтобы восстановить его в случае сбоя.

Поэтому первое, что нужно сделать при обнаружении сбоя Varnish, — это проверить системные журналы, чтобы увидеть, случалось ли это раньше. (Есть слухи, что один сайт перезапускал Varnish каждые 10 минут и по-прежнему обеспечивал лучшее обслуживание, чем его 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
[...]

Если вы сможете предоставить нам эту информацию, мы обычно сможем точно определить, где произошли неполадки, что значительно ускорит процесс исправления ошибок.

В дампе сбоя будет значительно больше информации, и перед отправкой всего нам, вы должны скрыть все конфиденциальные/секретные данные/куки/пароли/IP-адреса и т.д. Пожалуйста, сохраняйте контекст при этом, то есть не меняйте все IP-адреса на «X.X.X.X», а меняйте каждый IP-адрес на уникальную запись, иначе мы, скорее всего, будем более сбиты с толку, чем проинформированы.

Наиболее важной строкой является «Сообщение об ошибке», которое имеет два основных формата:

«Не хватает обработки ошибок в …»

Это ситуация, когда Varnish может завершиться, для которой мы ещё не написали код обработки ошибок.

Вероятнее всего, вам потребуется больше места для HTTP-заголовков и куки.

Пожалуйста, попробуйте это прежде, чем сообщать об ошибке.

«Ошибка проверки в …»

Это что-то плохое, что никогда не должно происходить, и, скорее всего, требуется отчёт об ошибке. Как всегда, если сомневаетесь, спросите нас в IRC, прежде чем создавать тикет.

В системном журнале всё может быть объединено в одну строку, но если вы можете воспроизвести сбой, сделайте это, запустив varnishd вручную:

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

Это позволит вам получить всё сообщение об ошибке в файл.

(Не забудьте набрать start для запуска процесса рабочего потока, что не является автоматическим при использовании -d. )

Varnish уходит в отпуск

Этот тип ошибок трудно отлаживать, потому что обычно люди убивают процесс и отправляют нам электронное письмо со словами «Varnish завис, я перезапустил его», что даёт нам всего около 1,01 бита полезной информации для отладки.

Здесь нам нужна вся информация, которую вы можете извлечь из вашей операционной системы до того, как вы убьёте процесс Varnish.

Одна из наиболее ценных деталей информации — это то, ожидают ли все потоки Varnish чего-то или один из них бешено вращается на каком-то бесполезном условии.

Команды, такие как top -H или ps -Haxlw или ps -efH, должны это определить.

Если один или несколько потоков вращаются, используйте strace или ktrace или truss (или любую другую утилиту вашей ОС) для получения следа системных вызовов, которые выдает процесс Varnish. Имейте в виду, что это может сгенерировать много очень повторяющейся информации; обычно достаточно данных за одну секунду.

Также запустите varnishlog на секунду и соберите вывод, а если varnishstat показывает какую-либо активность, зафиксируйте и это.

После этого убейте дочерний процесс Varnish, и позвольте мастер-процессу перезапустить его. Сообщите нам, сработало это или нет. Если нет, убейте все процессы Varnish и начните заново. Если и это не сработает, сообщите нам, это значит, что мы заблокировали ваше ядро.

Varnish делает что-то неправильно

Это простые ошибки: обычно от вас требуется только соответствующие транзакции, записанные с помощью varnishlog, и ваше объяснение, что не так с действиями Varnish.

Помните, что Varnish часто делает ровно то, что вы ему сказали, а не то, что вы имели в виду. Если ошибка, похоже, повлияет на всех остальных, уделите время на чтение вашего VCL и проверьте, действительно ли он делает то, что вы ожидаете.

Вы также можете попробовать установить параметр vsl_mask=+VCL_trace (или использовать varnishadm param.set vsl_mask +VCL_trace в работающем экземпляре), который сгенерирует записи журнала с номером строки и символа для каждого выполненного оператора в вашей программе VCL.