Комментарии 16
В 4ом заббиксе есть http agent, избавляет от парсинга jsonа
А в 2.0 появился ключ web.get и в 3.4 появился препроцессинг, так что до 3.4 можно было регуляркой в триггере проверять, а в 3.4 из json доставать данные. И никаких rce незащищённых не надо открывать, вы наверное не шифруете связь между сервером и агентом, а мне хватит и телнета чтобы получить remote shell на таких реализациях как у вас.
Всё ещё проще — даже в самых древних версиях в агенте есть web.page.get, с помощью него вытаскиваем весь JSON и засовываем в короткоживущий айтем типа Text. Дальше делаем все необходимые айтемы, как зависимые и с JSON Path препроцессором.
При этом на клиенте вообще ничего, кроме заббикс агента ставить не надо!
Посмотрите темплейт для nginx от AlexGluck — там как раз такой подход применяется.
При этом на клиенте вообще ничего, кроме заббикс агента ставить не надо!
Посмотрите темплейт для nginx от AlexGluck — там как раз такой подход применяется.
>Я сейчас работаю над проектом мессенджера на блокчейне
Лiл
Лiл
Стартап, блокчейн, иии… Zabbix. Почему именно он?
Та же Grafana с Prometheus в качестве хранилища лучше по всем параметрам (Имхо).
А подобная задача решается банальным вебхуком из панельки.
Та же Grafana с Prometheus в качестве хранилища лучше по всем параметрам (Имхо).
А подобная задача решается банальным вебхуком из панельки.
Zabbix — потому что надежное и удобное решение «из коробки». Prometeus, судя по описанию — это решение для очень крупных сетей. А Графана — это ещё дополнительный софт, чтобы рисовать графики. Которые и так есть в Заббиксе, но мы их не используем.
В общем, отвечая именно на вопрос «Почему» — потому, что это первое удобное решение, которое нашлось, при том, что я не проводил масштабного исследования всех доступных продуктов. Рассудил, что лучшее — враг хорошего.
В общем, отвечая именно на вопрос «Почему» — потому, что это первое удобное решение, которое нашлось, при том, что я не проводил масштабного исследования всех доступных продуктов. Рассудил, что лучшее — враг хорошего.
Что Вы подразумеваете под мониторингом ноды?
Как я понял — не саму доступность самого узла (сервера), а сервиса на нем?
Вообще MicroNovaX правильно пишет: если у Вас самописный HTTP-сервис (второе точно верно, первое — не уверен, но скорее всего), то проще всего сделать отдельный эндпойнт вида 127.0.0.1:36666/metrics и в нем выдать метрики в прометеусовском формате. Можно считать, что это уже стандарт де-факто на нынешнем этапе. А далее все достаточно легко делается. Интересно, что alertmanager легко умеет слать оповещения сразу в слак и не нужно городить костыли.
на самом деле нет. Это просто альтернативный подход к мониторингу. Не мониторинг узлов или еще чего-то, а сервис-ориентированный мониторинг. У этого принципа есть недостатки, но в целом годно.
если графики не нужны, то графану можно не ставить. Просто из средств визуализации данных (в том числе и метрик) Графана сейчас — лучшее, что есть на рынке.
Как я понял — не саму доступность самого узла (сервера), а сервиса на нем?
Вообще MicroNovaX правильно пишет: если у Вас самописный HTTP-сервис (второе точно верно, первое — не уверен, но скорее всего), то проще всего сделать отдельный эндпойнт вида 127.0.0.1:36666/metrics и в нем выдать метрики в прометеусовском формате. Можно считать, что это уже стандарт де-факто на нынешнем этапе. А далее все достаточно легко делается. Интересно, что alertmanager легко умеет слать оповещения сразу в слак и не нужно городить костыли.
Prometeus, судя по описанию — это решение для очень крупных сетей.
на самом деле нет. Это просто альтернативный подход к мониторингу. Не мониторинг узлов или еще чего-то, а сервис-ориентированный мониторинг. У этого принципа есть недостатки, но в целом годно.
А Графана — это ещё дополнительный софт, чтобы рисовать графики
если графики не нужны, то графану можно не ставить. Просто из средств визуализации данных (в том числе и метрик) Графана сейчас — лучшее, что есть на рынке.
Графана — ок.
Prometheus — для оперативного хранения метрик ок, для долговременного — не ок.
Алертинг — вообще отдельная история, т.к. через графану он гипер-костыльный. Через prometheus (точнее — alertmanager) — ок, но нужно его еще умудриться настроить. Это не сложно, но нужно день мозг понасиловать )
Если для коллег заббикс — приемлемый инструмент, то пускай используют.
Prometheus — для оперативного хранения метрик ок, для долговременного — не ок.
Алертинг — вообще отдельная история, т.к. через графану он гипер-костыльный. Через prometheus (точнее — alertmanager) — ок, но нужно его еще умудриться настроить. Это не сложно, но нужно день мозг понасиловать )
Если для коллег заббикс — приемлемый инструмент, то пускай используют.
Можно ещё из самого нодовского приложения zabbix-sender'ом(есть реализация под js) посылать нужные статусы при ошибках например или метрики какие нибудь (количество активных пользователей… ) — думали об этом?
Какой ужас!
Велосипедостроение в худшем его проявлении.
Читайте документацию к Заббиксу и используйте нативные методы получения и обработки данных.
Любые скрипты на агенте — ЗЛО, и должны быть последней крайней мерой.
Почти всё можно получить средствами встроенных в Заббикс-агент нативных средств.
web.page.regexp[127.0.0.1,api/blocks/getHeigh,36666,regexp,,]
Велосипедостроение в худшем его проявлении.
Читайте документацию к Заббиксу и используйте нативные методы получения и обработки данных.
Любые скрипты на агенте — ЗЛО, и должны быть последней крайней мерой.
Почти всё можно получить средствами встроенных в Заббикс-агент нативных средств.
web.page.regexp[127.0.0.1,api/blocks/getHeigh,36666,regexp,,]
Заббикс уже давно прикручен к телеграмм ботам, есть много готовых, удобных и быстрых решений, у Вас, скорее, частный случай для слак
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я научил Zabbix за своей нодой присматривать и о проблемах сообщать