Весь мой боевой опыт

А мы находились в одной казарме с ротой охраны. Много офицеров и солдат в нарядах, а патроны надо отстрелять. Дохерища. Двое старшин заряжают магазины. Ты цепляешь и в пустоту стреляешь. Потом меняешь автомат, и снова. Пока не оглохнешь

А магазины заправлять самим?

Нет

Потом допоздна чистишь эти автоматы

Мы так же развлекались, всегда с нач арт склада ходил помогать, как батальоны отстрелялись можно было вдоволь поразвлекаться

А нач склада ещё и зёма был

началось))

Закончилось уже. Все замолчали

Возвращаясь к мониторингу. Если кому-то показалось, что я пропагандирую scom или говорю, что с помощью других систем нельзя его реализовать - то перечитайте сообщения еще раз. Я не закрываю глаза на проблемы и недостатки продуктов MS, только потому, что я на MS работаю в данный момент. Делай я так, меня бы сложно было назвать нормальным инженером.

SCOM из коробки имеет интеграцию со встроенной системой мониторинга (Managed Availability). Ничего не мешает ее реализовать на Zabbix. Но опять же - лично я этого НИ РАЗУ не видела. Но это и не значит, что у кого-то этого нет. Для одного заказчика делали похожее в Log Analytics (лог Managed Availavility\Monitoring - туда пишутся последние ошибки).  MS давно уже ушел от мониторинга только счетчиков  - это не показательно. У вас могут быть задержки по дискам, которые реально не влияют на систему от слова никак. Надо ли в этом случае бежать и что-то делать срочно? В масштабах облака мониторинг посредством синтетических транзакций при огромном количестве серверов очень ресурсоемкая задача. Поэтому мониторинг выполняется через Managed Availability локально на каждом сервере. Про MA написано много статей, которые можно почитать https://techcommunity.microsoft.com/t5/exchange-team-blog/customizing-managed-availability/ba-p/592164 Ну и на русском в блогах тоже есть.
MA выполняет и проверку счетчиков производительности, и наличие событий в журналах, и проблемы при выполнении синтетических транзакций (подключение по разным протоколам, отправку и прием писем). Последнее - насколько я знаю, не умеет ни одна из систем мониторинга. Логически, продуктовая группа знает лучше всех, что именно нужно мониторить в ее продукте. Есть некоторые сторонние решения, которые, например, позволяют проверять ActiveSync снаружи. MA не делает проверку со стороны клиента  - т.е. если снаружи у вас есть система публикации, которая сломалась, или проблемы с балансировщиком - это будет сложно определить. Решается отдельно, для всех систем мониторинга.

По счетчикам Mapi\http был отдельный вопрос, т.к. от продуктовой группы нет рекомендаций по их порогам. У меня есть общий Baseline, который отработал на многих инсталляциях. Но его нужно проверять на конкретной инфре. MSExchange MapiHttp Emsmdb\Averaged Latency обычно меньше 15, Requests  - обычно меньше 70.

Как любая система мониторинга MA нуждается в настройке. Если у вас есть БД, для которых вы выключили индексы (мы их состояние проверяем) - надо делать переопределение для конкретных БД и т.д.

А вообще, стоит попробовать ответить на следующие вопросы, чтобы понять, насколько хорошо мониторинг настроен. Опять же, у каждого требования свои. Если произойдет что-то из нижеперечисленного  - узнаете ли вы об этом из оповещения?

1. Сервер не доступен
2. Сервис остановлен
3. Имеются проблемы доступа по определенным протоколам (нельзя подключиться в принципе, или подключение занимает длительное время)
4. Есть проблемы поиска (при это состояние каталога может быть healthy)
5. Все ли ок с высокой доступностью - например, у БД нет копии, или copy queue length не позволяет ее активировать автоматически и т.д.
6. Вы настроили интеграцию OWA+Skype, но щабыли указать сертификат в web.config

Это только примеры того, на каком уровне должен\может быть реализован мониторинг.

"не умеет ни одна из систем мониторинга" - это что не умеют?

Вызывать синтетические транзакции, как это делает клиент. Но вы поправьте, я далеко не со всеми системами имела дело. Только реализации у тех компаний, с которыми работала.

Exoprise так делает

Mail Queue and Mail Flow Tests
Email sensors test mail flow and mail queues for Exchange, Office 365, SPAM providers, OWA and more. They test mail queues for performance and availability by sending small messages to the auto-responder at the exomail@exotester.com recipient.

Metrics
There are 3 primary metrics collected for mail flow and mail queue tests:

MTA Inbound
The total time it takes to reply to an email from our auto-responders to the inbox. This metric measures inbound queue performance.
MTA Transport
The time it takes for a reply to reach the inbound MTA servers. This metric measures inbound transport performance and is a subset of the MTA Inbound time as reported by processing servers.
MTA Outbound
The time it takes to send an email to our CloudReady auto-responders. This metric measures outbound queue and transfer performance. MTA stands for message-transfer-agent and is responsible for the transmission of email between servers.

Smtp, ok. А mapi/http, active sync и т. Д.?

Smtp достаточно штатная вещь. Ее да, многие умеют

AS точно да. остальное не помню

Test and monitor Exchange MAPI over HTTP for availability and end-to-end performance. This sensor connects to a mailbox using MAPI over HTTP like newer Outlook versions.

Возможно) но как я понимаю, это не бесплатная система, которая стоит отдельных денег