AS
avg(some_value{instance_id="aa"}[1m]) > 1
Size: a a a
2020 June 04
AV
мы обсуждали с коллегами эту ситуацию они понимают что без ребалансинга это такой себе rf
это такой же replication, как и в m3db :) Его хватает для случаев, когда нужно существенно снизить вероятность утери части данных. В прежней схеме данные просто раскидывались между сторедж нодами. Поэтому при утере данных на одной из сторедж нод эти данные переставали быть видными в последующих запросах (т.е. они терялись). Теперь же все данные остаются видны при утере до RF-1 сторедж нод. Увеличение RF существенно снижает вероятность утери части данных, которая считается по формуле
Также репликация позволяет проводить rolling upgrade для vmstorage нод без временной недоступности части данных.
p^RF, где p - вероятность выхода из строя одного стореджа. Например, если вероятность выхода из строя одного стореджа равна 1%, то вероятность утери данных для RF=2 будет равна 0.01^2=0.01%, а для RF=3 она снизится до 0.01^3=0.0001%.Также репликация позволяет проводить rolling upgrade для vmstorage нод без временной недоступности части данных.
p
avg(some_value{instance_id="aa"}[1m]) > 1
я не про матч по вхождению полному\частичному а именно сравнение с int значением.
AS
это такой же replication, как и в m3db :) Его хватает для случаев, когда нужно существенно снизить вероятность утери части данных. В прежней схеме данные просто раскидывались между сторедж нодами. Поэтому при утере данных на одной из сторедж нод эти данные переставали быть видными в последующих запросах (т.е. они терялись). Теперь же все данные остаются видны при утере до RF-1 сторедж нод. Увеличение RF существенно снижает вероятность утери части данных, которая считается по формуле
Также репликация позволяет проводить rolling upgrade для vmstorage нод без временной недоступности части данных.
p^RF, где p - вероятность выхода из строя одного стореджа. Например, если вероятность выхода из строя одного стореджа равна 1%, то вероятность утери данных для RF=2 будет равна 0.01^2=0.01%, а для RF=3 она снизится до 0.01^3=0.0001%.Также репликация позволяет проводить rolling upgrade для vmstorage нод без временной недоступности части данных.
Саша, ну камон. https://m3db.github.io/m3/operational_guide/repairs/
AV
оно вроде отключено по умолчанию
AS
включено, выключено ни о том речь же
AV
AS
аналог да
AS
понятно что восстановление или даже увеличение rf это ппц какая дорогая процедура и по cpu и по дискам и по логике
AV
Советую еще почитать там раздел caveats and limitations внизу дока:
* Background repairs do not currently support M3DB's inverted index; as a result, it can only be used for clusters / namespaces where the indexing feature is disabled
* Background repairs will wait until (block start + block size + buffer past) has elapsed before attempting to repair a block. For example, if M3DB is configured with a 2 hour block size and a 20 minute buffer past that M3DB will not attempt to repair the 12PM->2PM block until at least 2:20PM
* Background repairs do not currently support M3DB's inverted index; as a result, it can only be used for clusters / namespaces where the indexing feature is disabled
* Background repairs will wait until (block start + block size + buffer past) has elapsed before attempting to repair a block. For example, if M3DB is configured with a 2 hour block size and a 20 minute buffer past that M3DB will not attempt to repair the 12PM->2PM block until at least 2:20PM
V
это два разных механизма.
Это я понял, спасибо! :) Но и в metric_relabel_configs не работает, кроме регулярки (.*)
AS
и даже понятно что в мониторинге оно имеет очень не большую ценность
AS
Советую еще почитать там раздел caveats and limitations внизу дока:
* Background repairs do not currently support M3DB's inverted index; as a result, it can only be used for clusters / namespaces where the indexing feature is disabled
* Background repairs will wait until (block start + block size + buffer past) has elapsed before attempting to repair a block. For example, if M3DB is configured with a 2 hour block size and a 20 minute buffer past that M3DB will not attempt to repair the 12PM->2PM block until at least 2:20PM
* Background repairs do not currently support M3DB's inverted index; as a result, it can only be used for clusters / namespaces where the indexing feature is disabled
* Background repairs will wait until (block start + block size + buffer past) has elapsed before attempting to repair a block. For example, if M3DB is configured with a 2 hour block size and a 20 minute buffer past that M3DB will not attempt to repair the 12PM->2PM block until at least 2:20PM
это я читал и пониимаю ага да. я писал уже в канале что не знаю аналогичной сущности такой как блок в vm поэтому это будет сложнее сделать когда придётся делать
V
Разобрался, добавив .* в конец регулярки
AS
а https://github.com/go-graphite/gorelka совсем мертвый?
больше года нет коммитов. Либо он идеален, либо в стагнации, чо
AV
нашёл для себя опцию в прометее
hashmod. много думалона нужна для горизонтального масштабирования сркейпинга большого количества таргетов. С помощью нее таргеты можно равномерно разделить на любое количество прометеусов, при этом используя одинаковый конфиг для скрейпинга и меняя в нем только один параметр - значение
regex в action: keep после action: hashmod. См. https://www.robustperception.io/scaling-and-federating-prometheusAS
она нужна для горизонтального масштабирования сркейпинга большого количества таргетов. С помощью нее таргеты можно равномерно разделить на любое количество прометеусов, при этом используя одинаковый конфиг для скрейпинга и меняя в нем только один параметр - значение
regex в action: keep после action: hashmod. См. https://www.robustperception.io/scaling-and-federating-prometheusда да. к сожалению от нее пришлось отказаться
AS
хотелось делать хеш по
__gcp_project_nameAS
но кейс совершенно не складывается ибо не понятно как сказать прометею какие считать рулы для для этого шадра