SCOM не обнаруживает экземпляры Apache или MySQL
проблема
После установки Агента Linux SCOM, SCOM правильно контролирует сервер Linux, но не обнаруживает ни одного экземпляра Apache или MySQL, т.е. ни одна запись не появляется в SCOM также при следующих представлениях:
Apache HTTP Server/Apache HTTP Servers
MySQL/MySQL Servers
Согласно всем руководствам, документам и пошаговым инструкциям вышеупомянутые записи должны быть заполнены теми серверами Linux, на которых были обнаружены экземпляры Apache и MySQL. Эти записи должны быть доступны перед дальнейшими шагами настройки и должны обеспечивать простые задачи настройки для настройки большинства сценариев по умолчанию.
Сами экземпляры Linux контролируются должным образом.
Я перечислил ниже всю соответствующую информацию и журналы, а также список выполненных шагов.
Есть идеи, что я пропустил?
Среда
- SCOM 2016 UR4 с последними пакетами управления соответствующего семейства мониторинга UNIX/Linux (начальные MP с носителей, обновленных до последней версии UR) и OSS (Apache, MySQL и обычные OSS MP)
- CentOS Linux выпуск 7.4.1708 (Core) с установкой по умолчанию Apache и MariaDB (без изменений в конфигурационных файлах)
- Агент SCOM Linux по умолчанию установлен со следующими версиями пакета:
scx-1.6.2-339.x86_64
mysql-cimprov-1.0.1-5.x86_64
apache-cimprov-1.0.1-9.x86_64
omi-1.2.0-35.x86_64
(эта версия вручную обновлена с версии 1.0.8, связанной с SCX, которая не была совместима сApacheHttpdProvider
ошибка подана)
История установки
- Настроенные пользователи:
scom-maint
а такжеscom-monit
вместе с соответствующими учетными записями и профилями RunAs на стороне SCOM - Настроенные
/etc/sudoers.d/scom
- SCX успешно установлен через SCOM вместе с
apache-cimprov
а такжеmysql-cimprov
- Мониторинг Apache и MySQL в ванильном состоянии не настроен (например, модуль Apache не загружен, учетные данные MySQL не настроены), поскольку все задачи настройки должны быть доступны через соответствующие задачи SCOM, которые должны быть доступны в
Apache/MySQL Servers
Просмотры.
Логи и файлы
/var/opt/omi/log/omiagent.root.root.log
Пусто, исключая ошибки, связанные сApacheHttpdProvider
вomi
совместимость версий, которая перестала появляться после обновленияomi
до 1.2.0/var/opt/omi/log/omiserver.log
Пусто, исключая ошибки, связанные с ошибкамиFailed to execute PREEXEC program
которые были связаны с этой ошибкой и перестали появляться после комментирования по умолчанию!includedir
в/etc/my.cnf
/var/opt/microsoft/mysql-cimprov/log/mysqllog.log
Регистрирует несколько ошибок, связанных с ненастроенным мониторингом MySQL/var/opt/microsoft/mysql-cimprov/log/scom-monit/mysqllog.log
Совершенно похоже на предыдущий файл/var/opt/microsoft/apache-cimprov
каталог не содержит логов или файлов, есть только пустойrun
каталог/var/opt/scx/scx.log
сгенерированный с подробной опцией не содержитapache
/mysql
ключевые слова (проверено с помощьюgrep -i
)/var/opt/scx/scom-monit/scx.log
не содержит ошибок (простоSCX Provider Module loaded
)
Обновление 1
Найдена и расследуется следующая запись, повторяющаяся в каждом цикле обнаружения (каждые 4 часа) в /var/log/secure
:
sudo: pam_unix(sudo:auth): conversation failed
sudo: pam_unix(sudo:auth): auth could not identify password for [scom-monit]
sudo: scom-monit : command not allowed ; TTY=unknown ; PWD=/var/opt/microsoft/scx/tmp ; USER=root ; COMMAND=/etc/opt/microsoft/scx/conf/tmpdir/scxuFPgv1
Последние 6 персонажей COMMAND
файл случайный.
1 ответ
Проблема была вызвана неправильной настройкой учетной записи RunAs. Профиль, назначенный для мониторинга, был настроен с включенным повышением sudo.
SCOM использует два профиля для мониторинга хостов UNIX/Linux:
UNIX/Linux Action Account
UNIX/Linux Privileged Account
В большинстве руководств рекомендуется использовать одну учетную запись для обеих целей, но в них четко не указано, что эта одна учетная запись должна быть определена в SCOM как две отдельные UNIX/Linux Accounts
экземпляры:
- Первый экземпляр должен быть настроен с
Elevate this account using sudo for privileged access
а затем назначен наUNIX/Linux Privileged Account
профиль - Второй экземпляр должен быть настроен с
Do not use elevation with this account
а затем назначен наUNIX/Linux Action Account
профиль
Теперь кажется, что когда агент SCX выполняет задачу или команду, нет атрибута, который прямо указывает, использовать ли sudo или нет, но использовать ли привилегированную учетную запись или нет. И высота, как настроено с конкретным UNIX/Linux Action Account
, используется независимо от того, требуется ли это или нет.