
<note warning>Целевой аудиторией данного руководства являются системные администраторы Сервера безопасности Тундук ответственные за установку и сопровождение программного обеспечения X-Road. Документ предназначен для читателей с умеренными знаниями администрирования Linux серверов и компьютерных сетей.</note>


<note tip>Все команды выполняются от пользователя root в консоле, либо от пользователя postgres.</note>


====== Мануал по администрированию messagelog на сервере безопасности ======

Целевой аудиторией руководства по установке являются системные администраторы сервера безопасности СМЭВ ТУНДУК ответственные за установку и сопровождение программного обеспечения X-Road.

Если объем базы данных сервера безопасности СМЭВ или журнала сообщений и использование дискового пространства выросли больше, чем вы изначально планировали, и объем дискового пространства продолжает расти, проблема, вероятно, заключается в настройках по умолчанию архивирования журналов сообщений, которые не подходят для вашего сервера безопасности. Сервер безопасности СМЭВ ТУНДУК предоставляет возможность автоматического архивирования и очистки журналов сообщений, а также, при желании, переноса их на другую машину, чтобы контролировать дисковое пространство.

<note important>Внимание! Согласно пункту 3 ст. 10 главы 3 и ст. 36 главы 6 Требований к взаимодействию информационных систем в системе межведомственного электронного взаимодействия «Түндүк», участник обязан минимум 3 года обеспечить хранение лог-файлов. В связи с этим рекомендуется периодично производить резервную копию содержимого в директории /var/lib/xroad/ сервера безопасности в другое дисковое хранилище. После резервного копирования можно удалить старые файлы из директории /var/lib/xroad/ за определенный период, если дисковое пространство заполнилось и нет возможности увеличить его.</note>

Архивация журналов сообщений состоит из 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

----

Автор Даниил Горбенко