Изменить: я нахожусь в процессе разработки инструмента мониторинга на основе Java, который будет отправлять периодические "проверки работоспособности" приложения Java, развернутого на кластере серверов GlassFish. Я пытаюсь определить лучший протокол для этого инструмента мониторинга, чтобы отправить информацию обратно на сервер мониторинга.
После первоначальных исследований с моей стороны кажется, что SNMP - это просто протокол для приложений типа монитора, чтобы сообщить о «состоянии работоспособности» чего-либо (части сети, сервера, кластера, приложения и т. Д.) в остальной части сети.
Если вышеприведенное неверно, пожалуйста, исправьте меня !!!
Предполагая, что обобщение более или менее точно, мой следующий вопрос: почему это протокол!?!?
В эпоху протоколов REST / SOAP / TCP, почему существует необходимость в стандартизированном протоколе, который подходит только для одного типа приложений (мониторинг)? Другими словами, если я разработчик, которому поручено создавать новый инструмент мониторинга, который периодически опрашивает сервер и сообщает о его ЦП и доступной памяти, какие преимущества дает мне SNMP по сравнению с простой POST-передачей в RESTful API через обычный HTTP?
Я уверен, что здесь чего-то не хватает - мне просто нужен кто-то, кто поможет соединить точки! Заранее спасибо!
Я вижу, что это уже получает closevote. Я захожу на superuser.com, чтобы ** учиться **, и у меня нет проблем с критикой, если это разумно! Я хотел бы спросить, почему это было закрыто!?!
pnongrata 12 лет назад
0
Я вижу, что причина закрытого голосования была "не реальным вопросом". Я смиренно дигри !! Резюмируя этот вопрос в одном предложении: «* Каковы преимущества в наши дни и возраст использования SNMP по сравнению с решениями на основе REST или SOAP? *» Я считаю, что это ** абсолютно ** настоящий вопрос!
pnongrata 12 лет назад
1
Какая проблема с компьютером решаема?
Ƭᴇcʜιᴇ007 12 лет назад
0
@ techie007 - пожалуйста, поймите, что этот ответ * не * вызов тому, что вы только что написали, это просто попытка получить ясность относительно того, где я должен публиковать подобные вопросы в будущем. Является ли «решаемая проблема с компьютером» * действительно * определенным критерием для вопроса SuperUser? Потому что это довольно расплывчато и включает StackOverflow, ServerFault и большинство других технических StackExchange сайтов. Если это так, то я говорю, что это решаемая проблема: я хочу, когда и где мне следует использовать SNMP. Если это не критерии, то что есть / есть? Этот ответ будет определять * где * это принадлежит!
pnongrata 12 лет назад
0
Из SU [FAQ] (http://superuser.com/faq): «Вы должны только задавать практические, отвечающие на вопросы вопросы, основанные на реальных проблемах, с которыми вы сталкиваетесь».
Ƭᴇcʜιᴇ007 12 лет назад
0
Пожалуйста, посмотрите мое редактирование - оно включает в себя мою актуальную проблему под рукой и убирает часть «тайны» из моего вопроса. Надеюсь, это превращает это из теоретического вопроса в практический.
pnongrata 12 лет назад
0
Даже после вашего редактирования вы все еще просите «лучший» протокол, который обычно используется только с мнением.
Ƭᴇcʜιᴇ007 12 лет назад
1
Это правда, но я думаю, что это лаконично и достаточно конкретно, чтобы заслужить нахождение в SuperUser как законный вопрос. Если ваше мнение будет достаточно других, я буду уважать сообщество SU, чтобы закрыть это.
pnongrata 12 лет назад
0
Еще один аргумент здесь: это не «лучший» (основанный на мнении) вопрос, хотя слово «* лучший *» на самом деле появляется в моем редактировании! Я прошу кого-нибудь перечислить ** конкретные ** преимущества SNMP по сравнению с более современным подходом, а именно: (1) абсолютно конечный и подотчетный, и (2) не субъективный. Снова, я поддерживаю это как законный вопрос. И хотя об этом спросили только 8 часов назад, и это ни в коем случае не является достаточным количеством времени для надежного ответа, я думаю, что отсутствие ответа действительно указывает на то, что мои инстинкты верны: SNMP не дает таких преимуществ.
pnongrata 12 лет назад
0
3 ответа на вопрос
3
Bob
необходимость стандартизированного протокола ... Потому что он стандартизирован? Это также предшествует HTTP (1988 против 1991). REST был бы с HTTP 1.0, 1996. Когда что-то используется, часто проще придерживаться его, хотя бы для поддержки предыдущих версий.
В ответ на ваши изменения: Вы хотите / нуждаетесь в других, уже существующих инструментах, чтобы иметь возможность общаться с вашим приложением? Если нет, вы можете использовать любой метод, который вам нравится, но вам нужно будет использовать свои собственные инструменты мониторинга. Если да, вам нужно использовать что-то, что уже обычно поддерживается, например, SNMP.
Так что, по вашему мнению, это не дает мне никаких преимуществ * по сравнению с решением на основе REST или SOAP?
pnongrata 12 лет назад
0
@AdamTannon SNMP является более устоявшимся и имеет значительно меньше накладных расходов, чем все, что связано с HTTP.
Ƭᴇcʜιᴇ007 12 лет назад
0
Опять не спорю здесь, просто пытаюсь понять. С такими фреймворками, как Jersey и моими собственными доморощенными библиотеками, и может получить RESTful веб-сервис, работающий с 30 строками кода. Можете ли вы уточнить, что вы подразумеваете под "накладными расходами"?
pnongrata 12 лет назад
0
@Bob - как единственный ответчик, я с радостью предоставлю вам «зеленую проверку», если вы можете привести конкретные преимущества, которые SNMP имеет по сравнению с более современными (REST / SOAP / и т. Д.) Подходами.
pnongrata 12 лет назад
0
@AdamTannon Вероятно, лучше подождать, пока кто-нибудь ответит. Я не достаточно знаком ни с SNMP, ни с другими подходами. Все, что я могу сказать, это то, что SNMP использовался в течение более длительного времени, и это достаточно стандартно, вы можете найти универсальный регистратор SNMP и ожидать, что он будет работать.
Bob 12 лет назад
1
http://www.snmp.com/protocol/snmp_rfcs.shtml содержит исчерпывающие требования и методы реализации для SNMP. Ничто не мешает вам или кому-либо еще использовать SNMP в интерфейсе на основе RESTful или SOAP для консолидации и администрирования данных SNMP, в отличие от Nagios или HP OpenView, и это хорошо, поскольку базовые структуры управления SNMP остаются для тех, кто хочет реализовать свои собственные идеи о том, как лучше управлять своими сетевыми устройствами.
Nevin Williams 11 лет назад
0
1
Nikodemus
Не будучи экспертом в этом, я бы предложил следующее:
SNMP имеет одну фиксированную базу управляющей информации, содержащую иерархии классов информации (например, фактическую пропускную способность интерфейсов). Таким образом, вы можете легко добавлять узлы в сеть, которую вы отслеживаете, без особых настроек.
Более того, есть машины, к которым у вас нет доступа. (Либо из-за разрешений, либо потому, что они являются упрощенными маршрутизаторами.) В этом случае SNMP будет простым способом получения и установки параметров конфигурации.
1
LawrenceC
RESTful API via plain 'ole HTTP
Это имеет следующие зависимости:
HTTP-сервер
внутренний процесс, вызываемый этим сервером, который поддерживает состояние
достаточно памяти, полосы пропускания и ресурсов хранения для обработки всех возможных одновременных попыток подключения, помимо того, что устройство должно делать (мы предполагаем, что вы хотите, чтобы ваше устройство выполняло другие действия, кроме ответа на запросы состояния)
и подзависимости всех платформ, необходимых для реализации вышеизложенного, если используются каркасы (то есть, если ваш бэкэнд-процесс написан на Perl, то это требует больше ресурсов и т. д.)
Вышеуказанное тривиально в наши дни (и многие устройства и т. Д. Имеют встроенные HTTP-серверы в наши дни), но когда был разработан SNMP, это не так.
SNMP намного проще и может легче обрабатываться встроенными устройствами с низким ресурсом (например, устаревшими коммутаторами и т. Д.), А программное обеспечение, которое отвечает на запросы SNMP, может быть написано легче с меньшей вероятностью уязвимостей безопасности.