Легковесная веб-аналитика GoatCounter на VDS: развертывание в systemd с SQLite, обход AdBlock и защита доступа в Nginx

Каждый владелец сайта или веб-сервиса сталкивается с дилеммой при выборе инструмента веб-аналитики. Популярные облачные решения вроде Яндекс.Метрики и Google Analytics требуют подключения тяжелых внешних скриптов, сохраняют cookies, передают данные третьим сторонам и принуждают вешать назойливые всплывающие окна согласия (cookie-баннеры). Кроме того, по данным профильных опросов среди разработчиков и системных администраторов, значительная часть технической аудитории (от 25% до 40%) использует uBlock Origin, AdGuard или встроенную защиту Brave, что приводит к слепым зонам в отчетах.

Автономные (self-hosted) альтернативы решают проблему приватности, но часто требуют внушительных аппаратных мощностей. Популярный Matomo работает на связке PHP + MySQL и при умеренном трафике требует от 1 ГБ оперативной памяти, а Plausible опирается на тяжелую колоночную СУБД ClickHouse и рантайм Elixir. На этом фоне GoatCounter выделяется радикальным минимализмом: это монолитный скомпилированный бинарник на языке Go со встроенной поддержкой SQLite, которому для обслуживания проектов достаточно 25–45 МБ RAM (от 25 МБ в простое до 40–45 МБ под активным трафиком).

1. Архитектура GoatCounter: почему Go + SQLite превосходят тяжелые стеки

GoatCounter спроектирован нидерландским разработчиком Мартином Турноем (Martin Tournoij, известный в open-source сообществе под ником arp242, официальный репозиторий github.com/arp242/goatcounter) с акцентом на скорость, низкое потребление ресурсов и уважение к приватности посетителей. В отличие от микросервисных платформ, где для запуска аналитики требуется поднимать Node.js, Redis, ClickHouse или PostgreSQL в Docker Compose, GoatCounter представляет собой полностью самодостаточное приложение:

• Монолитная компиляция: единый исполняемый ELF-файл размером около 16–20 МБ, содержащий внутри оптимизированный веб-сервер, роутер, шаблонизатор и базу данных стран GeoLite2 (также поддерживается подключение внешней базы через флаг -geodb).
• Встроенная СУБД SQLite с WAL: по умолчанию GoatCounter использует SQLite в режиме Write-Ahead Logging (WAL). Это обеспечивает конкурентную запись без взаимной блокировки параллельных запросов на чтение и исключает накладные расходы сетевых сокетов клиент-серверных СУБД.
• Асинхронная буферизация в памяти: входящие запросы фиксации просмотров (хиты) не вызывают немедленный синхронный fsync на диск. Они аккумулируются в кольцевом буфере в оперативной памяти и сбрасываются в SQLite пачками каждые 10 секунд, что снижает нагрузку на NVMe/SSD накопитель до минимума.
• Zero-Cookie и 8-часовая ротация сессий: система принципиально не использует cookies, localStorage или фингерпринтинг Canvas. Уникальность сессии рассчитывается хэшированием IP-адреса и строки User-Agent со специальной солью, которая автоматически ротируется каждые 8 часов (скользящее окно сессии). По истечении этого времени повторные визиты того же пользователя учитываются как новая сессия, что исключает возможность долгосрочного профилирования.

2. Плюсы и минусы GoatCounter для вебмастера и сисадмина

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

3. Установка бинарника GoatCounter и инициализация базы SQLite

Для развертывания используется актуальный стабильный релиз GoatCounter v2.7.0 (архитектура Linux amd64). Установка выполняется в изолированный каталог непривилегированного пользователя операционной системы, что полностью исключает запуск сервиса от имени root.

Создадим выделенного системного пользователя без права интерактивного входа по паролю и подготовим файловую структуру:

# Создание системного пользователя analytics
sudo useradd -r -m -d /opt/goatcounter -s /usr/sbin/nologin analytics

# Создание каталогов для бинарника и базы данных SQLite
sudo mkdir -p /opt/goatcounter/{bin,db}
sudo chown -R analytics:analytics /opt/goatcounter

