домовой
Тараканы нашептывают что надо переписать мониторинг сети на sqlite и php. А еще использовать всего две таблицы. одна для логов.
Во второй все что можно и нельзя придумать
список хостов (type=0)
список проверок для хоста (type=1 ) в info пишется путь к скрипту сенсору. в stdout скрипт должен вернуть цифру результата проверки .
список реакций на проверку хоста (type=2). в зависимости от того какой статус вернул скрипт сенсор выбирать и выполнять команды сопоставленые с проверкой и ее результатом
структура таблицы получается примерно такая
Из преимуществ:
мегапростой интерфейс управления. по сути три примитивных формы. и от силы десяток запросов для создания хлебных крошек, определение что именно будет писаться и для кого.
возможность задать несколько проверок.
из недостатков : все остальное
пока тараканы отказываются отвечать на главные вопросы жизни вселенной и всего такого:
а надо ли мне это? (собственно самый главный вопрос.)
должны ли команды реакции выполняться постоянно, или же только один раз, когда статус ответа сенсора изменился на состояние?
должны ли реакции выполняться в отдельном процессе?
где именно это определить?
как из такого дерева собрать нужную информацию?
куда засунуть расписание проверок?
а нужно ли делать скрипт который при заданом ид хоста или ид теста будет выполнять проверку хоста или собственно теста
не отпустила меня чудо трава
примерный псевдокод сервиса монитора сети
Во второй все что можно и нельзя придумать
список хостов (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 |
Из преимуществ:
мегапростой интерфейс управления. по сути три примитивных формы. и от силы десяток запросов для создания хлебных крошек, определение что именно будет писаться и для кого.
возможность задать несколько проверок.
из недостатков : все остальное
пока тараканы отказываются отвечать на главные вопросы жизни вселенной и всего такого:
а надо ли мне это? (собственно самый главный вопрос.)
должны ли команды реакции выполняться постоянно, или же только один раз, когда статус ответа сенсора изменился на состояние?
должны ли реакции выполняться в отдельном процессе?
где именно это определить?
как из такого дерева собрать нужную информацию?
куда засунуть расписание проверок?
а нужно ли делать скрипт который при заданом ид хоста или ид теста будет выполнять проверку хоста или собственно теста
не отпустила меня чудо трава
примерный псевдокод сервиса монитора сети