Инструменты пользователя

Инструменты сайта


manual_security_server_messagelog

Различия

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

Ссылка на это сравнение

Предыдущая версия справа и слева Предыдущая версия
Следующая версия
Предыдущая версия
manual_security_server_messagelog [2023/05/05 11:00]
infra
manual_security_server_messagelog [2023/08/18 05:46] (текущий)
infra
Строка 1: Строка 1:
 +
 +<note warning>​Целевой аудиторией данного руководства являются системные администраторы Сервера безопасности Тундук ответственные за установку и сопровождение программного обеспечения X-Road. Документ предназначен для читателей с умеренными знаниями администрирования Linux серверов и компьютерных сетей.</​note>​
 +
 +
 +<note tip>​Все команды выполняются от пользователя root в консоле,​ либо от пользователя postgres.</​note>​
 +
 +
 ====== Мануал по администрированию messagelog на сервере безопасности ====== ====== Мануал по администрированию messagelog на сервере безопасности ======
  
Строка 9: Строка 16:
 Архивация журналов сообщений состоит из 4 последовательных процессов,​ которые запускаются с настроенными интервалами:​ Архивация журналов сообщений состоит из 4 последовательных процессов,​ которые запускаются с настроенными интервалами:​
  
 +  - Архивирование записей из таблицы базы данных в zip-пакеты
 +  - Очистка или удаление записей из таблицы базы данных
 +  - Перенос архивных пакетов (по запросу)
 +  - Освобождение пустого места в базе данных,​ которое не было освобождено
 +
 +Первый шаг — собрать записи из таблицы журнала сообщений базы данных с отметкой времени и упаковать их в zip-файл,​ а также добавить примечание к каждой заархивированной записи в таблице базы данных,​ что запись была заархивирована.
 +После архивации активируется очистка таблицы для удаления из таблицы всех записей старше 30 дней (по умолчанию) и имеющих пометку о том, что они уже были заархивированы.
 +Если вы хотите перенести архивные пакеты на другую машину или диск, вы можете использовать вспомогательный сценарий,​ который использует протокол HTTP/HTTPS для передачи пакетов,​ или любое другое удобно для вас копирование,​ будь то scp и тд.
 +Последним шагом является освобождение незанятого места в БД (VACUUM), которое осуществляется самой БД в фоновом режиме. Освобождение пустого пространства — это последний шаг, освобождающий пространство,​ используемое для хранения данных.
 +
 +=====Конфигурации и параметры журнала сообщений=====
 +
 +Конфигурации архивирования журнала сообщений по умолчанию находятся в файле /​etc/​xroad/​conf.d/​addons/​message-log.ini.
 +Если размер вашей базы данных стал слишком большим,​ обычно первая причина заключается в том, что настройки по умолчанию не подходят.
 +Если вы хотите или вам необходимо изменить настройки по умолчанию,​ вы можете сделать это в файле /​etc/​xroad/​conf.d/​local.ini,​ который игнорирует настройки по умолчанию.
 +
 +Архивация журнала сообщений,​ очистка и перенос архивных пакетов,​ запускаются инструментом cron.
 +  * По умолчанию журналы сообщений старше 30 дней очищаются из базы данных.
 +  * По умолчанию интервал архивации равен 0 0 0/6 1/1 * ? *, что означает,​ что архивация запускается каждые 6 часов, начиная с начала суток или 00.00 (12 часов ночи).
 +  * По умолчанию интервал очистки равен 0 0 0/12 1/1 * ? *, что означает,​ что уборка запускается каждые 12 часов, начиная с начала суток или 00.00 (00:00).
 +
 +Существуют различные параметры для настройки архивации журнала сообщений,​ с помощью которых можно настроить архивацию в соответствии с потребностями вашего сервера безопасности:​
 +
 +  * keep-records-for – период в днях, в течение которого архивные журналы сообщений хранятся на сервере безопасности. По умолчанию это 30 дней.
 +  * archive-max-filesize – максимальный размер пакета архива журнала сообщений в байтах. По умолчанию это 32 МБ или 33 554 432 байта.
 +  * archive-interval - интервал архивации,​ используемый инструментом Cron для запуска процесса архивации журналов сообщений. По умолчанию каждые 6 часов.
 +  * archive-path – каталог,​ в который помещаются заархивированные пакеты журналов сообщений. По умолчанию это /​var/​lib/​xroad/​.
 +  * clean-interval – интервал очистки базы данных,​ используемый средством Cron для запуска журналов очистки сообщений в таблице logrecords базы данных. По умолчанию это каждые 12 часов.
 +  * archive-transfer-command – команда для передачи архивных журналов сообщений,​ запускаемая в конце процесса архивации. По умолчанию эта функция не включена.
 +  * archive-transaction-batch – максимальное количество журналов сообщений с отметкой времени одновременно. По умолчанию это 10 000.
 +
 +Больше информации - https://​github.com/​nordic-institute/​X-Road/​blob/​develop/​doc/​Manuals/​ug-syspar_x-road_v6_system_parameters.md#​37-message-log-add-on-parameters-message-log
 +
 +=====Перенос заархивированных пакетов=====
 +
 +Есть скрипт,​ который помогает переносить заархивированные пакеты на другую машину или диск.
 +
 +<​code>​
 +/​usr/​share/​xroad/​scripts/​archive-http-transporter.sh
 +</​code>​
 +
 +Для этого в файл конфигурации журнала сообщений /​etc/​xroad/​conf.d/​local.ini необходимо добавить следующий параметр:​
 +
 +<​code>​
 +archive-transfer-command=/​usr/​share/​xroad/​scripts/​archive-http-transporter.sh -r http://​my-archiving-server/​cgi-bin/​upload
 +</​code>​
 +
 +Этот скрипт использует протокол HTTP/HTTPS и позволяет переносить заархивированные пакеты,​ например,​ на отдельную машину для архивации. С помощью команды -r архивные пакеты журнала сообщений,​ которые уже были переданы с сервера безопасности,​ удаляются,​ чтобы освободить место на диске.
 +
 +Вы можете найти больше информации о передаче архивных пакетов и использовании флагов здесь:
 +https://​www.x-tee.ee/​docs/​live/​xroad/​ug-ss_x-road_7_security_server_user_guide.html#​112-transferring-the-archive-files-from-the-security-server
 +
 +=====Журналы сообщений с отметками времени и их изучение в базе данных=====
 +
 +Все журналы сообщений помещаются на сервер безопасности в журнал сообщений базы данных Postgres. По умолчанию отметка времени добавляется к 10 000 журналов сообщений каждые 48 минут. Если журналы сообщений имеют отметку времени,​ их можно заархивировать. Если существует более 10 000 журналов новых сообщений без метки времени,​ они останутся без метки времени,​ и метка времени будет добавлена к ним во время следующей штамповки времени в порядке приоритета.
 +
 +Все записи журнала сообщений на сервере безопасности находятся в таблице logrecord базы данных.
 +Чтобы получить доступ к таблице,​ необходимо войти в базу данных postgres с пользователем messagelog.
 +Пароль пользователя журнала сообщений по умолчанию находится в файле /​etc/​xroad/​db.properties.
 +
 +<​code>​
 +$ psql -h 127.0.0.1 -U messagelog messagelog
 +</​code>​
 +
 +Чтобы просмотреть все столбцы таблицы logrecord:
 +<​code>​
 +messagelog=>​ \d logrecord
 +</​code>​
 +
 +Для каждой записи в таблице logrecord есть архивный параметр,​ значение которого по умолчанию — «false». Когда запись имеет временную метку и архивируется,​ она будет изменена на «true». Все записи,​ значение параметра архива которых равно true, будут удалены в процессе очистки.
 +
 +Для подсчета журналов сообщений,​ не имеющих временных меток, можно использовать следующий порядок. Если возвращаемое число больше 10 000, проблема с отметкой времени,​ т.е. на сервере безопасности много трафика и каждые 48 минут создается более 10 000 журналов сообщений. Поскольку архивировать можно только журналы сообщений с отметками времени,​ они останутся на сервере безопасности. В более длительный период времени это может привести к увеличению дискового пространства базы данных.
 +В качестве решения мы хотим увеличить параметр timestamp-records-limit в журнале сообщений в файле конфигурации /​etc/​xroad/​conf.d/​local.ini;​ по умолчанию это 10 000. В таком случае более 10 000 журналов сообщений получают отметку времени каждые 48 минут.
 +
 +<​code>​
 +messagelog=>​ select count(1) from logrecord where discriminator::​text = '​m'::​text and signaturehash is not null;
 +count        ​
 +------- ​  
 +275 
 +(1 row)
 +</​code>​
 +
 +Чтобы узнать журнал последних сообщений без отметки времени,​ можно использовать следующую команду:​
 +
 +<​code>​
 +messagelog=>​ select to_timestamp(min(time)::​float/​1000) from logrecord where discriminator::​text = '​m'::​text and signaturehash is not null;  ​
 +to_timestamp ​              
 +---------------------------- ​      
 +2018-05-18 09:​14:​45.825+03
 +(1 row)
 +</​code>​
 +
 +Для подсчета журналов сообщений с отметкой времени,​ но еще не заархивированных,​ можно использовать следующую команду:​
 +
 +<​code>​
 +messagelog=>​ select count(1) from logrecord where timestamprecord in (select id from logrecord where discriminator::​text = '​t'::​text and archived = false); ​      
 +count        ​
 +------- ​      
 +802      ​
 +(1 row)
 +</​code>​
 +
 +Чтобы узнать последний журнал сообщений с отметкой времени,​ но еще не заархивированный,​ можно использовать следующую команду. Если возвращаемая дата старше,​ например,​ 30 дней (параметр по умолчанию keep-records-for),​ значит,​ что-то не так с архивацией. Весьма вероятно,​ что интервал архивирования следует пересмотреть и при необходимости увеличить.
 +
 +<​code>​
 +messagelog=>​ select to_timestamp(min(time)::​float/​1000) from logrecord where timestamprecord in (select id from logrecord where discriminator::​text = '​t'::​text and archived = false);
 +to_timestamp ​             ​
 +---------------------------- ​       ​
 +2018-05-18 06:​50:​45.854+03 ​       ​
 +(1 row)
 +</​code>​
 +
 +=====Пустое место в базе данных,​ которое не было освобождено=====
 +
 +Если архивирование журналов сообщений работает,​ но объем базы данных все равно слишком велик, проблема может быть в незанятом пустом месте базы данных. По умолчанию базы данных Postgres реализуют AUTOVACUUM или освобождение пустого пространства,​ которое полностью удаляет удаленные строки из таблиц базы данных и тем самым также освобождает пространство,​ которое использовалось для данных. К сожалению,​ в AUTOVACUUM много ошибок,​ и системы с большим количеством запросов данных могут испытывать проблемы с автоматическим освобождением пустого места. Если есть много пустого места, которое не было освобождено,​ полезно выполнить VACUUM FULL в базе данных. Большая проблема с этой операцией заключается в том, что таблицы будут заблокированы,​ и поэтому невозможно использовать таблицу базы данных одновременно. Для функционирования сервера безопасности это означает прерывание.
 +
 +Для того, чтобы узнать,​ сколько там пустого места, которое не освободилось,​ для начала нужно войти в базу данных.
 +
 +<​code>​
 +# su - postgres
 +</​code>​
 +
 +Затем выберите журнал сообщений базы данных и создайте расширение pgstattuple.
 +
 +<​code>​
 +$ psql -d messagelog
 +
 +messagelog=#​ create extension pgstattuple;​
 +</​code>​
 +
 +<note important>​Хорошей идеей будет сначала проверить текущую ситуацию в таблице журнала сообщений logrecord.</​note>​
 +
 +<​code>​
 +messagelog=#​ SELECT * FROM pgstattuple('​logrecord'​);​
 + ​table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent ​
 +
 +-----------+-------------+-----------+---------------+------------------+----------------+--------------------+------------+--------------
 +
 + ​106192896 | 53390 | 73798005 | 69.49 | 3009 | 4335848 | 4.08 | 27163284 | 25.58
 +
 +(1 row)
 +</​code>​
 +
 +Затем следует проверить текущее состояние таблицы всплывающих уведомлений (таблица всплывающих сообщений используется для хранения больших записей).
 +
 +<​code>​
 +messagelog=#​ SELECT * FROM pgstattuple('​pg_toast.'​||(select relname from pg_class where oid = (select reltoastrelid from pg_class where relname = '​logrecord'​)));​
 +    ​
 +table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent ​
 +
 +------------+-------------+------------+---------------+------------------+----------------+--------------------+------------+-------------- ​  
 +
 + ​3872366592 | 1743879 | 3103020219 | 80.13 | 259348 | 465236384 | 12.01 | 280865112 | 7.25
 +
 +(1 row)
 +</​code>​
 +
 +Результаты первого запроса показывают,​ что в таблице logrecords осталось 27 МБ или 25,58 % пустого пространства,​ которое не было освобождено. Результаты второго запроса показывают,​ что в таблице тостов осталось 280 МБ или 7,25% свободного места.
 +
 +В этом случае выполнение ПОЛНОЙ ВАКУУМНОЙ РАБОТЫ нецелесообразно. Если уровень пустого пространства,​ которое не было освобождено,​ критичен,​ например. 80%, вам следует рассмотреть возможность использования VACUUM FULL.
 +
 +=====Использование VACUUM FULL=====
 +
 +Прежде чем использовать VACUUM FULL, вам, безусловно,​ нужно подумать,​ нужно ли это делать и когда это делать,​ так как этот процесс блокирует таблицу базы данных,​ а это означает,​ что таблица не может быть использована до завершения процесса. Для функционирования сервера безопасности это означает прерывание.
 +
 +Сначала вам нужно войти в базу данных messagelog как пользователь messagelog.
 +
 +<​code>​
 +# psql -h 127.0.0.1 -U messagelog messagelog
 +</​code>​
 +
 +Запуск VACUUM FULL для таблицы logrecords.
 +
 +<​code>​
 +messagelog=#​ VACUUM FULL logrecord;
 +</​code>​
 +
 +Этот процесс может занять несколько часов. В этот период изменения объема базы данных можно отслеживать,​ например,​ с помощью команды:​
 +
 +<​code>​
 +$ df -h
 +</​code>​
 +
 +Процессы базы данных также можно контролировать с помощью команды:​
 +
 +<​code>​
 +$  sudo -i -u postgres psql -c "​select * from pg_stat_activity;"​
 +</​code>​
 +
 +Все различные параметры и более подробную информацию о журнале сообщений можно найти в главе 11 руководства пользователя сервера безопасности,​ в которой описывается журнал сообщений и варианты его использования.
 +https://​www.x-tee.ee/​docs/​live/​xroad/​ug-ss_x-road_7_security_server_user_guide.html#​11-message-log
 +
 +----
 +
 +Автор Даниил Горбенко
manual_security_server_messagelog.1683284427.txt.gz · Последние изменения: 2023/05/05 11:00 — infra