Загрузим скомпилированный бинарный архив с официальной страницы релизов GitHub. Автор публикует готовые исполняемые файлы в виде сжатых архивов .gz (например, goatcounter-v2.7.0-linux-amd64.gz):

# Загрузка актуального релиза v2.7.0 (Linux amd64)
cd /tmp
curl -sSL "https://github.com/arp242/goatcounter/releases/download/v2.7.0/goatcounter-v2.7.0-linux-amd64.gz" -o goatcounter.gz

# Распаковка и перемещение в рабочий каталог
gunzip -f goatcounter.gz
sudo mv goatcounter /opt/goatcounter/bin/goatcounter
sudo chmod 755 /opt/goatcounter/bin/goatcounter
sudo chown analytics:analytics /opt/goatcounter/bin/goatcounter

# Проверка работоспособности бинарника
/opt/goatcounter/bin/goatcounter version

Следующим шагом создаем базу данных SQLite и регистрируем корневой сайт аналитики вместе с учетной записью администратора. GoatCounter поддерживает команду db create site, где критически важно передать флаг -createdb для автоматического создания файла базы на чистой системе:

# Инициализация базы данных и создание сайта с учетной записью администратора
sudo -u analytics /opt/goatcounter/bin/goatcounter db create site   -createdb   -db=sqlite+/opt/goatcounter/db/goatcounter.sqlite3   -vhost=syskit.ru   -user.email=admin@syskit.ru   -user.password="SysKitStrongSecret2026!"

4. Настройка службы systemd с жесткой песочницей и лимитом памяти

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

Создадим юнит-файл /etc/systemd/system/goatcounter.service:

[Unit]
Description=GoatCounter Lightweight Web Analytics
After=network.target

[Service]
Type=simple
User=analytics
Group=analytics
WorkingDirectory=/opt/goatcounter

# Запуск на локальном порту 8089 с базовым префиксом /analytics
ExecStart=/opt/goatcounter/bin/goatcounter serve   -listen=127.0.0.1:8089   -tls=http   -db=sqlite+/opt/goatcounter/db/goatcounter.sqlite3   -base-path=/analytics

Restart=always
RestartSec=5s

# Песочница безопасности systemd
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=read-only
ReadWritePaths=/opt/goatcounter/db
PrivateTmp=true

# Лимиты ресурсов cgroups v2
MemoryMax=64M
MemoryHigh=50M

[Install]
WantedBy=multi-user.target

Разберем ключевые директивы конфигурации:

