Логирование

Лог событий аудита

На Портале администратора можно отслеживать все события, которые произошли в системе. Для этого перейдите в раздел Журналы событий > Аудит действий (CADF).

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

Ротация консольных логов

В KeyStack реализована ротация консольных логов на уровне хостовых систем с помощью logrotate из контейнера cron c общими для всех ротируемых логов параметрами.

Расписание по умолчанию:

# Максимальный размер файла лога
cron_logrotate_log_maxsize: "100M"
# Минимальный размер файла лога
cron_logrotate_log_minsize: "30M"
# Периодичность проведения операции ротации
cron_logrotate_rotation_interval: "weekly"
# Количество ротированных файлов для хранения
cron_logrotate_rotation_count: 6
# Расписание запуска ротации
cron_logrotate_schedule: "daily"

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

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

  1. Откройте веб-интерфейс GitLab.

  2. Перейдите в репозиторий региона project_k / deployments / <имя региона>.

  3. Откройте файл 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"

  4. Создайте новый пайплайн: Build > Pipelines > New Pipeline.

  5. Оставьте ветку по умолчанию, соответствующую установленному релизу.

  6. В открывшемся окне добавьте значение переменной KOLLA_ARGS равное -t common.

  7. Запустите пайплайн, нажав кнопку New pipeline.

  8. Дождитесь завершения задач на этапе setup.

  9. Запустите задачу deploy на этапе deploy и дождитесь её завершения.

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

Логи контейнеров

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

Параметры разделены на две группы: драйверы логов применяются развёртыванием, а ограничения объёма — задачей bootstrap-servers.

Примечание

Если вы используете docker, замените podman на 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

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

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

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

Вывод контейнера доступен и на Портале администратора: кнопка Podman Logs в карточке контейнера (см. Команды служб Docker/Podman), а также вкладка Логи в карточке гипервизора (см. Вкладка Логи).

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

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

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

# 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

Драйвер логов для одноразовых контейнеров задаётся отдельным параметром, см. Драйверы логов контейнеров.

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

Параметр

По умолчанию

Допустимые значения

Описание

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-юнита контейнера, поэтому все контейнеры на узле будут пересозданы. В регионе с несколькими управляющими узлами применяйте изменение поочерёдно, по одному узлу за раз.

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

  1. Откройте веб-интерфейс GitLab.

  2. Перейдите в репозиторий региона project_k / deployments / <имя региона>.

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

    container_log_driver: "k8s-file"
container_log_driver_oneshot: "journald"

  4. Создайте новый пайплайн: Build > Pipelines > New Pipeline.

  5. Оставьте ветку по умолчанию, соответствующую установленному релизу.

  6. В открывшемся окне добавьте значение переменной KOLLA_ARGS равное --limit <имя узла>, чтобы применить изменение к одному узлу.

  7. Запустите пайплайн, нажав кнопку New pipeline.

  8. Дождитесь завершения задач на этапе setup.

  9. Запустите задачу deploy на этапе deploy и дождитесь её завершения.

  10. Повторите процедуру для остальных узлов региона.

Ограничение объёма логов

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

Параметр

По умолчанию

Описание

podman_log_max_size

10485760

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

podman_api_log_level

warn

Уровень логирования службы podman API. При значении info в системный журнал попадает каждый запрос экспортёров, опрашивающих сокет.

podman_journald_config

См. пример ниже

Ограничения системного журнала на узле.

Вывод постоянно работающих контейнеров в системный журнал больше не попадает, однако в него пишут systemd, ядро, служба podman API и одноразовые контейнеры. Ограничение частоты защищает системные сообщения от вытеснения:

podman_journald_config:
  SystemMaxUse: "1G"
  RuntimeMaxUse: "256M"
  MaxRetentionSec: "1week"
  RateLimitIntervalSec: "30s"
  RateLimitBurst: "10000"

Примечание

При использовании docker перечисленные параметры не применяются: параметры хранения задаются в файле /etc/docker/daemon.json.

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

  1. Откройте веб-интерфейс GitLab.

  2. Перейдите в репозиторий региона project_k / deployments / <имя региона>.

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

  4. Создайте новый пайплайн: Build > Pipelines > New Pipeline.

  5. Оставьте ветку по умолчанию, соответствующую установленному релизу.

  6. Запустите пайплайн, нажав кнопку New pipeline.

  7. Дождитесь завершения задач на этапе setup.

  8. Запустите задачу bootstrap-servers и дождитесь её завершения.

Настройка дополнительного приемника журналов KeyStack в формате syslog

Для вывода логов в удалённый сервис системного журнала (syslog) используется fluent-plugin-remote_syslog — плагин Fluentd.

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

  1. В репозитории региона project_k / deployments / <имя региона> создайте файл config/fluentd/output/fluent-plugin-remote_syslog.conf со следующим содержанием:

    <match **>
  @type remote_syslog
  host <remote_syslog_IP_address>
  port 514
  protocol tcp
</match>

    • Параметры:

      • [match **] — регулярное выражение соответствия «всем» логам;

      • [host <remote_syslog_IP_address>] — ip-адрес (fqdn) сервиса syslog;

      • [port 514] — порт прослушивания сервиса syslog;

      • [protocol tcp] — протокол передачи данных.

  2. После развёртывания kolla-ansible конфигурационный файл td-agent.conf контейнера fluentd будет содержать следующие данные:

    # Outputs
# Included from conf/output/00-local.conf.j2:

# Included from /etc/kolla/config/fluentd/output/fluent-plugin-remote_syslog.conf:
<match **>
  @type remote_syslog
  host 10.120.120.125
  port 514
  protocol tcp
</match>

Пример возможной конфигурации плагина fluent-plugin-remote_syslog с секциями

<match foo.bar>
  @type remote_syslog
    host example.com
    port 514
    severity debug
    program fluentd
    hostname ${tag[1]}

    <buffer tag>
    </buffer>

    <format>
      @type single_value
      message_key message
    </format>
</match>

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

Название

Тип

Поддержка заполнения

Описание

hostname

string

support

Отправление журнала.

host

string

support

Системный журнал целевого узла.

port

integer (default: 514)

Системный журнал целевого порта.

host_with_port

string

support

Параметр для: style.

facility

string (default: "user")

support

Системный журнал объекта.

severity

string (default: "notice")

support

Системный журнал приоритетов.

program

string (default: "fluentd")

support

Системный журнал название программ.

protocol

enum (udp, tcp) (default: udp)

Протокол передачи данных.

tls

bool (default: false)

Использование TLS (только tcp).

ca_file

string

Путь к файлу ca_file (только для режима tls).

verify_mode

integer

SSL режим проверки (только для режима tls).

packet_size

integer (default: 1024)

Ограничение размера пакета системного журнала.

timeout

integer

Время ожидания передачи по протоколу TCP. Если значение равно 0, ожидайте вечно.

timeout_exception

bool (default: false)

Если значение равно true, вызовите исключение по тайм-ауту передачи.

keep_alive

bool (default: false)

Использование TCP для поддержания работоспособности.

keep_alive_idle

integer

Установите режим ожидания TCP для поддержания работоспособности во время простоя.

keep_alive_cnt

integer

Установите объём измерения TCP для поддержания работоспособности.

keep_alive_intvl

integer

Установите интервал измерения TCP для поддержания работоспособности.

Конфигурационные параметры для секции buffer

Название

По умолчанию

flush_mode

interval

flush_interval

5

flush_thread_interval

0.5

flush_thread_burst_interval

0.5

Конфигурационные параметры для секции format

Название

По умолчанию

@type

ltsv