Устранение неполадок мониторинга компьютеров UNIX и Linux

System Center — Operations Manager обеспечивает мониторинг компьютеров UNIX и Linux, аналогичных мониторингу компьютеров Windows. Вы можете отслеживать работоспособность, производительность, получать отчеты, выполнять задачи и реализовывать пользовательские инструментирование мониторинга.

Вы можете наблюдать за следующими компонентами компьютеров с ОС UNIX и Linux:

• службы и приложения;

• файловая система, дисковое пространство, область подкачки, оперативная память;

• Сетевые интерфейсы

• основные процессы и атрибуты;

• основные параметры конфигурации.

Прежде чем отслеживать компьютеры UNIX и Linux, необходимо выполнить следующие действия.

1. Импорт пакетов управления путем скачивания последних версий из Центра загрузки Майкрософт.
2. Создайте выделенный пул ресурсов для мониторинга компьютеров UNIX и Linux.
3. Настройте сертификаты для каждого сервера управления в пуле.
4. Создание и настройка учетных записей запуска от имени.
5. Установите агент в UNIX и Linux с помощью мастера обнаружения.

После выполнения описанных выше действий и успешного обнаружения и развертывания агента на одном или нескольких компьютерах UNIX и Linux необходимо убедиться, что они отслеживаются правильно. После развертывания агента учетные записи запуска от имени используются для обнаружения, выполняющихся с помощью применимых правил обнаружения, а затем запускают мониторинг. Через несколько минут в рабочей области администрирования перейдите к Управление устройствами/КОМПЬЮТЕРАм UNIX/Linux и убедитесь, что компьютеры не указаны как неизвестные. Их следует обнаружить и отобразить определенную версию ОС и дистрибутива.

По умолчанию Operations Manager отслеживает следующие объекты операционной системы:

• Операционная система
• Логический диск
• Сетевые адаптеры

Вы можете получить дополнительные возможности для мониторинга и взаимодействия на управляемых компьютерах с UNIX и Linux, используя шаблоны пакета управления UNIX и Linux. Дополнительные сведения см. в разделе Файл журнала UNIX или Linux и Процесс UNIX или Linux в руководстве по разработке.

Устранение неполадок с мониторингом UNIX и Linux

В следующем разделе содержатся сведения о проблемах, которые могут возникнуть при мониторинге компьютеров UNIX и Linux в Operations Manager.

Сообщения об ошибке подписи сертификата

В ходе установки агентов UNIX или Linux возможны следующие ошибки.

Event Type: Error  
Event Source: Cross Platform Modules  
Event Category: None  
Event ID: 256  
Date: 4/1/2009  
Time: 4:02:27 PM  
User: N/A  
Computer: COMPUTER1  
Description: Unexpected ScxCertLibException: Can't decode from base64  
; input data is:  

Данная ошибка возникает при вызове модуля подписи сертификата, но при этом сам сертификат пустой. Эта ошибка может быть вызвана сбоем подключения SSH к удаленной системе.

При возникновении этой ошибки выполните следующие действия.

1. Убедитесь, что управляющая программа SSH на удаленном узле запущена.

2. Убедитесь, что вы можете открыть сеанс SSH с удаленным узлом с помощью учетных данных, указанных в мастере обнаружения.

3. Убедитесь, что учетные данные, указанные в мастере обнаружения, имеют необходимые привилегии для обнаружения. Дополнительные сведения см. в разделе "Учетные данные", необходимые для доступа к компьютерам UNIX и Linux.

Имена узла и сертификата не совпадают

Общее имя, используемое в сертификате, должно совпадать с полным доменным именем (FQDN), разрешаемым Operations Manager. Если CN не соответствует, при запуске мастера обнаружения появится следующая ошибка:

The SSL certificate contains a common name (CN) that doesn't match the hostname  

Основные сведения сертификата на компьютере, работающем под управлением ОС UNIX или Linux, можно просмотреть, введя следующую команду:

openssl x509 -noout -in /etc/opt/microsoft/scx/ssl/scx.pem -subject -issuer -dates  

