Наблюдаемость

Три независимых потока, и их нельзя путать:

Поток	Где	Для чего
Метрики	отдельный слушатель, GET /metrics	мониторинг и алерты
Журнал эксплуатации	stdout, JSON или текст	диагностика, request_id в каждой строке и в заголовке ответа
Журнал аудита	файл со сцеплением записей хэшами, копия в системе сбора	юридически значимые события безопасности

Метрики слушают отдельный адрес (observability.metrics_listen, по умолчанию 127.0.0.1:9090): наружу смотрит только форма смены пароля, показатели и внутреннее устройство туда не отдаются.

Экспортируется: операции с паролем по результату, выдача и проверка факторов, отказы по ограничению попыток, длительность и ошибки обращений к каталогу, HTTP-запросы по маршрутам, активные сеансы и сценарии, состояние лицензии, ошибки записи аудита.

В метках метрик нет и не будет имён учётных записей, телефонов и адресов — множество их значений неограниченно, а сами значения относятся к персональным данным. Кто именно менял пароль, видно в журнале аудита. По той же причине в метку маршрута попадает только шаблон из закрытого перечня, а не сырой путь.

Выгрузка журнала в SIEM включается одной строкой (audit.syslog: "tcp://siem:514") и отправляет события по RFC 5424 с октетным обрамлением. Копия содержит запись целиком, включая номер и хэш, — система сбора может проверить цепочку сама. Файл остаётся источником истины: отправка неблокирующая, недоступный приёмник не задерживает смену пароля, а потери и обрывы видны в sspr_audit_forward_dropped_events и sspr_audit_forward_failures.

Ротация журнала — дело продукта, не logrotate. Граница файла — такая же запись цепочки: старый файл закрывается печатью со своим новым именем, новый начинается с записи, ссылающейся на предыдущий, нумерация сквозная. Удаление старых файлов по политике хранения тоже записывается в цепочку, поэтому sspr audit verify отличает файл, удалённый продуктом, от файла, изъятого рукой. Проверка идёт по всем файлам потоком и ловит подмену записи, усечение хвоста закрытого файла и пропажу файла из середины.