Для улучшения работы сайта мы используем файлы cookies. Оставаясь на сайте, вы соглашаетесь с политикой обработки персональных данных.

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

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

1.1. Использование хранилища Data Warehouse и Grafana для мониторинга zVirt

1.1.1. Общие сведения о Grafana

Grafana – это веб-инструмент пользовательского интерфейса для отображения отчетов на основе данных, собранных из базы данных Data Warehouse с именем ovirt_engine_history. См. панели мониторинга Grafana.

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

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

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

Полный охват может потребовать переноса Data Warehouse на отдельную виртуальную машину.

Инструкции по переносу хранилища Data Warehouse на отдельную машину см. в разделе Перенос базы данных и службы Data Warehouse на отдельную машину руководства администратора.

1.1.2. Установка

Интеграция с Grafana включена и устанавливается по умолчанию при выполнении команды engine-setup Менеджера управления как в варианте установки Stand Alone, так и в варианте Hosted Engine.

1.1.2.1. Настройка Grafana для единого входа

Команда engine-setup Менеджера управления автоматически настраивает Grafana так, чтобы существующие пользователи Менеджера управления смогли входить в систему с Портала администрирования, используя единый вход (SSO), но не создает пользователей автоматически.

Нужно создать новых пользователей ( Invite в пользовательском интерфейсе Grafana) и подтвердить их, после чего они смогут авторизоваться в системе.

Порядок действий:
  1. Задайте адрес электронной почты для пользователя в Менеджере управления, если он еще не задан.

  2. Авторизуйтесь в Grafana под именем существующего пользователя-администратора (изначально настроенного администратора).

  3. Нажмите Configuration  Users и выберите Invite.

  4. Введите адрес электронной почты и имя, после чего выберите роль (Role).

  5. Отправьте приглашение одним из следующих способов:

    • Выберите Send invite mail и нажмите Submit. Для этого способа нужен работающий локальный почтовый сервер, настроенный на машине с Grafana.

    • Выберите Pending Invites

      • Найдите нужную запись

      • Выберите Copy invite

      • Скопируйте и используйте эту ссылку для создания учетной записи, вставив ее прямо в адресную строку браузера или отправив другому пользователю.

Если вы используете параметр Pending Invites, то электронное письмо не отправляется и адрес электронной почты не обязательно должен существовать – подойдет любой адрес, выглядящий как действительный, если он настроен как адрес электронной почты пользователя Менеджера управления.

Чтобы авторизоваться под этой учетной записью:

  1. Войдите на веб-страницу приветствия администратора zVirt, используя учетную запись с этим адресом электронной почты.

  2. Выберите Портал мониторинга (Monitoring Portal), чтобы открыть панель мониторинга Grafana.

  3. Выберите Sign in with oVirt Engine Auth.

1.1.3. Встроенные панели мониторинга Grafana

В первоначальной конфигурации Grafana доступны следующие панели мониторинга для создания отчетов по центрам данных, кластерам, хостам и виртуальным машинам:

Таблица 1. Встроенные панели мониторинга Grafana**
Тип панели мониторинга Состав

oVirt Executive Dashboards

  • Панель мониторинга System – использование ресурсов и время безотказной работы хостов и доменов хранения в системе в соответствии с последними изменениями конфигураций.

  • Панель мониторинга Data Center – использование ресурсов, пики и время безотказной работы кластеров, хостов и доменов хранения в выбранном центре данных в соответствии с последними изменениями конфигураций.

  • Панель мониторинга Cluster – использование ресурсов, пики, избыточное выделение и время безотказной работы хостов и виртуальных машин в выбранном кластере в соответствии с последними изменениями конфигураций.

  • Панель мониторинга Host – сведения о новейшей и прошлых конфигурациях и метрики использования ресурсов для выбранного хоста за выбранный период.

  • Панель мониторинга Virtual Machine – сведения о новейшей и прошлых конфигурациях и метрики использования ресурсов для выбранной виртуальной машины за выбранный период.

  • Панель мониторинга Executive – использование ресурсов пользователями и количество операционных систем для хостов и виртуальных машин в выбранных кластерах за выбранный период.

oVirt Inventory Dashboards

  • Панель мониторинга Inventory – количество хостов, виртуальных машин и запущенных виртуальных машин, использование ресурсов и уровни избыточного выделения для выбранных центров данных в соответствии с последними изменениями конфигураций.

  • Панель мониторинга Hosts Inventory – FQDN, версия VDSM, ОС, модель ЦП, ядра ЦП, объем памяти, дата создания, дата удаления и сведения об оборудовании для выбранных хостов в соответствии с последними изменениями конфигураций.

  • Панель мониторинга Storage Domains Inventory – тип домена, тип хранилища, доступное пространство на диске, использованное пространство на диске, общий размер диска, дата создания и дата удаления для выбранных доменов хранения за выбранный период.

  • Панель мониторинга Virtual Machines Inventory – имя шаблона, ОС, ядра ЦП, объем памяти, дата создания и дата удаления для выбранных виртуальных машин в соответствии с последними изменениями конфигураций.