При этом вы увидите выходные данные, аналогичные следующим:

subject= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name  
issuer= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name  
notBefore=Mar 25 05:21:18 2008 GMT  
notAfter=Mar 20 05:21:18 2029 GMT  

Проверьте имена узлов и даты и удостоверьтесь, что они совпадают с именем, разрешенным сервером управления Operations Manager.

Если имена узлов не совпадают, используйте одно из следующих действий, чтобы устранить проблему:

• Если имя узла UNIX или Linux указано правильно, но сервер управления Operations Manager разрешает его неверно, измените запись DNS так, чтобы она соответствовала правильному полному доменному имени или добавьте запись в файл "Hosts" на сервере Operations Manager.

• Если имена узлов UNIX или Linux указаны неверно, выполните одно из указанных ниже действий.

  • Измените имя узла на узле UNIX или Linux на правильное и создайте новый сертификат.

  • Создайте новый сертификат с требуемым именем узла.

Измените имя сертификата:

Если сертификат был создан с неправильным именем, его можно изменить и повторно создать сертификат и закрытый ключ. Для этого выполните следующую команду на компьютере, работающем под управления ОС UNIX или Linux:

/opt/microsoft/scx/bin/tools/scxsslconfig -f -v  

Параметр -f принудительно перезаписывает файлы в файле /etc/opt/microsoft/scx/ssl.

Вы также можете изменить имя узла и доменное имя сертификата с помощью коммутаторов -h и -d , как показано в следующем примере:

/opt/microsoft/scx/bin/tools/scxsslconfig -f -h <hostname> -d <domain.name>  

Перезапустите агент, выполнив следующую команду.

/opt/microsoft/scx/bin/tools/scxadmin -restart  

Добавьте запись в файл узлов:

Если полное доменное имя не находится в обратном DNS, можно добавить запись в файл узлов, расположенный на сервере управления, чтобы предоставить разрешение имен. Файл узлов находится в папке Windows\System32\Drivers\etc. Запись в файле Hosts представляет собой комбинацию IP-адреса и полного доменного имени.

Например, чтобы добавить запись для узла с именем newhostname.newdomain.name с IP-адресом 192.168.1.1, добавьте следующее в конец файла узлов:

192.168.1.1      newhostname.newdomain.name  

Проблемы с пакетом управления

ExecuteCommand не поддерживает операторы конвейера или псевдонимы

При использовании псевдонима или оператора конвейера с параметром ExecuteCommand команда завершается ошибкой. Параметр ExecuteCommand не поддерживает оператор конвейера, псевдонимы и синтаксис оболочки.

В пакетах управления System Center Operations Manager, предназначенных для управления компьютерами UNIX и Linux, параметр ExecuteCommand не запускает процесс оболочки, что приводит к сбою пользовательского действия.

Для каждого из следующих типов настраиваемых действий указывается, как вызываются аргументы команд с помощью параметра ExecuteCommand или параметра ExecuteShellCommand :

• Microsoft.Unix.WSMan.Invoke.ProbeAction

• Microsoft.Unix.WSMan.Invoke.WriteAction

• Microsoft.Unix.WSMan.Invoke.Privileged.ProbeAction

• Microsoft.Unix.WSMan.Invoke.Privileged.WriteAction

Параметр ExecuteCommand передает аргументы командной строки в консоль без запуска процесса оболочки.

Параметр ExecuteShellCommand передает аргументы команды процессу оболочки с помощью оболочки пользователя по умолчанию. Эта оболочка поддерживает синтаксис конвейера, псевдонимов и оболочки.

Примечание.

Параметр ExecuteShellCommand использует оболочку по умолчанию пользователя, выполняющего команду. Если требуется определенная оболочка, используйте параметр ExecuteCommand и префикс аргументов команды с помощью требуемой оболочки.

В следующих примерах показано, как использовать параметры ExecuteCommand и ExecuteShellCommand:

• Передача аргументов командной строки в консоль без запуска процесса оболочки:

  <p:ExecuteCommand_INPUT xmlns:p="https://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem"> <p:Command> service syslog status </p:Command> <p:timeout>10</p:timeout> </p:ExecuteCommand_INPUT>

• Передача аргументов командной строки в процесс оболочки, ссылающийся на явную оболочку:

  <p:ExecuteCommand_INPUT xmlns:p="https://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem"> <p:Command> /bin/sh ps -ef syslog | grep -v grep </p:Command> <p:timeout>10</p:timeout> </p:ExecuteCommand_INPUT>

• Передача аргументов командной строки в процесс оболочки, использующий оболочку пользователя по умолчанию:

  <p:ExecuteShellCommand_INPUT xmlns:p="https://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem"> <p:Command> uptime |&nbsp; awk '{print $10}' |awk -F"," '{print $1}' </p:Command> <p:timeout>10</p:timeout> </p:ExecuteShellCommand_INPUT>

Ведение журнала и отладка

В этом разделе описывается, как включить средства ведения журнала и отладки для устранения неполадок с мониторингом компьютеров UNIX и Linux.

Примечание.

Параметры уровня журнала можно изменить без перезапуска агента. Подробнее.

Включение функции ведения журнала модуля Operations Manager

Агенты Operations Manager для UNIX и Linux поддерживают несколько файлов журналов, которые могут быть полезны при устранении неполадок с клиентом. Эти файлы журналов находятся на управляемом компьютере UNIX или Linux. Уровень ведения журнала агента можно настроить по мере необходимости. Более подробные журналы могут быть полезны при диагностике проблем. Для нормальной работы уровни журналов не должны быть заданы более подробно, чем конфигурации по умолчанию (промежуточные), чтобы предотвратить чрезмерный рост файлов журнала.

Примечание.

Вызовы, сделанные за пределами удаленного управления Windows, выполняются с помощью протокола SSH/SFTP. Эти компоненты основываются на отдельном от Operations Manager механизме регистрации в журнале.

Примечание.

Уровень ведения журнала для файла журнала omiserver.log нельзя изменить по умолчанию в этой версии агентов Operations Manager для UNIX и Linux.

1. Создайте пустой файл с именем EnableOpsmgrModuleLogging в каталоге Temp для учетной записи пользователя, вызвав эти модули, введя командную строку или строку PowerShell:

   COPY /Y NUL %windir%\TEMP\EnableOpsMgrModuleLogging
   

   New-Item "$env:windir\TEMP\EnableOpsMgrModuleLogging"
   

   Примечание.

   Как правило, это учетная запись SYSTEM, выполняя вызовы, и C:\Windows\Temp — это папка system temp по умолчанию.

2. После создания пустого файла Operations Manager немедленно начнет ведение журнала SSH и действия сертификата в каталог Temp. Скрипты, вызывающие журнал модулей SSH в <Scriptname.vbs>.log. Другие модули имеют свои собственные журналы.

В некоторых случаях может потребоваться перезапустить службу HealthService, чтобы получить ведение журнала EnableOpsmgrModuleLogging для принятия в силу.

Включение ведение журнала в агенте UNIX

В этих журналах сообщается о действиях агента UNIX. Если возникла проблема с данными, возвращенными в Operations Manager, просмотрите этот журнал. Можно задать объем сведений, регистрируемых командой scxadmin. Синтаксис этой команды выглядит следующим образом:

scxadmin -log-set [all|cimom|provider] {verbose|intermediate|errors}

В таблице ниже перечислены возможные значения параметра.

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

Использование DebugView для обнаружения неполадок

DebugView — это альтернативный метод EnableOpsmgrModuleLogging для устранения неполадок проблем обнаружения.

1. Скачайте DebugView из: https://go.microsoft.comfwlink/?Linkid=129486

2. Запустите DebugView на сервере управления, выполняющем поиск.

3. Запустите обнаружение агентов UNIX. В окнах DebugView можно просматривать выходные данные.

