Вендору за платформу и ресурсы

Интеграторам откаты?

Это уже комплаенс:)

Почитал, есть обнаружения, но при этом конфиг описан в yml. Как так?

Антон, а Prometheus не страдает тем же, чем страдают большинство систем мониторинга? Пришел  алерт и хуй знает о чем он? Типа http_get_request >= 400, а ты сидишь и думаешь, кто автор этого монитора и что он имел ввиду?

Парни, поделитесь чудо опытом.
Есть failover dhcp, средствами самого dhcp сервера, из 2х узлов.
Если вносишь изменения, ну например, создаёшь зону и в последствие реплицируешь на второй узел, scom выводит предупреждение, что внесено изменение в конфигурацию, иди почитай логи кто что навносил.
Это всё понятно и логично. но вот эти предупреждения нельзя закрыть. Единственное что спасает, через анализатор сбросить состояние, после чего само собой предупреждения уходят.
А как бы правильно это всё сделать?

То есть переопределить стандартное поведение по умолчанию??

ну видимо
я пока плаваю в сервисе, изучаю по мере внедрения

Я это к тому, что монитор делает то что нужно и делает правильно. Не нравится? Оверрайдим монитор.

Мы в этом смысле не стали его трогать и я время от времени отвечаю на тупые вопросы "а че это там в dhcp желтенькое?"

😭

Дело в том, что логичным как раз видится то, что если событие просмотрено администратором, значит сделаны выводы. И если на этом всё, вроде как логично "закрыть" эвент руками, при необходимости.
Видимо, я не стандартно понимаю процедуру, на свой лад)

Т.е. процесс: изменили конфигурацию, получили варнинг, просмотрели, ресетим алерт.
Что не так то??

Это правило берет EventID с лога, если оно не нужно, может быть проще отключить его?

Он же сказал, постоянно спрашивают почему сервера желтые )

Т.е. оверрайд на enabled = false ;)

Нет, оно нужно, информативно, еогда с сервисом работают несколько администраторов
А вот почему его нельзя закрыть руками - главный вопрос)

Я же сказал что меня тоже спрашивают :)

Всмысле нельзя? Reset health же

Ну понятно, что со сбросом состояния)