SARG для Squid: заводим парового архивариуса трафика

Есть один момент в жизни каждого, кто поднимал Squid хотя бы раз — не важно, для конторы на полсотни голов или для домашней сети, где сын качает торренты по ночам. Рано или поздно кто-то сверху спрашивает: “А куда у нас уходит трафик?”. И вот тут выясняется неприятная вещь: сырой access.log — это не отчёт, а гудящий паровой котёл без манометра. Давление есть, стрелка дрожит, а что происходит внутри — совершенно не ясно, пока не найдётся кто-то, кто умеет читать эти иероглифы построчно.

SARG (Squid Analysis Report Generator) — это тот самый манометр. Точнее, маленький автоматон-архивариус: берёт рулон бумажной ленты (access.log), пропускает через шестерёнки парсера и выдаёт вам аккуратный гроссбух в HTML — кто, куда, сколько мегабайт и во сколько часов ночи. Инструменту уже прилично лет, и об этом стоит сказать прямо, без утайки — но, как многие старые паровые механизмы, он всё ещё крутится в цехах, если знать, где смазать и куда не совать пальцы.

Зачем это вообще нужно в эпоху HTTPS

Кэшировать HTTPS-трафик Squid толком не может — весь смысл шифрования в том, что содержимое видит только браузер и сервер. Экономия канала, ради которой Squid массово ставили ещё десять лет назад, почти сошла на нет.

Но задача “кто и куда ходит” никуда не делась. Школы, офисы с контент-фильтрацией, провайдеры с биллингом по трафику, домашние роутеры на базе pfSense/IPFire — везде Squid по-прежнему стоит как прозрачный или явный прокси именно ради контроля и учёта, а не ради кэша. И вот для этого сценария SARG остаётся рабочей лошадкой: он не требует базы данных, не жрёт память демоном в фоне, просто раз в час перемалывает лог и выплёвывает статичный HTML. Идеально для небольшой инфраструктуры, где ставить Grafana ради одного отчёта — как использовать паровой молот для забивания канцелярской кнопки.

Что должно уже стоять на сервере

Предполагаю, что Squid у вас уже настроен и честно пишет логи в /var/log/squid/access.log — если нет, сначала разберитесь со Squid, потому что SARG сам по себе не proxy и трафик не считает, он только читает чужой дневник.

Проверить, что лог живой и растёт, можно одной командой:

sudo tail -n 20 /var/log/squid/access.log

sudo tail -n 20 /var/log/squid/access.log

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

Установка на Debian / Ubuntu / Linux Mint

Тут всё осталось приятно простым — пакет как лежал в репозиториях, так и лежит:

sudo apt update
sudo apt install sarg -y

sudo apt update
sudo apt install sarg -y

Установка на RHEL-семейство (AlmaLinux, Rocky Linux, Fedora)

Пакета sarg по умолчанию в базовых репозиториях RHEL-клонов нет. Первым делом стоит попробовать EPEL:

sudo dnf install epel-release -y
sudo dnf config-manager --set-enabled crb   # на AlmaLinux/Rocky 9 репозиторий CRB нужен для части зависимостей
sudo dnf install sarg -y

sudo dnf install epel-release -y
sudo dnf config-manager --set-enabled crb   # на AlmaLinux/Rocky 9 репозиторий CRB нужен для части зависимостей
sudo dnf install sarg -y

Если пакета в EPEL для вашей версии не нашлось (случается — сообщество EPEL сопровождает пакеты не всегда синхронно), собираем из исходников — дедовский способ, но рабочий:

sudo dnf groupinstall "Development Tools" -y
sudo dnf install gd gd-devel httpd -y

# Актуальную версию тарбола смотрите на странице проекта:
# https://sourceforge.net/projects/sarg/files/sarg/
wget https://downloads.sourceforge.net/project/sarg/sarg/sarg-2.4.0/sarg-2.4.0.tar.gz
tar -xvzf sarg-2.4.0.tar.gz
cd sarg-2.4.0
./configure
make
sudo make install

sudo dnf groupinstall "Development Tools" -y
sudo dnf install gd gd-devel httpd -y

# Актуальную версию тарбола смотрите на странице проекта:
# https://sourceforge.net/projects/sarg/files/sarg/
wget https://downloads.sourceforge.net/project/sarg/sarg/sarg-2.4.0/sarg-2.4.0.tar.gz
tar -xvzf sarg-2.4.0.tar.gz
cd sarg-2.4.0
./configure
make
sudo make install

