Комментарии 12
> Open-source как гарант отсутствия скрытых элементов.
Это не гарантия закладок и скрытых, или не очень скрытых элементов по результату начала СВО
Заббикс имеет пуш модель и высокочастотный мониторинг с частотой опроса 1 секунда (меньше не помню), активный агент. Прометей работает через пул модель и запросы с частотой 1 секунда на все метрики потребуют больше вычислительных ресурсов. Может кто нибудь из технических специалистов, квалифицированных, раскрыть тему мониторинга из того бреда, что написано в статье?
Если говорить о заббиксе и прометеусе в разрезе общих функциональных возможностей, то действительно, сбор системных метрик с помощью node exporter'а требует больше вычислительных ресурсов, чем шаблон заббикса с ограниченным количеством метрик, которые требуется в рамках какого-либо тестирования или задачи мониторинга при идентичных входных параметрах. Но в случае с нагрузочным тестированием freeipa, существенной разницы по нагрузке от сбора системных метрик не диагностируется. В свою очередь, первично нужно разделить сбор системных метрик и прикладных, так в данном случае мониторинг LDAP средствами заббикс в момент повышенной нагрузки неоднократно мог демонстрировать некорректные результаты, ввиду долгого выполнения сбора метрик скриптом с ldapsearch. Допуская несовершенство способа мониторинга в заббикс, было принято решение, протестировать ldap exporter с определенным набором метрик, необходимых для объективного мониторинга в рамках нагрузочного тестирования, с перспективой последующего использования в промышленной эксплуатации и необходимыми возможными доработками.
Частично сохранив логику предыдущего опыта мониторинга, в ldap exporter, при первом же нагрузочном тестировании, было обнаружено, что задержки отсутствуют и метрики приходят регулярно, несмотря на повышенную нагрузку LDAP в момент тестирования. Используя точечные более легкие запросы поиска, ldap exporter весьма успешно и быстро собирает все необходимые метрики. Таким образом закрывая потребность для НТ.
Но учитывая всю успешность подобного метода, полностью отказаться от заббикса проблематично и в промышленной эксплуатации они работают в тандеме, дополняя друг друга.
То есть, если заббикс будет из экспортёра забирать метрики, у него нет проблем с производительностью. Если нанять квалифицированного сотрудника, который напишет сбор метрик оптимально, а не на коленке как у вас тестировалось, то нет проблем с производительностью. В статье получается написано о чем?
В разрезе данного вопроса есть много специфических факторов, которые влияют на конечную цель. Логично предположить, что если оптимизировать сбор метрик, то с производительностью не возникнет проблем, но на практике наблюдалось, что в заббиксе возникали проблемы со сбором метрик даже с измененными запросами и Prometheus был отдан приоритет в рамках НТ. Так же ввиду определенных ограничений среды тестирования, с той версией заббикс, с которой в связке проводились тесты, забирать им метрики с экпортера не было возможности.
В статье описан весь процесс становления freeipa в качестве полноценного enterprise решения и мониторинг это одна из его частей.
К слову, мы всегда открыты к обмену опытом и каким-либо доработкам, если в результате они принесут большую пользу конечному продукту и его клиентам.
Поделитесь своим LDAP экспортером?
Присоединяюсь, тоже было бы интересно.
К сожалению собственным поделиться не можем, но Вы можете обратить внимание на этот https://github.com/ferringb/ldap_exporter. Именно по LDAP он покроет минимум потребностей.
Доброго дня! Может быть кто-то сталкивался с подобной задачей. Необходимо чтобы на серверах freeipa размещались разные организации (более 50), для удобства администрирования нужно их как-то отделить друг от друга (подобно доменам в дереве ad).
Насколько я понимаю, есть домен kerberos freeIPA, и в нем могут быть разные домены DNS. В настоящий момент на сервере freeipa развернула 2 области ДНС. Каким образом можно разделить на днс-домены домен freeIPA и явно указать компу, к какому днс-домену freeipa он принадлежит? Либо есть иные более удобные решения разграничения пулов пользователей.
ПК на Альт Рабочая станция 10, FreeIPA на Альт сервер 10
freeipa это не для управления организациями типа как IBM, SAP или 1C-продукты. оное существует чисто для сборки в керберизованную структуру пользаков, серверов и их групп и всяких Linux-политик.
То есть там заведомо не пошли по пути AD с кучей OU-шек и подобной дорогущей поприетарной ерундой.
Для организаций должны быть отдельные транзитивные домены (точнее реалмы, домены это термин чисто MS).
К сожалению до сих пор сообщество тему GC не реализовало, да и в ближайшее время не сможет, так как - это патенты MS. Нужны глобальные каталоги, нужна структура аналогичная AD со всякими лесами, доменами, сайтам и тд с зависимостями и наследованиями, а это уже уровень хранения, а не тема безопасности.
DNS тут совсем не причем, так как организации лишь содержат какие-то там сервера с именами *.hostname.com, а доменные имена серверов могут быть хоть google.com внутри инфраструктуры.
LDAP не запрещает насоздавать кучу объектов и тех же organization unit, внутри доменного суффикса, но только сразу вопрос: а что этим всем по сути будет управлять? freeipa заточена под конкретную задачу, под конкретный каталог, под конкретные пути.
Так-то можно все что угодно там сделать, вопрос только в сложности переработки всего кода практически с нуля.
Linux, Unix, безопасность: open source-проект FreeIPA как Enterprise-решение