AK
А вы юзали это решение? Если да, то можете поделиться впечатлениями?
Мы Kubernetes'ом и сборкой и деплоем больше занимались в 2019. Уверен, в этом году больше мониторинга будет. Наконец, будет чем поделиться интересным.
Size: a a a
2020 January 26
VS
Мы Kubernetes'ом и сборкой и деплоем больше занимались в 2019. Уверен, в этом году больше мониторинга будет. Наконец, будет чем поделиться интересным.
👍 ждем! И надеюсь про логгинг не забудете
2020 January 27
A
Гайз, привет
А не поможете продумать конфиг мониторинга на проме?
1. Есть идея соорудить федерацию. Один Пром чтоб был основным и хранил сырые данные до 30 дней, а другой - агрегированные год. Есть ли в этом смысл?
2. У смежных команд есть свой Прометей. Имеет ли смысл подключать его к федерации или просто подключить его сорсом к своей Графане? Есть шанс, что та команда не будет рада тяжёлым дашбордам, правда.
3. Нормальна ли практика работы через таргеты. Без сервис дискавери.
Инфосеки в конторе выносят мозг и не дают менять fqdn, да и вообще использовать sd.
А не поможете продумать конфиг мониторинга на проме?
1. Есть идея соорудить федерацию. Один Пром чтоб был основным и хранил сырые данные до 30 дней, а другой - агрегированные год. Есть ли в этом смысл?
2. У смежных команд есть свой Прометей. Имеет ли смысл подключать его к федерации или просто подключить его сорсом к своей Графане? Есть шанс, что та команда не будет рада тяжёлым дашбордам, правда.
3. Нормальна ли практика работы через таргеты. Без сервис дискавери.
Инфосеки в конторе выносят мозг и не дают менять fqdn, да и вообще использовать sd.
A
Я вообще ещё ни разу не развертывал Пром с нуля (всегда работал с уже готовым, as service), поэтому буду рад советам, чтоб заранее что-то учесть и не накосячить.
ST
Гайз, привет
А не поможете продумать конфиг мониторинга на проме?
1. Есть идея соорудить федерацию. Один Пром чтоб был основным и хранил сырые данные до 30 дней, а другой - агрегированные год. Есть ли в этом смысл?
2. У смежных команд есть свой Прометей. Имеет ли смысл подключать его к федерации или просто подключить его сорсом к своей Графане? Есть шанс, что та команда не будет рада тяжёлым дашбордам, правда.
3. Нормальна ли практика работы через таргеты. Без сервис дискавери.
Инфосеки в конторе выносят мозг и не дают менять fqdn, да и вообще использовать sd.
А не поможете продумать конфиг мониторинга на проме?
1. Есть идея соорудить федерацию. Один Пром чтоб был основным и хранил сырые данные до 30 дней, а другой - агрегированные год. Есть ли в этом смысл?
2. У смежных команд есть свой Прометей. Имеет ли смысл подключать его к федерации или просто подключить его сорсом к своей Графане? Есть шанс, что та команда не будет рада тяжёлым дашбордам, правда.
3. Нормальна ли практика работы через таргеты. Без сервис дискавери.
Инфосеки в конторе выносят мозг и не дают менять fqdn, да и вообще использовать sd.
1 - сначала лучше разберись с обычной конфигурацией, незачем городить сложные вещи если базовых навыков нет
2 - от конторы зависит и команд
3 - при небольшой конфигурации достаточно file-sd юзать
2 - от конторы зависит и команд
3 - при небольшой конфигурации достаточно file-sd юзать
ST
такого думаю тебе хватит
# REDIS EXPORTER
- job_name: Redis
file_sd_configs:
- files:
- '{{ file_sd_config_path }}/redis/*.yml'
# NODE EXPORTER
- job_name: Node
file_sd_configs:
- files:
- '{{ file_sd_config_path }}/node/*.yml'
# RABBITMQ EXPORTER
- job_name: RabbitMQ
file_sd_configs:
- files:
- '{{ file_sd_config_path }}/rabbitmq/*.yml'
A
1 - сначала лучше разберись с обычной конфигурацией, незачем городить сложные вещи если базовых навыков нет
2 - от конторы зависит и команд
3 - при небольшой конфигурации достаточно file-sd юзать
2 - от конторы зависит и команд
3 - при небольшой конфигурации достаточно file-sd юзать
Да, сначала хочу запустить простую схему из доки
Хорошо, уточню у тех ребят тоже тогда
О, file-based service discovery, точно!
Спасибо!
Хорошо, уточню у тех ребят тоже тогда
О, file-based service discovery, точно!
Спасибо!
A
такого думаю тебе хватит
# REDIS EXPORTER
- job_name: Redis
file_sd_configs:
- files:
- '{{ file_sd_config_path }}/redis/*.yml'
# NODE EXPORTER
- job_name: Node
file_sd_configs:
- files:
- '{{ file_sd_config_path }}/node/*.yml'
# RABBITMQ EXPORTER
- job_name: RabbitMQ
file_sd_configs:
- files:
- '{{ file_sd_config_path }}/rabbitmq/*.yml'
Ага, схоронил. Отлично
A
Планируется хостов 20-25, думаю. Вся инфра крайне редко меняется.
ST
Планируется хостов 20-25, думаю. Вся инфра крайне редко меняется.
file_sd с головой хватит
A
По большей части у меня просят метрики на блекбоксе. Всякие исмп/хттп чеки, проверки апи и тд
A
Это почти 50% того, что хотят видеть ребята на дашбордах
A
такого думаю тебе хватит
# REDIS EXPORTER
- job_name: Redis
file_sd_configs:
- files:
- '{{ file_sd_config_path }}/redis/*.yml'
# NODE EXPORTER
- job_name: Node
file_sd_configs:
- files:
- '{{ file_sd_config_path }}/node/*.yml'
# RABBITMQ EXPORTER
- job_name: RabbitMQ
file_sd_configs:
- files:
- '{{ file_sd_config_path }}/rabbitmq/*.yml'
выглядит как ручное создание ямлей жынжей, не стыдно?
ST
выглядит как ручное создание ямлей жынжей, не стыдно?
просто руками без днс дискавери круче?)
A
если чо к file_sd у меня претензий нет
A
выглядит как ручное создание ямлей жынжей, не стыдно?
все равно ансибл же будет трудиться
A
шаблонизировать над только
A
все равно ансибл же будет трудиться
даже в ансибле можно это делать не ручным вписыванием строк в ямль, а через например to_yaml
AV
кстати, у кого-нибудь есть опыт использования jsonnet для генерации yml конфига для прометея?
A
у меня был, но закончилось на том что я бы хотел спеку конфига для каждой версии научиться получать из кода, но посмотрев в код я понял что это нереально