Любые ресурсы ограничены -- это аксиома. Следовательно нельзя допускать их перерасхода. Особенно остро стоит эта проблема в случае, если ресурсом пользуются несколько человек. В нашем случае таким ресурсом является объем входящего трафика, который, как обычно стремится перерасти все отведенные для него пределы. Таким образом весь рост встает вечный вопрос -- что делать и кто виноват. Интерес далеко не праздный -- наверняка вам знакомы расспросы с пристрастием -- кто же из родственников или сослуживцев скачал оставшиеся на две недели 200 мегабайт за один день?
В этой статье мы поговорим о том, как нам получить от прокси-сервера эту важную статистику -- кто, когда, сколько и откуда выкачал информации. Эту информацию можно получить из лог-файлов прокси-сервера, в которых хранятся сведения о каждой транзакции произведенной сервером. Анализ лог-файла можно проводить разными способами, например загрузив его в таблицу базы данных или например в лист электронной таблицы, однако желательно использовать для этого надежные и удобные инструменты, которые помогут автоматически составить краткий, но очень информативный отчет о пользовании сервером. Таких средств разработано немало. На мой взгляд достойны упоминания следующие: Webalizer ( http://www.webalizer.org) и SARG ( http://web.onda.com.br/orso). Первый удобен для генерации наглядных отчетов, а второй имеет большее их количество и обеспечивает более широкие возможности для глубокого анализа использования пользователями трафика и прокси-сервера.
Изначально Webalizer создавался как быстрый анализатор лог-файлов веб-серверов (таких как Apache), однако он легко может быть перенастроен для анализа лог-файлов прокси-сервера. Webalizer генерирует красивые (с графиками) и информативные отчеты общего характера. Используя Webalizer можно наблюдать изменение параметров во времени (количество запросов к серверу, скачанных файлов, скачанных страниц, посещений, сайтов (ip-адресов клиентов, Кбайт)
Webalizer существует в виде бинарных пакетов для основных дистрибутивов Linux и FreeBSD. Однако этот путь инсталляции применим только для тех, кого устраивает английский язык генерируемых отчетов -- к сожалению локализация Webalizer производится только во время его компиляции.
Для компиляции и установки Webalizer понадобится установленная библиотека GD версии 1.8.x и библиотека FreeType версии 2.x. Компиляция эти библиотек несколько отличается от общепринятой, поэтому их следует установить из бинарных пакетов (они обязательно должны быть в вашем дистрибутиве или на ftp-сервере его производителя).
Процедура компиляции и установки Webalizer с русским интерфейсом проста:
tar xvf webalizer-2.1.tar.gz cd webalizer-2.1 ./configure --with-language=russian --with-etcdir=/usr/local/etc make make install (требуются права root)
Теперь следует откорректировать конфигурационный файл /usr/local/etc/webalizer.conf в соответствии с нашими потребностями. Например:
# Путь к лог-файлу LogFile /usr/local/squid/logs/access.log
# Тип лог-файла LogType squid
# Путь к файлам отчетов OutputDir /var/www/squid
# Выключить график по странам # Если его включить, то мы увидим сплошной зеленый круг # Свидетельствующий о том, что все клиенты принадлежат к одной стране CountryGraph no
# Указание количества позиций в сводных таблицах # По разным пунктам отчетов
# Сайты по посещениям TopSites 30
# Сайты по объему трафика TopKSites 10
# Конкретные ссылки по посещениям TopURLs 30
# Конкретные ссылки по объему трафика TopKURLs 10
# Пользователи по объему трафика TopUsers 20
# Запретить генерацию бесполезных отчетов TopReferrers 0 TopAgents 0 TopCountries 0 TopEntry 0 TopExit 0 TopSearch 0
Теперь Webalizer готов к работе: результатом команды
webalizer
будет сгенерированный отчет по использованию прокси-сервера, находящийся в каталоге /var/www/squid.
Анализатор SARG (Squid Analysis Report Generator), как следует из названия является специализированным генератором отчетов для прокси-сервера squid. На мой взгляд он дает значительно более точную картину использования трафика и сервера (например SARG генерирует отчет по пользователям/ip-адресам и времени дня, что позволяет видеть сколько каждый пользователь в качает в определенные часы). Однако SARG не хватает наглядности -- он не использует в отчетах графики (впрочем с этим можно мириться). Вторым существенным недостатком SARG является сравнительно низкая производительность -- он пожалуй на порядок уступает Webalizer в скорости обработки лог-файла.
SARG доступен в виде бинарного RPM-файла ( http://ptt.mcl.ru/orso), а так же в виде исходных кодов ( http://web.onda.com.br/orso/sarg-1.1.1.tar.gz)
Компиляция SARG не вызывает затруднений:
tar xvf sarg-1.1.1.tar.gz cd sarg-1.1.1 ./configure make make install
По умолчанию SARG инсталлирует конфигурационные файлы в директорию /usr/local/sarg. Файл называется sarg.conf. Следует отредактировать его в минимально подходящую форму:
# Русский язык language Russian_koi8
# Укажем местонахождение лог-файла access_log /usr/local/squid/logs/access.log
# Укажем местонахождение отчетов output_dir /var/www/squid
# Заголовок страницы отчета title "Статистика доступа к прокси-серверу"
# Почтовый адрес на который будет отправляться отчет output_email admin@my.net.ru
# Если у машин вашей сети есть DNS-имена, следует # Разрешить разрешение имен resolve_ip yes
# Европейский формат даты (по-умолчанию -- американский) date_format e
# Утилита для отправки почты mail_utility mail
# Сортировка списка популярных сайтов по трафику # В порядке убывания topsites_sort_order BYTES D
# Разрешенные отчеты # topsites показывать сайты, запросы и трафик # sites&users показывать какие пользователи ходили на сайт # date/time показывать использованный трафик по дням и часам # denied показывать полные ссылки на сайты с отказанным доступом # auth_failures - показывать ошибки аутентификации report_type topsites sites&users date/time
# Используемая таблица символов charset Koi8-r
SARG готов к работе. Запуск осуществляется командой
sarg
после чего через некоторое время будет сгенерирован отчет в каталоге /var/www/squid.
Итак в данный момент мы научились создавать отчеты содержащие информацию о том, с какого ip-адреса сколько трафика было скачано. К сожалению, если одной машиной пользуются несколько человек, мы не сможем сказать сколько скачал каждый из них. А если в вашей сети используется протокол автоматического присваивания ip-адресов DHCP, то эти отчеты вообще не будут нести никакой практической ценности -- ip-адрес в такой сети может время от времени меняться произвольным образом.
Таким образом для персонификации пользователей (а так же вообще для контроля доступа к прокси-серверу) следует воспользоваться предоставляемой squid возможностью базовой аутентификации (логин/пароль, передаваемые открытым текстом). Однако надо помнить о возможном перехвате логинов и паролей излишне любопытными пользователями, к сожалению простых и недорогих способов решения этой проблемы не существует -- это либо покупка дорогостоящих коммутаторов (switch), либо административные меры воздействия.
Для организации персонализированного доступа к прокси-серверу необходимо воспользоваться программной ncsa_auth поставляемой в исходных кодах в дистрибутиве исходных кодов squid в каталоге auth_modules/NCSA. Модуль легко компилируется и инсталлируется:
make make install
Теперь необходимо внеси следующие изменения в конфигурационный файл squid.conf:
# Правила доступа к прокси-серверу acl domainusers proxy_auth REQUIRED http_access allow domainusers
# Укажем аутентификационный модуль authenticate_program /usr/local/squid/bin/ncsa_auth /usr/local/squid/etc/passwd
В качестве файла паролей используется /usr/local/squid/etc/passwd, в принципе вместо него можно воспользоваться файлом /etc/master.passwd с соответствующими правами доступа, однако делать так ни в коем случае не следует :-) если конечно вы хотя бы немоного опасаетесь компрометации всех ваших паролей.
Самый простой способ создания такого файла заключается в использовании программы htpasswd из комплекта веб-сервера Apache следующим образом:
htpasswd /usr/local/squid/etc/passwd username
где username имя пользователя. После запуска (первый запуск должен проходить с ключом -c) программа запросит пароль, после его ввода сведения о пользователе заносятся в указанный файл.
Теперь при попытке обращения к прокси-серверу в браузере появится окошко для ввода пароля и имени пользователя, и если они верные доступ будет открыт. Таким образом в отчетах анализаторов лог-файлов трафик будет учтен по пользователям, что нам и требовалось.
Строго говоря для анализа лог-файлов прокси-сервера squid можно использовать любой анализатор логов для веб-серверов, который "понимает" стандартный NSCA-формат лог-файла. Однако из-за специфики отчетов таких анализаторов они не всегда могут давать адекватную картину использования прокси-сервера. Впрочем если вас устраивают отчеты генерируемые анализатором логов веб-сервера вам необходимо настроить squid для генерации веб-подобного лог-файла. За это отвечает параметр emulate_httpd_log файла конфигурации squid.conf. Для включения эмуляции лога веб-сервера следует установить этот параметр в состояние "on".
Следует отметить, что через некоторое время объем анализируемой информации (размер лог-файла) возрастет настолько, что даже быстрый Webalizer будет справляться с ее анализом довольно долгое время. Самым простым методом борьбы с размером лог-файлов является так называемая ротация лог-файлов -- процесс в результате которого лог-файл через определенные промежутки времени закрывается, переименовывается, возможно архивируется и на его месте начинается новый лог-файл. Если скорость роста лог-файла не велика, удобно проводить ротацию лог-файла прокси-сервера раз в месяц при помощи демона cron выполнив следующую команду (от имени пользователя root):
crontab -e
и, воспользовавшись запустившимся редактором добавить в конец файла строку:
0 0 1 * * /usr/local/squid/bin/squid -k rotate
после чего выйти, предварительно сохранив файл. Таким образом мы заставили cron запускать squid с опцией ротации лога первого числа каждого месяца в ноль часов. По умолчанию в результате ротации squid создает максимально 10 лог-файлов, прибавляя к имени файла точку с цифрой, причем большая цифра соответствует более старому файлу.
Для контроля максимального количества лог-файлов в конфигурационном файле присутствует параметр logfile_rotate с числовым параметром, означающим максимальное количество одновременно существующих лог-файлов. При превышении количества лог-файлов над указанным в конфигурационном файле, старые лог-файлы замещаются новыми. Комментарии: 0 Отправить другу |