Попробовал использовать zVirt API для мониторинга. Был очень недоволен тем, что системный журнал HE забился бесчисленными событиями входа через API, и найти там что-нибудь нужное стало проблематично. Пришлось отказаться.
Как можно выпускать в массы ядро, в котором отсутствует поддержка современного оборудования, особенно отечественных производителей? Это безумие со стороны Орионсофт. Ядро полуживое или мертвое на протестированных нами серверных конфигурациях. У вас же есть партнерские отношения с производителями отечественного серверного оборудования. Можно было совместно протестировать ядро перед выпуском его в массы.
У меня много лет работает вариант в комбинации udp+ping и bat-скрипт у пользователей. Потому что tcp с разных провайдеров иногда не срабатывал, терялся стук в середине цепочки. Плюс для большей безопасности стук идет на один IP, а дыра открывается на другом IP.
Если вкратце, то анализируется вывод команды, возможны три состояния каждого сенсора: disabled, healty и unhealty. В нормально работающей системе состояний unhealty быть не должно... Но, например, в exchange2016 есть несколько сенсоров (на текущий момент у меня 4), которые всегда unhealty. Microsoft это объясняет by design. Чтобы они не мешали в мониторинге, их можно перевести в статус disabled командой Add-ServerMonitoringOverride, но максимум ровно на 1 год.
Далее в любой системе мониторинга с определенной периодичностью отслеживаем количество сенсоров в статусе unhealty, которое должно быть всегда равно нулю. Если оно изменилось, значит что-то отвалилось из компонентов сервера и надо разбираться. У меня сразу показывается отвалившийся сенсор и его healthset. А далее гуглим сенсор и думаем как это править.
Если речь идет именно про мониторинг здоровья Exchange, то нельзя не упомянуть встроенные средства мониторинга из подсистемы Managed Availability, как то HealthSet, Probes, Monitors... и соответствующие команды, которые показывают здоровье сервера: Get-HealthReport, Get-ServerHealth ... Правда очень мало информации по использованию этого дела и не просто прикрутить это к внешним системам. У меня именно через Get-ServerHealth мониторятся сервера, и это более информативнее в разрезе внутреннего взаимодействия компонентов сервера, чем через стандартные счетчики...
Кроме этого системные журналы Exchange содержат очень много важной информации по здоровью, которые тоже очень полезно мониторить...
Попробовал использовать zVirt API для мониторинга. Был очень недоволен тем, что системный журнал HE забился бесчисленными событиями входа через API, и найти там что-нибудь нужное стало проблематично. Пришлось отказаться.
Отлично! Просто многие отечественные производители об этом умалчивают, либо вовсе не реализуют.
Хвалиться Ngfw - это сейчас модно. А вот про поддержку zbf ни слова.
Как можно выпускать в массы ядро, в котором отсутствует поддержка современного оборудования, особенно отечественных производителей? Это безумие со стороны Орионсофт. Ядро полуживое или мертвое на протестированных нами серверных конфигурациях. У вас же есть партнерские отношения с производителями отечественного серверного оборудования. Можно было совместно протестировать ядро перед выпуском его в массы.
У меня много лет работает вариант в комбинации udp+ping и bat-скрипт у пользователей. Потому что tcp с разных провайдеров иногда не срабатывал, терялся стук в середине цепочки. Плюс для большей безопасности стук идет на один IP, а дыра открывается на другом IP.
У меня массово не проходят онлайн-платежи внутри РФ.
Если вкратце, то анализируется вывод команды, возможны три состояния каждого сенсора: disabled, healty и unhealty. В нормально работающей системе состояний unhealty быть не должно... Но, например, в exchange2016 есть несколько сенсоров (на текущий момент у меня 4), которые всегда unhealty. Microsoft это объясняет by design. Чтобы они не мешали в мониторинге, их можно перевести в статус disabled командой Add-ServerMonitoringOverride, но максимум ровно на 1 год.
Далее в любой системе мониторинга с определенной периодичностью отслеживаем количество сенсоров в статусе unhealty, которое должно быть всегда равно нулю. Если оно изменилось, значит что-то отвалилось из компонентов сервера и надо разбираться. У меня сразу показывается отвалившийся сенсор и его healthset. А далее гуглим сенсор и думаем как это править.
Если речь идет именно про мониторинг здоровья Exchange, то нельзя не упомянуть встроенные средства мониторинга из подсистемы Managed Availability, как то HealthSet, Probes, Monitors... и соответствующие команды, которые показывают здоровье сервера: Get-HealthReport, Get-ServerHealth ... Правда очень мало информации по использованию этого дела и не просто прикрутить это к внешним системам. У меня именно через Get-ServerHealth мониторятся сервера, и это более информативнее в разрезе внутреннего взаимодействия компонентов сервера, чем через стандартные счетчики...
Кроме этого системные журналы Exchange содержат очень много важной информации по здоровью, которые тоже очень полезно мониторить...