oVirt Service Level Dashboards

  • Панель мониторинга Uptime – плановое время простоя, внеплановое время простоя и общее время для хостов, виртуальных машин с признаком высокой доступности и всех виртуальных машин в выбранных кластерах за выбранный период.

  • Панель мониторинга Hosts Uptime – время безотказной работы, плановое время простоя и внеплановое время простоя для выбранных хостов за выбранный период.

  • Панель мониторинга Virtual Machines Uptime Dashboard – время безотказной работы, плановое время простоя и внеплановое время простоя для выбранных виртуальных машин за выбранный период.

  • Cluster Quality of Service

    • Панель мониторинга Hosts – время, в течение которого выбранные хосты работали с загрузкой ЦП и ОЗУ выше и ниже соответствующих пороговых значений за выбранный период.

    • Панель мониторинга Virtual Machines – время, в течение которого выбранные виртуальные машины работали с загрузкой ЦП и ОЗУ выше и ниже соответствующих пороговых значений за выбранный период.

oVirt Trend Dashboards

  • Панель мониторинга Trend – показатели использования 5 наиболее и наименее загруженных (по ОЗУ и ЦП) виртуальных машин и хостов в выбранных кластерах за выбранный период.

  • Панель мониторинга Hosts Trend – использование ресурсов (количество виртуальных машин, ЦП, ОЗУ и сетевые приемники/передатчики) для выбранных хостов за выбранный период.

  • Панель мониторинга Virtual Machines Trend – использование ресурсов (ЦП, ОЗУ, сетевые приемники/передатчики, дисковый ввод/вывод) для выбранных виртуальных машин за выбранный период.

  • Панель мониторинга Hosts Resource Usage – посуточное и почасовое использование ресурсов (количество виртуальных машин, ЦП, ОЗУ и сетевые приемники/передатчики) для выбранных хостов за выбранный период.

  • Панель мониторинга Virtual Machines Resource Usage – посуточное и почасовое использование ресурсов (ЦП, ОЗУ, сетевые приемники/передатчики, дисковый ввод/вывод) для выбранных виртуальных машин за выбранный период.

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

Более подробную информацию о панелях мониторинга см. в Описание панелей портала мониторинга

Встроенные панели мониторинга настраивать нельзя.

1.2. Настройка системы мониторинга доменов хранения

Содержимое данного раздела актуально для версии zVirt 3.1 и выше.

Система виртуализации zVirt предоставляет администратору информацию о нагрузке на домены хранения в реальном времени для помощи в принятии решений о размещении дисков виртуальных машин при их создании, изменении и перемещении.

Правильная работы подсистемы обеспечивается установленными в виртуальных машинах гостевыми дополнениями.

Функциональность поддерживается для следующих гостевых ОС:

  • ОС Windows XP/7/2003/2008 и новее

  • Linux

1.2.1. Отображение информации о нагрузке на домены хранения

Информация предоставляется в виде метрик (MB/s) в столбцах Cкорость чтения, Скорость записи, Задержка записи и Задержка чтения в следующих элементах интерфейса:

  • Хранилище (Storage)  Домены (Domains)

    domain view
  • Хранилище (Storage)  Диски (Disks)

    disks view
  • Ресурсы (Compute)  Виртуальные машины (Virtual Machines)Имя ВМ (Name VM)Диски (Disks)

    vdisk view

1.2.2. Настройка оповещений о превышении нагрузки на домены хранения

Дополнительно можно настроить пороговые значения параметров мониторинга для доменов хранения, после превышения которых администратор будет оповещен о событии в Блок уведомлений (раздел Предупреждения) и в События (Events):

messages
Порядок действий:
  1. Нажмите Хранилище (Storage)  Домены (Domains).

  2. При изменении настроек существующего:

    • Нажмите на имя домена который хотите настроить (откроется его расширенное описание) или просто выделите нужный домен левой кнопкой мыши.

    • Нажмите Управление доменом (Manage Domain).

    • В появившемся окне Управление доменом (Manage Domain) разверните параметр Конфигурация контроля мониторинга и оповещений (Monitoring and alerting configuration control), нажав на раскрывающую стрелку expander down.

  3. При создании нового:

    • Нажмите Новый домен (New Domain).

    • В появившемся окне Новый домен (New Domain) разверните параметр Конфигурация контроля мониторинга и оповещений (Monitoring and alerting configuration control), нажав на раскрывающую стрелку expander down.

      domain notify config
  4. Включите оповещения выбрав Включить мониторинг использования хранилища и оповещения (Enabled storage usage monitoring and alerting) и введите пороговые значения параметров. Если значение параметра установить равным 0, то оповещение производиться не будет.

