Система учета интернет-трафика

Ну то как нащот того что я написал?

kisil написал:

Ну то как нащот того что я написал?

Ну вообще то веб-интерфейс trafstat активно отправляет запросы к DNS серверу, разрезолвивает DNS-имена удаленных серверов. Если у тебя не было запросов из контролируемой под сети к внешнему миру, то DNS-имена и не будут появляться.

У тебя вообще стоит какой нибудь кеширишующий DNS-сервер на шлюзе?

Вот возник такой вопрос. Чисто на досуге. А какое применение автор видит своему детищу? Какой масштаб?

Просто я тоже пишу подобный проект. Но меня пугают объёмы, как оказывается, не нужной информации.

Serg79 написал:

[quote=kisil]Ну то как нащот того что я написал?

Ну вообще то веб-интерфейс trafstat активно отправляет запросы к DNS серверу, разрезолвивает DNS-имена удаленных серверов. Если у тебя не было запросов из контролируемой под сети к внешнему миру, то DNS-имена и не будут появляться.

У тебя вообще стоит какой нибудь кеширишующий DNS-сервер на шлюзе?[/quote]
на шлюзе поднятый кешырующий ДНС. Ты прав я заметил что он правильно разрешает имя-айпи, а айпи-имя вроде как нет. Я это заметил на днях, когда ознакомлялса с твоим проэктом, но просто щас нету времени розобратса. У меня командировки по 2 штуки на неделю. вот разберусь с нагальными проблемами тогда розберусь с обратной зоной в ДНС.
Я вообщето спрашывал не это а вот что

serg79 как на меня инфа про порти нужна. Но что я хочу сказать. Может луче будет складать в базу инфу только про компи локальной сети. ну например по ip 192.168.0.1-192.168.0.254 и все. И чтобі сохраналлась инфа про ети адреса куда и скока они ходили.
вот например:
В прикрепленом файле есть инфа по айпишниках моей сети куда и сколько они стянули но тут и естя инфа про сервер с адресом 95.25.53.171. Зачем нужна сберегать инфу про етот сервер.

kisil, на счет разделения хранения портов, для одних хостов хранить а для других нет, думаю не целесообразно. Это нужно будет иметь тогда две таблицы в одной будут порты в другой нет. Если хранить в одной таблице, то вводить дополнительный флаг указывающий что поле "порт" не используется. Короче как то все это криво.

Тут оптимальней принять решение: хранить или не хранить. Я решил хранить информацию о запрашиваемых портах.