Настройка sarg.conf

Файл конфигурации живёт по адресу /etc/sarg/sarg.conf (пакетная установка) или /usr/local/etc/sarg.conf (сборка из исходников). Открываем и правим четыре ключевых рычага:

sudo nano /etc/sarg/sarg.conf

sudo nano /etc/sarg/sarg.conf

Путь к логу Squid:

access_log /var/log/squid/access.log

access_log /var/log/squid/access.log

Куда складывать готовые отчёты (на Debian/Ubuntu веб-корень Apache — /var/www/html, у nginx может отличаться):

output_dir /var/www/html/squid-reports

output_dir /var/www/html/squid-reports

Формат даты в отчётах (e — европейский dd/mm/yy, u — американский):

date_format e

date_format e

И самое важное для повторяющихся запусков — перезаписывать отчёт за уже пройденную дату, а не плодить дубликаты:

overwrite_report yes

overwrite_report yes

Сохраняем, закрываем — переходим к первому запуску.

Первая генерация отчёта

sudo sarg -x

sudo sarg -x

Флаг -x включает подробный вывод — полезно при первом запуске, чтобы видеть, где именно паровая машина может закашляться:

SARG: Init
SARG: Loading configuration from /etc/sarg/sarg.conf
SARG: Reading access log file: /var/log/squid/access.log
SARG: Records in file: 45211, reading: 100.00%
SARG: Records read: 45211, written: 45211, excluded: 0
SARG: Squid log format
SARG: Period: 2026 Aug 04
SARG: Sorting log ...

SARG: Init
SARG: Loading configuration from /etc/sarg/sarg.conf
SARG: Reading access log file: /var/log/squid/access.log
SARG: Records in file: 45211, reading: 100.00%
SARG: Records read: 45211, written: 45211, excluded: 0
SARG: Squid log format
SARG: Period: 2026 Aug 04
SARG: Sorting log ...

Если вместо этого вылетает command not found при подключении по SSH — это классика жанра, почти всегда виновата пересылка локали (LANG/LC_*) с клиентской машины на сервер, где нужных локалей нет. Лечится либо установкой недостающих локалей, либо отключением SendEnv LANG LC_* на клиенте в ~/.ssh/config.

Смотрим результат

Готовые отчёты лежат там, куда указали в output_dir, и открываются через браузер:

http://ip-адрес-сервера/squid-reports

http://ip-адрес-сервера/squid-reports

Автоматизация через cron

Ручками дёргать sarg -x — удел одного вечера. Дальше это должен делать часовой механизм:

sudo crontab -e

sudo crontab -e

Добавляем строку для запуска раз в час:

0 * * * * /usr/bin/sarg -x

0 * * * * /usr/bin/sarg -x

Современные альтернативы, если хочется дальше в будущее

SARG хорош для «поставил — раз в час получил статичный HTML» на небольшой инфраструктуре. Если нужна живая аналитика с фильтрами и без ожидания следующего крон-тика, посмотрите в сторону:

• SquidAnalyzer — идейный преемник, тоже статичные HTML-отчёты, но чуть более современный код и активнее развивается.
• Отправка access.log в связку Grafana + Loki или ELK/Opensearch — если у вас уже крутится стек мониторинга под другие сервисы, довести до него ещё и Squid — вопрос одного конфига Promtail/Filebeat, а не отдельного демона.

Для домашней сети или небольшого офиса — SARG всё ещё абсолютно адекватный выбор. Для растущей инфраструктуры — держите в уме, что это временное решение, а не строительство на века.

Грабли, собранные лично

• Ротация логов и SARG не дружат из коробки. Если logrotate перекладывает access.log в момент, когда SARG его читает, отчёт может получиться урезанным. Разносите время ротации и время генерации отчёта хотя бы на 10–15 минут.
• Сжатые логи SARG понимает сам — .gz, .bz2 и .Z можно скармливать напрямую через -l, распаковывать вручную не нужно.
• Права на output_dir — частая причина пустой директории после “успешного” запуска: веб-сервер должен иметь право читать файлы, которые создал пользователь, от которого запущен SARG. Проще всего сразу назначить владельцем директории отчётов того же пользователя, от чьего имени работает Apache/nginx.