Журналы и аудит региона¶

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

Файлы журналов сервисов — сообщения о работе сервисов, запросах и ошибках. Доступны в OpenSearch и в файлах журналов соответствующего сервиса.
События аудита CADF — записи о действиях пользователей и результатах их выполнения. Доступны в OpenSearch и в разделе Аудит действий (CADF) Портала администратора.
Стандартные потоки контейнеров — вывод процессов контейнера в stdout и stderr. Для просмотра используются команды движка контейнеров. При наличии драйвера journald записи также доступны в системном журнале.

Fluentd собирает настроенные источники журналов и отправляет записи в OpenSearch. События CADF поступают в Fluentd из RabbitMQ с тегом infra.cadf. Фильтр Fluentd разбирает вложенное JSON-сообщение перед отправкой в хранилище. Внешние получатели подключаются отдельно.

Первичное включение сбора журналов и аудита описано в статье Настройка мониторинга и аудита региона. Журналы LCM настраиваются отдельно — см. Отправка событий аудита во внешние системы.

Просмотр журналов¶

Поиск в OpenSearch¶

На Портале администратора откройте Журналы событий > Анализ логов. Доступ зависит от назначенной роли; см. Ролевая модель на Портале администратора.

Для поиска по журналам используется шаблон индексов OpenSearch Dashboards. Если он ещё не создан, выполните настройку шаблона. При стандартном префиксе индексов выберите flog-* и поле времени @timestamp. Создание шаблона определяет, какие данные отображаются в Dashboards, и не настраивает их отправку из Fluentd.

Вкладка Логи в карточке гипервизора также показывает записи из OpenSearch. Подробнее см. в разделе Вкладка Логи.

Просмотр событий аудита CADF¶

На Портале администратора откройте Журналы событий > Аудит действий (CADF). Раздел показывает события аудита, сохранённые в OpenSearch. Для поиска укажите период и фильтры по действию, инициатору или результату.

Описание полей событий и фильтров приведено в следующей статье:

CADF-события на Портале администратора

Файлы журналов сервисов¶

Журналы сервисов записываются в файлы каталога /var/log/kolla/<служба>/ в контейнерах и собираются Fluentd в OpenSearch. Расположение файлов и типы узлов, на которых работают сервисы, приведены в статье Файлы журналов компонентов платформы.

Вывод работающих контейнеров¶

Отдельно от файлов журналов сервисов существует вывод контейнера в стандартные потоки stdout и stderr. Его хранит движок контейнеров. Настройки драйверов и ограничения объёма этого вывода не влияют на содержимое /var/log/kolla/.

При использовании файловых драйверов k8s-file для Podman и json-file для Docker вывод хранится в файлах. Для стандартных каталогов хранения используются следующие пути:

Движок контейнеров	Расположение файла	Чем ограничивается объём
Podman	`/var/lib/containers/storage/overlay-containers/<идентификатор контейнера>/userdata/ctr.log`	Параметр `podman_log_max_size`, см. Ограничения хранения вывода контейнеров
Docker	`/var/lib/docker/containers/<идентификатор контейнера>/<идентификатор контейнера>-json.log`	Файл `/etc/docker/daemon.json`, параметры `max-size` и `max-file`

Чтобы просмотреть вывод контейнера на узле, где он работает, выполните команду:

# {docker|podman} logs <имя контейнера>

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

Вывод одноразовых контейнеров¶

Одноразовые контейнеры — начальной настройки службы (bootstrap), синхронизации схемы базы данных, миграции данных — могут удаляться сразу после завершения работы вместе со своим файлом лога. Команда podman logs для удалённого контейнера недоступна. Поэтому их вывод по умолчанию направляется в системный журнал journald, где сохраняется и после удаления контейнера.

Например, чтобы просмотреть вывод контейнера bootstrap_glance, выполните на узле, где он запускался, команду:

# journalctl CONTAINER_NAME=bootstrap_glance

