Не на ingester'е

да, будет неплохо

Привет, сорри, вчера не отписал, в принципе вот описание дедупликации в thanos: https://github.com/improbable-eng/thanos/blob/master/docs/components/query.md#deduplication

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

спасибо, почитаю

интересный способ - каждому прометеусу присваивается уникальный лейбл, по которому потом происходит слияние данных. Т.е. данные с разных прометеусов сохраняются в разные временные ряды, даже если прометеусы собирают метрики из одних и тех же сервисов. Слияние этих рядов происходит во время обработки запроса. Нужно подумать, как это реализовать в VictoriaMetrics.
Преимущество этого метода - удаление "провалов" в графиках, если одна из реплик прометеуса временно перестает работать
Недостатки:
1) усложненная конфигурация, в которой легко допустить ошибку - нужно выбрать имя лейбла для дедупликации, правильно прописать разные значения для этого лейбла в конфиге реплик прометеуса, после чего правильно указать его в конфиге VictoriaMetrics
2) дублирование временных рядов в базе. Они будут занимать дополнительное место на диске

Похожую штуку можно сделать с помощью promxy:
- запустить два инстанса VictoriaMetrics
- в конфиге первой реплики прометеуса прописать запись данных на первый инстанс VM, в конциге второй реплики - запись данных на второй инстанс VM
- перед инстансами VM поставить promxy
- все запросы из графаны отправлять в promxy

Что-то типа вот этого https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/Single-server-VictoriaMetrics#high-availability , но это обеспечивает непрерывную работу в случае выхода из строя одной из реплик VictoriaMetrics

Мы сейчас как раз такой сетап у нас прикручиваем. Плюс trickster. Правда один пром пишет в две виктории сразу. Наверное стоит переделать на два прома, каждый со своей Викторией

О, хороший вариант. Еще думал прикрутить реверс проксю перед vm для даунсемплинга, промы собирают раз в 30 секунд, прокся накапливает за 5 минут и шлет в vm.

Там же можно вырезать лейблы репликации.

вышла версия 1.15.0 - https://github.com/VictoriaMetrics/VictoriaMetrics/releases
в ней увеличена скорость записи для большого количества временных рядов и уменьшено время, необходимое на graceful shutdown

CPU или core ? Учитываются real core или HT тоже?

В лицензировании

Скажем, у меня 2x2640v4 , получается по 2килобакса на сервер. Минималка (3 ноды) - 6 килобаксов.
Я не знаю на кого расчет в плане продаж, но кмк для большинства средних компаний РФ дороговато. может быть, я не прав, конечно.

Или есть какие-то другие схемы лицензирования?

учитываются все ядра, в т.ч. и HT. Большинству маленьких и средних компаний будет достаточно бесплатной single-node версии - ее производительность хорошо масштабируется с количеством ядер CPU до десятков миллионов вставок в секунду. См. https://medium.com/@valyala/measuring-vertical-scalability-for-time-series-databases-in-google-cloud-92550d78d8ae
Кластерная версия расчитана на компании с очень большим объемом метрик. Цена намного ниже по сравнению с конкурентами, если учитывать не только стоимость лицензии, но и затраты на оборудование (CPU, RAM, storage), необходимое для достижения аналогичной производительности

я что-то нажала и все пропало. если точнее, в 1.15.0 что-то пошло не так

wget -O- http://172.20.10.73:8428/api/v1/query?query=%7B__name__%3D%22rabbitmq_queue_consumer_utilisation%22%7D%5B301s%5D&time=2019-04-26T13%3A51%3A35.611Z
Apr 26 13:54:59 ip-172-20-10-73 systemd[1]: victoriametrics.service: Main process exited, code=exited, status=2/INVALIDARGUMENT

рад предоставить более подробную инфу