zbackup+s3sync, но да, это тестовый стенд, его мучаю

SIGTERM тоже должен нормально обрабатываться и приводить к graceful shutdown. Но лучше глянуть в логи контейнера после его остановки вашим способом и посмотреть, была ли обработка graceful shutdown или он просто был убит без предварительных ласк :) При graceful shutdown в логах должна быть строчка gracefully shutting down the service и после нее должны идти логи с описанием того, как данные сбрасываются на диск и завершается работа приложения.

проверил, что при остановке одной из vmstorage нод новые данные записываются в оставшиеся vmstorage ноды. Во время недоступности этой ноды vmselect'ы строят запросы только по части данных, оставшихся на живых vmstorage нодах. После возвращения в строй остановленной vmstorage ноды vmselect'ы строят запросы по всем данным в полном объеме без потерь. Если у вас теряются данные после рестарта / обновления vmstorage нод, то пишите - будем разбираться

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

вы же создаете бэкап из снэпшота, а не из живых данных? https://github.com/VictoriaMetrics/VictoriaMetrics/tree/cluster#backups . И не забывайте удалять старые снэпшоты через /snapshot/delete?snapshot=<id>, чтобы они не занимали место с течением времени после слияния или удаления соответствующих файлов в живых данных.

да, с помощью снапшотов, снапшот удаляется после того как сделан бекап

спасибо

привет

привет. Написал ответ в issue

нужно проверить все варианты из ответа

ок

А где-нибудь описано как потребление VM оперативки зависит от длины time-series ( не их кол-ва) / retentionPeriod ?

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

Речь об общем числе точек в отдельных time-series и выборе: если забыть о месте на диске, то держать всю детальную историю в одном инстансе VM или разнести на short-term и long-term (aggregated). Выборки в основном будут за сравнительно короткий интервал по времени, долговременные тренды не в приоритете, им можно и притормаживать.
И вопрос вдогонку: как длина series в базе будет влиять на время рестарта VM.

Можно хранить все в одном инстансе. Он оптимизирован под использование, когда читаются в основном недавно записанные данные. Чтение большого количества долговременных данных тоже оптимизировано - вм сканирует до 50 миллионов точек в секунду на ядро процессора, распараллеливая работу на все имеющиеся ядра, поэтому можно не делать агрегацию в отдельный сторедж. По поводу времени рестарта - оно линейно зависит от суммарного количества точек в базе плюс суммарного количества временных рядов. Но коэффициент зависимости очень маленький, поэтому база с триллионом точек и миллиардом временных рядов должна открываться за пару секунд на обычном hdd, а на ssd - еще быстрее

Привет, во всех промах, что пишут в кластерную vm в логах ошибки:

level=warn ts=2019-06-05T13:04:48.072970642Z caller=queue_manager.go:230 component=remote queue=0:http://vm.tsdb-use1.core.afdevops.com/insert/5/prometheus msg="Remote storage queue full, discarding sample. Multiple subsequent messages of this kind may be suppressed."

всего 7 промов, каждый пишет в свой тенант, общий sample rate ~450к в секунду

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