Имена таких контейнеров соответствуют выполняемой операции, например bootstrap_glance, bootstrap_neutron или nova_list_cells. Пример вывода:

Sep 17 08:34:47 ctrl-01 80a2635f7b3f[19696]: 2026-09-17 08:34:47.534 INFO glance.db.sqlalchemy.metadata [-] Metadata loaded
Sep 17 08:34:47 ctrl-01 80a2635f7b3f[19696]: +++ exit 0

Доступность записей зависит от настроек хранения и ограничения частоты сообщений в journald. Драйвер одноразовых контейнеров задаётся отдельно — см. Драйверы логов контейнеров.

Управление уведомлениями о событиях аутентификации в Keystone¶

По умолчанию Keystone не отправляет сообщения об успешной аутентификации пользователя и процессе аутентификации, так как из-за большого количества этих событий уведомления могут засорять логи. Отключаются следующие типы уведомлений: identity.authenticate.success (успешная аутентификация); identity.authenticate.pending (процесс аутентификации).

Настроить отправку уведомлений по типам событий можно через конфигурационный файл keystone.conf. Для этого необходимо задать в файле параметр notification_opt_out, который отключает отправку уведомлений по указанным типам событий. К примеру, можно настроить конфигурацию таким образом, чтобы отключались только уведомления о pending-событиях аутентификации, а уведомления об успешных и неуспешных попытках аутентификации отправлялись.

Для передачи уведомлений в тему notifications должен быть включён параметр keystone_default_notifications_topic_enabled. Порядок включения приведён в инструкции по настройке мониторинга и аудита.

Чтобы настроить конфигурацию:

Откройте веб-интерфейс развёрнутого GitLab.
Перейдите в репозиторий project_k / deployments / <имя региона>.
Перейдите в директорию config. Если такой директории нет, создайте её.
Откройте файл keystone.conf или создайте его. Добавьте в файл следующие строки:
[DEFAULT] notification_opt_out = identity.authenticate.pending
Данная конфигурация отключит только уведомления о процессе аутентификации.
Сохраните изменения в репозитории региона.
Создайте новый пайплайн: Build > Pipelines > New Pipeline.
Оставьте ветку по умолчанию, соответствующую установленному релизу.
В открывшемся окне добавьте параметры:
- KOLLA_ANSIBLE_DEPLOY_ACTION — deploy;
- KOLLA_ARGS — -t keystone.
Запустите пайплайн New pipeline.
Дождитесь успешного выполнения задачи setup, а затем запустите задачу deploy.
Дождитесь завершения выполнения задачи.

Хранение и ротация¶

Файлы журналов сервисов, вывод контейнеров и индексы OpenSearch имеют отдельные настройки хранения. Изменение ротации файлов не ограничивает размер индексов или системного журнала.

Ротация файлов журналов сервисов¶

В KeyStack реализована ротация файлов журналов сервисов с помощью утилиты logrotate, запускаемой из контейнера cron. Для ротируемых журналов используются следующие параметры ротации:

cron_logrotate_log_maxsize — размер файла, при превышении которого ротация выполняется независимо от интервала. По умолчанию — 100M.
cron_logrotate_log_minsize — минимальный размер файла для ротации по заданному интервалу. По умолчанию — 30M.
cron_logrotate_rotation_interval — интервал ротации. По умолчанию — weekly (раз в неделю).
cron_logrotate_rotation_count — количество ротированных файлов для хранения. По умолчанию — 6.
cron_logrotate_schedule — частота запуска logrotate. По умолчанию — daily (ежедневно).

Размер проверяется при очередном запуске logrotate. Значение maxsize не задаёт жёсткий предел: между запусками файл может стать больше указанного размера.

Для просмотра действующих правил и списка ротируемых журналов откройте на узле региона файл /etc/kolla/cron/logrotate.conf.

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

Откройте веб-интерфейс развёрнутого GitLab.
Перейдите в репозиторий project_k / deployments / <имя региона>.

