--- read_when: - Вам потрібен надійний журнал дій Gateway без зберігання вмісту - Ви вирішуєте, чи вмикати аудит життєвого циклу повідомлень - Потрібно пояснити, що підтверджують і чого не підтверджують записи аудиту summary: Історія аудиту лише метаданих для запусків агентів, дій інструментів і життєвих циклів повідомлень за згодою користувача title: Історія аудиту x-i18n: generated_at: "2026-07-16T18:01:24Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 32 provider: openai source_hash: 1005b214a674f0f888d759837bd627be458cefcf9ed61bda722499333361dc45 source_path: gateway/audit.md workflow: 16 --- # Історія аудиту Gateway зберігає обмежений журнал аудиту, що містить лише метадані, у спільній базі даних стану OpenClaw. Він дає відповіді на операційні запитання, як-от «який агент виконувався, коли та як завершив роботу», «які дії інструментів виконувалися під час запуску», а коли аудит повідомлень увімкнено — «чи надійшло прийняте вхідне повідомлення до диспетчеризації» та «чи досягло вихідне повідомлення кінцевого стану доставки». Журнал зберігає ідентичність, порядок, походження, дію, стан і нормалізовані коди результатів. Він ніколи не зберігає запити, тіла повідомлень, аргументи чи результати інструментів, вкладення, назви файлів, URL-адреси, вивід команд або необроблений текст помилок. ## Сімейства записів Події запусків і дій інструментів записуються щоразу, коли аудит увімкнено (типове налаштування). Події життєвого циклу повідомлень вмикаються окремо й типово вимкнені. | Сімейство | Дії | Типово | | ------------ | -------------------------------------------------------- | ------- | | Запуски агентів | `agent.run.started`, `agent.run.finished` | увімкнено | | Дії інструментів | `tool.action.started`, `tool.action.finished` | увімкнено | | Повідомлення | `message.inbound.processed`, `message.outbound.finished` | вимкнено | Кожен запис містить стабільний ідентифікатор події, монотонну послідовність журналу, часову позначку життєвого циклу, виконавця, дію, стан, `schemaVersion: 1` і `redaction: "metadata_only"`. Повний опис полів і фільтрів запитів див. у розділі [Записи аудиту](/cli/audit). ## Події життєвого циклу повідомлень Установіть [`audit.messages`](/uk/gateway/configuration-reference#audit), щоб вибрати, що записувати, а потім перезапустіть Gateway: - `off` (типове значення): записи повідомлень відсутні. - `direct`: лише повідомлення в прямих розмовах. - `all`: повідомлення в прямих розмовах, групах і каналах. Записи повідомлень створюються на двох авторитетних межах: - Рядки **вхідних повідомлень** записуються, коли прийняте повідомлення надходить до диспетчеризації ядра, включно з дубльованими та кінцевими результатами обробки. - Рядки **вихідних повідомлень** записуються, коли спільна надійна доставка досягає кінцевого результату: надіслано, пригнічено, сталася помилка або явний `unknown` для надсилань із неоднозначним через аварійне завершення результатом. Результати відновлення черги та черги невдалих повідомлень також враховуються. Кожне початкове логічне корисне навантаження відповіді отримує один кінцевий рядок; поділ на частини та розгалуження адаптера агрегуються в `resultCount`. ### Класифікація типу розмови Режим `direct` є межею конфіденційності, тому повідомлення класифікується як пряма розмова лише тоді, коли це підтверджують відомості про призначення: шлях надсилання оголосив тип розмови призначення або маршрут сеансу доставки точно вказує канал і адресата доставки. Слабші сигнали, як-от стан політики або початкова розмова, можуть класифікувати повідомлення як `group` (виключаючи його зі збирання `direct`), але ніколи не можуть стверджувати `direct`. Повідомлення, для яких неможливо довести, що вони прямі, класифікуються як `unknown` і не записуються в режимі `direct`. Тому канали, які не оголошують типи чатів, можуть записувати менше рядків у режимі `direct`, ніж у режимі `all`. ## Модель конфіденційності Рядки повідомлень ніколи не зберігають необроблені ідентифікатори платформи. Ідентифікатори облікового запису, розмови, повідомлення та цілі, якщо кореляція доступна, експортуються лише як локальні для інсталяції ключові псевдоніми (`hmac-sha256:v1::`): - Ключ HMAC генерується під час першого використання, має розділені домени для кожного типу ідентифікатора та зберігається в тій самій базі даних стану, що й журнал. - Псевдоніми стабільні в межах однієї інсталяції, тому рядки про ту саму розмову можна співвідносити, не розкриваючи ідентифікатор платформи. - Це **кореляція, а не анонімізація**: кожен, хто має доступ на читання до бази даних стану, також має ключ і може перевіряти потенційні необроблені ідентифікатори за псевдонімами. Експорт через RPC і CLI ніколи не містить ключа. - Якщо матеріал ключа відсутній або пошкоджений, а рядки повідомлень збережено, Gateway працює за принципом безпечної відмови та відкидає нові записи повідомлень замість непомітної ротації на новий ключ, яка розділила б кореляцію. Записи запусків та інструментів зберігають `sessionKey` і `sessionId` для кореляції; канонічні ключі сеансів самі можуть містити ідентифікатори облікових записів платформи або адресатів. Записи повідомлень навмисно не містять їх обох. Експорт аудиту залишається чутливими операційними метаданими навіть без вмісту: часові дані, канали, результати та стабільні псевдоніми дають змогу співвідносити активність. Захищайте експорт такими самими засобами контролю доступу та правилами зберігання, що й інші операторські записи. ## Межі охоплення й доказовості Журнал працює за принципом докладання максимальних зусиль і навмисно обмежений. Розглядайте його як свідчення того, що було записано, а не як доказ того, що відбулося: - **Відсутність рядка нічого не доводить.** Вхідні повідомлення, відкинуті до прийняття, надсилання з процесів CLI без запущеного реєстратора Gateway, а також локальні для Plugin або прямі шляхи надсилання, які оминають спільну надійну доставку, не залишають записів. - Записи проходять через обмежений фоновий робочий процес; збій робочого процесу або переповнення черги призводить до відкидання записів і реєстрації одного операційного попередження. - Вихідні надсилання з неоднозначним через аварійне завершення результатом записуються як `unknown`, а не як вигадані результати. Цей журнал призначений для налагодження та операційного аналізу. Він не є повним архівом відповідності вимогам; якщо такий архів потрібен, використовуйте зовнішню систему, яка отримує дані через [OpenTelemetry](/uk/gateway/opentelemetry) або інструменти на рівні каналів. ## Зберігання, термін зберігання та міграція Записи зберігаються у спільній базі даних стану (`state/openclaw.sqlite`) і записуються поза критичним шляхом доставки. Запити ніколи не повертають записи, старші за 30 днів, а журнал обмежено 100,000 рядків; прострочені рядки видаляються під час запуску, щогодинного обслуговування та подальших записів. Обслуговування терміну зберігання триває, навіть коли збирання вимкнено. Під час оновлення з Gateway із попереднім журналом лише для запусків та інструментів схема автоматично мігрується під час запуску (або через `openclaw doctor --fix`); наявні рядки та їхні послідовності журналу зберігаються. ## Виконання запитів - CLI: [`openclaw audit`](/cli/audit) із фільтрами за агентом, сеансом, запуском, типом, станом, напрямком, каналом, часовими межами та сторінковою навігацією за курсором. - RPC Gateway: `audit.activity.list` (потребує `operator.read`) повертає версіоноване об'єднання подій активності V1; випущений RPC `audit.list` залишається незмінним для старіших клієнтів запусків та інструментів. Див. [Протокол Gateway](/uk/gateway/protocol#audit-ledger-rpc). ## Пов’язані матеріали - [CLI записів аудиту](/cli/audit) - [Довідник із конфігурації](/uk/gateway/configuration-reference#audit) - [Протокол Gateway](/uk/gateway/protocol#audit-ledger-rpc) - [OpenTelemetry](/uk/gateway/opentelemetry)