Наша служба и опасна и трудна

Так и будет, пока мы будем все мерить «доступность сервиса». Пора переходить на «доступность бизнеса»

вероятно лучше всего когда оно равно между собой
сервис = бизнес
нет сервиса - конвейер денег встал

коллеги, добрый день, подскажите плиз, осваиваю prometheus - поднял его на отдельном сервере, хочу настроить мониторинг kubernetes, как правильнее его будет мониторить в данном случае? поставив node_exporter на ноды кубернетиса? во всех имеющихся статьях прометей стоит внутри кубера

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

особого смысла держать пром вне кластера нет

да, ответили уже в другой группе, спасибо)

Коллеги, все доброго дня!
Направьте, пожалуйста, в вопросе формирования и мониторинга бэкапов.
Что есть сейчас:
Задачки в кроне, которые запускают баш-скрипты с разной периодичностью.
Эти скрипты формируют архивы с бекапами для ряда сервисов, затем отправляют эти архивы в s3.
Все работает ок, пока работает)
Если что-то случилось, из-за чего бэкапы не создались (поменялись права у скрипта или s3 не авторизует), то я об этом никак не узнаю.
Хочется получать оповещения в случае, если бэкапы не создались или не выгрузились.
Пока из решений на поверхности - запускать бэкапные скрипты средствами TeamCity, где уже настроить реакцию на фэйл. Но возможно есть более пряморукие решения.

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

Например после строчки создания бэкапа проверить в той же директории создался ли бэкап, если нет, то записать ошибку в отдельный файл. В конце исполнения скрипта содержимое результатов выслат ьпо почте

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

Ну или другой вариативности “костыль” - простой скрипт бэкапирования на питоне с инкрементом метрики прометеуса при каждом бэкапе. Дальше аллерты из аллертменеджера куда угодно. Так точно будете знать, что забэкапировалось, а что нет. Работает ли сам скрипт (метрика up). Туда же можно прикручивать уже проверку бэкапа в S3 и соответствующие метрики на этот счет.

Ага, тоже думал про это, спасибо!
Однако-ж, а нет ли решения без костылей? Мне просто кажется, что этот вопрос решает примерно каждая it-команда. Неужели все пилят скрипты?
Или никто не запаривается и все верят, что один раз настроенный крон будет работать всегда?
Откуда у вас уверенность, что у вас есть бэкап за вчера?)

Из личного опыта, делал ранее лишь бэкап сетевых устройств. ПО называется Rconfig, может быть и для ваших нужд подойдет. Там как раз все нужные функции имеются.

Есть у меня один знакомый, у него крон бэкапит mysql уже лет семь. День в день! 🙂 Но проверять конечно надо, и если у вас есть уже настроенная система мониторинга, то костыльность решения становится не такой уж и явной.

Почему не используйте macula/Bareos??

Есть вопрос по регуляркам...
вот есть докер образ

rejistry.com/core_left:1.0.186
надо вытащить core_left:1.0.186

вот такая штука(  (?:.+/)?([^:]+)(?::.+)   )   у меня вытаскивает  core_left
Как сделать так чтобы ещё и тег вытаскивала?

Никому это там не нужно. Это обычный вебсайт, средней руки вебмастера. Там требование: “чтоб работал и кушать не просил”.

почему в амазоне не дает удалить s3 бакет если я зашел под рутовой учеткой

-> @AWS_RU