В общем, нужно написать демона, который бы считывал количство байт, прошедших через через определенную цепочку iptables (аналог iptables -L some_chain -xvn). Цепочка задается по имени. Если решать задачу "в лоб", то можно просто считать текст, который выдает вызов iptables, и парсить его. А как можно считать информацию напрямую?
Насколько я понял, текстовый вариант ограничит точность счетчика байт 9ю 10чнами цифрами (это неприемлимо), а в iptables она наверняка выше.
Какие есть варианты?

Gluk (Kazan)
Обнулять счетчики.
Время от времени
ОЧевидно, я неточно выразился. Имел в виду - можно ли данные счетчиков получить напрямую, без вызова iptables с последующим парсингом текста?

Вопрос снимаю - полезу ковырять исходники iptables...

Gluk (Kazan)А смысл ? мало гемороев ???
это уровень ядра, а данные будут те-же
Извините, но вопрос был "как получить данные iptables напрямую, без парсинга текста" а не про смысл и др варианты. Просто счетчики считывать придется часто. Плюс у текстового вывода ограничение в 9 цифр - это мало. Потом, мне нужно напрямую.

sanek842
посмотри у iptables действие queue

Большое спасибо.

Gluk (Kazan)
Иногда (очень часто) САМЫЙ главный вопрос - ЗАЧЕМ
Обижайся не обижайся - твое дело :)

Помимо гемороя твое решение будет (скорее всего) не переносимо
Хорошо, обьясняю.
Нужно собрать учетчик траффика, который мог бы сканнить созданные мной цепочки iptables, собирать статистику и (желательно) рисовать реал-тайм график для каждой цепочки, если иксы доступны. Учетчик либо должен работать как демон, либо запускаться кроном. Кроме сборки/хранения статистики нужно получить скорость передачи данных по данной цепочке в данный момент. Единственный вариант получить такие сведения, который мне пришел в голову - это сканнить (не смейтесь) все нужные мне цепочки один раз в секунду. Поэтому и не нравится вариант с постоянным вызовом iptables и считыванием каждый раз текста с последующей обработкой. Плюс не нравится то, что точность подсчета у iptables, как я понимаю, большая, но полное число байт, когда они переваливают за гиг, получить не выйдет (9цифр). Обычно такие вещи (учет траффика) делают (как я понял, полазив по сети) на машине запуском скрипта один раз в сутки. Проблема в том, что машина не работает круглосуточно, а данные iptables во время ребута теряются. (можно, конечно, воспользоваться iptables-save и iptables-restore, но это не поможет, как я понимаю, если машина не работала в тот момент, когда данные должны были сбрасываться на диск).

Соответственно, как я понимаю, в программе должно быть две части:
1) демон - сборщик статистики, который может быть реализован на скриптах и запускаться кроном раз в час.
2) Простенький монитор, например, плагин к gkrellm, который не будет изменять значения счетчиков, а будет просто показывать скорость.

Затык на данный момент именно с монитором. Счетчики явно доступны напрямую, и раз обращаться к ним понадобиться часто, то вариант с вызовом iptables, по-моему, не самый оптимальный.

Возможно, что есть именно такая готовая система, но я такой не нашел, и на 4х форумах полный аналог мне не посоветовали. Так что решил попробовать собрать свое.

Насчет переносимости - делаю только для себя, на свою машину.

miksoftВозможно, я ошибаюсь или у меня устаревшие сведения, но счетчики в iptables 32-разрядные, т.е. те самые 9 цифр. И где-то мне попадался на глаза патч, который делает их 64-разрядными.
Простите, 32бита вмещают приблизительно в 2(если signed)..4 (если unsigned) раза больше, чем 9 десятичных цифр ;)

onstat-
Попробуйте постомтреть в сторону snmp & mrtg .

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

onstat-
SNMP это универсальное средство доступа к статистике и конфигурации
для всех роутеров. ( де-факто стандарт)

Поиск можно начать отсюда:

iptables+snmp

mrtg - универсальный построитель графиков на perl, заточенный на работу с snmp протоколом.


PS прошу прощения за offtop.
Спасибо. mrtg вроде бы удолветворяет требованиям к графикам/статистике... Буду ковырять дальше.

По поводу mrtg. все-таки это "Не оно" Хотя и позволяет данные из ip-tables через перл-скрипты получать и т.д.
Статистики почасовой нет, среднечасовая скорость мне не нужна, нужна табличка с суммарными значениями и много других мелочей. Хотя идея насчет Web-интерфейса/gd неплохая. Это шороший софт, для вычисления, например, годового графика темперетуры за окном :).

