i
Вижу что это создаёт точку отказа на ровном месте
Если про второй пром - он хоть как будет и на нем будут настраиваться алерты и прочее
Size: a a a
2020 February 25
AS
Их можно считать в промкси
i
Ну и супер инстанс создаёте. Масштабировать придется вертикально
Ну во-первых с одним проще как раз можно поднимать, не отжираются ресурсы кластера
i
По факту на другом проекте в кластере под пром пришлось отдельную ноды выделить
i
В итоге - то же самое
AS
Ну и с дедупом алертов будет либо беда либо будет не возможно отличить с какого кластера пришёл алерт
i
Ну и с дедупом алертов будет либо беда либо будет не возможно отличить с какого кластера пришёл алерт
В федерации это можно же пометить как раз
i
лейбл кластера добавить
i
Федерация такая же в общем почти джоба как сбор метрик откуда-то там
AS
лейбл кластера добавить
Ага. Ну смотрите.
G
influxdata/telegraf tagged: 1.13.4
Link: https://github.com/influxdata/telegraf/releases/tag/1.13.4
Release notes:
Link: https://github.com/influxdata/telegraf/releases/tag/1.13.4
Release notes:
Telegraf 1.13.4
2020 February 26
W
не вижу корреляции с персонажами...
G
influxdata/telegraf description changed: 1.13.4
Link: https://github.com/influxdata/telegraf/releases/tag/1.13.4
Release notes:
Link: https://github.com/influxdata/telegraf/releases/tag/1.13.4
Release notes:
## v1.13.4 [2020-02-25]More
#### Release Notes
* Official packages now built with Go 1.13.8.
#### Bugfixes
* [#6988](https://github.com/influxdata/telegraf/issues/6988): Parse NaN values from summary types in prometheus input.
* [#6820](https:/...
SS
Подаскажите, пожалуйста, как можно подключить prometheus-operator к уже развернутому из stable инстансу Prometheus?
AG
Всем привет!
В https://landing.google.com/sre/sre-book/chapters/practical-alerting/#sharding-the-monitoring-topology написано, что borgmon на глобальном уровне работает с агрегированными значениями.
А как такую же схему сделать в пром?
Вот допустим есть в датацентре пром, который скрейпит метрики из этого ДЦ.
В global prom прописываю федерацию, но тогда глобальный просто будет получать все данные по метрикам.
А кто должен агрегированием заниматься?
В https://landing.google.com/sre/sre-book/chapters/practical-alerting/#sharding-the-monitoring-topology написано, что borgmon на глобальном уровне работает с агрегированными значениями.
А как такую же схему сделать в пром?
Вот допустим есть в датацентре пром, который скрейпит метрики из этого ДЦ.
В global prom прописываю федерацию, но тогда глобальный просто будет получать все данные по метрикам.
А кто должен агрегированием заниматься?
ST
кто нибудь встречал доку по миграции tsdb прома в другой пром-инстанс? что то вроде подмапить данные под чужой бинарник? какие есть подводные камни, не могу нагуглить
google по миграции выдает инфу по миграциям между версиями
google по миграции выдает инфу по миграциям между версиями
AS
кто нибудь встречал доку по миграции tsdb прома в другой пром-инстанс? что то вроде подмапить данные под чужой бинарник? какие есть подводные камни, не могу нагуглить
google по миграции выдает инфу по миграциям между версиями
google по миграции выдает инфу по миграциям между версиями
настрой remote_read из того с которого собрался мигрировать. перестань там собирать данные.
собирай новые данные на новом инстансе.
дождись пока на исходном кончится рентешен.
готово
собирай новые данные на новом инстансе.
дождись пока на исходном кончится рентешен.
готово
ST
настрой remote_read из того с которого собрался мигрировать. перестань там собирать данные.
собирай новые данные на новом инстансе.
дождись пока на исходном кончится рентешен.
готово
собирай новые данные на новом инстансе.
дождись пока на исходном кончится рентешен.
готово
ну вот по факту самый простой вариант это тупо сделать такую же конфигурацию и ждать пока данные станут одинаковыми а потом старый убить, интересен был вопрос можно ли без ожиданния старую tsdb под новый инстанс перенести без потерь =)
AS
придется совмещать данные. я такую процедуру не знаю.
N
Ну если с даунтаймом, то просто папочку можно перенести имхо