• -listen=127.0.0.1:8089 — сервис привязывается строго к петлевому интерфейсу localhost. Прямой доступ к порту 8089 из интернета полностью заблокирован.
• -base-path=/analytics — указывает GoatCounter, что интерфейс и трекер работают во внутреннем подкаталоге сайта (например, https://syskit.ru/analytics/).
• ProtectSystem=full — монтирует системные каталоги /usr, /boot и /etc в режиме «только для чтения».
• ReadWritePaths=/opt/goatcounter/db — разрешает запись исключительно в директорию базы данных SQLite, предотвращая модификацию любых других файлов на диске.
• MemoryMax=64M — защищает сервер от случайных утечек памяти: процесс гарантированно не сможет потребить больше 64 МБ RAM.

Применим изменения, активируем автозагрузку и запустим сервис:

sudo systemctl daemon-reload
sudo systemctl enable --now goatcounter.service

# Проверка статуса и использования памяти
systemctl status goatcounter.service

5. Требования к VDS и аппаратные ресурсы

Поскольку GoatCounter скомпилирован в машинный код Go и не использует виртуальные машины рантайма вроде JVM или Node.js, системные требования к серверу минимальны. Однако производительность аналитики напрямую зависит от скорости операций ввода-вывода (IOPS) дисковой подсистемы, так как SQLite активно использует дисковые страницы для поддержания целостности транзакций.

Для надежного размещения рекомендуется выбирать виртуальные серверы с быстрыми накопителями NVMe и стабильной сетевой связностью в проверенных дата-центрах.

6. Почему блокировщики режут аналитику и принцип first-party маскировки

Владельцы сайтов технической и IT-направленности часто теряют до 30–40% реального трафика в отчетах аналитики. Популярные блокировщики (uBlock Origin, AdGuard, Brave Shields, Pi-hole) используют открытые списки фильтрации — в первую очередь EasyList, EasyPrivacy и Peter Lowe’s Ad Server List. Блокировка происходит по двум фундаментальным механизмам:

1. Блокировка по доменному имени: если скрипт подгружается со стороннего сервера (third-party), например gc.zgo.at или mc.yandex.ru, сетевой запрос отклоняется браузером еще на этапе DNS или инициализации соединения.
2. Блокировка по сигнатурам URL и путям: если имя скрипта или эндпоинт сбора содержат распространенные шаблоны (/count.js, /goatcounter.js, /analytics.js, /pixel.gif), правило регулярного выражения блокировщика перехватывает запрос даже на вашем собственном домене.

Для восстановления полноты метрик мы настраиваем First-Party Reverse Proxy в Nginx, который решает сразу три задачи:

• Служебное имя файла: скрипт отслеживания отдается по адресу /assets/js/telemetry.js. Для браузерных фильтров по умолчанию он выглядит как штатный технический бандл сайта.
• Внутренний API-эндпоинт: сбор аналитических данных выполняется методом Beacon/POST на внутренний роут /api/telemetry/count.
• Отсутствие CORS и внешних DNS-запросов: все запросы идут на тот же домен первого уровня (first-party context), не вызывая подозрений у стандартных эвристических алгоритмов.

7. Конфигурация Nginx: проксирование трекера и двухконтурная защита дашборда

На стороне фронтенд-сервера Nginx нам необходимо разделить публичный трафик (скрипт и прием хитов) и защищенную административную панель. Панель GoatCounter ни в коем случае нельзя оставлять открытой в общий доступ.

Мы применим двухконтурную защиту и Rate Limiting:

1. Контур 1 (Уровень Nginx): ограничение доступа через auth_basic (HTTP Basic Authentication). Защищает приложение от ботов, сканеров уязвимостей и попыток подбора пароля еще до того, как запрос коснется рантайма Go.
2. Контур 2 (Уровень GoatCounter): штатная авторизация по логину и паролю администратора.
3. Защита от флуда (Rate Limiting): ограничение частоты запросов к эндпоинту телеметрии, защищающее SQLite от DoS-атак.

Сначала сгенерируем файл с хэшированным паролем с помощью утилиты htpasswd (пакет apache2-utils):

# Установка утилиты htpasswd при необходимости
sudo apt-get install -y apache2-utils

# Генерация файла паролей с надежным алгоритмом хэширования
sudo htpasswd -bc /etc/nginx/.htpasswd_stats admin_user "SuperSecretPassword2026!"
sudo chmod 640 /etc/nginx/.htpasswd_stats
sudo chown root:www-data /etc/nginx/.htpasswd_stats

Теперь создадим конфигурационный файл Nginx (например, в /etc/nginx/conf.d/goatcounter.conf или в секции server 443 ssl вашего сайта):

# Ограничение частоты запросов от одного IP (15 запросов в секунду)
limit_req_zone $binary_remote_addr zone=telemetry_limit:10m rate=15r/s;

# 1. First-party скрипт отслеживания (маскировка под служебный бандл)
location = /assets/js/telemetry.js {
    proxy_pass http://127.0.0.1:8089/analytics/count.js;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    
    # Кэширование скрипта в браузере на 1 сутки
    expires 1d;
    add_header Cache-Control "public, no-transform";
}

# 2. Эндпоинт отправки статистики (маскировка под внутреннее API)
location = /api/telemetry/count {
    # Защита от флуда и бот-трафика
    limit_req zone=telemetry_limit burst=30 nodelay;

    proxy_pass http://127.0.0.1:8089/analytics/count;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    
    # Отключение буферизации для мгновенной доставки Beacon-запросов
    proxy_buffering off;
}

# 3. Закрытый дашборд аналитики (двойной контур защиты)
location /analytics/ {
    auth_basic "SysKit Analytics Protected Area";
    auth_basic_user_file /etc/nginx/.htpasswd_stats;
    
    proxy_pass http://127.0.0.1:8089;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_buffering off;
}

# Корректный 301-редирект при обращении без замыкающего слэша
location = /analytics {
    return 301 https://$host/analytics/;
}

Проверим корректность синтаксиса и перезагрузим веб-сервер:

sudo nginx -t
sudo systemctl reload nginx

Если вы настраиваете чистый Nginx или хотите проверить заголовки безопасности, используйте готовый конфигуратор Nginx Reverse Proxy на SysKit, а также онлайн-утилиту SSL Чекер для проверки валидности сертификата.

8. Подключение скрипта на сайт, проверка сетевых запросов и аудит базы данных

Для активации сбора аналитики достаточно добавить одну строку в шаблон вашего веб-приложения или CMS (обычно в файл подвала перед закрывающим тегом </body>):

<!-- Автономная веб-аналитика (First-party телеметрия без cookie, обход блокировщиков) -->
<script data-goatcounter="https://vash-domen.ru/api/telemetry/count" async src="/assets/js/telemetry.js"></script>

Атрибут data-goatcounter указывает JS-скрипту, на какой адрес отправлять телеметрические пакеты. Скрипт выполняется в асинхронном режиме (async), благодаря чему загрузка страницы и отрисовка контента происходят без задержек.

Проверим корректность работы сквозного контура:

1. Откройте сайт в браузере в режиме инкогнито со стандартным фильтром uBlock Origin или AdGuard.
2. Откройте панель разработчика (F12) на вкладке Network (Сеть).
3. Убедитесь, что файл telemetry.js загружен со статусом 200 OK и типом javascript, а на адрес /api/telemetry/count отправлен запрос методом POST (sendBeacon) или GET со статусом 200 OK.

Теперь проверим фиксацию данных в базе SQLite. Важно помнить, что GoatCounter накапливает входящие хиты в оперативной памяти и сбрасывает их на диск пачками с интервалом около 10 секунд (поэтому новый переход появляется в таблице не сиюсекундно). Выполним инспекцию таблиц paths и hits через Python:

# Проверка зафиксированных страниц и общего количества просмотров в SQLite
sudo python3 -c "
import sqlite3
con = sqlite3.connect('/opt/goatcounter/db/goatcounter.sqlite3')
cur = con.cursor()
print('--- Зафиксированные страницы (paths) ---')
for row in cur.execute('SELECT path, title FROM paths LIMIT 5'):
    print(row)
print('--- Зарегистрировано просмотров в таблице hits ---')
print(cur.execute('SELECT count(*) FROM hits').fetchone()[0])
con.close()
"

9. Резервное копирование SQLite в режиме WAL и траблшутинг

В режиме WAL база данных состоит из трех файлов: основного goatcounter.sqlite3, служебного файла разделяемой памяти goatcounter.sqlite3-shm и журнала упреждающей записи goatcounter.sqlite3-wal. Простое копирование утилитой cp во время активной записи может привести к повреждению данных (corrupted database).

Существует два надежных способа организации бэкапов SQLite:

1. Точечные снимки через VACUUM INTO: встроенная команда SQLite создает атомарный консистентный файл без блокировки читателей и писателей.
2. Потоковая непрерывная репликация через Litestream: специализированная утилита, которая перехватывает WAL-фреймы в реальном времени и стримит их в S3-хранилище с RPO менее 1 секунды.

Создание горячего резервного снимка командой VACUUM INTO:

# Создание горячего резервного снимка базы данных
sudo sqlite3 /opt/goatcounter/db/goatcounter.sqlite3 "VACUUM INTO '/opt/goatcounter/db/backup_$(date +%Y%m%d_%H%M%S).sqlite3';"

# Проверка целостности созданного бэкапа
sudo sqlite3 /opt/goatcounter/db/backup_*.sqlite3 "PRAGMA integrity_check;"

Для непрерывной репликации в облако достаточно установить Litestream и запустить фоновый процесс, указав бакет S3:

# Пример непрерывной репликации в S3 через Litestream
litestream replicate /opt/goatcounter/db/goatcounter.sqlite3 s3://my-backups-bucket/goatcounter