Утомляет тратить время на воинствующих неофитов(обычно неофиты грешат обвинениями, в чем-то, в адрес людей задающих вопросы, либо читайте про Brilliant Jerks in Engineering), но. Вопросы задаются, чтобы обрести понимание, а не отстаять какую-то точку зрения. Можно конечно без понимания, просто на веру что-то принять, но приятнее понимать причины того или иного решения. Почитал [доку](https://prometheus.io/docs/introduction/faq/#why-do-you-pull-rather-than-push?): Overall, we believe that pulling is slightly better than pushing, but it should not be considered a major point when considering a monitoring system. For cases where you must push, we offer the Pushgateway. Рили, пушгейт, вместо опции у экспортера?

Утомляет тратить время на воинствующих неофитов(обычно неофиты грешат обвинениями, в чем-то, в адрес людей задающих вопросы, либо читайте про Brilliant Jerks in Engineering), но. Вопросы задаются, чтобы обрести понимание, а не отстаять какую-то точку зрения. Можно конечно без понимания, просто на веру что-то принять, но приятнее понимать причины того или иного решения. Почитал [доку](https://prometheus.io/docs/introduction/faq/#why-do-you-pull-rather-than-push?): Overall, we believe that pulling is slightly better than pushing, but it should not be considered a major point when considering a monitoring system. For cases where you must push, we offer the Pushgateway. Рили, пушгейт, вместо опции у экспортера?

какой опции?

какой опции?

ты же можешь указать, какие метрики отдавать? Как аргумент

Утомляет тратить время на воинствующих неофитов(обычно неофиты грешат обвинениями, в чем-то, в адрес людей задающих вопросы, либо читайте про Brilliant Jerks in Engineering), но. Вопросы задаются, чтобы обрести понимание, а не отстаять какую-то точку зрения. Можно конечно без понимания, просто на веру что-то принять, но приятнее понимать причины того или иного решения. Почитал [доку](https://prometheus.io/docs/introduction/faq/#why-do-you-pull-rather-than-push?): Overall, we believe that pulling is slightly better than pushing, but it should not be considered a major point when considering a monitoring system. For cases where you must push, we offer the Pushgateway. Рили, пушгейт, вместо опции у экспортера?

*отстоять

могу

и даже могу указать какой порт открыть

могу

почему бы не добавить аргумент с адресом сервера ? ))

и что по-твоему экспортер будет с ним делать?

все кругом неофиты, а я дартаньян

почему бы не добавить аргумент с адресом сервера ? ))

вместо того, чтобы выносить это в отдельный код

при пулл-модели

при пулл-модели

при чистой пулл - ничего это вопрос для дискусии, зачем выносить функционал сюда https://prometheus.io/docs/instrumenting/pushing/ если можно было прям в экспортере это сделать? Default - pull

написано же там где-то, что pushgateway сделан для безысходных случаев

пушгейтвей это костыль для определённого юзкейза

короче, если хочешь юзать прометей, то юзай pull и юзай сервис-дискавери

тогда у тебя всё будет хорошо

Яж не поспорить, а подиоложить )

Проблема в том, что сделать все и сразу сложно. Поэтому лучше сделать что-то одно

а если не секрет, чем раньше пользовался?

Другой вопрос, у графаны есть куча темплейтов, но вчера попробовал с десяток разных и почти все с ходы не взлетели(юез правки), т.к. в Variables, каждый указывает, что хочет. Это тоже ок?

к сожалению, да

а если не секрет, чем раньше пользовался?

Zabbix, Munin, MRTG

прометей довольно гибкий

графана очень гибко настраивается

и тебе всё равно надо будет под себя переделывать

и тебе всё равно надо будет под себя переделывать

это уже понял :)

на самом деле (tm) нарисовать вменяемые дашборды в графане - намного сложнее, чем настроить прометея

Кстати, например, python prometheus_client вполне себе умеет делать export в pushgateway, но почему-то это все равно никто не реализовывает.

Кстати, например, python prometheus_client вполне себе умеет делать export в pushgateway, но почему-то это все равно никто не реализовывает.

Там почти все умеют, просто в рамках парадигмы Prometheus у push и pull немного разное применение.

это либы умеют, а не экспортеры

и либе это логично уметь, потому что бывают разные случаи, когда надо странное

а если у тебя готовый экспортер который нормально умеет прометея и нормально ложится на пул-модель, то это тебе не надо

в графане в пай чарте нельзя цвет менять? 0_о

нашел

Сценарий который хочу реализовать: - один Prometheus - одна Grafana (но много команд, у которых свои дашборды, можно ли на уровне ldap разграничить доступ к дашбордам?) - конфиги (alertmanager, prometheus, grafana) в репе (Gitlab) - изменения в конфигах через MR в Gitlab Такое возможно, у кого-то может даже так уже в проде?

у нас на прошлой работе прометей настраивался Puppet'ом

конфиги Puppet лежали в гите, да

у нас на прошлой работе прометей настраивался Puppet'ом

у нас salt, но суть та же

И как быть с long-term метриками? Когда я хочу посмотреть, что было 5-8 месяцев назад?

есть несколько вариантов

