проблема с хранением секретов

[kalek]

Добрый день.
Имеется следующий конфиг:
Zabbix 6.4. Два сервера с настроенным HA, два независимых друг от друга прокси, работающих в пассивном режиме, БД postgresql 15.
Всякие ключи/пароли/токены, используемые в item'ах хранятся в hashicorp vault. Соответственно в макросах они прописаны в формате vault secret.
И временами заббикс начинает их терять.
item'ы начинают выдавать сообщения вроде
FATAL: password authentication failed

а в логе появляются сообщения вида
cannot get secrets for path "secret/Infra/zbx/psql_monitor": no data

Через некоторое время все восстанавливается и данные снова начинают нормально собираться, а потом может опять отвалиться.
Какой-то явной периодичности не наблюдается ни в длительности отсутствия секретов, ни во времени появления проблемы.
В логах самого vault'а ничего по этому поводу нет.
Каких-то сбоев соединений от zabbix к vault тоже не видно.

Провел эксперимент на двух одинаковых - на одном оставил пароль в vault'е, на втором прописал его в макрос. После чего на втором проблемы с потерями прекратились.
Так что дело явно в интеграции с vault.

Подскажите, можно ли это как-то починить?

[Andrew Grekhov]

На сервере zabbix глянь графики: Zabbix server performance (см. очереди), Zabbix data gathering process busy %, zabbix internal.
А также загрузку диска СУБД. Есть корреляция с частотой ошибок?
У меня пароли или в макросе, или во внутренних скриптах, и проблем таких не было.
Вернее были проблемы из за слишком частого опроса, и контроллеры сами восстанавливались для чтения где то через сутки.

[kalek]

По графикам корреляции не видно. Никаких скачков ни когда секреты пропадают, ни когда появляются.
Если у хоста перенести пароли в макрос, то проблема на нем уходит, но хотелось бы разобраться с vault'ом, а не перетаскивать все эти секреты из него в заббикс

[kalek]

Может у заббикса есть какой-то отдельный процесс, который за это отвечает? Чтобы за ним понаблюдать повнимательнее.
Хотя в доке похожего не видно.

[Andrew Grekhov]

Помониторь размер файлов логов.

[kalek]

С логами картина вполне ожидаемая.
При потере секретов количество резко скакануло - вывалилась куча сообщений item became not supported, после чего вернулось к более-менее нормальным значениям.
И похожая картина, когда секреты вернулись.
Если в цифрах, то за час до потери в лог записалось 263 строчки, за час сразу после - 1472, а в течение следующего часа - 375

[Andrew Grekhov]

Смотреть загрузку диска, ctxt, прошерстить cron, anacron. Сделать мониторинг SMART диска. Atop с записью процессов в файл.
А под какой ОС это всё работает?

[kalek]

По графикам в заббиксе каких-то скачков/отклонений не видно. Для этих item'ов пароли не нужны, так что данные нормально собираются.
В кроне никаких сторонних заданий нет.
atop поставил, но тут надо ждать, когда опять секреты отвалятся.
Все данные сервера - это виртуалки, так что в SMART смотреть не на что.
ОС на всех Ubuntu 22.04

[Andrew Grekhov]

> SMART смотреть не на что.
У вас там SAS чтоли? Или SSD? Тогда, да, информации не густо.
На обычных дисках при нагрузке ID=7 обычно проседает.

>Ubuntu 22.04
и
> В кроне никаких сторонних заданий нет.
Два взаимо исключающих понятия. Я лично задолбался мусор на Raspbean вычищать.
Просмотрите ещё раз.
Пока у вас симптомы: на левый софт (лишние cron, вирусня), или железячное (вроде вспухшего конденсатора в БП.)

[kalek]

Задания в кроне есть, но только системные вещи вроде logrotate, ничего левого.
А что касается жестких, то сервера виртуальные и какого-то конкретного железного диска, воткнутого в конкретную машину нет. Есть NAS, прикрученный к vsphere, где эти виртуалки и живут.
То же самое относится и к блоку питания.
Вообще не проблемы с железом не очень похоже, потому что машинки переезжали между хостами vsphere, а проблема оставалась