2.10. Ведение журнала
Shardman — критически важная точка в пользовательской инфраструктуре, так как в ней хранятся все пользовательские данные. Это делает ведение журнала обязательным. Поэтому пользователь должен понимать, как работает ведение журнала в Shardman. Из-за сложности устройства Shardman поддерживаются журналы из нескольких источников: журналы демона shardmand, который управляет конфигурацией кластера, и журналы из экземпляров базы данных PostgreSQL.
2.10.1. Журналы PostgreSQL
Shardman использует стандартные параметры ведения журнала PostgreSQL, описанные здесь. Параметры ведения журнала должны быть внесены в файл sdmspec.json в раздел pgParameters, как показано в следующем примере:
{
"ShardSpec": {
"pgParameters": {
"log_line_prefix": "%m [%r][%p]",
"log_min_messages": "INFO",
"log_statement": "none",
"log_destination": "stderr",
"log_filename": "pg.log",
"logging_collector": "on",
"log_checkpoints": "false",
...
},
...
},
...
}
По умолчанию журналы размещаются в каталоге вида /var/lib/pgpro/sdm-14/data/keeper-cluster0-clover-1-shrn1-0/postgres/log. В этом примере cluster0 — текущий кластер, clover-1-shrn1 — имя текущего сегмента, 0 — идентификатор интегрированного процесса keeper. Чтобы изменить каталог размещения журналов, задайте параметр log_directory.
2.10.2. Журналы shardmand
shardmand — это модуль systemd, его журналы записываются в journald. Ознакомиться с его работой можно, используя команду journalctl. Например, чтобы получить все журналы с 2023-05-09 10:00 для службы shardmand кластера cluster0, можно использовать следующую команду:
$ journalctl -u shardmand@cluster0.service
Для фильтра журналов по времени можно использовать параметры --since и --until, ограничивающие отображаемые записи после или до заданного времени соответственно. Значения времени могут быть представлены в различных форматах. Для абсолютных значений времени следует использовать YYYY-MM-DD HH:MM:SS. Например можно увидеть все записи с 10:15 10 января 2023 года, выполнив:
$ journalctl -u shardmand@cluster0.service --since "2023-01-10 17:15:00"
Если компоненты вышеуказанного формата опущены, будут применены некоторые значения по умолчанию. Например, если дата не указана, предполагается текущая дата. Если компонент времени отсутствует, указывается «00:00:00» (полночь). Секунды также можно не указывать, чтобы по умолчанию подставлялось значение «00»:
$ journalctl -u shardmand@cluster0.service --since "2023-01-10" --until "2023-01-11 03:00"
Чтобы задать уровень детализации журнала для всех служб Shardman, укажите SDM_LOG_LEVEL в файле конфигурации shardmand.
2.10.3. Сбор информации о сбоях обслуживающих процессов
Некоторые сбои вызваны отказами оборудования или проблемами самой СУБД. Чтобы понять причину сбоя, используйте crash_info. Для этого задайте параметр, следуя этим указаниям:
Создайте каталог на каждом узле кластера, доступный для пользователя Shardman операционной системы (обычно
postgres). Записи об ошибках запишутся в этот каталог.install -d -o postgres -g postgres -m 700 /var/lib/postgresql/crashinfo
Задайте значение параметра
crash_info_location.Примечание
Это приведёт к перезапуску СУБД.
shardmanctl --store-endpoints http://etcdserver:2379 set -y crash_info_location=/var/lib/postgresql/crashinfo
Чтобы убедиться, что изменения вступили в силу, отправьте сигнал процессу СУБД, что приведёт к его отказу с созданием дампа памяти и перезапуску экземпляра.
Примечание
Делайте это исключительно в среде тестирования.
Подключитесь к СУБД и узнайте PID обслуживающего процесса текущего сеанса:
postgres=# select pg_backend_pid();
pg_backend_pid
----------------
23770Отправьте сигнал SIGSEGV процессу с данным PID:
kill -11 23770
Это приведёт к сбою этого процесса, а в каталог /var/lib/postgresql/crashinfo запишется файл, содержащий время, обратную трассировку и причину ошибки:
# Signal
Program received signal: 11 (SIGSEGV)
Signal UTC date time: 25.10.2024 08:37:02
# Program
pid: 23770
ppid: 17506
program_invocation_name: postgres: postgres postgres 10.42.42.10(34202) idle
program_invocation_short_name: tgres 10.42.42.10(34202) idle
exe_path: /opt/pgpro/sdm-14/bin/postgres
exe: postgres
# Backtrace
1 postgres + 0x5b55c0 0x55c5ba8459b7 0x00007ffcbef19070 bt_crash_handler + 0x3f7
2 libc.so.6 + 0x4251f 0x7f01c2caa520 0x00007ffcbef19140 __sigaction + 0x50
unknown ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
3 libc.so.6 + 0x125f80 0x7f01c2d8df9a 0x00007ffcbef195b8 epoll_wait + 0x1a
epoll_wait ../sysdeps/unix/sysv/linux/epoll_wait.c:30
4 postgres + 0x433870 0x55c5ba6c39bb 0x00007ffcbef195c0 WaitEventSetWait + 0x14b
5 postgres + 0x320de0 0x55c5ba5b0e74 0x00007ffcbef19650 secure_read + 0x94
6 postgres + 0x327d20 0x55c5ba5b7dae 0x00007ffcbef196a0 pq_recvbuf + 0x8e
7 postgres + 0x328980 0x55c5ba5b8995 0x00007ffcbef196c0 pq_getbyte + 0x15
8 postgres + 0x457da0 0x55c5ba6e909c 0x00007ffcbef196d0 PostgresMain + 0x12fc
9 postgres + 0x3ce210 0x55c5ba65ef86 0x00007ffcbef19a60 ServerLoop + 0xd76
10 postgres + 0x3cf240 0x55c5ba65fe18 0x00007ffcbef1a040 PostmasterMain + 0xbd8
11 postgres + 0x14ecc0 0x55c5ba3df182 0x00007ffcbef1a0c0 main + 0x4c2
12 libc.so.6 + 0x29d10 0x7f01c2c91d90 0x00007ffcbef1a0f0 __libc_init_first + 0x90
__libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
13 libc.so.6 + 0x29dc0 0x7f01c2c91e40 0x00007ffcbef1a190 __libc_start_main + 0x80
call_init ../csu/libc-start.c:128
__libc_start_main_impl ../csu/libc-start.c:379
14 postgres + 0x14f200 0x55c5ba3df225 0x00007ffcbef1a1e0 _start + 0x25