DH
Size: a a a
2021 November 23
DH
Мысль проста, в алертменеджере настроить правило на метрики прома, если метрики (например up ) меньше 1, тогда слать алерт.
AE
спасибо
AE
прочитал. так, сам себя он скрапит, но алерт то кто-то должен инициировать?
AE
пром должен ткнуть ам, мол шли алерт
DH
Пром никого не должен тыкать. Алерт менеджер сам цепляется к прому и гоняет запросы. А потом согласно конфигу и ответу или не ответу на запрос шлёт оповещение
AE
вот что-то такое я слышал, ага
AE
я был бы рад, если бы так. однако:
https://prometheus.io/docs/prometheus/latest/configuration/configuration/#alertmanager_config
написано по ихнему, что пром шлёт в ам алерт
An alertmanager_config section specifies Alertmanager instances the Prometheus server sends alerts to.
https://prometheus.io/docs/prometheus/latest/configuration/configuration/#alertmanager_config
написано по ихнему, что пром шлёт в ам алерт
DH
А точно, сорян. Спутал немного. Тогда да, пром нужно мониторить внешними штуками.
AE
вот норм нарыл по кейворду "мёртвый мужик"
PK
Подскажите, есть запрос удалять отвалившиеся джобы после одной успешной (они порождаются CronJob-ом), как это проще всего сделать?
Пример - синхронизация с системой раз в час, и другая система может прилечь. Хотелось бы, чтобы если она поднялась и синк прошёл - упавшие джобы удалились бы.
Пример - синхронизация с системой раз в час, и другая система может прилечь. Хотелось бы, чтобы если она поднялась и синк прошёл - упавшие джобы удалились бы.
PK
Есть конечно history limits, но это слегка не то, что требуется. Можно в каком-нибудь финалайзере удалять это через кубапи. Но может я чего-то упускаю, и есть менее костыльный способ?
AS
Кстати argo-workflows очень не плох
PK
Ну я думал kubectl в контейнер положить и права дать. Смотреть exit code в entry point и если success - удалить сломавшиеся.
PK
Но выглядит костыльно