Ключевые слова:ipcad, statistic, log, traffic, (найти похожие документы)
From: Laja aka GNU
Newsgroups: email
Date: Mon, 23 Aug 2006 14:31:37 +0000 (UTC)
Subject: Пример сриптов для учета трафика
Все упоминаемые скрипты можно взять с http://laja.hotbox.ru/trafst/trafst.tgz
или http://www.opennet.me/soft/trafst.tgzДАНО
Шлюз на базе FreeBSD 4.11. Настроенный файервол ipfw, используется
natd (divert правила в файерволе). Правила файервола - в /etc/firewall.conf.
ЦЕЛЬ
Необходимо замерять трафик на шлюзе. Нагрузка на шлюз по возможности
должна быть минимальной. Файлы не должны занимать много места на
диске.
МОТИВАЦИЯ
Аппаратная платформа шлюза слабая. Задачу предпочтительно решать так,
чтобы на шлюзе не требовалось ставить никаких сложных СУБД, биллингов
и т.п. Отчеты предполагается хранить на другой машине во внутренней
сети.
РЕШЕНИЕ
Первоначально автором задача решалась с использованием связки ipcad +
qbe1t (http://sf.net/projects/qbe1t) + скрипты. Однако, хранение
данных о трафике, собранных коллектором ipcad, в текстовом виде
и последующий их анализ утилитой qbe1t, оказался процессом долгим
и не очень гибким. Было решено собранную информацию о трафике все-таки
хранить в неком бинарном виде, запросы к которой будут производиться
гораздо быстрее. Кроме того, бинарный формат займет на диске меньшее
место.
Можно было бы написать свои программы для работы с таким простым
бинарным форматом, однако было решено использовать имеющийся софт.
Запросы подразумевали аггрегацию, группировку данных, наложение
сложных условий, поэтому требовалась поддержка простого и лаконичного
языка запросов, на сегодня это пока еще SQL.
Установка СУБД для поддержки SQL была крайне нежелательной. В качестве
альтернативы был выбран продукт sqlite.
Для написания своих скриптов используется язык Python. Для доступа к
файлу данных sqlite из скриптов Python требуется библиотека (bind)
pyslite.
Отчеты было решено хранить на выделенном сервере, а на шлюзе хранить
информацию с коллектора (ipcad) в сжатом виде на ограниченный срок, после
истечения которого удалять ее (при необходимости можно информацию
с коллектора также сбрасывать на выделенны сервер, однако необходимо
на нем следить за ней, т.е. организовать ротацию или сброс резервной
долгосрочной копии).
Т.о. схема работы выстроилась такая:
1. Коллектор ipcad собирает информацию
2. Раз в N мин. собираем эту информацию в одном файле (ipcad.db)
3. Раз в месяц по собранной информации за месяц строим отчеты и
отсылаем их по FTP на выделенный сервер, информацию с коллектора
компрессируем и храним указанное число дней. По их истечению -
удаляем эти файлы.
ДОПОЛНИТЕЛЬНОЕ ПО
Для решения задачи требуется добавить некоторое программное обеспечение:
* empty с http://empty.sourceforge.net/ (c) Михаил Захаров
утилита для запуска и иммитации интерактивного взаимодействия с
программами, которые требуют от пользователя ввода каких-л. команд
* ipcad с http://lionet.info/ipcad/ (c) Лев Валкин
коллектор трафика
* python с http://python.org (с) Гвидо ван Россум
интерпретатор языка Python
* sqlite с http://www.sqlite.org/ (c) Ричард Хипп
библиотека для работы с простой однофайловой БД через SQL
* pysqlite с http://initd.org/tracker/pysqlite (c) Герхард Хэринг
bind для sqlite-библиотеки к языку Python
СХЕМА БД
Файл БД будет называться /var/log/ipcad/ipcad.db. В нем будут созданы
две таблицы: stat и dump. В таблице stat будет хранится общая информация
(счетчики ipfw для входного/выходного трафика и т.п.), в таблице dump - вся
информация, собранная по трафику коллектором ipcad.
#sqlite3 /var/log/ipcad/ipcad.db
SQLite version 3.3.7
Enter ".help" for instructions
sqlite> .schema stat
CREATE TABLE stat(
ipfw_in_p int,ipfw_in_b int,ipfw_out_p int,ipfw_out_b int,ipcad_stat text, date int);
sqlite> .schema dump
CREATE TABLE dump(
src text,dst text,packets int,bytes int,srcport int,dstport int,proto int, if text,date int);
Как видно, используются только два типа данных: text и int. Адреса хранятся
как текст в виде: '192.168.1.1', напр. Дата - это момент времени, когда был
сброс информации, т.о. у всех пакетов, прошедших за N минут (дискретизация
"сброса" данных в ipcad.db) будет одно время. Оно имеет тип int и хранится
в виде 150915, что значит 15-ое число 09:15. Месяц не записывается, т.к.:
1) "дискретизация" сброса общей статистики = 1 мес
2) Сброшенная статистика содержит в имени файла (в виде суффикса) месяц
и год
Остальные поля тривиальны:
ipfw_in_p - счетчик пакетов на входящем (divert) правиле ipfw
ipfw_in_b - счетчик байт на входящем (divert) правиле ipfw
ipfw_out_p, ipfw_out_b - аналогично
ipcad_stat - текст, выдаваемый ipcad-ом при вводе rsh 127.0.0.1 stat
Поля таблицы dump - это колонки вывода ipcad-а при rsh 127.0.0.1 sh ip acco
ОПИСАНИЕ РАБОТЫ
Собственно оно уже вырисовывается. Раз в 7 мин по cron-у происходит
сброс данных с коллектора ipcad в /var/log/ipcad/ipcad.db (каталог
должен быть создан самостоятельно!) при помощи скрипта traffl.sh,
вызывающей программу trafstfl.py. Раз в месяц происходит (опять же
по cron) вызов скрипта trafst.sh, который вызывает программу
m4 для генерации по шаблону файла-отчета в HTML-формате.
Запросы исполняет программа trafstq.py, которая выводит результаты
запросов в виде HTML таблиц. В качестве приятного бонуса она "умеет"
выводить результаты любых запросов в виде HTML-таблиц в HTML-документе
либо просто в виде текстового файла. Файл отчет - это HTML документ,
который имеет вид traf.08.2006.html, напр. (месяц, год!). После своего
формирования он отправляется на выделенный сервер по FTP при помощи
утилиты empty. Трафик (ipcad.db) зажимается, имя зажатого файла также
включает суффикс с датой; создается новый ipcad.db.
СКРИПТЫ
Скрипты лежать на http://laja.hotbox.ru/trafst/trafst.tgz
или http://www.opennet.me/soft/trafst.tgz
Все необходимое находится в каталогах:
./usr - что нужно скопировать в /usr
./etc - что нужно скопировать в /etc
crontab - это содержимое crontab-файла, для "автоматизации" исполнения
в нужное время нужных скриптов.
trafst.sh, known_hosts нужно подправить по своему усмотрению.
ВЫВОД
Установка данного софта крайне проста и не требует много времени.
Конфигурация также максимально проста. Скорость работы высока,
устанавливаемый дополнительный софт занимает крайне мало дискового
пространства. Пожалуй, это очень экономичное решение поставленной
задачи. Данное решение применимо только в SOHO.
Запуск происходит из-под cron-а, который запускает главные
скрипты, написанные на shell. Далее, они используют в качестве
инструментария скрипты, написанные на Python. Такая схема
позволяет легко добавить параллельный анализ статистики через,
например, NetFlow: для этого нужно лишь дополнить Shell-скрипт
trafst.st, который помимо основной своей работы должен "сбросить"
по NetFlow очередную порцию информации с коллектора ipcad на
какую-нибудь машину с установленной биллинговой системой, последняя
может в конце концов даже взаимодействовать с используемой у вас 1С.
БЛАГОДАРНОСТИ
Всем людям, имена которых перечислены после (c), а также персонально
Льву Валкину за оказанную помощь в правильной настройке ipcad!
LICENSED
GNU LGPL - на всякий случай ;)
1) Признаюсь, видел много критики против trafd и поэтому не решился на его использование. Да и ipcad выглядит (чисто субъективно) более зрелым и "стандартным".
2) Скрипты на Перле/Питоне - это был первоначальный позыв, однако, все же некая "база" с SQL интерфейсом оказывается более предпочтительной, особенно когда нужно "поднять" старый трафик и выяснить какой-то вопрос, например, такого-то числа лазил ли такой-то туда-то... Такое бывает ;)
Ну а без учета 1) и 2) я думаю Ваш вариант еще более "экономичен" :)
У меня стоит FreeNIBS+MPD+ MYSQL+SQUID+IPFW+NATD+APACHE(php,mod-ssl,mod-decirity) на одной машине Пентиум 166Мгц, и отлично работает, не надо изобретать велосипед заново!
Хм, неконструктивные замечания. Хотя я специально заострял на етом внимание. Повторюсь: предложите более экономный способ? Вы говорите MySQL, Apache?! :) Что тяжелее: 1 кг или 100 кг? :) ИМХО предложенный мною способ - самый экономичный. Экономичнее, видимо, не бывает. А возражения вида "а у меня Apache+MySQL и все работает, зачем же мне еще один способ?" непринимаются, ибо к делу ну совсем даже не относятся :)
В моем случае было бы предпочтительнее использовать MySQL, т. к. этот шлюз еще и веб-сервер (Apache&php&MySQL), буду рад, если кто-нибудь подскажет приемлемый вариант.