Условия и выбор источника
Зафиксируйте установленный релиз Keycloak, realm, приложение и период. Источники latest меняются, поэтому приведённый маршрут требует сверки со своей версией. Для сохранённых пользовательских событий проверьте Save events, выбранные типы и Expiration в настройках realm. Отдельно установите, читаете ли вы Admin API, интерфейс Events или журнал event listener. Административные операции имеют собственный аудит и не заменяются LOGIN. Для рабочего поиска нужны уже предоставленные права чтения; эта инструкция не создаёт роли, не меняет настройки и не получает токен.
Как отобрать события
В интерфейсе выберите пользовательские события нужного realm и ограничьте интервал, тип и клиент. Эквивалентный GET-шаблон показан во вкладке запросов: путь использует имя realm, а не realmId из объекта. Он требует существующей разрешённой аутентификации; секреты в пример не включены. Учтите first/max и полноту страниц выдачи. Если работаете с локальным JSON-массивом API, примените отдельный jq-фильтр. Не используйте его без изменения для построчного server log: другой формат требует другого разбора.
Разбор примера
LOGIN_ERROR в примере относится к portal-demo в указанном realm и содержит invalid_user_credentials. Поля userId и sessionId отсутствуют намеренно: на раннем отказе пользователь или сессия ещё могут быть не установлены. Не заменяйте отсутствие пустой строкой или именем из соседней попытки. Сохраните type, time и доступный контекст; при преобразовании времени проверьте единицы и часы. В текущем исходнике EventBuilder time формируется в миллисекундах. Пример не позволяет отличить ошибку человека от автоматизированного обращения без других наблюдений.
Интерпретация
Разделяйте попытку входа, успешный вход в IdP, обмен кода на токен и действие внутри приложения. Даже LOGIN не подтверждает чтение конкретного документа или выполнение операции. Похожая последовательность событий не доказывает, что их инициировал один человек: учитывайте общие устройства, прокси и параллельные запросы. Для оценки ошибки важны тип, этап и контекст, а не только название. ipAddress необходимо сопоставить с конфигурацией прокси и доступными сетевыми журналами; само поле не гарантирует адрес конечного устройства.
Следующий шаг
Свяжите доступные realm/client/user/session и время с журналами приложения, а при внешнем провайдере — с upstream IdP. Выпишите отдельно подтверждённые переходы и разрывы цепочки. Для вопроса об изменении пользователя, клиента или роли перейдите к административному аудиту и проверьте операцию/ресурс/субъекта. Не смешивайте API EventRepresentation с текстовым сообщением listener: у них разная форма и условия доставки. Поиск в справочнике объясняет поля, но не подтверждает настройку MFA или фактическое использование токена в вашей системе.
Если записи нет
Проверьте realm, границы времени, страницы API, тип события, сохранение и срок хранения. Затем разделите отсутствие в event store и отсутствие в server log: listener и хранилище событий имеют отдельные механизмы. Ошибка 403 говорит о доступе, а не о нулевом числе событий. При пустом userId сначала исследуйте доступный контекст, не назначая пользователя по похожему имени. Сравните исходный ответ с индексом назначения и ошибками доставки. Пустая выдача не исключает вход, если нужный тип не сохранялся или данные уже истекли.