А как нащот логирования инфы только для определёных айпишок указаных самим админом. Или это я что то загнул слишком. :(

zerg написал:

Вот возник такой вопрос. Чисто на досуге. А какое применение автор видит своему детищу? Какой масштаб?

Zerg, не пойму твои вопросы. В качестве применений это в названии темы. Какой масштаб, это время покажет. Но мне еще много чего хочется добавить в систему.

Сейчас у меня на повестке одна главная задача, как можно сильней уплотнить хранимые данные. В идеале статистика за год не должна превышать 1 Гбайт для 50 контролируемых хостов. Далее хочу добавить разбиение вывода таблиц статистики на страницы (а то таблица с 1500 записями разрезолвивает DNS-имена слишком долго), но это чисто техническая задача и не требует обдумывания организации хранения данных. Вот эти основные задачи, можно сказать, подведут черту под версией 0.1.

В следующей версии планирую добавить ограничения по использованию Интернет ресурсов. То есть, добавить возможность выдавать пользователям например 50 Мбайт на неделю и если пользователь их израсходовал, закрывать ему интернет до конца недели.

Как то так zerg. Да вообще проект можно развивать и совершенствовать бесконечно. Лично я вижу большой потенциал по развитию функционала.

kisil написал:

А как нащот логирования инфы только для определёных айпишок указаных самим админом. Или это я что то загнул слишком. :(

А зачем выделять отдельные IP в качестве объектов наблюдения? Для коллектора трафика все IP-одинаковы. Лучше добавить фильтр в веб-интерфейс, который позволяет просматривать инфу только по конкретному IP.

Serg79 написал:

[quote=kisil]А как нащот логирования инфы только для определёных айпишок указаных самим админом. Или это я что то загнул слишком. :(

А зачем выделять отдельные IP в качестве объектов наблюдения? Для коллектора трафика все IP-одинаковы. Лучше добавить фильтр в веб-интерфейс, который позволяет просматривать инфу только по конкретному IP.[/quote]
Верно. Вот что я имел ввиду но не мог высказать. oO

Serg79 написал:

(а то таблица с 1500 записями разрезолвивает DNS-имена слишком долго)

разве резолв идёт в момент после дампа в БД?

system-root написал:

разве резолв идёт в момент после дампа в БД?

Нет, резолв идет на странице показывающей "статистику запрашиваемых удаленных серверов", т.е. в веб-интерфейсе.

Система предполагает авторизацию пользователей по IP+MAC.
То есть:
ты, как администратор, вбиваешь ручками IP(mac) адрес и это пользователь может выходить в инет.
Юзеры, которые не внесены в список пользователей (их IP(mac)- адреса не занесены в базу програмулинки) НЕ имеют доступа в инет.

Изменил структуру таблицы хранящей трафик (#45), теперь данные должны занимать процентов на 35% - 40% меньше места. Но еще предстоит решить проблему уплотнения старых данных (#44).

kisil, если есть возможность погонять новый вариант, то сделай это плиз. Брать лучше всего последнюю актуальную версию с trunk-a.

Да еще, на данный момент скрипт выгружающий трафик игнорирует все протоколы кроме TCP и UDP, в дальнейшем это планируется исправить, и по этому для коллектора лучше добавить ограничение на диапазон снимаемого трафика. У меня так он настроен:
Файл: /etc/trafd/trafctl.conf

trafd_eth0_expression="(tcp and (portrange 1-1023 and not broadcast)) or (udp and (portrange 1-1023 and not broadcast))"

Я попробую только не понял откуда стянуть новую версию.?
:D

kisil написал:

Я попробую только не понял откуда стянуть новую версию.?
:D

Загружай последнюю версию прям с репозитария. Загружать надо с рабочей (trunk) ветки, там всегда находится самая последняя версия.

Загрузить можно следующей командой:

svn co http://svn.shelek.su/public/trafstat/trunk/

В дальнейшем что бы обновиться до самой последней версии достаточно будет выполнить команду:

svn update

Да еще, там структура таблицы 'traffic' в базе изменилась, так что базу лучше будет пересоздать. Если необходимо переконвертировать старые данные, то есть скрипт 'convTrafTable.pl' который переносит данные из таблицы 'traffic' в старой базе, в таблицу 'traffic' новой базы.

Serg79 написал:

Нет, резолв идет на странице показывающей "статистику запрашиваемых удаленных серверов", т.е. в веб-интерфейсе.

нужно сделать наоборот, т.е. дампить уже отрезолвенные имена.
почему?
1) данные уже не изменятся и не введут в заблуждение
2) не будет "узкого" места.

system-root, ну я так не думаю. Во первых, хранение IP-адресов в базе занимает меньше места, так как IP-адрес можно представить в виде 'uint32' и все строки в таблице фиксированного размера. Во вторых поиск по IP-адресу в базе выполняется на порядок быстрее, чем если бы поиск шел по строкам (DNS-имена). Да и коллектор трафика работает на уровне IP-адресов.
А быстродействие резолва решается поднятием на системной машине кеширующего DNS-сервера, довольно быстро большинство DNS-имен осядет в кеше и разрезолвивание будет выполнятся на порядок быстрее.

кеширование работает только до перезагрузки.
зачем искать по DNS-именам если можно просто совмещать [UNIQUE]IP=[UNIQUE]DNS? или это не возможно?

Маленькая просьба по web интерфейсу:
указать что базу создавать надо в кои8 кодировке и просьба добавить после установления связи с базой строку:

mysql_query("SET NAMES 'koi8r';");

- установка кодировки связи с базой

Вопрос к пользователям:
- железо: Intel(R) Atom(TM) CPU D510 @ 1.66GHz
- система: Ubuntu Linux 10.04
- ядро: Linux 2.6.32-24-server on x86_64
Система стала с помощью небольшого напильника (в основном пути в скриптах). Поставил сброс статистики через 5 минут в кроне, и ночью случилась беда: видно perl скрипт не успел занести данные в базу и был вызван повторно в результате утром бред в статистике и куча запущенных процессов... :(

кто-то с таким сталкивался?