Если установить переключатель конфигурации контроля мониторинга и оповещений в Отключить мониторинг использования хранилища и оповещения (Disabled storage usage monitoring and alerting), то оповещения производится не будут, но информация по скорости записи и чтения, задержки записи и чтения будет отображена в соответствующих элементах интерфейса.

1.2.3. Алгоритм работы оповещений

Есть три основных параметра, которые определяют алгоритм работы:

StorageDomainMonitoring_MetricsScrapePeriodSeconds

Устанавливает период проверки значений метрик с заданными лимитами.

Например: установлено значение 20, значит каждые 20 сек измеряются показания метрик на превышение)

Значение по умолчанию: 20

StorageDomainMonitoring_InvalidMeasurementsCountTolerationThreshold

Определяет кол-во измеренных подряд превышений заданного лимита после старта системы. При превышении которого будет выдано сообщение.

Например: установлено значение 6, временной интервал проверки задан 20, значит - если после старта в течение 2 минут (6*20 = 120 = 2 минуты) нагрузка будет превышать заданный лимит, то будет выдано уведомление

Значение по умолчанию: 3

StorageDomainMonitoring_InvalidMeasurementsCountForRepetitiveNotification

Определяет кол-во измеренных подряд превышений заданного лимита после отправки самого первого уведомления о превышении лимитов, при превышении которого будет выдано повторное сообщение.

Например: установлено значение 60, временной интервал проверки StorageDomainMonitoring_MetricsScrapePeriodSeconds задан 20, значит - после выдачи первого сообщения при сохранении нагрузки через 20 минут (60*20 = 1200c = 20 минут) будет выдано повторное сообщение. Если нагрузка будет сохраняться и дальше, то через 20 мин будет выдано ещё сообщение и т.д. Т.е. нагрузка должна сохраняться в течение заданного времени (в данном примере не менее 20 мин), иначе уведомление придет позже

Значение по умолчанию: 1080

Все вышеописанное применяется к каждой метрике отдельно.

Все настройки задаются через команду engine-config -s <параметр>=<значение> и далее systemctl restart ovirt-engine, после чего новые настройки незамедлительно вступают в силу.

Пример 1. Настройка оповещений
engine-config -s  StorageDomainMonitoring_MetricsScrapePeriodSeconds=10
engine-config -s  StorageDomainMonitoring_InvalidMeasurementsCountTolerationThreshold=2
engine-config -s  StorageDomainMonitoring_InvalidMeasurementsCountForRepetitiveNotification=10

Система запущена, установлена и подана нагрузка на ВМ.

Результаты:
  1. Первое уведомление о превышении заданных лимитов пришло через 20 секунд (нагрузка сохраняется);

  2. Повторное уведомление о превышении лимитов пришло через 100 секунд (нагрузка сохраняется);

  3. Следующее уведомление ожидаем придёт через 100 секунд при сохранении нагрузки;

  4. В случае если нагрузка прервалась и через некоторое время возобновилась и продолжалась не менее 100 секунд придет повторное уведомление.

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

2.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. Журнал создается каждый раз при выполнении команды. В имени файла указываются дата и время запуска, что позволяет создавать множество журналов.

2.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.

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

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

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

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

Таблица 4. Журналы SPICE для серверов SPICE гипервизора
Тип журнала Местонахождение журнала Чтобы изменить уровень журнала:

Сервер SPICE хоста/гипервизора

/var/log/libvirt/qemu/(guest_name).log

Выполните команду export SPICE_DEBUG_LEVEL=5 на хосте/гипервизоре до запуска гостевой машины. Парсинг этой переменной выполняет QEMU, и в случае запуска для всей системы будет напечатана отладочная информация обо всех виртуальных машинах в системе. Эту команду нужно запускать на каждом хосте в кластере. Эта команда работает только на уровне хоста/гипервизора, а не кластера.

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

Таблица 5. Журналы spice-vdagent для гостевых машин
Тип журнала Местонахождение журнала Чтобы изменить уровень журнала:

Гостевая машина Windows

C:\Windows\Temp\vdagent.log

C:\Windows\Temp\vdservice.log

Не применимо

