Доброго времени суток! Подскажите пожалуйста, с помощью чего можно подсчитывать трафик в реальном времени?

Дано:
1. Linux Debian 5;
2. Клиенты, с постоянными IP-адресами;
3. Трафик во вне, проходящий через интерфейс eth3.

Задача:
Посчитать по IP-шнику входящий и исходящий трафик, проходящий через интерфейс eth3. Подсчёт по возможности должен быть как можно точнее и производиться в реальном времени, желательно по каждому порту в отдельности.

P.S. В линуксе почти ещё новичек, по этому прошу не судить строго!

Что значит, в реальном времени? Ставится пакет iptables, ищется в гугле подходящий скрипт и подпиливается под себя.
http://www.google.ru/search?q=iptables+ban...;client=firefox

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

Почитал больше кол-во информации и комментариев по поводу подсчёта трафика с помощью iptables. Мнения очень сильно разнятся, по поводу качества и точности подсчёта трафика таким методом. Скажите пожалуйста, что Вы думаете по поводу точности учёта трафика таким методом?

Всё зависит от метода снятия данных с нетфильтра.

От себя могу порекомендовать следующее:
0. Не зморачиваемся с iptables.
1. Ставите netflow-сенсор на свой маршрутизатор.
2. Ставите куда-нибудь ещё (можно туда же, если нагрузка позволяет) анализатор трафика или простенький биллинг.
3. Отправляете netflow-трафик с сенсора в коллектор.

Получите (если будете юзать биллинг) удобное решение учета трафика, если ещё и анализатор - удобную систему мониторинга (для понимания, что плохо и кто козел).

Для начала рекомендую пакеты fprobe (сенсор) и flow-tools (куча утилит для netflow) оба есть в репозиториях дебиана (опенсорс). В качестве биллинга - Abills (опенсорс), в качества анализатора - Manageengine Netflow Analyzer (не опенсорс и стоит денег) или FlowScan (погуглите, опенсор вроде).
Юзаю:
fprobe и flow-tools - бесценный софт;
анализатор от Manageengine хорош, но стоит тоже хорошо;
Abills - большой комбайн, тяжеловат, мутноват, но вроде работает.
Цели использования отличаются от ваших, но вроде и вам подойдёт.

ZeeLax, спасибо огромное за консультацию, уже изучаю описанное выше.

Хотелось бы ещё уточнить один маленький нюанс! Если учёт трафика необходимо организовать на устройстве с очень малой вычислительной мощностью. Какой из способов учёта трафика будет давать наименьшую нагрузку на процессор и потреблять наименьшее кол-во ОЗУ? Так же, ключевым требованием является то, что обновление статистики должно быть не реже 1 раза в минуту.

Нагрузка сильно зависит от глубины учета. Если только трафик - это просто. Если трафик, с учетом на ресурсы - это уже сложнее. Если учитывать порты - ещё сложнее. Опять же, раз минуту если хотите, то тут много не сагрегируешь, стало быть, тоже нагрузка будет выше, чем раз в 20 минут, допустим, аккаунтинг снимать.
Если не юзать анализатор, а просто учет - нагрузка будет ниже. Manageengine жрет кучу ресурсов, как дисковых, так и высислительных.
Вообще, советую не экономить, и вести учет на достаточно производительной железке. Естественно, "достаточная производительность" зависит от трафика - как от мегабитов, так и от PPS.

Уважаемый ZeeLax! Скажите пожалуйста, а откуда все эти системы учёта снимают данные, которые потом анализируются? Как я понял - основная масса систем учёта работает на прикладном уровне, а оставшееся часть уже на более низком уровне. Хотелось бы выяснить источники данных для систем прикладного уровня.

Данные в этом случае снимает только сенсор. Если брать fprobe, то он делает это с помощью библиотеки pcap (libpcap в нашем случае).
Данные о трафике передаются коллектору по протоколу NetFlow, широко применяющемуся в сетях на основе Cisco и других вендоров. Коллектор, обрабатывая пакеты NetFlow определяет расход трафика, нагрузку и прочие данные, в зависимости от логики своей работы (логика зависит от типа приложения, частью которого является коллектор).