Документация NetAMS

Причина подобного требования в том, что OID является также уникальным ключом (PRIMARY KEY) в базе данных, и счетчики привязаны к нему. Кстати, из этого следует, что никто не мешает переименовывать юниты по ходу работы.

NeTAMS представляет собой достаточно гибкий инструмент учета трафика и установки некоторых ограничений на работу пользователей. Круг задач, которые можно решить с использованием данной программы, чрезвычайно широк, и у каждого администратора есть свои пожелания по организации работы программы и тому, как она взаимодействует с пользователями. Для облегчения задачи настройки и использования NeTAMS под ваши конкретные задачи был создан интерфейс в виде ряда функций, который позволяет управлять программой и получать от нее данные из ваших написанных самостоятельно Perl–скриптов и CGI–программ.

Для применения интерфейса вы должны включить в начало вашей программы строку:

require «netams_api.pl»

Вот список функций, которые определены в этом интерфейсе:

• $result=netams_login($hostname, $port, $username, $password); — осуществляет соединение с программой, используя указанные параметры. Если $result начинается со слов «Welcome», то соединение прошло успешно

• 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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