«Запрошенный читатель недействителен. Читатель либо не существует, либо срок его действия истек» Ошибка при получении данных о производительности в SCOM - PullRequest
Новая
       14

«Запрошенный читатель недействителен. Читатель либо не существует, либо срок его действия истек» Ошибка при получении данных о производительности в SCOM

0 голосов
/ 30 апреля 2018

Фрагмент сценария, который я выполняю: 

 $reader = $managementgroupobj.GetMonitoringPerformanceDataReader() 
 while ($reader.Read())    // << Error in this line.
 { 
      $perfData = $reader.GetMonitoringPerformanceData() 
      $valueReader = $perfData.GetValueReader($starttime,$endtime) 
      while ($valueReader.Read()) 
      { 
           $perfValue = $valueReader.GetMonitoringPerformanceDataValue()
      } 
 }

Здесь $managementgroupobj является экземпляром класса ManagementGroup.

Разница $starttime и $endtime варьируется от 15 минут до 1 часа в зависимости от последнего выполнения того же сценария.

Фрагмент собирает данные производительности успешно в течение длительного времени. но потом, из ниоткуда, выдает следующую ошибку:

"Запрошенный читатель недействителен. Читатель либо не существует, либо срок его действия истек" 

[ log_level=WARN pid=2716 ] Execute command 'get-scomallperfdata' failed. The requested reader was not valid. The reader either does not exist or has expired.
at GetSCOMPerformanceData, E:\perf\scom_command_loader.ps1: line 628
at run, E:\perf\scom_command_loader.ps1: line 591
at <ScriptBlock>, E:\perf\scom_command_loader.ps1: line 815
at <ScriptBlock>, <No file>: line 1
at <ScriptBlock>, <No file>: line 46
   at Microsoft.EnterpriseManagement.Common.Internal.ServiceProxy.HandleFault(String methodName, Message message)
   at Microsoft.EnterpriseManagement.Common.Internal.EntityObjectsServiceProxy.GetObjectsFromReader(Guid readerId, Int32 count)
   at Microsoft.EnterpriseManagement.Common.DataReader.Read()
   at CallSite.Target(Closure , CallSite , Object )
  • В чем причина упомянутой ошибки .?
  • Было бы здорово, если бы я познакомился с механизмом PerformanceDataReader.

Примечание:

  • Объем данных, которые он получил до получения ошибки, был 100k +. и это заняло почти час, чтобы получить эти данные.
  • Я думаю, что возможная проблема была с количеством данных, которые он должен получить. Это может быть своего рода TimoutException.
  • Было бы замечательно, если бы я получил хотя бы некоторое знание обоих упомянутых выше вопросов.

Спасибо.

Ответы [ 2 ]

0 голосов
/ 09 мая 2018

Поскольку конечной целью является выгрузка ВСЕХ данных производительности в другой инструмент, API SCOM не будет обеспечивать достаточную производительность, поэтому рекомендуется прямой запрос SQL.

Немного фона:

  1. SCOM имеет буксирные БД. Оперативный содержит все текущее состояние, в том числе почти в режиме реального времени данные о производительности. База данных хранилища данных хранит исторические данные, включая агрегированные (почасовые и ежедневные) данные о производительности. Все приведенные ниже запросы относятся к оперативной базе данных.
  2. SCOM как платформа может контролировать абсолютно все - это реализовано в пакетах управления, поэтому каждый MP может вводить новые классы (типы) отслеживаемых объектов и / или новые счетчики производительности для существующих классов. Скажем, вы можете создать устройство MP для устройства SAN и начать сбор данных о производительности. Или вы можете создать еще один MP, который добавит счетчик «Количество файлов» в класс «Windows Logical Disk».

Учитывая вышеперечисленные моменты, приведенные ниже запросы относятся к классу "Компьютер Windows" (поэтому не будет работать, если вы будете отслеживать серверы Unix, вам нужно будет изменить класс) и ко всем связанным объектам.

Шаг 1: Найти все доступные счетчики для компьютера Windows по его имени.

NB !: результаты могут отличаться в зависимости от версии ОС и MP, установленных в вашем SCOM. 

declare @ServerName as nvarchar(200) = 'server1.domain.local'

select pc.*
  from PerformanceCounterView pc
  join TypedManagedEntity tme on tme.TypedManagedEntityId = pc.ManagedEntityId
  join BaseManagedEntity bme on tme.BaseManagedEntityId = bme.BaseManagedEntityId
  where (bme.TopLevelHostEntityId = (select BaseManagedEntityId from BaseManagedEntity where FullName = 'Microsoft.Windows.Computer:'+@ServerName))
order by ObjectName, CounterName, InstanceName

Шаг 2: Повторите фактические данные о производительности для каждого счетчика, найденного на шаге 1.

@SrcId параметр - это PerformanceSourceInternalId столбец из предыдущего запроса.

NB !: все метки времени в SCOM указаны в UTC. Приведенный ниже запрос принимает ввод по местному времени и производит вывод также по местному времени. 

declare @SrcID as int = XXXX
declare @End as datetime =  GETDATE()
declare @Start as datetime = DATEADD(HOUR, -4, @End)

declare @TZOffset as int = DATEDIFF(MINUTE,GETUTCDATE(),GETDATE())

SELECT SampleValue, DATEADD(MINUTE, @TZOffset, TimeSampled) as TS
  FROM PerformanceDataAllView
  where (PerformanceSourceInternalId = @SrcID)
        and (TimeSampled > DATEADD(MINUTE, -@TZOffset, @Start))
        and (TimeSampled < DATEADD(MINUTE, -@TZOffset, @End))

По умолчанию SCOM сохраняет только последние 7 дней производительности «в реальном времени», затем агрегируется и выгружается в хранилище данных.

Не вызывайте эти запросы слишком часто и не используйте оператор «NO LOCK», чтобы не блокировать сам SCOM.

Надеюсь, это поможет.

Приветствие Max

0 голосов
/ 07 мая 2018

вызов читателя вернет true, если читатель перешел к следующему результату, и false, если нет; согласно методике . Если вы получаете исключение, это не может сделать ни один из них. Я предполагаю, что что-то нарушило связь между вами и экземпляром SCCM.

Если это проблема тайм-аута, я не уверен, что это тайм-аут SCCM. Ошибка ничего не говорит о тайм-ауте. Насколько я знаю, это вызов RPC под капотом, и RPC не имеет таймаута :

Ваш клиент может зависнуть двумя способами: подключение к сети может может привести к потере запросов к серверу или самому серверу. При использовании параметров по умолчанию RPC никогда не будет прерывать вызов, и ваш клиент поток будет ждать ответа вечно.

Может быть, брандмауэр закрывает ваше соединение через определенный промежуток времени?

Если вы хотите подключить свое исполнение, рассмотрите кеширование . Похоже, у вас есть намного больший сценарий, чем фрагмент, который мы видим. Отбросив это, просто чтобы вы знали, его вариант.

...