У нас настроены автоматические резервные копии. Насколько мне известно, они выполняются без проблем, но мы хотели бы отслеживать их с помощью простого сервиса, например https://healthchecks.io, чтобы быть уверенными.
Есть ли способ настроить простой вызов их API для подтверждения завершения резервного копирования? Что-то вроде этого:
Вы можете провести реверс-инжиниринг API Discourse, чтобы получить список резервных копий, а затем вам нужно будет предпринять действия для определения самой последней копии и того, как давно она была создана.
Если резервное копирование не удастся, вы получите уведомление.
Единственная проблема, с которой я когда-либо сталкивался, возникала, когда резервное копирование планировалось на то же время, что и автоматизированная персонализированная маркетинговая рассылка или перезагрузки.
Как я понимаю, это работает, когда существует скрытый график резервного копирования базы данных (ведь одного раза в день недостаточно, верно?), а встроенная система предупреждений отстает, максимум на 24 часа. Но это могло бы служить системой раннего предупреждения, если Discourse не работает из-за сбоя базы данных, однако из-за кэширования пользователи не замечают этого сразу.
Я полностью ошибаюсь? Или я совсем не близок к истине?
Спасибо. Если нет возможности настроить «хук» после завершения резервного копирования, то, по-моему, лучшим решением будет реверс-инжиниринг API Discourse для получения информации о последней резервной копии. Тогда у нас будет полный контроль над действиями в случае сбоя резервного копирования. Однако было бы идеально, если бы можно было добавить хук (веб-хук или команду оболочки) после завершения резервного копирования.
Если вы хотите вызвать хук после завершения резервного копирования, думаю, вам потребуется создать плагин.
Вы действительно предлагаете использовать сбой резервного копирования как способ узнать, что Discourse недоступен?
/srv/status даёт довольно хорошее представление, хотя Discourse может сломаться способами, которые не отражаются в этом статусе. Он покажет, если база данных повреждена.
Я не предлагаю ничего другого, кроме как делать резервную копию базы данных чаще, чем раз в день. Я просто подумал, что уведомление по электронной почте об ошибке резервного копирования могло бы служить сигнальной тревогой.
