PK
с операторм не путайте. там почти нет темплейтов в конфиге
Size: a a a
2020 January 20
YZ
с операторм не путайте. там почти нет темплейтов в конфиге
https://github.com/helm/charts/blob/master/stable/prometheus/templates/server-configmap.yaml как нет?) Ну ладно это уже офтоп
PK
это обертка для CM
YZ
Спасибо
SP
а что тогда юзать вместо statsd перед графитом?
В push-модели делать что-то, чтобы писать в итоге графит? Ну такое. Чем сам графит не угодил?
YZ
В push-модели делать что-то, чтобы писать в итоге графит? Ну такое. Чем сам графит не угодил?
статсд же для агрегации. Так?
Смысл писать напрямую в графит тысячи метрик в один момент времени если все равно нужен агрегированный результат 🤔
Смысл писать напрямую в графит тысячи метрик в один момент времени если все равно нужен агрегированный результат 🤔
A
А вот если нужно как раз события неагрегированые - что общество посоветует
A
Чтобы все равно перцентили уметь из каропки
VS
статсд же для агрегации. Так?
Смысл писать напрямую в графит тысячи метрик в один момент времени если все равно нужен агрегированный результат 🤔
Смысл писать напрямую в графит тысячи метрик в один момент времени если все равно нужен агрегированный результат 🤔
если хранить сырые данные, можно делать агрегацию в любой момент времени и по любым критериям
YZ
если хранить сырые данные, можно делать агрегацию в любой момент времени и по любым критериям
а если в графит 2 метрики пришли в один момент времени?
VS
а если в графит 2 метрики пришли в один момент времени?
различать их и писать с двумя разными именами
YZ
различать их и писать с двумя разными именами
ну такое себе. вот у тебя деплоймент с кучей реплик и все они пишут метрики с одинаковыми именами. напрмер после каждого обработанного сообщения шлют counter
service_name.processed_message.count:1
Что их теперь на serivice_name разделять? я конечно понимаю что можно, но имхо на тех же графиках получится ад похуже чем любой график метрик подов, построенный по имени пода
service_name.processed_message.count:1
Что их теперь на serivice_name разделять? я конечно понимаю что можно, но имхо на тех же графиках получится ад похуже чем любой график метрик подов, построенный по имени пода
BG
если хранить сырые данные, можно делать агрегацию в любой момент времени и по любым критериям
Хранить сырые данные дорого, всегда считать аггрегации по кучи данных дорого
VS
Хранить сырые данные дорого, всегда считать аггрегации по кучи данных дорого
ну это да, зато возможности
G
grafana/grafana description changed: v6.6.0-beta1
Link: https://github.com/grafana/grafana/releases/tag/v6.6.0-beta1
Release notes:
Link: https://github.com/grafana/grafana/releases/tag/v6.6.0-beta1
Release notes:
[Download Page](https://grafana.com/grafana/download/6.)More
[What's New Highlights](https://grafana.com/grafana/download/6.6.0-beta1)
[Release Notes](https://community.grafana.com/t/release-notes-v6-6-x/24924)
## Breaking changes
* **PagerDuty...
BG
ну это да, зато возможности
Ну, пром же так же делает. Те же бакеты разве можно разумно сделать в графите? Все равно аггрегация, только в клиенте
BG
Что не всегда удобно
VS
Ну, пром же так же делает. Те же бакеты разве можно разумно сделать в графите? Все равно аггрегация, только в клиенте
перцентили? В целом нельзя, да, их можно только имея данные по каждому запросу посчитать.