Херово с консистентностью будет. Бывает что есть всякие "кроны", или "задания" из очереди, и если они запустятся после ввода нового мастера, но до накатки изменений, могут случатся совсем непонятные вещи. Чтобы контролировать потенциальные проблемы которые могут при этом возникнуть, придется много чего пытаться удержать в голове.
Имхо, таким образом Вы придумали себе головняк, либо Вам пока еще "везло".
Странно, обычно ровно такое поведение когда лицензия не применилась \ не перечиталась. Если в логах везде пусто, попробуйте через admin API включить логи клиента, может что то понятнее станет.
Виктор Ведмич не совсем понимаю, как это может помочь. Ресурс нужно реализовывать в обоих ролях. Теги тоже не совсем понятно как помогут, по этой же причине.
Великолепная статья. Но позвольте один вопрос. Сталкивались ли вы со следующей проблемой. К примеру у Вас есть роли backend и frontend, к обоим хостам имею доступ определенные пользователи. Все пользователи объявлены в глобальном хэше $users, а для каждой роли есть наборы пользователей в виде $backend_users{ ab => $users['ab'], bc => $users['bc'], $frontend_users{ bc => $users['bc'] } В production это 2 разных хоста, на dev среде, эти роли совмещены на одном хосте. В результате при вызове create_resources, получаем duplicate decloration, а в связи с тем что это функция, проверить существование пользователя через if defined[] непонятно как (ну не перечисляя всех пользователей конечно). Что делать ?
Сергей Петриков: это как то не "по инжинерному". Правила не хочется разделять потому, что на их базе уже создано куча графиков и скринов. разделение потребует переделке их всех. поскольку новые итемы будуn новые =(
Написано только что
Сергей Петриков: логи анализируются скриптом, он только сендид данные в заббикс. Переписывать полностью реализацию сбора данных и разворачивать это на обширном парке серверов не хочется
Бинго. В этом и проблема. Регэксп можно, но придется итемы которые мы хотим "отфильтровать", выделит ь в отдельный discovery rule. И это опять же неудобно потому что условие внутри рула. А мы храним множество "свойств" хоста при помощи макросов.
Про все это я и написал в описании вопроса :)
Больше идей, больше ! :). Даже костыльных на ваш взгляд :)
Сергей Петриков: Запросто :) прототип хочется создать такого такого вида
nginx.log.collector[{HOST.NAME},{#LOG},nginx.log.last_1_min_long_responses_count,inotify,10 sec ago,{$NGINX_EXCLUDE_LOGS}]
В свою очередь $NGINX_EXCLUDE_LOGS это макрос хоста.
Сергей Петриков: Вопрос довольно конкретный. Как создать при помощи LLD итем, у которого в качестве аргумента будет user macros задаваймый на каждом хосте.
Я рад что у вас все хорошо. Перечитайте пожалуйста еще раз вопрос. Проблема в том что для prototype item нельзя в качестве ключа указать user macros. Я ищу решение.
index0h: Ооо, я походу понял Вашу нотацию. Вы предложили Graphite / ELK / Sentry :), а я было подумал что слэшиком вы разделили вариативные составные части целой системы :)
Имхо, таким образом Вы придумали себе головняк, либо Вам пока еще "везло".