Откройте файл globals.d/REGION.yml и измените или добавьте переменные:

cron_logrotate_log_maxsize: "100M"
cron_logrotate_log_minsize: "30M"
cron_logrotate_rotation_interval: "weekly"
cron_logrotate_rotation_count: 6
cron_logrotate_schedule: "daily"

Сохраните изменения в репозитории региона.
Создайте новый пайплайн: Build > Pipelines > New Pipeline.
Оставьте ветку по умолчанию, соответствующую установленному релизу.
Добавьте переменные:
- KOLLA_ANSIBLE_DEPLOY_ACTION — deploy;
- KOLLA_ARGS — -t common.
Запустите пайплайн New pipeline.
Дождитесь успешного выполнения задачи setup, а затем запустите задачу deploy.
Дождитесь завершения выполнения задачи.

Ротация logrotate охватывает только файлы журналов сервисов. Объём вывода контейнеров в stdout и stderr ограничивается отдельно, см. Ограничения хранения вывода контейнеров.

Драйверы логов контейнеров¶

Параметр	По умолчанию	Допустимые значения	Описание
`container_log_driver`	`k8s-file`	`k8s-file`, `journald`, `none`, `passthrough`	Драйвер логов постоянно работающих контейнеров. Действует только при `kolla_container_engine: podman`: Docker берёт драйвер и параметры хранения из файла `/etc/docker/daemon.json`.
`container_log_driver_oneshot`	`journald`	`journald`, `none`, а также `k8s-file` для Podman и `json-file` для Docker	Драйвер логов одноразовых контейнеров. Только значение `journald` позволяет выводу пережить удаление контейнера.

Изменение параметра container_log_driver меняет описание systemd-юнитов контейнеров Podman. При применении настройки затронутые контейнеры будут перезапущены. Параллельный перезапуск экземпляров одного сервиса на нескольких узлах может привести к временной недоступности этого сервиса, поэтому изменение рекомендуется применять поочерёдно: по одному узлу за раз.

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

Откройте веб-интерфейс развёрнутого GitLab.
Перейдите в репозиторий project_k / deployments / <имя региона>.
Откройте файл globals.d/REGION.yml и измените или добавьте переменные:
container_log_driver: "k8s-file" container_log_driver_oneshot: "journald"
Сохраните изменения в репозитории региона.
Создайте новый пайплайн: Build > Pipelines > New Pipeline.
Оставьте ветку по умолчанию, соответствующую установленному релизу.
В открывшемся окне добавьте параметры:
- KOLLA_ANSIBLE_DEPLOY_ACTION — deploy;
- KOLLA_ARGS — --limit <имя узла>, чтобы применить изменение к одному узлу.
Запустите пайплайн New pipeline.
Дождитесь успешного выполнения задачи setup, а затем запустите задачу deploy.
Дождитесь завершения выполнения задачи.
Повторите процедуру для остальных узлов региона.

Ограничения хранения вывода контейнеров¶

Для Podman настраиваются размер файла вывода каждого контейнера, уровень логирования службы Podman API и ограничения системного журнала journald на узле. Настройки journald распространяются на весь системный журнал, включая вывод одноразовых контейнеров.

Параметры задаются в файле globals.d/REGION.yml, но применяются задачей bootstrap-servers, а не задачей deploy.

При стандартном драйвере k8s-file вывод постоянно работающих контейнеров не попадает в системный журнал. В него пишут systemd, ядро, служба Podman API и одноразовые контейнеры. Если для постоянно работающих контейнеров выбран драйвер journald, их вывод также сохраняется в системном журнале.

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

Примечание

При использовании Docker параметры Podman из этой инструкции не применяются. Для файлового драйвера Docker параметры хранения max-size и max-file задаются в файле /etc/docker/daemon.json.

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

Откройте веб-интерфейс развёрнутого GitLab.
Перейдите в репозиторий project_k / deployments / <имя региона>.

