1

Редактировать: я нахожусь в процессе разработки инструмента мониторинга на основе Java, который будет периодически отправлять "проверки работоспособности" приложения Java, развернутого на кластере серверов GlassFish. Я пытаюсь определить лучший протокол для этого инструмента мониторинга, чтобы отправить информацию обратно на сервер мониторинга.

После первоначальных исследований с моей стороны кажется, что SNMP - это просто протокол для приложений типа монитора, чтобы сообщить о "состоянии работоспособности" чего-либо (части сети, сервера, кластера, приложения и т.д.) в остальной части сети.

  • Если вышеприведенное неверно, пожалуйста, исправьте меня !!!

Предполагая, что обобщение более или менее точно, мой следующий вопрос: почему это протокол!?!?

В эпоху протоколов REST/SOAP/TCP, почему существует необходимость в стандартизированном протоколе, который подходит только для одного типа приложений (мониторинг)? Другими словами, если я разработчик, которому поручено создавать новый инструмент мониторинга, который периодически опрашивает сервер и сообщает о его ЦП и доступной памяти, какие преимущества дает мне SNMP по сравнению с простой POST-передачей в RESTful API через обычный HTTP?

Я уверен, что здесь чего-то не хватает - мне просто нужен кто-то, кто поможет соединить точки! Заранее спасибо!

3 ответа3

3

необходимость стандартизированного протокола... Потому что это стандартизировано? Это также предшествует HTTP (1988 против 1991). REST был бы с HTTP 1.0, 1996. Как только что-то используется, его часто легче придерживаться, хотя бы для традиционной поддержки.

В ответ на ваши изменения: Вы хотите / нуждаетесь в других, уже существующих инструментах, чтобы иметь возможность общаться с вашим приложением? Если нет, вы можете использовать любой метод, который вам нравится, но вам нужно будет использовать свои собственные инструменты мониторинга. Если да, вам нужно использовать что-то, что уже обычно поддерживается, например, SNMP.

1
RESTful API via plain 'ole HTTP

Это имеет следующие зависимости:

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

Вышеуказанное тривиально в наши дни (и многие устройства и т.д. Имеют встроенные HTTP-серверы в наши дни), но когда был разработан SNMP, это не так.

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

1

Не будучи экспертом в этом, я бы предложил следующее:

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

Более того, есть машины, к которым у вас нет доступа. (Либо из-за разрешений, либо потому, что они упрощенные маршрутизаторы.) В этом случае SNMP будет простым способом получить и установить параметры конфигурации.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .