LINUX.ORG.RU

Выбор протокола для агента системы мониторинга

 , , , ,


0

1

Всем здравствуйте.

Есть задача периодически снимать значение некой целочисленной метрики (в общем случае – по сети) у ряда машин с дальнейшим представлением исторических данных на графике (как это делает MRTG – за день, за неделю, за месяц, за год). Предполагаю связать своего колхозного агента с какой-л. системой мониторинга (с какой именно – выбор свободен).

Но есть вопрос выбора протокола взаимодействия, и здесь возникают нюансы.

  • SNMP. Казалось бы, любая собака умеет взаимодействовать по SNMP, и с аутентификацией там (в третьей версии протокола) всё хорошо, но вот почитал я, как внедрить своего суб-агента в snmpd через AgentX – и вижу, что это ни разу не просто.
  • Произвольный текстовый или бинарный протокол и интеграция с inetd/xinetd. Очевидный плюс в простоте решения. Минусы:
    • невозможно навесить аутентификацию;
    • не только лишь всякая система мониторинга сумеет снять данные, используя произвольный протокол. Кажется, здесь получится использовать лишь MRTG, т. е. это «восход солнца вручную».
  • NRPE. Хорош своей популярностью (едва ли не второе место после SNMP; поддерживают, как минимум, Nagios, Icinga и OpenNMS), но позволяет передавать лишь данные вида «всё хорошо»/«почти хорошо»/«плохо»/«совсем плохо». Т. е. не годится.
  • HTTP. Прекрасен всем, но не хотелось бы на каждой машине поднимать httpd с CGI. Хотя есть вариант embedded-сервера, как это сделано, напр., в API агентов для Prometheus (там text/plain поверх HTTP). Данные в формате Prometheus могут «читать» и другие инструменты, напр., OpenNMS и Zabbix.
  • SSH. SSH есть везде, и это хорошо. Но снять данные, используя вывод команды ssh remote-host agent-command, кажется, возможно лишь в MRTG. А при наличии M машин с N метрик вручную описывать M x N графиков в mrtg.cfg не хотелось бы (т. е. хотелось бы ещё какой-л. аналог service/MIB discovery, как в SNMP).

Что посоветуете?

★★★★★

Последнее исправление: Bass (всего исправлений: 9)

prometheus exporter, то бишь, хттп

/thread :)

P.S.: snmp, и в правду, нетривиальный, а средства разработки своего агента, вообще платные, насколько я помню.

Разрабатывать руками без кодгена вообще муторно.

aol ★★★★★
()
Последнее исправление: aol (всего исправлений: 1)

NRPE. Хорош своей популярностью (едва ли не второе место после SNMP; поддерживают, как минимум, Nagios, Icinga и OpenNMS), но позволяет передавать лишь данные вида «всё хорошо»/«почти хорошо»/«плохо»/«совсем плохо». Т. е. не годится.

Ты бы сразу написал - nrpe мне не нравится.

nrpe передает строку. Как ты её будешь использовать - твоё личное дело.

nagios+pnp4nagios передает параметры после символа «|»

vel ★★★★★
()

Я бы использовал заббикс. С самого сервера можно забирать данные по ssh, или поставить на сервера заббикс агента (можно на нем и буфер настроить чтобы данные не терялись при пропаже сети) и им уже мониторить.

Промитис как советовали выше мне кажется менее подходящим так как придется возиться с экспортером, держать его запущенным, возиться с tls для шифрования. Заббикс делает это все проще и из коробки

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

А можешь поделиться ссылками?

Ибо я Zabbix второй день как вижу. Речь о вот этом протоколе агента и вот этом запуске скриптов по SSH?

Bass ★★★★★
() автор топика
Последнее исправление: Bass (всего исправлений: 1)

Я делал такое для сбора данных датчиков температуры, в принципе HTTP + JSON тут выше крыши. Если нужна авторизация - добавляется JWT-токен в заголовок.

Проблемы начнутся при росте объема данных и/или частоты их обновления, но врядли это тот вариант.

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

Я это все к тому что RFC как официальный стандарт давно не поспевает за фактическим стандартом, коим является JWT.

Во-вторых rfc7540

Не знал что уже стандартизировали. Хотя сейчас есть уже HTTP/3 же.

Ну и это, ты бы огласил что-ли свои претензии к JWT в таком случае.

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

Спасибо, проект интересный, но смущает отсутствие полной поддержки Python 3 (только 2.7) и отсутствие бинарных пакетов (приседания с pip, virtualenv и ручная сборка mod_wsgi — не то, на что хотелось бы тратить время).

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

Не знал что уже стандартизировали.

Его уже obsolete даже успели в пользу 9113.

Ну и это, ты бы огласил что-ли свои претензии к JWT в таком случае.

Там не так вообще всё.

Начнём с идиотических названий самих rfc, например 7518 - «алгоритмы json-веба». Дальше, читая «abstract», ситуация местами чуть проясняется, а местами лишь усиливается атмосфера идиотии.

Во-вторых, у авторов явная мания придумывания капслочных сокращений на ровном месте, чем больше, тем лучше, которая при дальнейшем рассмотрении оказывается лишь одним из симптомов общей графомании - стремления наплодить как можно больше и как можно более длинных и «спецификациеобразно» выглядящих текстов.

В-третьих, о чём собственно этот так называемый стандарт? Про json-представление каких-то криптографических данных? Про саму криптографию? Причём тут вообще «JSON Web» собственно? Невразумительная каша.

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

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Начнём с идиотических названий самих rfc, например 7518 - «алгоритмы json-веба». Дальше, читая «abstract», ситуация местами чуть проясняется, а местами лишь усиливается атмосфера идиотии.

Ты серьезно чтоли? На полном серьезе подходишь к техническому тексту с мерками кинокритика аля БедКомедиан?

В-третьих, о чём собственно этот так называемый стандарт?

Начни вот отсюда:

https://jwt.io/

Стандарт про хранение метаданных клиентской сессии, подписанных ключем сервера и передаваемых с помощью отдельного HTTP-заголовка.

Придумано для всякой веб-автоматики, HTTP-клиентов где нет куков и локального хранилища, чтобы тостеры с холодильниками могли данные по API тягать.

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

Ты серьезно чтоли? На полном серьезе подходишь к техническому тексту с мерками кинокритика аля БедКомедиан?

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

Стандарт про хранение метаданных клиентской сессии, подписанных ключем сервера и передаваемых с помощью отдельного HTTP-заголовка.

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

Начни вот отсюда: https://jwt.io/

Ещё и целый сайт ради алгоритма подписи строк, мда. «industry standard». Объяснения всё так же два: графомания и желание прославиться.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от Bass

Спасибо, проект интересный, но смущает отсутствие полной поддержки Python 3 (только 2.7)

Да, оно немного свое отживает, вытесняется всякими Прометеями. По производительности им проигрывает. Но, как и всякое старье — простое и надежное. Для небольших проектов и локалхостов самое то.

и отсутствие бинарных пакетов (приседания с pip, virtualenv и

Это где нету? В Дебиане есть. В Арче — в AURе.

ручная сборка mod_wsgi — не то, на что хотелось бы тратить время).

Так uwsgi есть же. Настраивается достаточно просто.

urxvt ★★★★★
()

Но снять данные, используя вывод команды ssh remote-host agent-command, кажется, возможно лишь в MRTG.

А ещё в Ansible. Собираешь к себе в папочку и парсишь как хочешь вдоль и поперёк. Для колхоза идеально.

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

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

Знаешь у меня натуральный когнитивный диссонанс с твоего поста. Это примерно как человек, наизусть выучивший все тома Библии жаловался бы на чрезмерную сложность комиксов про человека-паука.

JWT что в виде стандарта что в виде реализации дико прост и примитивен. Как у тебя получается одновременно жаловаться на его переусложненность и читать RFC для HTTP/2 - не представляю.

Весь смысл в стандартизации JWT это отбить желание всяким Васянам от разработки лепить свои реализации, где например они могут вместо «сложного» public-private keypair реализовать xor от строки, чем и проводить ее «декодирование».

Прецеденты были, я видел что было до JWT и какую дичь на коленке лепили мамкины погромисты.

alex0x08 ★★★
()
Последнее исправление: alex0x08 (всего исправлений: 1)
Ответ на: комментарий от alex0x08

JWT что в виде стандарта что в виде реализации дико прост и примитивен.

Примитивен по сути, но в том и дело, что «стандарт» при этом занимает кучу ненужных страниц.

То, что он короче чем http/2 (но даже тут они умудрились разбить свою графоманию на аж 5 отдельных номеров rfc - так смотрится солиднее) - не показатель. Надо сравнивать не длину текста саму по себе а отношение количества текста к сложности описываемого явления. У этих jwt это отношение запредельно большое.

Не представляю каким образом наличие rfc jwt помешает кому-то реализовывать токены другим способом. Разве что такой способ приходит в голову: недо-веб-кодер думает над тем, как ему сделать токен, ничего путного в голову не приходит, зато вдруг он видит этот jwt и «о, круто, модный индустриальный стандарт! надо использовать», после чего скорее всего качает к нему какую-то мутную библиотеку для своего мутного фреймворка и пользуется. Да, это наверно лучше чем если б он сам там дыр наделал.

firkax ★★★★★
()

вот почитал я, как внедрить своего суб-агента в snmpd через AgentX – и вижу, что это ни разу не просто

Да вроде всё понятно, в чём проблема-то? API черезжопное, конечно, но отдавать одну чиселку (без поддерева) вообще элементарно.

Ну а так плюсую Prometheus.

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

Я бы использовал заббикс. С самого сервера можно забирать данные по ssh, или поставить на сервера заббикс агента (можно на нем и буфер настроить чтобы данные не терялись при пропаже сети) и им уже мониторить.

Ага-ага.. Для использования буффера - вынь и подай ему active check, при этом оно само будет ходить в сервер за ними. Аутентификации нет как класса, шифрование - жрущий TLS, который overkill в этом месте. Добавим сюда неспособность поддерживать постоянное соединение с агентом, жуткий overhead на передачу json структур, поганую обработку ошибок запуска скриптиков, муторные пляски с конфигами и sudo.

Или взять snmpd который в V3 протоколе тебе и шифрование и авторизацию сразу умеет. И через exec/extend/extend-sh получить заветные циферки из любого скриптика не составляет проблемы. Заодно и с кодом завершения скриптика.

LynxChaus
()