Откройте файл globals.d/REGION.yml и измените или добавьте нужные параметры. Например:

# Предельный размер файла вывода контейнера при драйвере k8s-file, в байтах.
# По умолчанию — 10485760 (10 МиБ).
# Podman обрезает файл на месте, ротированные копии не создаются.
podman_log_max_size: 10485760

# Уровень логирования службы Podman API. По умолчанию — warn.
# При значении info в журнал попадает каждый запрос экспортёров к API.
podman_api_log_level: "warn"

# Пример ограничений системного журнала journald на узле.
podman_journald_config:
  # Лимит объёма постоянных журналов в /var/log/journal.
  SystemMaxUse: "1G"
  # Лимит объёма временных журналов в /run/log/journal.
  RuntimeMaxUse: "256M"
  # Срок хранения журналов.
  MaxRetentionSec: "1week"
  # Интервал для ограничения частоты сообщений каждой службы.
  RateLimitIntervalSec: "30s"
  # Базовый порог количества сообщений одной службы за этот интервал.
  RateLimitBurst: "10000"

Сохраните изменения в репозитории региона.
Создайте новый пайплайн: Build > Pipelines > New Pipeline.
Оставьте ветку по умолчанию, соответствующую установленному релизу.
Запустите пайплайн New pipeline.
Дождитесь успешного выполнения задачи setup, а затем запустите задачу bootstrap-servers.
Дождитесь завершения выполнения задачи.

Хранение индексов OpenSearch¶

Политика хранения индексов OpenSearch описана в разделе Настройка глубины хранения индексов в OpenSearch.

Отправка во внешние системы¶

Отправка событий аудита CADF во внешний syslog-приёмник¶

Для отправки событий аудита CADF во внешний приёмник в формате syslog используется плагин fluent-plugin-remote_syslog сервиса Fluentd.

Перед настройкой убедитесь, что в регионе включён аудит CADF. Порядок включения приведён в разделе Включение мониторинга и аудита.

Для настройки отправки событий аудита во внешний приёмник:

Откройте веб-интерфейс GitLab.
Перейдите в репозиторий региона project_k / deployments / <имя региона>.
Создайте файл config/fluentd/output/01-cadf-export-syslog.conf, если он ещё не создан. При необходимости создайте недостающие каталоги. Добавьте в файл следующую конфигурацию:
<match infra.cadf> @type copy <store> @type remote_syslog host RSYSLOG_IP_ADDRESS port RSYSLOG_PORT protocol udp packet_size 8000 </store> <store> @type rewrite_tag_filter <rule> key Logger pattern /^infra\.cadf$/ tag infra.cadf.export </rule> </store> </match>
Где:
- RSYSLOG_IP_ADDRESS — IP-адрес внешнего приёмника событий аудита;
- RSYSLOG_PORT — порт приёмника;
- protocol udp — протокол передачи данных;
- packet_size 8000 — ограничение размера syslog-пакета в байтах.
События CADF будут отправляться во внешний syslog-приёмник, при этом продолжая поступать в OpenSearch. События останутся доступны в разделе Журналы событий > Аудит действий (CADF) Портала администратора.
Сохраните изменения в репозитории региона.
Создайте новый пайплайн: Build > Pipelines > New Pipeline.
Оставьте ветку по умолчанию, соответствующую установленному релизу.
В открывшемся окне добавьте параметры:
- KOLLA_ANSIBLE_DEPLOY_ACTION — deploy;
- KOLLA_ARGS — -t common.
Запустите пайплайн New pipeline.
Дождитесь успешного выполнения задачи setup, а затем запустите задачу deploy.
Дождитесь завершения выполнения задачи.
Проверьте поступление новых событий аудита на стороне syslog-приёмника.

Отправка в дополнительный OpenSearch¶

Принципы отправки журналов в дополнительное хранилище OpenSearch описаны в разделе Добавление нового output для сборщика логов.