Во второй все что можно и нельзя придумать
список хостов (type=0)
список проверок для хоста (type=1 ) в info пишется путь к скрипту сенсору. в stdout скрипт должен вернуть цифру результата проверки .
список реакций на проверку хоста (type=2). в зависимости от того какой статус вернул скрипт сенсор выбирать и выполнять команды сопоставленые с проверкой и ее результатом
структура таблицы получается примерно такая
id | parent_id | title | info | type | status |
1 | 0 | так записывается компьютер | статуса192.168.1.1 | 0 | не важно |
2 | 1 | так записывается тест компьютера ...пингуем роутер | /path/to/custom/ping/sсript | 1 | последний ответ скрипта выполнявшего проверку |
3 | 2 | ping work | /shell/sсriрt/address/.... | 2 - реакция. | 0 |
4 | 2 | ping not work | /usr/bin/mplayer /home/1/ghostbuster.mp3 | 2 | 1 |
5 | 2 | я верю, что сша станет морем | /path/to/kill/all/people/sсriрt | 2 | 1 |
Из преимуществ:
мегапростой интерфейс управления. по сути три примитивных формы. и от силы десяток запросов для создания хлебных крошек, определение что именно будет писаться и для кого.
возможность задать несколько проверок.
из недостатков : все остальное
пока тараканы отказываются отвечать на главные вопросы жизни вселенной и всего такого:
а надо ли мне это? (собственно самый главный вопрос.)
должны ли команды реакции выполняться постоянно, или же только один раз, когда статус ответа сенсора изменился на состояние?
должны ли реакции выполняться в отдельном процессе?
где именно это определить?
как из такого дерева собрать нужную информацию?
куда засунуть расписание проверок?
а нужно ли делать скрипт который при заданом ид хоста или ид теста будет выполнять проверку хоста или собственно теста
не отпустила меня чудо трава
примерный псевдокод сервиса монитора сети