Приведу небольшой пример:
1. Мониторинг логов сервера приложений.
2. Мониторинг логов IIS + OT WEB логов.
3. Мониторинг работы служб.
4. Мониторинг производительности серверов.
5. Мониторинг зависания работы служб.
6. Мониторинг очередей работы прикладного сервера.
7. Мониторинг активности пользователей + количество подключений.
8. Мониторинг доступности к файловому хранилищу + скорость доступа.
9. Мониторинг дисков на предмет переполнения.
10. Мониторинг количество транзакций на SQL сервере.
11. Мониторинг доступа к дискам, на всех серверах комплекса.
12. Мониторинг утечки памяти.
13. Мониторинг ошибок на серверах OS.
Как мы видим не все показатели можно постоянно контролировать, часть придется доверить автоматизированным системам. Если сервис является критичным, то мониторинг можно продублировать на опережение, при возникновении ошибки действия на сервере выполняются автоматически. Другими словами, если один из сервисов отключился, то никто не мешает его поднять автоматически, при этом уведомив администраторов системы о падении. После этого администраторы должны найти причину падения и устранить ее.
И так вернемся к вопросу мониторинга, таблица монитора в OMNITRACKER Service Control Panel, ни что иное как события выполняемые системой, то что вызывают пользователи. В логах сервера мы наблюдаем жизненный цикл системы, эти файлы являются приоритетом наблюдения администратора. Немного разберем почему это важно, если с сервером что-то произойдет, скажем пропадет внутрисетевое соединение между серверами, (администратор первый должен среагировать на ситуации, не дожидаясь автоматизированной системы и когда все сервисы свалятся.) из-за заблокированной группы пойдут ошибки маршрутизации на портале. Даже обычная остановка движения всех логов должна настораживать и привлекать внимание, т.к. система находится в постоянном изменении.
То-есть обязательно логи сервера должны бежать на втором мониторе администратора, внимание к логам можно привлечь подкраской текста, чтобы реагировать на проблемы. Вторая часть мониторинга это аналитический мониторинг, звучит пугающе, но по факту это устранение блокировок вызванные теми или иными причинами «это отдельная тема для обсуждения». В дополнении и удобства контроля над системой администраторами системы, можно использовать СМС уведомления, очень удобный механизм. В системе OT есть интересный баг, дочерние службы которые устанавливаются вместе с сервером, такие как email gateway, email, index, все эти службы могут запускаться в не зависимости от работы центральной службы сервера. Что является ошибкой, можно сделать зависимость служб «в этом плане система не зависима», но тут возникает встречный вопрос, на сколько это нужно делать, в каждом случае.
Одной из самый интересных ошибок системы является утечка памяти и ее явление на поведение системы. Тут сложно судить, что именно в системе вызывает данные утечки, но с уверенностью можно сказать, если один раз в месяц производить полный перезапуск серверов, то можно избежать довольно большое количество ошибок которые могут возикать (из опыта).
Если есть проблемы с лицензированием, то также необходимо контролировать активность пользователей и реагировать на это, например увеличивать или уменьшать пороговые значения для автоотключения (web/client). Как правило любой мониторинг требует внимания, поэтому стоить систему мониторинга нужно из реалий жизни, если есть такая возможность, то это необходимо делать. В противном случае, система будет работать в штатном режиме ровно до тех пор, пока порог ошибок не будет превышен максимальными значениями системы.
В системе есть не документированные возможности например внесение в реестр системы ключей, которые могут отображать целостность кластера. OMNINET наверняка заложили подобный функционал не спроста, в будущем возможно эти функции появятся и в графическом клиенте. Что касается логов самого сервера OMNINET постарались разделить каждый блок системы на модули, тем самым появилась возможность запускать в логирования те или иные события. В документации по этому поводу все подробно описано, F1 как говорится если что-то не понятно, прочтите документацию.
Мониторинг позволяет нам не только следить за жизнью системы, но и также позволяет оптимизировать те или иные запросы к системе, увеличивая ее производительность. Тему производительности затрону как ни-будь в другой раз, например: «Пользовательские запросы вызывающие высокую нагрузку на систему».
По возможности хотелось бы услышать Ваши дополнения по на счет мониторинга. Возможно я что-то упустил или Вам есть что дополнить.
