LINUX.ORG.RU

расширение snmp

 agentx, , ,


0

1

суть такова. необходимо собирать кое-какую диагностическую статистику, частично общесистемную, типа текущей загрузки проца или сетевух, частично весьма специфичную, отдаваемую своими железяками или софтом. было решено использовать для этого расширения net-snmp и perl-овых субагентов и создать свою ветку oid-ов в private.enterprises.

такая вот преамбула. а вопрос вот в чем. естественно, что различные классы отдаваемых данных разбиты на группы. в каждой группе предположительно 5-10 параметров. как лучше реализовывать такую схему - на каждую группу создавать свой mib и своего субагента, или сделать один mib и один скрипт для обработки всего? или может какая-то комбинация предыдущих двух вариантов?

з.ы. смена протокола и/или программных средств не рассматривается

★★★★★

Сам писал такое на аналогичном стеке. Только гораздо масштабнее чем просто сбор данных. Выбор хороший.

Нифига не понял из задачи. Класс это набор групп? Тогда при описании класса подключаем к нему mix-in'ы (группы).

В перловой программе будет инстанцироваться класс, и будут дергаться его методы.

Про разделение на скрипты не совсем понял. Опиши типичные use case.

outtaspace ★★★
()
Ответ на: комментарий от outtaspace

есть корневой oid - $root_oid = ".1.3.6.1.4.1.229767.639";

к нему цепляются группы параметров, каждая группа - это или просто перечень параметров, или таблица, когда точно число параметров неясно (например сетевух может быть от одной до 4-х).

интересует, что лучше в плане производительности - каждую из таких групп описать своим mib-ом и создать для нее отдельного перлового субагента, регистрируя его на свою ветку ($root_oid + ".NNN") или все эти группы описать в одном mib-е и все обрабатывать одним агентом?

ananas ★★★★★
() автор топика
Ответ на: комментарий от ananas

У меня была совсем иная архитектура, основанная на ООП.

Была ветка команд (шаблон проектирования Command). Это некая бизнес логика, в том числе дергающая snmp. Каждая команда имела id, а не имя, так проще. Инстанцировалась фабрикой:

my $command = CommandFactory->create($command_id); # Command::${command_id}->new

$command->execute;

Это вместо do /path/to/script.pl

Была ветка девайсов, SNMPDevice (SNMPDevice::$model_id, где $model_id это id из корпоративной ERP, в которой каждой ревизии каждой модели свитча заведена карточка), в которой описывались конкретные свитчи. Каждый конкретный класс это набор методов (например добавить/удалить вилан).

Классам SNMPDevice через mix-in добавляется новые возможности. К примеру свитч может возвращать список маков в вилане. Описывается это в виде mix-in'а:

package SNMPDevice::42;

use parent qw(SNMPDevice);

use SNMPDevice::Vlan::42 qw(add_vlan delete_vlan);

Все свитчи которые поддерживают oid'ы для работы с виланом, описанные в SNMPDevice::Vlan::42, могут переиспользовать этот модуль, причем не наследуясь от него.

outtaspace ★★★
()
Ответ на: комментарий от outtaspace

тоже забавная идея, надо будет обдумать. дякую

ananas ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.