Vector-proxy - это тот же самый vector, который выполняет только проксирование трафика(у вас на схеме это Vector-агрегатор). В нашем случае используется F5 балансировщик, который распределяет трафик между N Vector-proxy. Можно вполне использовать и HA-Proxy для этих целей. Т.к. при взаимодействии между Vector -> Vector, успешно доставленным сообщение считает только при подтверждении его доставки приемником, то перезагрузка одного из N Vector-proxy не приводит к потере сообщений, т.к. не доставленное сообщение отправляется повторно по новому адресу полученному от балансировщика.
Почему Кафка, а не балансировка между n-нодами Vector? Уже много времени прошло, но на сколько помню свои исследования, Кафка из 9 год проживал 250к строк в секунду, один вектор прожевал 50-60к строк. Поставить балансировщик и 5 вектор прокси по идее выгоднее.
P.S. мы не смогли отказаться от кибаны, т.к. потребители логов админы и дежурка, но тоже рассматривали данную схему, т.к. она более выгодна с точки зрения утилизации ресурсов . Остались на OVK(opensearch, vector, kibana)
Это путь расположения динамических пользовательских параметров. Их можно расположить в удобном для Вас месте изменив в скрипте переменную dyn_up_dir
Если вопрос в том, почему используется отдельная от стандартных пользовательских параметров директория, то это надо для того, что бы агент zabbix не старался их загрузить при старте(отделить стандартные UP от динамических). Можно это сделать через иное расширение файлов, это уже дело удобства/привычки.
Можно, конечно, сделать и плагин, но постоянно пересобирать агент, что бы добавить свой плагин как-то не очень хочется. Так же в нашем случае из-за отсутствии рута проще использовать скрипт, т.к. скрипт можно разлить своими руками, а обновлять агентов, надо напрягать админов, и этап распространения растянется надолго.
Если бы можно было написав плагин отдать его Zabbix, то это был бы интересный вариант, но тут нужно что бы сообщество поддержало соответствующий ZBX-NEXT.
AlexGluck написал основные моменты с использованием system.run, немного дополню. Ключ элемента данных ограничен в последних версиях 2048 символами. Так же сталкивались с тем, что не любую команду можно запихнуть в system.ru(возможно что-то недосмотрел, утверждать не буду). С безопасниками можно договориться на использовании system.run с ведением списка AllowKey, но это доставляет примерно туже головную боль, что и распространение UserParameter, а ввиду вышеописанных ограничений system run, то выбрали для себя использование UserParameter
Vector-proxy - это тот же самый vector, который выполняет только проксирование трафика(у вас на схеме это Vector-агрегатор). В нашем случае используется F5 балансировщик, который распределяет трафик между N Vector-proxy. Можно вполне использовать и HA-Proxy для этих целей. Т.к. при взаимодействии между Vector -> Vector, успешно доставленным сообщение считает только при подтверждении его доставки приемником, то перезагрузка одного из N Vector-proxy не приводит к потере сообщений, т.к. не доставленное сообщение отправляется повторно по новому адресу полученному от балансировщика.
Почему Кафка, а не балансировка между n-нодами Vector? Уже много времени прошло, но на сколько помню свои исследования, Кафка из 9 год проживал 250к строк в секунду, один вектор прожевал 50-60к строк. Поставить балансировщик и 5 вектор прокси по идее выгоднее.
P.S. мы не смогли отказаться от кибаны, т.к. потребители логов админы и дежурка, но тоже рассматривали данную схему, т.к. она более выгодна с точки зрения утилизации ресурсов . Остались на OVK(opensearch, vector, kibana)
Это путь расположения динамических пользовательских параметров. Их можно расположить в удобном для Вас месте изменив в скрипте переменную dyn_up_dir
Если вопрос в том, почему используется отдельная от стандартных пользовательских параметров директория, то это надо для того, что бы агент zabbix не старался их загрузить при старте(отделить стандартные UP от динамических). Можно это сделать через иное расширение файлов, это уже дело удобства/привычки.
Можно, конечно, сделать и плагин, но постоянно пересобирать агент, что бы добавить свой плагин как-то не очень хочется. Так же в нашем случае из-за отсутствии рута проще использовать скрипт, т.к. скрипт можно разлить своими руками, а обновлять агентов, надо напрягать админов, и этап распространения растянется надолго.
Если бы можно было написав плагин отдать его Zabbix, то это был бы интересный вариант, но тут нужно что бы сообщество поддержало соответствующий ZBX-NEXT.
AlexGluck написал основные моменты с использованием system.run, немного дополню. Ключ элемента данных ограничен в последних версиях 2048 символами. Так же сталкивались с тем, что не любую команду можно запихнуть в system.ru(возможно что-то недосмотрел, утверждать не буду). С безопасниками можно договориться на использовании system.run с ведением списка AllowKey, но это доставляет примерно туже головную боль, что и распространение UserParameter, а ввиду вышеописанных ограничений system run, то выбрали для себя использование UserParameter