timescale, например, недавно в бложике у себя писали, что они ништяк для прометейского лонг-терм

timescale, например, недавно в бложике у себя писали, что они ништяк для прометейского лонг-терм

https://docs.timescale.com/v0.8/tutorials/prometheus-adapter оно ?

не знаю, я это не юзал

А кто-то в постгрю пробовал?

А кто-то в постгрю пробовал?

хехе, по ссылке которую я приложил, есть ответ

Похоже ответ на мой вопрос запинин в шапке в общем, я доделал адаптер для прома - https://github.com/akumuli/akumuli-propmetheus-adapter с этой штукой akumuli можно использовать как long-term storage для прома, при этом должно получаться очень дешево по ресурсам (akumuli может всосать в разы больше прома на том же железе)

для akumuli вроде сделано только remote-write

без read

для akumuli есть datasource для графаны

это значит что надо будет делать два графика

дублировать запросы

один для прометея, второй для акумули

Хочется как можно меньше движушихся частей

Буду пробовать, потом расскажу

а чем у тебя твои сервера настраиваются? солтом же?

а ты же можешь тем же солтом при настройке сервера добавлять его в какой-то список?

а потом на хосте с прометеем из этого списка создавать конфиг

а потом на хосте с прометеем из этого списка создавать конфиг

да, так и будет

ну тогда тебе какая разница, пул или пуш

всё будет само

ну тогда тебе какая разница, пул или пуш

- вопрос был для понимания - на тестовые стенды (пара), руками разложил экспортеров, делал в конце дня и не подумал о salt

всё будет само

??

кнопка - сделать хорошо ))

ну да

под кнопкой конечно куча костылей, подпорок и говнокода

ERROR: S client not available

но главное чтобы работало

Вчера вот такое было https://promcon.io/2018-munich/talks/prometheus-monitoring-mixins/

Есть у кого-нибудь опыт распиливания доступа к графане по командам?

Есть у кого-нибудь опыт распиливания доступа к графане по командам?

а чего нужно? есть опыт

Есть много команд разработчиков, есть AD, есть grafana. Хочу: Общие дашборды - видны всем, только чтение Специфичные для команды - видны только им и можно редактировать

была попытка использовать организации (плохо), была попытка делпоя по командам отдельных графан в контейнерах с общим роутингом кому куда (чуть лучше)

AD тут не самый хороший помощник

организации же вроде улучшили в последних версиях графаны

на самом деле хотелось бы тоже послушать мнение

Первый вариант - заюзать организации. И добавлять в них группы людей А второй способ в настройках дашборда есть вкладка "Permissions"

У меня сделано так, что есть N организаций. Юзеры рпаскиданы по "Teams" + в рамках организации можно контролировать видимость/права для дашбордов

Первый вариант - заюзать организации. И добавлять в них группы людей А второй способ в настройках дашборда есть вкладка "Permissions"

второй вариант нам в итоге понравился больше, просто очень уж часто кросс командные интересы возникают, замучаешься перекидывать по организациям. этот вариант меньше нагрузки на команду мониторинга дает. на крайняк если кто то неаккуратно порушил, всегда можно откатить

У меня сделано так, что есть N организаций. Юзеры рпаскиданы по "Teams" + в рамках организации можно контролировать видимость/права для дашбордов

Team - сущность в organiztion?

второй вариант нам в итоге понравился больше, просто очень уж часто кросс командные интересы возникают, замучаешься перекидывать по организациям. этот вариант меньше нагрузки на команду мониторинга дает. на крайняк если кто то неаккуратно порушил, всегда можно откатить

дашборды в одной репе или как-то инклюдами?

да, в одной

Team - сущность в organiztion?

Team это сущность, в которой просто можно организовать юзеров. К организациям не имеет отношения

Team нужен для настройки видимости/прав для дашборда

Team нужен для настройки видимости/прав для дашборда

понял

Team это сущность, в которой просто можно организовать юзеров. К организациям не имеет отношения

Grafana может LDAP groups? Могу я их в Team засунуть LDAP Group?

Grafana может LDAP groups? Могу я их в Team засунуть LDAP Group?

не сталкивался

Или придется сначала всем залогиниться, потом мне распихать их в Team'ы и дать тимам доступ к бордам?

не сталкивался

ок

http://docs.grafana.org/installation/ldap/ LDAP to Grafana Org Role Sync Mappings In [[servers.group_mappings]] you can map an LDAP group to a Grafana organization and role. These will be synced every time the user logs in, with LDAP being the authoritative source. So, if you change a user’s role in the Grafana Org. Users page, this change will be reset the next time the user logs in. If you change the LDAP groups of a user, the change will take effect the next time the user logs in.

нельзя в team ldap_groups, лдап только на роли мапится

@mozgoo будет жить. Поприветствуем!

нельзя в team ldap_groups, лдап только на роли мапится

а роли вешаются на Team ?

нет

роли как я понимаю вешаются на всю организацию, поэтому, похоже нельзя всех поселив в одной, рулить правами через ldap

но In [[servers.group_mappings]] you can map an LDAP group to a Grafana organization я могу же смапить LDAP group и Organization?

у меня только viewer и editor замаплены

тогда можно dev.team = organization