Прислано kiliwin 22-04-2009 13:22
#1
Исходные условия
1. Берем для примера организацию с непрерывным циклом работы.
2. Сисадминов выводить по сменам ни кто не хочет.
3. Перерыв в работе разных участков сети и серверов сказывается на финансовых прибылях
Задача
1. Проверять работоспособность всех определенных контрольных точек
2. В случае сбоев пытаться во становить работоспособность
3. Как можно быстрее оповещать кого то, каким то способом о том:
а)что накрылось,
б)когда накрылось
Кто что скажет по этому поводу?
Редактировал kiliwin 22-04-2009 21:14
Прислано kiliwin 22-04-2009 21:12
#2
прочитано тут
http://cert.uzsci...
Методы мониторинга состояния сети
Выбор способов и объектов мониторинга сети зависит от множества факторов – конфигурации сети, действующих в ней сервисов и служб, конфигурации серверов и установленного на них ПО, возможностей ПО, используемого для мониторинга и т.п. На самом общем уровне можно говорить о таких элементах как:
1. проверка физической доступности оборудования;
2. проверка состояния (работоспособности) служб и сервисов, запущенных в сети;
3. детальная проверка не критичных, но важных параметров функционирования сети: производительности, загрузки и т.п.;
4. проверка параметров, специфичных для сервисов и служб данного конкретного окружения (наличие некоторых значений в таблицах БД, содержимое лог-файлов).
Начальный уровень любой проверки – тестирование физической доступности оборудования (которая может быть нарушена в результате отключения самого оборудования либо отказе каналов связи). Как минимум, это означает проверку доступности по ICMP-протоколу (ping), причем желательно проверять не только факт наличия ответа, но и время прохождения сигнала, и количество потерянных запросов: аномальные значения этих величин, как правило, сигнализируют о серьезных проблемах в конфигурации сети. Некоторые из этих проблем легко отследить при помощи трассировки маршрута (traceroute) – ее также можно автоматизировать при наличии «эталонных маршрутов».
Следующий этап – проверка принципиальной работоспособности критичных служб. Как правило, это означает TCP-подключение к соответствующему порту сервера, на котором должна быть запущена служба, и, возможно, выполнение тестового запроса (например, аутентификации на почтовом сервере по протоколу SMTP или POP или запрос тестовой страницы от веб-сервера).
В большинстве случаев, желательно проверять не только факт ответа службы/сервиса, но и задержки – впрочем, то относится уже к следующей по важности задаче: проверке нагрузки. Помимо времени отклика устройств и служб для различных типов серверов существуют другие принципиально важные проверки: память и загруженность процессора (веб-сервер, сервер БД), место на диске (файл-сервер), и более специфические – например, статус принтеров у сервера печати.
Способы проверки этих величин варьируются, но один из основных, доступных почти всегда – проверка по SNMP-протоколу. Помимо этого, можно использовать специфические средства, предоставляемые ОС проверяемого оборудования: к примеру, современные серверные версии ОС Windows на системном уровне предоставляют так называемые счетчики производительности (performance counters), из которых можно «считать» довольно подробную информацию о состоянии компьютера.
Наконец, многие окружения требуют специфических проверок – запросов к БД, контролирующих работу некоего приложения; проверка файлов отчетов или значений настроек; отслеживание наличия некоторого файла (например, создаваемого при «падении» системы).
Прислано kiliwin 23-04-2009 11:48
#3
по реализации
1. программка должна запускаться сервисом
2. программка должна сама определяться кто, как и кому будет стучать о неполадках. То есть у нас допустим 50 серверов расположенных на разных объектах, программа при старте должна проверить какие виды коммуникаций ей доступны с внешним миром, интернет, сотовая связь, дозвон по модему и т.д., после дать широковещательное сообщение по внутренней сети, что то типа "я работаю, у меня есть такие то виды сигнализации, есть в сети кто круче или раньше зарегестренный?" Если ни кто не откликается - программа считает себя главной и при запросе от другого узла сообщает данную инфу. Если откликается - то меряются возможностями и выбирают "старшего". если возможности равны то "бросаем монетку".