В Сети (да и не в Интернет тоже) распространено достаточно много заблуждений касательно того, как OpsMgr генерирует алерты. Исходя из этих заблуждений люди зачастую пытаются сделать заведомо невозможное и, когда это не выходит, идут в основном двумя путями: на форумы с вопросами или куда-нибудь еще с жалобами на “баги”.
Алерты являются одним из важнейших компонентов практически любой системы мониторинга. Ведь мы покупаем систему мониторинга для того, чтобы она нас “предупреждала”, так? Поэтому очень важно знать как именно алерты работают. Для того, чтобы точно понимать в каком случае система будет вас оповещать. Сегодня я немного расскажу об этом. Для того, чтобы сразу было понятно о чем я буду рассказывать, я скажу, что под именем “алерт” я буду рассматривать то, что появляется в консоли. Здесь не будет ничего о том как и по каким каналам их можно рассылать.~~~
Все алерты можно разделить на две группы:
- Сгенерированные мониторами
- Сгенерированные правилами
Для обоих групп существует механизм подавления. Он предназначен для того, чтобы минимизировать количество алертов, появляющихся в консоли (а так же в почтовых ящиках, IM, телефонах в виде SMS и так далее). Думаю, ни для кого не секрет, что большинство правил и мониторов работают периодично, то есть запускаются раз в N секунд. И раз в N секунд (теоретически) способны генерировать алерт. Вы хотите найти утром в своем почтовом ящике (или на консоли) сотню- другую алертов о том, что ночью у вас остановилась служба Computer Browser на одном сервере? Думаю нет, не хотите. Вполне достаточно одного.
Для того, чтобы не выпускать много алертов на одно и то же событие существует встроенный механизм подавления. Как он работает?
Алерты, вызванные изменением состояния монитора (сгенерированные мониторами)
Для этих алертов механизм подавления базируется на ID монитора. Подавление по ID означает, что данный экземпляр монитора (говоря простыми словами – это конкретный монитор, работающий на конкретном сервере) будет выпускать только один алерт – в тот момент, когда состояние монитора изменится.
Мониторы еще называют “машинами состояния” (state machine). Главное предназначение монитора – отображать текущее состояние компонента, за которым он наблюдает и отражать (в том числе и генерацией алерта) изменение состояния.
Все алерты, которые не отображают изменение состояния (то есть, например, монитор находится в Critical, срабатывает еще раз и “понимает”, что компонент находится в “плохом” состоянии) будут подавлены. Поэтому никогда не закрывайте алерты, сгенерированные мониторами, вручную. При закрытии алерта состояние монитора, который его выпустил, не изменяется. И поэтому вы не получите новых алертов до тех пор, пока состояние монитора не изменится (то есть, говоря проще – пока вы его не сбросите вручную и затем монитор, сработав, не изменит свое состояние на “плохое”). То есть, если вы закроете алерт, который сгенерирован монитором, вы рискуете забыть, что у вас есть проблема.
Данное поведение не конфигурируемо. Вы не можете его изменить.
Алерты, сгенерированные правилами
У правил поведение функции подавления алертов конфигурируемо. Правило получает настройки из блока конфигурации alert generating write action.
Как это выглядит? Вот правило из пакета управления AD 2003:
<Rule ID="WMI_Replication_Provider_is_not_installed_Replication_cannot_be_monitored_fully"
Enabled="onStandardMonitoring"
Target="AD2003Core!Microsoft.Windows.Server.2003.AD.DomainControllerRole"
ConfirmDelivery="false" Remotable="false"
Priority="Normal" DiscardLevel="100">
<Category>EventCollection</Category>
<DataSources>
<DataSource ID="EventDS" TypeID="Windows!Microsoft.Windows.EventProvider">
<ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
<LogName>Operations Manager</LogName>
<Expression>
<And>
<Expression>
<SimpleExpression>
<ValueExpression>
<XPathQuery>Params/Param[1]</XPathQuery>
</ValueExpression>
<Operator>Equal</Operator>
<ValueExpression>
<Value>AD Replication Monitoring</Value>
</ValueExpression>
</SimpleExpression>
</Expression>
<Expression>
<RegExExpression>
<ValueExpression>
<XPathQuery>EventDisplayNumber</XPathQuery>
</ValueExpression>
<Operator>MatchesMOM2005RegularExpression</Operator>
<Pattern>^(68)$</Pattern>
</RegExExpression>
</Expression>
</And>
</Expression>
</DataSource>
</DataSources>
<WriteActions>
<WriteAction ID="GenerateAlert" TypeID="SystemHealth!System.Health.GenerateAlert">
<Priority>1</Priority>
<Severity>1</Severity>
<AlertOwner>$Data/PublisherName$</AlertOwner>
<AlertMessageId>$MPElement[Name="WMI_be_monitored_fully.AlertMessage"]$</AlertMessageId>
<AlertParameters>
<AlertParameter1>$Data/EventDescription$</AlertParameter1>
</AlertParameters>
<Suppression>
<SuppressionValue />
</Suppression>
</WriteAction>
</WriteActions>
</Rule>
Обратите внимание на блок:
<Suppression>
<SuppressionValue />
</Suppression>
Это и есть настройки подавления. Как это работает:
1. Тэга Suppression нет
Подавление игнорируется и алерт генерируется всегда.
2. Тэг Suppression пустой
<Suppression></Suppression>
или
<Suppression/>
Подавление игнорируется и алерт генерируется всегда (пустой тег создается для многих мониторов, которые создаются из UI).
3. Пустой тег SuppressionValue
<Suppression>
<SuppressionValue />
</Suppression>
Подавление базируется на ID правила. То есть поведение подавления будет как у мониторов.
4. Не пустой тег SuppressionValue
<Suppression>
<SuppressionValue>Какое-то-значение</SuppressionValue>
</Suppression>
Подавление будет выполняться на базе вычисления хеша для “Какого-то-значения” + ID правила.
Хэш вычисляется агентом всегда. Поэтому настройки подавления не оказывают дополнительного влияния на производительность.
Узнать, были ли подавлены алерты от конкретного источника (правила) вы можете открыв в консоли свойства правила и посмотрев параметр Repeat Count, Если он присутствует и больше нуля – это и есть количество подавленных алертов.