4. DebugView представляет пошаговый вывод данных процесса мастера обнаружения. Часто это наиболее быстрый способ обнаружения неполадок.

Включение функции ведения журнала Operations Manager для удаленного управления Windows

Данный метод подробного отслеживания применяется для просмотра запросов удаленного управления Windows, используемого Operations Manager для сбора данных от агентов. Если вы подозреваете, что с подключением WinRM возникла проблема, в этом журнале содержатся подробные сведения, которые могут помочь в устранении неполадок.

1. На сервере управления, который отслеживает агенты UNIX или Linux, откройте командную строку.

2. Введите следующие команды в командной строке:

   1. cd C:\Program Files\Microsoft System Center\Operations Manager\Tools

   2. StopTracing.cmd

   3. StartTracing.cmd VER

3. Воспроизведение проблемы сбоя в Operations Manager.

4. Введите следующие команды в командной строке:

   1. StopTracing.cmd

   2. FormatTracing.cmd

5. Найдите WS-Man в файле TracingGuidsNative.log.

Примечание.

Служба удаленного управление Windows называется также WS-Management (WS-Man).

Примечание.

Команда FormatTracing открывает окно проводника Windows, отображающее C:\Windows\Logs\OpsMgrTrace каталог. Файл TracingGuidsNative.log находится в этом каталоге.

Управление файлами журналов UNIX и Linux

Агенты Operations Manager для UNIX и Linux не ограничивают размер файлов журнала агента. Чтобы контролировать максимальный размер файлов журналов, реализуйте процесс для управления ими. Например, во многих ОС UNIX и Linux имеется стандартная служебная программа logrotate. Ее можно настроить для контроля файлов журналов, используемых агентами Operations Manager для UNIX или Linux. После ротации или изменение файлов журналов агента, он должен получить сигнал о ротации файлов, чтобы продолжать ведение журнала. Вы можете использовать команду scxadmin с параметром –log-rotate согласно следующему синтаксису:

scxadmin -log-rotate all

Пример файла конфигурации служебной программы Logrotate

В следующем примере показан файл конфигурации для смены файлов scx.log и omiserver.log с помощью программы logrotate Linux. Как правило, logrotate будет выполняться как запланированное задание (с крондом) и работать с файлами конфигурации, найденными в /etc/logrotate.d. Чтобы протестировать и использовать этот файл конфигурации, измените конфигурацию, чтобы она соответствовала вашей среде, и свяжите файл или сохраните его в /etc/logrotate.d.

#opsmgr.lr  

#Rotate scx.log  
#Weekly rotation, retain four weeks of compressed logs  
#Invoke scxadmin -log-rotate to resume logging after rotation  

/var/opt/microsoft/scx/log/scx.log {  
rotate 4  
weekly  
compress  
missingok  
notifempty  
postrotate  

/usr/sbin/scxadmin -log-rotate all  
endscript  
}

#Rotate scx.log for the monitoring user account named: monuser  
#Weekly rotation, retain four weeks of compressed logs  
#Invoke scxadmin -log-rotate to resume logging after rotation  

/var/opt/microsoft/scx/log/monuser/scx.log {  
rotate 4  
weekly  
compress  
missingok  
notifempty  
postrotate  

/usr/sbin/scxadmin -log-rotate all
endscript  
}  

#Optionally, rotate omiserver.log. This requires that OMI be stopped and started to prevent  
#impact to logging. Monthly rotation, retain two weeks of compressed logs  
#Uncomment these lines if rotation of omiserver.log is needed  

#/var/opt/microsoft/scx/log/omiserver.log{  
#        rotate 2  
#        monthly  
#        compress  
#        missingok  
#        notifempty  
#        prerotate  
#        /usr/sbin/scxadmin -stop  
#        endscript  
#        postrotate  
#        /usr/sbin/scxadmin -start  
#        endscript\
#}  

Следующие шаги

Дополнительные рекомендации по устранению распространенных проблем с развертыванием агента см. в разделе "Устранение неполадок с Operations Manager 2012: вики-сайт обнаружения агентов UNIX/Linux".