1. Паспорт развёртывания
Определите продукт и server release, deployment, узел, bucket и объект. Источник документации относится к MinIO AIStor; он не подтверждает поведение любой Community-сборки MinIO. Зафиксируйте место получения аудита и часы. Сначала проверьте, существовала ли отправка аудита в рассматриваемый момент: по документации назначение по умолчанию не публикуется.
2. Найдите запись у получателя
В имеющейся копии audit receiver отберите api.name=GetObject, затем bucket,object и интервал. jq читает JSON-поток и не делает нового запроса к хранилищу. Установите, добавляет ли receiver собственную обёртку; при её наличии сначала отделите исходный объект аудита. Сохраните requestID и deployment-контекст, чтобы не смешать одинаковые имена bucket разных сред.
3. Прочитайте результат
Пример связывает GetObject учебного reports/demo.csv с api.status=OK и statusCode=200. Адрес remotehost=192.0.2.20 — наблюдаемый peer, а не установленный человек. requestPath уточняет путь, но identity в сокращённом фрагменте опущена. Здесь не утверждается, что клиент полностью сохранил документ или что имела место утечка. Для этих выводов нужен контекст передачи и прав.
4. Проверьте смысл операции и счётчиков
Разделите запрос API, его зарегистрированный итог и последующую работу клиента. Диапазонное чтение, несколько запросов и повторные попытки не должны автоматически превращаться в несколько полных копий объекта. Значения rx/tx и время ответа трактуйте по документации именно установленного релиза и сохранённому формату. Не складывайте похожие поля receiver с исходными API-счётчиками без установленной семантики.
5. Сопоставьте обращение с доступом
Проверьте доступные данные аутентификации и владельца ключа, приложение, журнал выданных полномочий и состояние объекта на момент операции. Прокси может менять наблюдаемый адрес; разные версии одного объекта могут иметь одинаковый путь. Для атрибуции человеку нужна связь с приложением или управлением ключами. В заключении отдельно перечислите техническую identity, прочитанный объект и подтверждённый объём/результат, если такие данные действительно есть.
6. Если события нет
Проверьте действовавший target аудита, фильтры, состояние receiver и доступный период. При недоступности получателя очередь может накапливаться, а переполнение допускает потерю событий. Сравните исходный поток, очередь/доставку и индекс приёмника, не меняя конфигурацию задним числом. Отсутствие записи не доказывает отсутствия чтения; обозначьте, где именно цепочка регистрации не подтверждена. Для webhook успешный ответ приёмника ещё не гарантирует, что он сохранил событие: это нужно сверить в его хранилище.