Документация NetAMS - [34]

• netams_send($command); — отправляет команду $command на исполнение

• $result=netams_read(); — считывает в переменную $result результат выполнения команды

• $result=netams_readline(); — то же самое, но программа ожидает вывода признака конца строки (перевод строки, "\n»). использовать не рекомендуется

• netams_logout(); — осуществляет разрыв соединения.

Вот список идущих с программой скриптов, которые можно применять на практике или рассматривать как примеры программирования общения с NeTAMS:

• netams_example.cgi — выводит результат выполнения команды show version в виде cgi–программы. после небольшой модификации превращается в утилиту командной строки.

• login.cgi — интерфейс к сервису login.

• netams_graph.cgi — программа, динамически создающая картинки в формате PNG с графическим отображением статистики для заданного юнита и всех его политик учета, за последние неделю или месяц. параметры вызова (метод GET):

• unit=UNIT_NAME — обязательный параметр, определяет имя юнита, для которого будет рисоваться картинка

• policy=POLICY_NAME — имя политики, которая будет отображаться. при отсутствии параметра policy будут отрисованы все активные политики.

• prefix=PREFIX — буква, определяющая временной период графика, W (неделя) или M (месяц) соответственно, по умолчанию =W

• nolegend=FLAG — при любом установленном значении запрещает отрисовку легенды с отображением цвета, которым будет отрисовываться данные о политике.

• Данный скрипт использует модули GD.pm и библиотеку libgd. Для FreeBSD вам надо выполнить что–то вроде cd /usr/ports/graphics/p5–GD ; make install. В текущем каталоге необходимо иметь файл lucon.ttf, это TrueType–шрифт Lucida Console из дистрибутива Windows XP.

Место NeTAMS среди других считалок

Вокруг вертится много разных непонятных названий: ipcad, netflow, NetUP, Cisco, netgraph, биллинг и прочее. Что это все значит и с чем это едят?

Если вы попали на этот сайт, значит вам наверняка надо:

а) Учитывать IP–трафик в сети

б) Брать с кого–то за это деньги (опционально)

Грубо говоря, решением первой задачи занимаются системы учета трафика, второй задачи — системы биллинга.

С задачей учета трафика успешно справляется достаточно большое количество программ. Они имеют (или нет) средства, чтобы:

• Собрать циферки

• Суммировать циферки

• Положить сумму в базу или лог

• Отобразить циферки согласно (сложному) запросу

• Скомандовать внешней программе о превышении (редко)

Собрать циферки можно многими путями, из которых можно выделить следующие:

• Счетчики пакетов вашей операционной системы

• Можно делать опрос встроенных счетчиков на правилах ipfw/iptables, но сразу возникают вопросы: кто будет эти правила выставлять–убирать, как часто делать такой опрос (скорость vs. точность), насколько это все удобно и гибко

• Анализ потока NetFlow

• Фирма Cisco Systems придумала способ, как отдавать информацию о промаршрутизированном трафике наружу, другим программам. Это делается при помощи протокола NetFlow, который описан тут. Правильным образом настроенный маршрутизатор периодически отсылает на указанный сервер UDP–пакеты, содержащие Flow Records — информацию о прошедшем трафике, суммированную по разным признакам. Принимающей стороне остается лишь разобрать и переварить пакеты.

• Опрос другого сетевого устройства по SNMP

• Нельзя сказать, что это удачный метод, т.к. стандартные счетчики SNMP содержат только информацию по количеству байтов/пакетов, прошедших через интерфейс, без разделения на протоколы–порты–адреса.

• Встроиться вовнутрь ядра операционной системы и получать статистику «из первых рук»

• Очень быстро работает, но фактически приводит к экспорту логов/потока netflow из ядра, не больше.

• Слушать на интерфейсе

• Широко известная библиотека libpcap позволяет посмотреть на каждый пакет (и его заголовки), проходящий через роутер.

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

Чтобы статистика не потерялась после перезагрузки компьютера, ее надо хранить в базе данных, желательно SQL. При этом упрощается процесс получения выборок по заданному признаку.

Для отображения статистики часто пишется веб–интерфейс, работающий с базой данных, и позволяющий сделать выборку по заданному критерию (время, адреса и прочее).

Если требуется производить какие–либо действия по управлению трафиком (отключение клиента) по превышению значения счетчиков, эти счетчики должен периодически мониторить какой–нибудь демон или скрипт.

В природе существует большое количество «считалок», в разной степени попадающих под вышеприведенное описание. Их хороший обзор приведен тут: http://www.unixfaq.ru/index.pl?req=qs&id=247.

Дальнейшее развитие систем учета трафика — системы биллинга. Их основные свойства:

• Развитый интерфейс управления, настройки, запросов; клиентская часть

• Перевод счетчиков «считалок» в деньги согласно тарифному плану. Тарифные планы могут быть чрезвычайно хитрыми.

• Ведение счетов клиента (платежи, смена планов, блокировка, …)