8. Ведение журнала

Для ведения журнала HAProxy всегда использует сервер syslog, поскольку сам не обращается к файловой системе. Стандартный способ — отправлять журналы по UDP на сервер журналирования (по умолчанию на порт 514). Очень часто используется адрес 127.0.0.1, где работает локальный демон syslog, но также применяется передача по сети на центральный сервер. Центральный сервер даёт дополнительные преимущества, особенно в схемах active-active, где желательно объединять журналы в порядке поступления. HAProxy может отправлять журналы локальному демону syslog и через сокет UNIX, но это совершенно не рекомендуется: если сервер syslog перезапустить во время работы haproxy, сокет будет заменён, а новые записи журналов будут теряться. Поскольку HAProxy изолирован в окружении chroot, он не сможет повторно подключиться к новому сокету. На практике также наблюдалось, что буферы журналирования сокетов UNIX очень малы, из-за чего сообщения теряются даже при очень низкой нагрузке. Однако для тестирования такой вариант вполне допустим.

Чтобы HAProxy отправлял журналы локальному демону с категорией facility «local0», рекомендуется добавить в секцию «global» следующую директиву:

log 127.0.0.1:514 local0

а затем добавить следующую директиву в каждую секцию «defaults» либо в каждую секцию фронтенда и бэкенда:

log global

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

Некоторые демоны syslog по умолчанию не принимают трафик UDP, поэтому синтаксис включения этой возможности зависит от используемого демона:

• Для sysklogd нужно передать аргумент «-r» в командной строке демона, чтобы он прослушивал сокет UDP для удалённых журналов. Учтите, что ограничить прослушивание адресом 127.0.0.1 невозможно, поэтому он будет принимать журналы и от удалённых систем.

• Для rsyslogd в файл конфигурации необходимо добавить следующие строки:

$ModLoad imudp
$UDPServerAddress *
$UDPServerRun 514

• Для syslog-ng можно создать новый источник следующим образом, а затем добавить его как допустимый источник в одну из директив «log»:

source s_udp {
  udp(ip(127.0.0.1) port(514));
};

Дополнительные сведения приведены в руководстве используемого демона syslog. Если в системных файлах журналов нет записей, выполните следующие проверки:

• Перезапустите haproxy. Каждый фронтенд и бэкенд записывает строку о своём запуске. Если эти записи поступают, журналирование работает.

• Выполните «strace -tt -s100 -etrace=sendmsg -p <haproxy’s pid>» и выполните действия, которые должны попасть в журнал. В выводе должны быть видны сообщения журнала, отправляемые через sendmsg(). Если их нет, перезапустите haproxy под strace. Если журналы по-прежнему отсутствуют, в конфигурации определённо есть ошибка.

• Запустите tcpdump для наблюдения за портом 514, например на интерфейсе обратной петли, если трафик передаётся локально: «tcpdump -As0 -ni lo port 514». Если пакеты видны, это доказывает, что они отправляются, и нужно искать неисправность в демоне syslogd.

Хотя журналы трафика отправляют фронтенды, принимающие входящие соединения, бэкенды также должны иметь возможность отправлять записи, чтобы сообщать об изменении состояния сервера по результатам проверки работоспособности. Дополнительные сведения обо всех доступных настройках журналирования приведены в руководстве по конфигурации HAProxy.

Удобно выбрать категорию facility, которая не используется другими демонами. В примерах HAProxy часто предлагаются «local0» для журналов трафика и «local1» для административных журналов, поскольку на практике эти категории нигде не встречаются. Одной категории также было бы достаточно. Раздельные журналы удобны для анализа, но важно помнить, что в них иногда содержатся конфиденциальные сведения, поэтому их нельзя смешивать с другими журналами, которые могут случайно попасть к посторонним.

Для устранения неполадок в рабочей среде без существенного влияния на производительность сервера рекомендуется использовать утилиту «halog», поставляемую с HAProxy. Она похожа на grep и предназначена для очень быстрой обработки файлов журналов HAProxy. Типичная скорость составляет от 1 до 2 GB журналов в секунду. Она умеет извлекать только определённые записи (например, искать по классам кодов состояния HTTP, состояниям завершения соединений, диапазонам времени ответа или только ошибки), считать строки, ограничивать число выводимых строк и выполнять более сложную статистическую обработку: сортировать серверы по времени ответа или числу ошибок, URL по времени или числу обращений, адреса клиентов по числу обращений и так далее. Это очень удобно для быстрого выявления аномалий, например бота, бесконечно обходящего сайт, и их блокирования.