This monitor measures the Health Service Management Groups\Send Queue \% Used counter for the Health service.
This monitor measures the Health Service Management Groups\Send Queue % Used and generates the following states:
Состояние монитора | Send Queue % Used Threshold |
Предупреждение | 50 % |
Критическое | 60 % |
Это может быть вызвано низкой пропускной способностью или высокой задержкой подключения от службы работоспособности управления System Center к ее родительскому серверу управления. Это также может быть вызвано правилами, которые собирают данных больше, чем родительский сервер управления может обработать, особенно когда у родительского сервера управления много агентов, отправляющих ему отчеты с большим количеством данных.
Вместе с администраторами сети проверьте, полностью ли используется пропускная способность сетевого подключения от службы работоспособности управления System Center к ее родительским серверам управления. Если это так, может потребоваться обновление сетей, чтобы учесть интенсивность трафика.
Если обновление сети невозможно (например, если служба работоспособности управления System Center или сервер шлюза расположены в удаленном филиале), можно отключить ненужные правила сбора данных. Ниже приводится список типов правил, которые можно отключить, а также последствия их отключения.
Тип правила | Назначение правила | Последствия отключения |
Сбор данных о производительности | Сбор данных производительности в рабочую базу данных и/или хранилище данных. | При отключении правила сбора данных о производительности представлению, в котором отображаются данные о производительности, больше не поступают данные. Если это было правило для сбора данных о производительности в хранилище данных, то отчеты, зависящие от таких данных, больше не будут их обрабатывать. |
Сбор данных о событиях | Сбор данных событий для диагностики. В некоторых случаях событие может полезно не для создания предупреждения, а для аналитического или быстрого устранения неполадок. | При отключении правила сбора данных событий в представление, в котором они отображаются, больше не поступают данные. Если это было правило для сбора данных в хранилище данных, то отчеты, зависящие от таких данных, больше не будут их обрабатывать. |
Наконец, если такие данные все еще нужны, в системе можно реализовать другую возможность, чтобы попытаться снизить объем данных, отправленных по сети, — использовать оптимизированные правила сбора показаний счетчика производительности и правила сбора консолидированных событий. В приведенной ниже таблице представлена сводка их преимущества и объяснятся, как получаются сводные данные.
Тип правила | Преимущество | Как происходит суммирование данных |
Правило сбора данных о производительности | Only sends the performance data sample if it deviates from the last sample within some percentage. E.g., if the last sample was 42, and the rule was configured to only collect to a new sample with a tolerance of 10%, the next sample will need to 42 +/- 4.2 (e.g. next sample needs to be greater than 46.2 or less than 37.8) | Поскольку в рабочую базу данных или хранилище данных отправляются только данные производительности, превышающие настроенный допуск, такие данные будут менее точными. Чем больше допуск, тем меньше точность. |
Правило сбора консолидированных событий | Этот тип правил сбора данных событий отвечает за отправку данных, в случае когда настройки параметров отличаются от последнего события. Например, правило консолидированного сбора можно настроить на консолидирование событий со следующими идентичными параметрами:
Затем можно настроить промежуток времени для консолидации таких событий (например 10 минут). Если указанному выше критерию удовлетворяет несколько событий в пределах заданного 10-минутного периода, отправляется только одно событие с приращением значения свойства "Число повторов". Если такое событие часто возникало на одном агенте, это означает, что за 24-часовой период отправлялось бы 144 событий, что может быть значительно меньше, чем число событий, действительно зарегистрированных в журнале событий. | Необходимо хорошо представлять, по каким параметрам и свойствам событий осуществляется консолидация. Например, если настроить на описание, то будут отправляться события с уникальным описанием события (например в нем содержится имя пользователя). Например, вместо этого можно консолидировать по параметру события, представляющему поле имя пользователя. Кроме того, очень большие промежутки консолидации приводят к следующему:
|
См. справку по продукту или перейдите к панели создания и настройки в консоли, чтобы создать описанный выше тип правил.
Target | Microsoft.SystemCenter.Agent | ||
Parent Monitor | Microsoft.SystemCenter.HealthService.PerformanceHealthRollup | ||
Category | PerformanceHealth | ||
Enabled | True | ||
Alert Generate | True | ||
Alert Severity | Error | ||
Alert Priority | High | ||
Alert Auto Resolve | True | ||
Monitor Type | Microsoft.SystemCenter.HealthService.ConsecutiveSampleDoubleThreshold | ||
Remotable | True | ||
Accessibility | Public | ||
Alert Message |
| ||
RunAs | Default |
<UnitMonitor ID="Microsoft.SystemCenter.HealthService.CollectionRule.Performance.SendQueuePercentUsedMonitor" Accessibility="Public" Enabled="true" Target="SCLibrary!Microsoft.SystemCenter.Agent" ParentMonitorID="Microsoft.SystemCenter.HealthService.PerformanceHealthRollup" Remotable="true" Priority="Normal" TypeID="Microsoft.SystemCenter.HealthService.ConsecutiveSampleDoubleThreshold" ConfirmDelivery="false">
<Category>PerformanceHealth</Category>
<AlertSettings AlertMessage="Microsoft.SystemCenter.HealthService.CollectionRule.Performance.SendQueuePercentUsedMonitor_AlertMessageResourceID">
<AlertOnState>Error</AlertOnState>
<AutoResolve>true</AutoResolve>
<AlertPriority>High</AlertPriority>
<AlertSeverity>Error</AlertSeverity>
<AlertParameters>
<AlertParameter1>$Data/Context/Value$</AlertParameter1>
</AlertParameters>
</AlertSettings>
<OperationalStates>
<OperationalState ID="BelowThreshold" MonitorTypeStateID="UnderWarningThreshold" HealthState="Success"/>
<OperationalState ID="BetweenThresholds" MonitorTypeStateID="OverWarningThresholdUnderErrorThreshold" HealthState="Warning"/>
<OperationalState ID="OverThreshold" MonitorTypeStateID="OverErrorThreshold" HealthState="Error"/>
</OperationalStates>
<Configuration>
<ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
<CounterName>Send Queue % Used</CounterName>
<ObjectName>Health Service Management Groups</ObjectName>
<InstanceName>$Target/ManagementGroup/Name$</InstanceName>
<AllInstances>false</AllInstances>
<Frequency>180</Frequency>
<PercentFull>95</PercentFull>
<NumSamples>3</NumSamples>
<WarningThreshold>90</WarningThreshold>
<ErrorThreshold>95</ErrorThreshold>
</Configuration>
</UnitMonitor>