зависимо, осталось от предшественника там что-то или нет? Словил сценарий с потерей недоставленных данных, когда:
a) --remoteWrite.url vmagent-ов указывает на FQDN (victoria-metrics), а не IP;
b) в результате аварии и восстановительных работ, victoria-metrics сервис (который стал недоступен) уехал на другой IP (с переносом всей иерархии и данных их бекапа - реплика файловой системы),с обновлением IP в DNS для существующей записи.
c) vmagent-ы (несколько штук) в результате недоступности накопили опеределенное количество метрик в /tmp, но:
Сама поблема:
Прописывание в /etc/hosts (параллельно с модификацией DNS) на хостах vmagent никак не повлияло в течении последующих нескольких часов на рассасывание очереди.
Ручные kill -SIGHUP или curl на /-/reload влияют на перечитывание конфига, нет так и не повлияли на выгрузку данных из спул-queue.
При рестарте vmagent весь спул (~30 GB данных) успешно был уничтожен и 'дыра' в метриках так и осталась навеки вечные ;)
Вопрос - как работают периодические попытки отправить данные - при старте --remoteWrite.url ресолвится и навеки кешируется пока процесс работает? Или с чем может связана недоставка, после изменения IP victoria-metrics ? + Как жить дальше, если файловер именно на уровне DNS ( IP меняются но FQDN в качестве --remoteWrite.url неизменен)
1. Какая версия vmagen-a? 2. Запускаете его как: docker/бинарник ?
Обсуждают сегодня