Comments 23
А фаервол не проще настроить?
а с аккаунта с которого публиковали почему не поерничать?
Если у вас метрики раздаются через nginx, да лучше в нем ограничить, чем раньше тем лучше. Вы в любом случае настраиваете файрвол жеж.(по хорошему)
Плюс переконфигурация nginx/iptables/nftables не требует перезапуска экспортера.
Ниже уже сказали про надежность решения.
а с аккаунта с которого публиковали почему не поерничать?
Хамоватый виртуал самовыпилился, ему на смену ниже в комментах пришли три новых (ну да, они все трое сегодня зарегистрировались, чтобы оставить первый в своей жизни коммент на сайте, восхваляющий решение автора :) ) Первый раз вижу, чтобы тут так смешно реагировали на критику.
Вообще-то есть простые прокси, типа vmagent, специально для этого предназначенные.
Ну тогда уж надо сразу настраивать какой-то пайплайн пересборки node-exporter с этим патчем при выходе каждого нового релиза, делать для своей версии репозиторий, который добавлять в пакетные менеджеры на всех хостах... А ещё в systemd unit для запуска node exporter этот флаг добавлять.
Реально проще, как уже написали, файрволл. У меня та же Ansible роль, что node exporter устанавливает (ну и по другим экспортерам аналогично), сразу добавляет правило nftables для доступа с определённых IP. Список IP в глобальной переменной, если что-то поменялось - поменял переменную, прогнал плейбук - и всё.
Проблема в том, что вместо решения с кучей шагов, на которых что-то может пойти не так и потребовать ручного вмешательства (скажем, что-то в новой версии node exporter будет конфликтовать с нашими патчами, и хорошо, если оно просто компилироваться откажется, а не молча перестанет работать), тот же результат можно достичь гораздо проще и надёжнее. А поскольку node exporter на все сервера всё равно надо с помощью чего-то установить и порт для него на них открыть, не руками же, - то решение с фаерволлом вообще не влечёт дополнительных трудозатрат, просто добавляем один доп. параметр.
P.S. Было предложение реализовать такой флаг в issues node exporter'а, отклонено по аналогичной причине - это задача прокси или фаерволла, для самого сервиса это out of scope. Концептуально верно, думаю - каждой задаче свой инструмент, unix way и всё такое.
А что такого секретного в этих метриках, что их необходимо фильтровать по IP?
Почему не подходит авторизация?
Читаю все комментарии и складывается впечатление, что люди готовы захаять любое предложение, человек сделал за Вас большую работу. Вы вправе соглашаться или не соглашаться с этим, предлагать скои конструкции на конструкции. Порождая новые сущности. Опять побеждает воинствующее невежество. Все готовы ради хайпа кинуть в соседа...
Только вероятность что вы попадете, не велика, а вот ручки то уже испачкаете!!!
Вам предложили простое, элегантное решение, существующее во многих агентах, к примеру того же zabbix. Нет желание использовать не используйте.
Сами то Вы что либо сделали в своей жизни кроме того что обхаяли кого-то и кинули в соседа!???
Все предложение, настроить файрвол, поставить дополнительно что-то еще, использовать непопулярный алгоритм шифрования bcrypt, с сомнительной стойкостью, нагородить не весть чего...
Печально, что хабрчани скатывается в...
Тут всего два комментария:
Решил, что это полезное изменение, ок. А есть ли MR в апстрим?
Фильтрация по IP адресам это совсем странно. Добавь поддержку подсетей, чаще нужна именно она (конкретные адреса можно заводить как /32 или поддержать в списке как IP/mask, так и просто IP)
Простите что вмешиваюсь, но позвольте уточнить сколько агрегаторов в вашей сети, имею ввиду серверов Prometheus или VictoriaMetrics? Явно не больше дву-трех для конкретного узла!
Тогда встает вопрос о целесообразности маски!
Но это мое мнение и Вы вправе не согласиться с ним!
Всё так, их счётное количество.
Но потом внезапно запускается новый пром (т.к. ресурсов одного не хватает и решили горизонтально масштабироваться) и на сотнях хостов нужно менять конфигурацию.
Конечно, это проблема "будущих нас", да и вообще, позволяет создавать работу на пустом месте, но точно ли это надо? ;))
p.s. А если учесть, что node exporter используется на, думаю, даже не миллионах, а десятках миллионов хостов, то при вводе функционала нужно учитывать потребность всех массовых потенциальных пользователей, а не пилить личный-персональный форк.
Простите за некорректное поведение и ответить вопросом на вопрос:
Вы используете в инфраструктуре zabbix агентов, или Pandora агентов, или ОкАгента!?
Тогда как Вы планирует вопросы "будущих нас" при увеличении zabbix серверов или zabbix прокси или Pandora сервера, ОкСервера!?
И Вы уверены что в будущем не появится то что даст вам более интересные решения сбора метрик с хостов чем имеющиеся!? И Вам не прийдется в связи с этим менять всю логику сбора метрик.
А так же какой жизненный цикл ваших хостов и какой процент из них имеет аптайм или время создания больше 3х-5лет?
Вы используете в инфраструктуре zabbix агентов, или Pandora агентов, или ОкАгента!?
От агентов отказались, каждая команда регистрирует свои хосты в консуле, из консула рендерится динамический конфиг для прометеев (на то были свои причины и они за скоупом обсуждения).
Команда мониторинга сама отвечает за сайзинг своих ресурсов и может менять хосты-скпейперы при необходимости, мониторинг живёт в отдельной подсети.
И Вы уверены что в будущем не появится то что даст вам более интересные решения сбора метрик с хостов чем имеющиеся!?
Уверен, что точно появится. Но замена всей инфраструктуры мониторинга происходит значительно реже, чем горизонтальное масштабирование существующей инфраструктуры.
А так же какой жизненный цикл ваших хостов и какой процент из них имеет аптайм или время создания больше 3х-5лет?
Про аптайм не скажу, но хостов с жизненным циклом более 3х лет в моей зоне ответственности довольно много, что у других пользователей систем мониторинга я не в курсе.
CIDR'ы - это база
Нужная статья, Спасибо дорогой!
Не обращай на комментаторов внимание, у большинства их них нет ни одной статьи, а многие, судя по комментам, слабо разбираются в вопросе!
Да, несомненно есть положительные и отрицательные стороны в данном подходе как и в любом другом.
Хорошо когда софт пишут продуманно и дают пользователем достаточно инструментария для реализации своих замыслов, а не заставляют искать счастье на стороне в виде сторонних приложений.
Предложенный тобой подход годится для устройств с ограниченными ресурсами, и позволяет ИБ не беспокоится об утечке чувствительных данных.
По возможности свяжись со мной, есть предложения для обсуждения!
Спасибо за труд! Давно не хватало данного, простого решения, компактного и логичного, почему отказались от этого разработчики, до сих пор не понятно.
Статья ради статьи, патч ради патча.
Ограждение по IP это неудобно, особенно если прометей живёт в кубе и может мигрировать с хоста на хост и соответственно IP может меняться и даже подсети, может оказаться, что в 1 момент у вам нет метрик ни с одного из экспортеров.
По этому логичнее просто закрывать базовой авторизацией, а это как и написали выше - штатный функционал - https://ruan.dev/blog/2021/10/10/setup-basic-authentication-on-node-exporter-and-prometheus
Ограничение доступа к метрикам Node Exporter по IP-адресам