Сбор сведений о среде

1. Мониторинг и наблюдение

В этой главе рассмотрен ряд способов мониторинга и получения метрик и журналов из системы ПО «zVirt Max». К таким способам относятся:

Использование Хранилища (DWH)
Отправка метрик в удаленный экземпляр Elasticsearch

1.1. Использование Хранилища (DWH)

Данные от Менеджера управления собираются каждую минуту и агрегируются каждый час и каждые сутки. Данные сохраняются в соответствии с настройкой охвата (scale), заданной в конфигурации Хранилища (DWH) во время выполнения команды engine-setup (Базовый (Basic) или Полный (Full) охват):

Базовый (Basic) (по умолчанию) – включает в выборку данные за 24 часа, почасовые данные за 1 месяц, а посуточные данные не сохраняет.
Полный (Full) (рекомендуется) – включает в выборку данные за 24 часа, почасовые данные за 2 месяца и посуточные данные за 5 лет.

Полный охват может потребовать переноса Хранилища (DWH) на отдельную виртуальную машину.

1.2. Отправка метрик и журналов в удаленный экземпляр Elasticsearch

Рокитсофт не является владельцем и не поддерживает Elasticsearch. Чтобы развернуть эту опцию, необходимо иметь опыт настройки и обслуживания Elasticsearch.

Можно настроить Менеджер управления и хосты для отправки данных метрик и журналов в существующий экземпляр Elasticsearch.

Для этого запустите роль Ansible, которая настраивает collectd и rsyslog на Менеджере управления и все хосты на сбор метрик engine.log, vdsm.log и collectd, и отправьте их в экземпляр Elasticsearch.

1.2.1. Установка collectd и rsyslog

Разверните службы collectd и rsyslog на хостах, чтобы собирать журналы и метрики.

Эту процедуру не нужно повторять для новых хостов. Менеджер управления автоматически настраивает каждый новый добавляемый хост на отправку данных в Elasticsearch во время развертывания хоста.

Процедура

Авторизуйтесь на машине с Менеджером управления, используя SSH.
Скопируйте /etc/ovirt-engine-metrics/config.yml.example , чтобы создать /etc/ovirt-engine-metrics/config.yml.d/config.yml:
```
cp /etc/ovirt-engine-metrics/config.yml.example /etc/ovirt-engine-metrics/config.yml.d/config.yml
```
Измените параметры ovirt_env_name и elasticsearch_host в файле config.yml и сохраните файл. К файлу можно добавить следующие дополнительные параметры:
```
use_omelasticsearch _cert: false

rsyslog_elasticsearch_usehttps_metrics: !!str off

rsyslog_elasticsearch_usehttps_logs: !!str off
```
- Если используются сертификаты, установите параметр use_omelasticsearch_cert в значение true.
- Чтобы отключить журналы или метрики, используйте параметры:
  rsyslog _ elasticsearch _ usehttps _ metrics и/или rsyslog _ elasticsearch _ usehttps _ logs.

Разверните collectd и rsyslog на хостах:

/usr/share/ovirt-engine-metrics/setup/ansible/configure_ovirt_machines_for_metrics.sh

Скрипт configure_ovirt_machines_for_metrics.sh запускает роль Ansible, которая включает в себя linux-system-roles, и использует её для развертывания и конфигурирования службы rsyslog на хосте. Rsyslog собирает метрики из службы collectd и отправляет их в Elasticsearch.

1.2.2. Схема журналирования и анализ журналов

Для интерактивного исследования данных, собранных из ПО «zVirt Max», используйте страницу Обнаружить (Discover). Каждый собранный набор результатов называется документом (document).

Сбор документов выполняется из следующих файлов журналов:

engine.log – содержит все отказы пользовательского интерфейса oVirt Engine, события поиска в Active Directory, проблемы баз данных и другие события.
vdsm.log – файл журнала для VDSM, агента Менеджера управления на хостах виртуализации, содержащий события, связанные с хостами.