Его надо будет либо с чем-то комбинировать, либо переделывать.
Придется все-таки писать свое...

Gluk (Kazan)1. Раз в секунду действительно довольно часто, раз в минуту в самый раз.

Раз в минуту мне слишком медленно - не даст нормального обновления графика. Это не сервер с безлимитным траффиком, к сожалению, чем чаще график будет обновляться, тем лучше. Частое обновление графика нужно только потому, что всегда есть шанс залезть в платный диапазон адресов, и просадить кучу денег. :) (некоторые счатливчики умудрялись с кривонастроенным торрентом до 10к рублей просадить) Вариант с чем-то вроде gkrellm (скорость без разбиения на диапазоны) не подходит, так как в сети есть torrent-ресурсы, которые активно используются, но расположены в бесплатных диапазонах IP.

Gluk (Kazan)
2. Счетчики можно обнулять после каждого считывания

А вот это не обязательно. Вообще наиболее логично было бы собрать две независимые друг от друга части - одна будет (как раз раз в минуту или даже реже) считывать счетчики на предмет статистики и сбрасывать данные на диск, возможно даже орудовать с базами данных или файлами статистики - это не суть важно. Вторая ничего не будет на диск сбрасывать, а будет тупо мониторить счетчики для отображения скорости передачи и тех же самых персловутых графиков.

Gluk (Kazan)
3. iptables-save/restore не умеет сохранять текущие значения счетчиков (насколько мне известно)

Умеют. с ключом --counters или -c. Могу сюда кусок мануала скинутЬ, если хотите. (версия iptables 1.3.5)

Gluk (Kazan)
4. Если есть желание собирать примитивную окраску трафика, конфигурация весьма усложниться и вполне возможно ухудшится производительность файервола

НЕ могли бы это обосновать? (особенно интересует ухудшение работы файервола)
Есть готовая цепочка, файервол уже собран так, чтобы можно было данные с него быстро получать по интересующим меня диапазонам. Именно поэтому мне не совсем нравится вариант с продолжением поиска софта - есть почти готовая система, в которой не хватает только деталей, зачем искать новую альтернативу?

Gluk (Kazan)
5. SNMP-аккаунтинг в описанном случае действительно выглядит оптимально

Признаюсь, с SNMP не работал. Краткое описание почитал, погуглил и, как я понял, в конечном итоге все всё равно будет работать через надстройки над iptables. Интересующие меня пакеты идут с одного единственного интерфейса (ADSL-модем через Ethernet) но нужно отследить два разных ip диапазона и набора протоколов. (могу здсеь выложить скрипт файервола, если хотите) Соответственно, как я понимаю, чтобы получить раздельную статистику дял каждого, мне придестся лезть в настройки модема и править уже его конфигурацию и iptables (модем тоже под линуксом работает), который нетривиален и генерится автоматом, или ставить на своей машине snmp демона, который опять же с iptables будет работать в конечном итоге...

Gluk (Kazan)
6. С такими хотелками в самый раз был бы Netflow :)

"NetFlow is an open but proprietary network protocol developed by Cisco Systems to run on Cisco IOS-enabled equipment for collecting IP traffic information." Вот зачем мне это на домашнем компьютере с одним (не считая рута) пользователем? :) Тем более, как я понял, оно пропиетарное...

Gluk (Kazan)
7. От падения питания это конечно не защитит, но если прописать демон в /etc/init.d то на корректном shutdow-е, он вполне может опращивать счетчики (напоследок)
От падения питания спасет только частый опрос счетчиков. Другого варианта не вижу, если честно.

Gluk (Kazan)Попотрошить iptables можно с целью снятия издержек на частые ее запуски, по типу сделать также но в виде монитора

Об этом изначально вопрос и поднимался. Исходя из задачи - читать счетчики напрямую будет быстрее, чем получать текст через редирект потоков и парсинг текста (а то и через |grep|awk или perl)

Gluk (Kazan)
Степень усложнения конфигурации файерволла зависит от степени детельности окраски статистики, которую вы собираетесь собирать

Мне ничего особо сложного не нужно. Только число байт, прошедшее через выбранные мной цепочку, заданную по имени (таких цепочек несколько должно быть). Статистика нужна разбитая по часам/дням/неделям/месяцам/годам. Вполне нормальным вариантом будет гасить особо древнюю статистику (детальную за прошлый месяц, например)...
А график - независимый от статистики компонент, который и историю свою вести не будет...