ОК, давайте обсудим.
Система состоит из парсера, таблиц БД и набора sql- и шелл-скриптов. Вызывается по крону (кронтаб прилагается)
Парсер сделан на С++. Запускается периодически по крону.
Вкратце алгоритм парсера:
1. Считать параметры конфигурации из файла (параметры подключения к БД, место расположения access.log'a)
2. Открыть ассесс.лог;
3. Установить соединение с БД, открыть транзакцию;
4. Для каждой записи ассесс лога:
4.1 Считать поля;
4.2 Укоротить, если нужно, поля, превышающие макс. длину (переполнение буфера не пройдет :);
4.3 Записать данные в БД ("insert into access_log...")
5. Если все ок, то:
5.1 commit transaction
5.2 close database connection
5.3 обнулить файл ассесс.лог
6. В случае ошибки, откатить транзакцию назад (rollback), закрыть ассесс.лог
При возникновении ошибок (нет доступа к ассесс.лог, нет доступа к БД и тд) парсер валит сообщения в syslog
Теперь, о базе. База состоит из следующих таблиц:
access_log - приемник информации из access.logа
daily_logs - "уплотненный" лог
proxy_users - таблица соответствия ip и имен хостов клиентов прокси
friendly_nets - адреса "дружественных" сетей, трафик из которых бесплатный.
Парсер запускается периодически из крона, валит информацию в таблицу access_log.
Раз в сутки (опять же, по крону) вызывается скрипт logrotate, который переливает с информацию в из таблицы access_log в daily_logs, уплотняя ее при этом (отсечение поля url и некоторых других, отсечка хитов, группировка трафика по дате, peerhost, remotehost...). Кроме этого, в таблицу proxy_users добавляются IP новых, ранее не работавших с прокси, пользователей. Им автоматически присваиваются имена "NO_NAME".
для формирования отчетов созданы следующие views:
- users_today - статистика по клиентам за текущие сутки;
- sites_today - статистика по посещенным сайтам за текущие сутки;
- users_daiy, sites_daily - статистика за вчера;
- users_weekly, sites_weekly - статистика за последние 7 дней;
- users_monthly, sites_monthly - статистика c начала месяца.
при формировании отчетов производится фильтрация трафика от "дружественных" сетей. Таблица friendly_nets содержит поле типа inet, может быть наполнена любым количеством записей типа "адрес/маска сети", "адрес хоста" и др. Для того, чтобы организовать фильтрацию, парсер резолвит адрес удаленного хоста (gethostbyname()) и сохраняет его в поле "peerhost_ip" таблицы access.log
Формирование отчетов производится шелл-скриптами run.daily, run.weekly, run.monthly. Отчеты могут быть высланы на указанный в этих скриптах мэйл, а также могут быть опубликованы на локальном http-сервере.
Что есть на сегодняшний день:
- сборка и установка компонент отчасти автоматизированы (make;make install). Почему отчасти - потому что нет проверки наличия требуемых компонент (libpq) и требуется заточка Makefile-а под свое программное окружение;
- создание базы и ее инициализация выполняются вручную (createdb squidlog; psql squidlog< initdb.sql);
- конфиг по-умолчанию и кронтаб прилагаются;
- конфигурирование системы производится вручную, путем правки кронтаба, шелловских скриптов run.* и наполнения таблиц фильтрации и списка клиентов.
Что нужно, на мой взгляд, для "продвижения" продукта в массы:
- запустить проект (sourceforge?)
- полностью автоматизировать процесс сборки и установки, задействовав autoconf, automake;
- разработать тулзы для конфигурирования системы;
- разработать frontend к базе (java?), "подмарафетить" внешний вид публикуемых на http-сервере отчетов;
- организовать сборку бинарных пакетов (deb, rpm...)
- ну и, конечно же, разработать пользовательскую документацию.
Эта система уже набрала приличный опыт боевого применения - работает почти 2 года, обслуживает сеть из ~50 клиентов, "переваривая" в месяц до 10Гиг трафика. Может это и не очень внушительные цифры, но есть возможность для масштабирования, например, за счет размещения БД на выделенном сервере.
Да и вот еще какая мысль: с помощью данной системы легко организовать централизованный учет статистики с нескольких кэшей.
PS: Есть и вариант названия проекта: SALO - Squid Access LOg analyzer (привет землякам :))