Гостевая машина 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] [&#124; &amp; tee spice-vdagent.log]

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

Для клиентских машин Linux
  1. Включите отладку SPICE, выполнив команду remote-viewer с параметром --spice-debug. После появления запроса введите URL-адрес для подключения, например, spice://virtual_machine_IP:port.

    #  remote-viewer --spice-debug
  2. Чтобы запустить клиент SPICE с параметром отладки и передать ему файл .vv, загрузите файл console.vv и выполните команду remote-viewer с параметром --spice-debug и укажите полный путь к файлу console.vv.

    # remote-viewer --spice-debug __/path/to/__console.vv
Для клиентских машин Windows
  1. В virt-viewer версии 2.0-11.el7ev и более поздних установщик virt-viewer.msi устанавливает virt-viewer и debug-viewer.exe.

  2. Выполните команду remote-viewer с аргументом --spice-debug, указав ей путь к консоли:

    remote-viewer --spice-debug _path\to\console.vv_
  3. Чтобы просмотреть журналы, подключитесь к виртуальной машине, и вы увидите командную строку с запущенным GDB, которая печатает стандартный вывод и стандартную ошибку remote-viewer.

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

Файл журнала Описание

/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, включая информацию об ошибках импорта. UUID – это UUID импортированной виртуальной машины, а Date – дата и время начала импортирования.

/var/log/vdsm/supervdsm.log

Регистрирует в журнале задачи VDSM, которые выполнялись с разрешениями суперпользователя.

/var/log/vdsm/upgrade.log

VDSM использует этот файл журнала во время обновлений хостов для регистрации изменений конфигурации.

/var/log/vdsm/mom.log

Регистрирует действия менеджера избыточного выделения памяти VDSM.

2.5. Настройка журналирования на уровень отладки для служб zVirt

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

Таблица 6. Службы zVirt и пути к файлам 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, который нужно изменить, существует. Если необходимо, создайте его.

Порядок действий:
  1. Добавьте в файл sysconfig службы следующую строку:

    OVIRT_SERVICE_DEBUG=1
  2. Перезапустите службу:

    # systemctl restart <service>

Теперь для файла журнала sysconfig службы задан уровень отладки.

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

2.6. Основные файлы конфигурации для служб zVirt

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

Таблица 7. Службы zVirt и файлы конфигурации
Служба Путь к файлу 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

2.7. Настройка централизованного журналирования

2.7.1. Настройка zVirt для передачи сообщений о событиях системы в сторонний сервер журналирования.

Систему управления виртуализацией zVirt можно настроить на передачу сообщений о событиях в системе в централизованный сервер журналирования по стандартному протоколу syslog. zVirt позволяет настроить отправку сообщений как отдельных хостов, так и всех хостов отдельного кластера.

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

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

  1. Нажмите Ресурсы (Compute)  Кластеры (Clusters).

  2. При изменении настроек существующего:

    • Нажмите Имя (Name) кластера, который хотите настроить (откроется его расширенное описание) или просто выделите нужный кластер левой кнопкой мыши.

    • Нажмите Изменить (Edit).

    • В появившемся окне Изменить кластер (Edit Cluster) выберите закладку Журналирование (Logging).

  3. При создании нового:

    • Нажмите Новый (New).

    • В появившемся окне Новый кластер (New Cluster) выберите закладку Журналирование (Logging).

      cluster logging
  4. Отметьте флажком Определить адрес Syslog-сервера (Determine Syslog server address) и введите в ставшее доступным поле ввода IP-адрес сервера журналирования или его полное доменное имя. Через двоеточие - адрес порта, по которому работает сервер журналирования, если порт отличается от стандартного.

  5. При необходимости отметьте флажком Использовать TCP-соединение (Use TCP connection).

2.7.1.2. Настройка передачи сообщений о событиях системы в сторонний сервер журналирования для одного хоста виртуализации

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

  1. Нажмите Ресурсы (Compute)  Хосты (Hosts).

  2. При изменении настроек существующего:

    • Нажмите Имя (Name) хоста, который хотите настроить (откроется расширенное описание хоста) или просто выделите нужный хост левой кнопкой мыши.

    • Нажмите Изменить (Edit).

    • В появившемся окне Изменить хост (Edit Host) выберите закладку Журналирование (Logging).

  3. При создании нового:

    • Нажмите Новый (New).

    • В появившемся окне Новый хост (New Host) выберите закладку Журналирование (Logging). image::host-logging.png[role-center]

  4. Отметьте флажком Определить адрес Syslog-сервера (Determine Syslog server address) и введите в ставшее доступным поле ввода IP-адрес сервера журналирования или его полное доменное имя. Через двоеточие - адрес порта, по которому работает сервера журналирования, если порт отличается от стандартного.

  5. При необходимости отметьте флажком Использовать TCP-соединение (Use TCP connection).

2.7.2. Пример настройки

Приведён для справки, все настройки производятся из интерфейса zVirt.
2.7.2.1. Настройки хоста виртуализации

Файл /etc/rsyslog.d/10-cluster.conf:

# Модуль чтения из файла
module(load="imfile" mode="inotify")
# Шаблон отправляемой по сети строки
template (name="Longtag" type="string"
string="<%PRI%>%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag%%$.suffix%%msg:::sp-if-no-1st-sp%%msg%")

# Правило отправки сообщений о событиях на сервер
ruleset(name="sendLog") {
action(type="omfwd" Target="192.168.1.155" Port="514" protocol="tcp" Template="Longtag")
}

# Правило для извлечения части пути из имени файла
ruleset(name="appLogs") {
    set $.suffix=re_extract($!metadata!filename, "(.*)/([^/]*)", 0, 2, "app.log");
    call sendLog
}

# Задаем тестовый файл для отслеживания
input(type="imfile"
    file="/var/log/test/test.log"
    tag="test__"
    ruleset="appLogs"
    addMetadata="on")

# Задаем каталог для отслеживания
input(type="imfile"
    file="/var/log/tst/*.log"
    tag="tst__"
    ruleset="appLogs"
    addMetadata="on"
)
2.7.2.2. Настройка сервера журналирования (для ОС семейства RedHat Enterprise Linux).

Настройка с портами по умолчанию

  1. В конец файла /etc/rsyslog.conf внесите следующие изменения:

    # Provides TCP syslog reception
    # for parameters see http://www.rsyslog.com/doc/imtcp.html
    #module(load="imtcp") # needs to be done just once
    #input(type="imtcp" port="514")
    
    # Загружаем модуль udp
    module(load="imudp")
    input(type="imudp" port="514" ruleset="RemoteLogProcess")
    
    # Загружаем модуль tcp
    module(load="imtcp")
    input(type="imtcp" port="514" ruleset="RemoteLogProcess")
    
    # Шаблон для сохранения логов (/var/log/_ip_/_year-month-day_/_programname_with_catalog_)
    template(name="RemoteLogSavePath" type="list") {
        constant(value="/var/log/")
        property(name="fromhost-ip")
        constant(value="/")
        property(name="timegenerated" dateformat="year")
        constant(value="-")
        property(name="timegenerated" dateformat="month")
        constant(value="-")
        property(name="timegenerated" dateformat="day")
        constant(value="/")
        property(name="$.logpath")
    }
    
    # Шаблон для вывода только сообщения
    template(name="OnlyMsg" type="string" string="%msg:::drop-last-lf%\n")
    
    # Загружаем модуль записи в файл
    module(load="builtin:omfile"
        FileOwner="root"
        FileGroup="adm"
        dirOwner="root"
        dirgroup="adm"
        FileCreateMode="0640" DirCreateMode="0755")
    
    # Интерпретировать \n как перевод строки
    $EscapeControlCharactersOnReceive off
    
    # Правило для разбора приходящих логов
    ruleset(name="RemoteLogProcess") {
        if ( $syslogfacility >= 16 ) then
        {
            # Заменяем __ на /
            set $.logpath = replace($programname, "__", "/");
                # Сохранение в файл:
                # dynaFileCacheSize - максимальное количество открытых сгенерированных лог-файлов
            # dynaFile - правило для генерации имени лог-файла
            # template - шаблон записываемых сообщений
                # flushOnTXEnd - сброс буфера после приема сообщения
                # asyncWriting - асинхронная запись
            # flushInterval - время сброса буфера в секундах
                # ioBufferSize - размер буфера
                action(type="omfile" dynaFileCacheSize="1024" dynaFile="RemoteLogSavePath" template="OnlyMsg"
            flushOnTXEnd="off" asyncWriting="on" flushInterval="1" ioBufferSize="64k")
        } else {
                if (($syslogfacility == 0)) then {
                    set $.logpath = "kern";
            }
                else if (($syslogfacility == 4) or ($syslogfacility == 10)) then {
                    set $.logpath = "auth";
            }
                else if (($syslogfacility == 9) or ($syslogfacility == 15)) then {
                    set $.logpath = "cron";
            } else {
                    set $.logpath = "syslog";
            }
                action(type="omfile" dynaFileCacheSize="1024" dynaFile="RemoteLogSavePath" template="RSYSLOG_FileFormat"
                flushOnTXEnd="off" asyncWriting="on" flushInterval="1" ioBufferSize="64k")
        }
    }
    
    #### GLOBAL DIRECTIVES ####
    
    # Where to place auxiliary files
    global(workDirectory="/var/lib/rsyslog")
    
    # Use default timestamp format
    #module(load="builtin:omfile" Template="RSYSLOG_TraditionalFileFormat")
    
    # Include all config files in /etc/rsyslog.d/
    #include(file="/etc/rsyslog.d/*.conf" mode="optional")
  2. Добавьте разрешающие правила в firewalld (если установлен):

    firewall-cmd --add-port=514/tcp --permanent
    firewall-cmd --add-port=514/udp --permanent
    firewall-cmd --reload
    Если порт службы изменён на другой (описывается ниже), то его также следует добавить в разрешающие правила.
  3. Перезапустить службу rsyslog.service и проверить статус:

    systemctl restart rsyslog
    systemctl status rsyslog
  4. Сообщения будут сохранятся сервером согласно настроек шаблона:

    # Шаблон для сохранения логов (/var/log/_ip_/_year-month-day_/_programname_with_catalog_)
    template(name="RemoteLogSavePath" type="list") {
        constant(value="/var/log/")
        property(name="fromhost-ip")
        constant(value="/")
        property(name="timegenerated" dateformat="year")
        constant(value="-")
        property(name="timegenerated" dateformat="month")
        constant(value="-")
        property(name="timegenerated" dateformat="day")
        constant(value="/")
        property(name="$.logpath")
    }

В /var/log/ будут созданы каталоги с именем равным IP удалённого хоста, с которого собираются сообщения о событиях.

Смена порта, используемого службой сервера журналирования по умолчанию на другой:

Порядок действий:
  1. Убедитесь, что порт больше 1023 (порты от 0 до 1023 являются привилегированными и зарезервированными для своих служб).

  2. Проверьте список всех открытых портов:

    ss -lntu
  3. Если нужный порт не открыт, то добавьте его в разрешающие правила firewalld:

    firewall-cmd --add-port=<port>/tcp --permanent
    firewall-cmd --add-port=<port>/udp --permanent
    firewall-cmd --reload
  4. Поменяйте в конфигурационном файле /etc/rsyslog.conf порты на нужные в следующих строках:

    input(type="imudp" port="<port>" ruleset="RemoteLogProcess")
    ...
    input(type="imtcp" port="<port>" ruleset="RemoteLogProcess")
  5. Перезапустите rsyslog.service и проверьте статус.

    systemctl restart rsyslog
    systemctl status rsyslog

    При необходимости поменять порт, используемый по умолчанию на привилегированный (0-1023) необходимо:

    Не рекомендуется менять порт на привилегированный (0-1023), так как эти порты являются зарезервированными для соответствующих служб.
  6. Если нужный порт не открыт, то добавьте его в разрешающие правила firewalld:

    firewall-cmd --add-port=<port>/tcp --permanent
    firewall-cmd --add-port=<port>/udp --permanent
    firewall-cmd --reload
  7. Настройте SElinux:

    setsebool -P nis_enabled 1
    setcap 'cap_net_bind_service=+ep' /usr/sbin/rsyslogd (только для Centos 8 Stream)
    semanage port -a -t syslogd_port_t -p tcp <port>
    semanage port -a -t syslogd_port_t -p udp <port>
  8. Перезапустите rsyslog.service и проверьте статус.

    systemctl restart rsyslog
    systemctl status rsyslog

2.7.3. Отправка логов Engine

Данная функция доступна только в zVirt версии 3.2 или выше

Для локализации проблем в работе системы zVirt предоставляет возможность отправки журналов Engine для режима установки Hosted engine.

Для включения отправки журналов Engine на syslog-сервер выполните следующие действия.

Порядок действий:
  1. Нажмите Ресурсы (Compute)  Виртуальные машины (Virtual Machines)

  2. Выделите машину, на которой запущена ВМ HostedEngine и нажмите Изменить (Edit)

  3. В окне Изменить виртуальную машину (Edit virtual machine) Перейдите в раздел Журналирование (Logging)

  4. Отметьте флажком Определить адрес Syslog-сервера (Determine Syslog server address) и введите в ставшее доступным поле ввода IP-адрес сервера журналирования или его полное доменное имя. Через двоеточие - адрес порта, по которому работает сервер журналирования, если порт отличается от стандартного.

  5. Дополнительно: вместо протокола UDP для передачи журналов можно использовать протокол TCP. Для этого отметьте флажком Использовать TCP-соединение (Use TCP connection)

  6. Дополнительно: для обеспечения более безопасного взаимодействия с syslog-сервером можно включить шифрование. Для этого отметьте флажком Включить шифрование (Use TLS protocol)

2.7.4. Настройка использования шифрования

Данная функция доступна только в zVirt версии 3.2 или выше

Благодаря поддержке протокола SSL zVirt предоставляет возможность использовать более безопасное взаимодействие с внешним syslog хранилищем.

С помощью симметричного шифрования обеспечивается сохранность конфиденциальности, а коды аутентификации сообщений гарантируют целостность сообщений.

Функцию шифрования можно активировать с помощью опции Включить шифрование (Use TLS protocol) раздела Журналирование (Logging) для кластеров (окна Новый кластер (New Cluster) и Изменить кластер (Edit Cluster)), хостов (окна Новый хост (New Host) и Изменить хост (Edit Host)), а также для ВМ HostedEngine (окно Изменить виртуальную машину (Edit virtual machine)).

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

В качестве примера будет настроено шифрование для передачи журналов хоста.

  • ip сервера журналирования - 192.168.48.56

  • ip хоста - 192.168.40.29

  • zVirt установлен на машине 192.168.40.30.

Порядок действий:
  1. Настройте журналирование для хоста:

    1. Нажмите Ресурсы (Compute)  Хосты (Hosts)

    2. Выделите нужный хост левой кнопкой мыши и нажмите Изменить (Edit)

    3. В появившемся окне Изменить хост (Edit Host) выберите закладку Журналирование (Logging)

    4. Отметьте флажком Определить адрес Syslog-сервера (Determine Syslog server address) и введите в ставшее доступным поле ввода IP-адрес сервера журналирования или его полное доменное имя. Через двоеточие - адрес порта, по которому работает сервера журналирования, если порт отличается от стандартного.

    5. Отметьте флажком Использовать TCP-соединение (Use TCP connection)

    6. Отметьте флажком Включить шифрование (Use TLS protocol)

    7. Нажмите ОК

    logging
  2. После нажатия кнопки ОК происходит следующее:

    • Утилитой openssl на zVirt-машине (192.168.40.30) выполняется генерация и подписание сертификатов для хоста (192.168.40.29) и для сервера журналирования (192.168.48.56).

    • Сертификат для хоста (rslclient-192.168.40.29-cert.pem), ключ (rslclient-192.168.40.29-key.pem) и CA-сертификат (rsyslog-ca.pem) сохраняются в каталоге хоста /etc/pki/rsyslog.

    • Сертификат для сервера (rslserver-192.168.48.56-cert.pem), ключ (rslserver-192.168.48.56-key.pem) и CA-сертификат (rsyslog-ca.pem) сохраняются в архив (rslserver-192.168.48.56.tar.gz) в каталоге zVirt-машины /etc/pki/ovirt-engine/rsyslog.

  3. Содержимое полученного архива (rslserver-192.168.48.56.tar.gz) расположите в каталоге /etc/pki/rsyslog сервера журналирования. Например, так (команды выполняются на сервере журналирования от имени пользователя root):

    scp root@192.168.40.29:/etc/pki/ovirt-engine/rsyslog/rslserver-102.168.48.56.tar.gz /etc/pki/rsyslog
    cd /etc/pki/rsyslog
    tar xf rslserver-102.168.48.56.tar.gz

    Посмотреть свойства сертификата можно с помощью команды openssl:

    openssl x509 -text -noout -in rslserver-102.168.48.56-cert.pem
  4. Заполните конфигурационный файл (/etc/rsyslog.conf) следующим содержимым:

    # rsyslog configuration file
    
    # For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html
    # or latest version online at http://www.rsyslog.com/doc/rsyslog_conf.html
    # If you experience problems, see http://www.rsyslog.com/doc/troubleshoot.html
    
    #### MODULES ####
    
    module(load="imuxsock"    # provides support for local system logging (e.g. via logger command)
        SysSock.Use="off") # Turn off message reception via local log socket;
                # local messages are retrieved through imjournal now.
    module(load="imjournal"         # provides access to the systemd journal
        StateFile="imjournal.state") # File to store the position in the journal
    #module(load="imklog") # reads kernel messages (the same are read from journald)
    #module(load"immark") # provides --MARK-- message capability
    
    # Increase the amount of open files rsyslog is allowed, which includes open tcp sockets
    # This is important if there are many clients.
    # http://www.rsyslog.com/doc/rsconf1_maxopenfiles.html
    $MaxOpenFiles 2048
    
    # make gtls driver the default
    $DefaultNetstreamDriver gtls
    
    $DefaultNetstreamDriverCAFile /etc/pki/rsyslog/rsyslog-ca.pem
    $DefaultNetstreamDriverCertFile /etc/pki/rsyslog/rslserver-192.168.48.56-cert.pem
    $DefaultNetstreamDriverKeyFile /etc/pki/rsyslog/rslserver-192.168.48.56-key.pem
    
    # Provides UDP syslog reception
    # for parameters see http://www.rsyslog.com/doc/imudp.html
    module(load="imudp") # needs to be done just once
    input(type="imudp" port="514" ruleset="RemoteLogProcess")
    
    # Provides TCP syslog reception
    # for parameters see http://www.rsyslog.com/doc/imtcp.html
    module(load="imtcp"
        MaxSessions="2000"
        StreamDriver.mode="1"
        StreamDriver.authmode="x509/name"
        PermittedPeer="192.168.40.29" # list ip/fqdn
        ) # needs to be done just once
    input(type="imtcp" port="514" ruleset="RemoteLogProcess")
    
    # Шаблон для сохранения логов (/var/log/_ip_/_year-month-day_/_programname_with_catalog_)
    template(name="RemoteLogSavePath" type="list") {
        constant(value="/var/log/")
        property(name="fromhost-ip")
        constant(value="/")
        property(name="timegenerated" dateformat="year")
        constant(value="-")
        property(name="timegenerated" dateformat="month")
        constant(value="-")
        property(name="timegenerated" dateformat="day")
        constant(value="/")
        property(name="$.logpath")
    }
    
    # Шаблон для вывода только сообщения
    template(name="OnlyMsg" type="string" string="%msg:::drop-last-lf%\n")
    
    # Загружаем модуль записи в файл
    module(load="builtin:omfile"
        FileOwner="root"
        FileGroup="adm"
        dirOwner="root"
        dirgroup="adm"
        FileCreateMode="0640" DirCreateMode="0755")
    
    # Интерпретировать \n как перевод строки
    $EscapeControlCharactersOnReceive off
    
    # Правило для разбора приходящих логов
    ruleset(name="RemoteLogProcess") {
        if ( $syslogfacility >= 16 ) then
        {
            # Заменяем __ на /
            set $.logpath = replace($programname, "__", "/");
            # Сохранение в файл:
            # dynaFileCacheSize - максимальное количество открытых сгенерированных лог-файлов
            # dynaFile - правило для генерации имени лог-файла
            # template - шаблон записываемых сообщений
            # flushOnTXEnd - сброс буфера после приема сообщения
            # asyncWriting - асинхронная запись
            # flushInterval - время сброса буфера в секундах
            # ioBufferSize - размер буфера
            action(type="omfile" dynaFileCacheSize="1024" dynaFile="RemoteLogSavePath" template="OnlyMsg"
            flushOnTXEnd="off" asyncWriting="on" flushInterval="1" ioBufferSize="64k")
        } else {
            if (($syslogfacility == 0)) then {
                set $.logpath = "kern";
            }
            else if (($syslogfacility == 4) or ($syslogfacility == 10)) then {
                set $.logpath = "auth";
            }
            else if (($syslogfacility == 9) or ($syslogfacility == 15)) then {
                set $.logpath = "cron";
            } else {
                set $.logpath = "syslog";
            }
            action(type="omfile" dynaFileCacheSize="1024" dynaFile="RemoteLogSavePath" template="RSYSLOG_FileFormat"
            flushOnTXEnd="off" asyncWriting="on" flushInterval="1" ioBufferSize="64k")
        }
    }
    
    #### GLOBAL DIRECTIVES ####
    
    # Where to place auxiliary files
    global(workDirectory="/var/lib/rsyslog")
    
    # Use default timestamp format
    #module(load="builtin:omfile" Template="RSYSLOG_TraditionalFileFormat")
    
    # Include all config files in /etc/rsyslog.d/
    include(file="/etc/rsyslog.d/*.conf" mode="optional")
    
    #### RULES ####
    
    # Log all kernel messages to the console.
    # Logging much else clutters up the screen.
    #kern.*                                                 /dev/console
    
    # Log anything (except mail) of level info or higher.
    # Don't log private authentication messages!
    *.info;mail.none;authpriv.none;cron.none                /var/log/messages
    
    # The authpriv file has restricted access.
    authpriv.*                                              /var/log/secure
    
    # Log all the mail messages in one place.
    mail.*                                                  -/var/log/maillog
    
    
    # Log cron stuff
    cron.*                                                  /var/log/cron
    
    # Everybody gets emergency messages
    *.emerg                                                 :omusrmsg:*
    
    # Save news errors of level crit and higher in a special file.
    uucp,news.crit                                          /var/log/spooler
    
    # Save boot messages also to boot.log
    local7.*                                                /var/log/boot.log
    
    global(debug.gnutls="10" debug.logFile="/var/log/rsyslogdebug.log")

    Опция $DefaultNetstreamDriverCAFile указывает на главный сертификат (rsyslog-ca.pem).

    Опция $DefaultNetstreamDriverCertFile указывает на сертификат для сервера (rslserver-102.168.48.56-cert.pem).

    Опция $DefaultNetstreamDriverKeyFile указывает на ключ для сервера(rslserver-102.168.48.56-key.pem).

    Опция PermittedPeer перечисляет разрешенные хосты для приема логов (192.168.40.29).

  5. Перезапустите сервис rsyslog.

    systemctl restart rsyslog.service

Новые логи будут появляться на сервере журналирования в каталоге /var/log/192.168.40.29/