Таблица 1. Доступны следующие поля:
Параметр	Описание
_ id	Уникальный идентификатор документа
_ index	Идентификатор индекса, которому принадлежит документ. Индекс с префиксом project.ovirt-logs является единственным, который имеет отношение к странице Обнаружить (Discover).
hostname	Для engine.log это имя хоста Менеджера управления. Для vdsm.log это имя хоста.
level	Уровень критичности записи в журнале: TRACE, DEBUG, INFO, WARN, ERROR, FATAL.
message	Тело сообщения, содержащегося в документе.
ovirt.class	Имя Java-класса, сгенерировавшего этот журнал.
ovirt.correlationid	Только для engine.log. Этот идентификатор используется для соотнесения нескольких частей одной задачи, выполняемой Менеджером управления.
ovirt.thread	Имя потока Java, внутри которого была создана запись в журнале.
tag	Заранее определенные наборы метаданных, которые можно использовать для фильтрации данных.
@timestamp	[ время ] (Troubleshooting#information-is-missing-from-kibana) создания записи.
_ score	—
_ type	—
ipaddr4	IP-адрес машины.
ovirt.cluster _ name	Только для vdsm.log. Имя кластера, которому принадлежит хост.
ovirt.engine _ fqdn	FQDN Менеджера управления.
ovirt.module _ lineno	Файл и номер строки в файле, которая запустила команду, определенную в ovirt.class.

1.3. Файлы журналов

1.3.1. Файлы журналов установки Менеджера управления

Таблица 2. Установка
Файл журнала	Описание
*/var/log/ovirt-engine/engine-cleanup_ _ yyyy _ mm _ dd _ hh _ mm _ ss_*.log	Журнал команды engine-cleanup. Эта команда используется для сброса установленного Менеджера управления. Журнал создается каждый раз при выполнении команды. В имени файла указываются дата и время запуска, что позволяет создавать множество журналов.
/var/log/ovirt-engine/engine-db-install-*yyyy _ mm _ dd _ hh _ mm _ ss.log*	Журнал команды engine-setup, в котором подробно описывается создание и конфигурирование базы данных engine.
/var/log/ovirt-engine/ovirt-engine-dwh-setup-*yyyy _ mm _ dd _ hh _ mm _ ss.log*	Журнал команды ovirt-engine-dwh-setup. Эта команда используется для создания базы данных ovirt _ engine _ history для отчетности. Журнал создается каждый раз при выполнении команды. В имени файла указываются дата и время запуска, что позволяет создавать множество журналов.
/var/log/ovirt-engine/setup/ovirt-engine-setup-*yyyymmddhhmmss.log*	Журнал команды engine-setup. Журнал создается каждый раз при выполнении команды. В имени файла указываются дата и время запуска, что позволяет создавать множество журналов.

1.3.2. Файлы журнала Менеджера управления

Таблица 3. Обслуживание
Файл журнала	Описание
/var/log/ovirt-engine/engine.log	Отражает все сбои графического пользовательского интерфейса Менеджера управления, события поиска в Active Directory, проблемы с базой данных и другие события.
/var/log/ovirt-engine/host-deploy	Файлы журналов с хостов, развернутых из Менеджера управления.
/var/lib/ovirt-engine/setup-history.txt	Отслеживает установку и обновление пакетов, ассоциированных с Менеджером управления.
/var/log/httpd/ovirt-requests-log	Регистрирует в журнале файлы из запросов, сделанных через HTTPS к Менеджеру управления (включая время, которое заняло выполнение каждого запроса). Заголовок Correlation-Id включается для того, чтобы дать возможность сравнивать запросы при сравнении файла журнала с /var/log/ovirt-engine/engine.log.
/var/log/ovn-provider/ovirt-provider-ovn.log	Регистрирует в журнале действия провайдера OVN. Информацию о журналах Open vSwitch см. в документации на Open vSwitch.

1.3.3. Файлы журналов SPICE

Файлы журналов SPICE могут помочь при устранении проблем с подключениями SPICE. Для запуска отладки SPICE измените уровень журнала на отладку (debugging). Затем определите местонахождение журнала.

И клиенты, используемые для доступа к гостевым машинам, и сами гостевые машины имеют файлы журналов SPICE. Если клиент SPICE был запущен с использованием собственного клиента, для которого загружен файл console.vv, то для клиентских журналов используйте команду remote-viewer, чтобы включить отладку и сгенерировать вывод журнала.

1.3.4. Журналы SPICE для серверов SPICE гипервизора

Таблица 4. Журналы SPICE для серверов SPICE гипервизора
Тип журнала	Местонахождение журнала	Чтобы изменить уровень журнала
Сервер SPICE хоста/гипервизора	/var/log/libvirt/qemu/(guest _ name).log	Выполните команду export SPICE _ DEBUG _ LEVEL=5 на хосте/гипервизоре до запуска гостевой машины. Парсинг этой переменной выполняет QEMU, и в случае запуска для всей системы будет напечатана отладочная информация обо всех виртуальных машинах в системе. Эту команду нужно запускать на каждом хосте в кластере. Эта команда работает только на уровне хоста/гипервизора, а не кластера.

1.3.5. Журналы SPICE для гостевых машин

Таблица 5. Журналы spice-vdagent для гостевых машин
Тип журнала	Местонахождение журнала	Чтобы изменить уровень журнала:
Гостевая машина Windows	C: \ Windows \ Temp \ vdagent.log C: \ Windows \ Temp \ vdservice.log	Не применимо
Гостевая машина Red Hat Enterprise Linux	Используйте journalctl от имени root-пользователя.	Чтобы запустить службу spice-vdagentd в режиме отладки, от имени root-пользователя создайте файл /etc/sysconfig/spice-vdagentd, содержащий следующую запись: SPICE _ VDAGENTD _ EXTRA _ ARGS=”-d -d” Чтобы запустить spice-vdagent в режиме отладки, в командной строке выполните: $ killall - u $USER spice-vdagent $ spice-vdagent -x -d [ -d ] [ \|& tee spice-vdagent.log ]

1.3.6. Журналы SPICE для клиентов SPICE, запущенных с использованием файлов console.vv

Для клиентских машин Linux:

Включите отладку SPICE, выполнив команду remote-viewer с параметром --spice-debug. После появления запроса введите URL-адрес для`подключения, например, spice://virtual_machine_IP:port.
```
remote-viewer --spice-debug
```
Чтобы запустить клиент SPICE с параметром отладки и передать ему файл c расширением .vv, загрузите файл console.vv и выполните команду remote-viewer с параметром --spice-debug и укажите полный путь к файлу console.vv.
```
remote-viewer --spice-debug /path/to/console.vv
```

Для клиентских машин Windows:

В virt-viewer версии 2.0-11.el7ev и более поздних установщик virt-viewer.msi устанавливает virt-viewer и debug-viewer.exe.
Выполните команду remote-viewer с аргументом spice-debug, указав ей путь к консоли:
```
remote-viewer --spice-debug  path\to\console.vv
```
Чтобы просмотреть журналы, подключитесь к виртуальной машине, и вы увидите командную строку с запущенным GDB, которая печатает стандартный вывод и стандартную ошибку remote-viewer.

1.4. Файлы журналов хоста

Таблица 6. Файлы журналов хоста
Файл журнала	Описание
/var/log/messages	Файл журнала, который используется libvirt. Для просмотра журнала используйте journalctl. Чтобы просматривать журнал, нужно быть членом групп adm, systemd-journal или wheel.
/var/log/vdsm/spm-lock.log	Файл журнала с информацией о способности хоста получать права на аренду в роли Менеджера пула хранения (SPM). Этот журнал содержит информацию о предоставлении, лишении, обновлении прав на аренду или об отказе в этих правах.
/var/log/vdsm/vdsm.log	Файл журнала для VDSM, агента Менеджера управления на хосте (хостах).
/tmp/ovirt-host-deploy-*Date.log*	Журнал развертывания хоста, который копируется в Менеджер управления как /var/log/ovirt-engine/host-deploy/ovirt-Date-Host-Correlation _ ID.log после успешного развертывания хоста.
/var/log/vdsm/import/import-*UUID-Date.log*	Файл журнала с подробным описанием импорта виртуальных машин с хоста KVM, провайдера VMware или хоста RHEL 5 Xen, включая информацию об ошибках импорта. UUID – это UUID импортированной виртуальной машины, а Date – дата и время начала импортирования.
/var/log/vdsm/supervdsm.log	Регистрирует в журнале задачи VDSM, которые выполнялись с разрешениями суперпользователя.
/var/log/vdsm/upgrade.log	VDSM использует этот файл журнала во время обновлений хостов для регистрации изменений конфигурации.
/var/log/vdsm/mom.log	Регистрирует действия менеджера избыточного выделения памяти VDSM.

1.5. Настройка журналирования на уровень отладки для служб ПО «zVirt Max»

Журналы следующих служб ПО «zVirt Max» можно настроить на уровень отладки, изменив файл sysconfig каждой службы.

Таблица 7. Службы ПО «zVirt Max» и пути к файлам sysconfig
Служба	Путь к файлу
ovirt-engine.service	/etc/sysconfig/ovirt-engine
ovirt-engine-dwhd.service	/etc/sysconfig/ovirt-engine-dwhd
ovirt-fence-kdump-listener.service	/etc/sysconfig/ovirt-fence-kdump-listener
ovirt-websocket-proxy.service	/etc/sysconfig/ovirt-websocket-proxy

Эта модификация влияет на процесс журналирования, выполняемый оболочкой Python, а не основным процессом службы.

Настройка журналирования на уровень отладки полезна для отладки проблем, связанных с запуском, например, если основной процесс не запускается из-за отсутствующей или некорректной среды выполнения Java или библиотеки.

Предварительные условия

Убедитесь, что файл sysconfig, который нужно изменить, существует. Если необходимо, создайте его.

Процедура

Добавьте в файл sysconfig службы следующую строку:
```
OVIRT_SERVICE_DEBUG=1
```
Перезапустите службу:
```
systemctl restart  < service >
```
Теперь для файла журнала sysconfig службы задан уровень отладки.

Эта настройка предписывает выполнять журналирование в системный журнал, поэтому генерируемые ею журналы можно найти либо в /var/log/messages, а не в файле журнала конкретной службы, либо использовав команду journalctl.

1.6. Основные файлы конфигурации для служб ПО «zVirt Max»

В дополнение к файлу sysconfig, у каждой из этих служб ПО «zVirt Max» есть еще один файл конфигурации, который используется чаще.

Таблица 8. Службы ПО «zVirt Max» и файлы конфигурации
Служба	Путь к файлу sysconfig	Основной файл конфигурации
ovirt-engine.service	/etc/sysconfig/ovirt-engine	/etc/ovirt-engine/engine.conf.d/ * .conf
ovirt-engine-dwhd.service	/etc/sysconfig/ovirt-engine-dwhd	/etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/ * .conf
ovirt-fence-kdump-listener.service	/etc/sysconfig/ovirt-fence-kdump-listener	/etc/ovirt-engine/ovirt-fence-kdump-listener.conf.d/ * .conf
ovirt-websocket-proxy.service	/etc/sysconfig/ovirt-websocket-proxy	/etc/ovirt-engine/ovirt-websocket-proxy.conf.d/ * .conf

1.7. Настройка сервера журналирования хостов

Хосты генерируют и обновляют файлы журналов, записывая свои действия и проблемы. Централизованный сбор этих файлов журналов упрощает отладку.

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

Процедура

Проверьте, разрешает ли межсетевой экран трафик через порт UDP 514 и открыт ли он для трафика службы syslog:
```
firewall-cmd --query-service=syslog
```
Если будет выведено нет (no), разрешите трафик через порт UDP 514, как показано ниже:
```
firewall-cmd --add-service=syslog --permanent
firewall-cmd --reload
```

Создайте на сервере syslog новый файл .conf (например, /etc/rsyslog.d/from_remote.conf) и добавьте следующие строки:

template(name="DynFile" type="string"
string="/var/log/%HOSTNAME%/%PROGRAMNAME%.log")

RuleSet(name="RemoteMachine") {  action(type="omfile"
dynaFile="DynFile") }

Module(load="imudp")

Input(type="imudp" port="514" ruleset="RemoteMachine")

Перезапустите службу rsyslog:
```
systemctl restart rsyslog.service
```
Авторизуйтесь на гипервизоре и в файл /etc/rsyslog.conf добавьте следующую строку:
```
 * .info;mail.none;authpriv.none;cron.none @ < syslog-FQDN > :514
```
Перезапустите службу rsyslog на гипервизоре.
```
systemctl restart rsyslog.service
```
Теперь централизованный сервер журналов настроен на получение и хранение сообщений (messages) и безопасных (secure) журналов с хостов виртуализации.

1.8. Включение SyslogHandler для передачи журналов Менеджера управления на удаленный сервер syslog

Данная реализация позволяет передавать записи журналов из engine.log и server.log на сервер syslog.

Настройка реализации SyslogHandler

Создайте файл конфигурации 90-syslog.conf в каталоге /etc/ovirt-engine/engine.conf.d и включите в него следующее содержимое:

SYSLOG _ HANDLER _ ENABLED=true SYSLOG _ HANDLER _ SERVER _ HOSTNAME=localhost SYSLOG _ HANDLER _ FACILITY=USER _ LEVEL
Установите и настройте rsyslog.
```
dnf install rsyslog
```
Настройте SELinux, чтобы разрешить трафик rsyslog.
```
semanage port -a -t syslogd_port -p udp 514
```
Создайте файл конфигурации /etc/rsyslog.d/rhvm.conf и добавьте следующее содержимое:
```
user. */var/log/jboss.log

module(load="imudp") # needs to be done just once

input(type="imudp" port="514")
```
Перезапустите службу rsyslog.
```
systemctl restart rsyslog.service
```
Если межсетевой экран включен и активен, выполните следующую команду, чтобы добавить необходимые правила для открытия портов rsyslog в Firewalld:
```
firewall-cmd --permanent --add-port=514/udp
firewall-cmd --reload
```
Перезапустите Менеджер управления.
```
systemctl restart ovirt-engine
```

Сервер syslog теперь может получать и хранить файлы engine.log.

1.9. Отчет о событиях безопасности

ПО zVirt Max предоставляет возможность собирать информацию, о различных событиях системы. Каждое событие имеет свой тип, критичность, описание, ассоциированный с ним обьект, например, хост или хранилище.

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

Critical
Debug
Emergency
Fatal
High
Low
Meduim

Подробное описание уровней критичности представлено в таблице.

Таблица 9. Описание уровней критичности
Уровень	Описание
Critical	Критические ошибки системы виртуализации, которые необходимоу срочно устранить, могут приводит к отказу функционирование каких-либо компонент.
Debug	Выполнение отладки и тестирования компонент системы виртуализации, могут требовать выполнения определенных действий, например в случае неудачного входа в систему требуется проверить данные пользователя или обратиться к администратору.
Emergency	Аварийная ситуация или события требующие срочного исправления параметров и настроек системы виртуализации.
Fatal	Фатальные ошибки компонент системы виртуализации, приводящие к выходу из строя или свидетельствующие об отказе системы или его компонент.
High	События, связанные с изменением параметров и разрешений системы виртуализации, могут приводить к неправильному функционированию компонент. Например, возникают при повышении прав пользователей или изменении ролей.
Low	Уведомления о функцинировании отдельных компонент и рекомендации использовать определенные инструменты. Например если недоступно или не настроено полное резервное копирование, рекомендуется использовать engine-backup.
Meduim	События, связанные с изменением параметров и разрешений системы виртуализации, требующие выполнить определенные действия для улучшения функционирования системы. Например возникают после проверки обновлений или при необходимости установить недостающие пакеты.

Для получения отчетов о событии безопасности ПО zVirt Max использует API, что позволяет обращаются к отчетам через стандартный протокол передачи гипертекста (HTTP).

доступ к отчетам безопасности имеет пользователь типа «Администратор» с ролью «Администратор безопасности средства виртуализации (SecurityAdministratorVirtualizationTools)».

Для получения доступа необходимо в адресной строке браузера ввести значение следующего типа:

протокол:// FQDN_сервера c менеджером управления/security-report

Например: http:// zvirtvm.rockitsoft.local/security-report

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

В результате будет загружена таблица со следующей структурой, описание которой представлено в таблице.

Таблица 10. Описание структуры отчета в формате .csv
Индекс (Index)	Код (Code)	Автор (Author)	Время (Time)	Описание (Description)
Числовой индекс данного события. Индексы событий всегда возрастают, поэтому события с более высокими индексами гарантированно будут старше, чем события с меньшими индексами.	Предопределенный числовой индекс события описывающий событие созданное каким либо компонентом архитектуры.	Имя пользователя	Временная метка в формате: часы:минуты чч.мм.гггг	Текстовое описание произошедшего события.

Для отправки метрик и журналов за день на почту используется скрипт security-backup.sh. Данный скрипт анализирует содержимое базы данных событий audit_log, выбирает события безопасности и перессылает их в формате .csv на почту согласно указанным параметрам SMTP-сервера в файле send _ report.py.