Хочу добавить SNMP в приложение. Есть альтернативы agentx?

мне кажется, что мсье хочет странного :-)

простое и надёжное решение - написать консольную утилитку управления вашим приложением и пачку скриптов для snmpd которые будут эту утилитку дёргать.

Меня даже не сколько управление, сколько сбор статистки интересует. Утилиты не очень нравятся, т.к. из кода проще генерить всякие таблицы итд. Также еже есть код, который генерит дерево объектов с состояниями (ок/warning/critical).

Мои рекомендации и вопросники:

1. Целевое назначение. Не в даваясь в технические аспекты опишите как вы видите, чтобы все работало. Назовите людей их примерные должности, которым придется пользоваться вашим продуктом. Как они будут взаимодействовать с ним? Опять же выкиньте из головы все свои познания от технических реализациях. Сейчас важно четко представлять какие действия должны совершаться, а какие нет.

2. Рассмотрите технические решения с точки зрения программиста/разработчика. Отберите два-три решения, которые позволяют достигнуть поставленной цели. Выпишите все плюсы и минусы, которые вам известны.

3. Позаботьтесь об людях: разработчики, деплойеры, администраторы, клиенты/пользователи/операторы. Насколько удобно будет деплойеру, если вдруг окажется, что кругом 100500 однотипных машин разворачивать ваш продукт? Как достигнув свою цель (например, выбрав standalone embedded snmp daemon), вы облегчите использование вашим продуктом этим людям?

4. Исходя из учета всех аспектов, скорректируйте план необходимых действий. Например, если у вас нет деплойера, нет 100500 машин и не планируется, то можно усложнить использование продуктом в угоду скорости/простоте разработки.

5. Делайте ставку на краткосрочные или долгосрочные перспективы. Сложности это миф, если вы четко видите путь к успеху. Например, интеграция с agentx по-началу будет неприятной, неудобной. Решение, которое идеально вписывается в поставленную цель, окупит себя в первой же реализации. И наоборот, если уйти от agentx, забить болт на сис.админские стандарты, стандарты безопасности, то скорей всего клиент не примет и заставит все переделывать, либо просто будут дурно думать о вас как разработчике/архитекторе/проектировщике.

Все это не имеет роли, если делается для себя или используется в протипах. Что касается agentx, да и snmp в целом, то следует учитывать следующие вещи:

1) Open source аналогов net-snmp практически нет. Все, что имеется неполноценны, либо заброшены. Можете поискать платные решения, если вам не нравится net-snmp.

2) net-snmp не так уж страшен как кажется. Да, интерфейс у него ого-го, но работает и проверен временем.

3) SNMP хорош, когда у вас много GHz и отличный интернет-канал. В остальном он проигрывает любым решениям из-за особенностей архитектуры.

4) Из пункта 3 вытекает, что SNMP не годится для съема статистики быстрее чем раз в 1 секунду. И то, тут есть большая оговорка на максимальный размер посылаемых данных: при огромных запросах-ответах и большом количестве агентов (сотни-тысячи) съем в 1 секунду будет уже великим достижением. Если нужно что-то близкое к реалтайму, то надо использовать другой протокол, который изначально учитывал этот фактор.

5) Собственный протокол может быть удобен для тех, кто вообще не пользуется snmp. Более того, в велосипедстве своих протоколов нет ничего плохого, особенно если вы решили отказаться от интеграции с системным snmpd.

6) Свои сервера нынче модно строить на REST. Это так, к слову :) Некоторые крутые дяди, которые работают в больших компаниях любят эти 4 буквы.

Из mini_snmpd выгрызть всё что нужно и засунуть в своё поделие.

Хотя я бы тупо через pass /usr/bin/myappstats в net-snmp ветку сделал. Раз в 500 проще, чем велосипеды изобретать.

Короче придется cнова развлекаться с agentX. Для сбора подробной статистики у нас в приложении есть свои графики, а тут я думаю, никого опрос более частый чем один раз в 1-5 минут не заинтересует