Перейти до вмісту

Зберігання та експорт даних

Railhook зберігає кожну подію, спробу й вхідну подію, і лише політика зберігання не дає цим таблицям рости безкінечно. Ця сторінка показує, що зберігається і скільки, та як відповісти на запит про експорт чи видалення.

Що зберігається і скільки

Section titled “Що зберігається і скільки”

Задайте це в .env. Значення за замовчуванням не дають розгортанню на власному сервері рости без меж.

Дані Змінна За замовчуванням
Невдалі спроби DATA_RETENTION_ATTEMPTS_DAYS 90 днів
Успішні (2xx) спроби DATA_RETENTION_SUCCESSFUL_ATTEMPTS_DAYS 14 днів
Події DATA_RETENTION_EVENTS_DAYS 90 днів
Вхідні події DATA_RETENTION_INCOMING_EVENTS_DAYS 30 днів
Спроб на доставку DATA_RETENTION_MAX_ATTEMPTS_PER_DELIVERY 10
Полишені записи outbox OUTBOX_DEAD_RETENTION_DAYS 90 днів
Журнал запитів тунелю 7 днів

Чому значення саме такі:

  • Успішні спроби видаляються першими. Спроба з 2xx мало що каже, коли ви вже знаєте, що все спрацювало; невдала — це запис для налагодження. Видалення успішних за 14 днів прибирає більшу частину обсягу й зберігає докази.
  • Події та невдалі спроби мають спільні 90 днів. Якщо тримати спроби довше за їхню подію, лишаться записи, що вказують у нікуди.
  • Обмеження на доставку ловить те, чого не зловить вік: ендпоінт, що падає тиждень, продовжує додавати спроби до тієї самої доставки.

Коли запускається очищення

Section titled “Коли запускається очищення”
Завдання Розклад за замовчуванням Змінна
Основне очищення Щодня о 02:00 DATA_RETENTION_CRON
Обмеження спроб на доставку Кожні 30 хвилин DATA_RETENTION_LIMIT_CRON
Сплескове очищення Кожні 4 години DATA_RETENTION_BURST_CLEANUP_CRON
Метрики розміру таблиць Кожні 15 хвилин DATA_RETENTION_TABLE_METRICS_INTERVAL_MS

Записи видаляються пакетами по DATA_RETENTION_BATCH_SIZE (за замовчуванням 1000), тож перший запуск після тривалої перерви не блокує платформу.

Спроби доставки й журнал запитів тунелю розбито на партиції за часом у Postgres. Для цих таблиць прострочений період прибирається видаленням цілої партиції, що відбувається миттєво, а не видаленням записів по одному. PARTITION_MAINTENANCE_ENABLED (за замовчуванням true) створює партиції наперед і видаляє прострочені.

Перевірте, що очищення працює

Section titled “Перевірте, що очищення працює”
Метрика Значення
delivery_attempts_table_rows, events_table_rows, incoming_events_table_rows Оцінка кількості записів у кожній великій таблиці
delivery_attempts_cleanup_total, events_cleanup_total, incoming_events_cleanup_total Видалені записи
partition_dropped_total Видалені партиції
partition_default_rows Записи, що потрапили в партицію за замовчуванням. Має бути нуль; будь-що інше означає, що партиції бракувало.

Якщо таблиця росте, а її лічильник очищення стоїть, завдання не запускається. Перевірте значення cron і логи API близько 02:00.

Власник може експортувати організацію через GET /api/v1/orgs/{orgId}/export. Експорт — один JSON-документ із конфігурацією та історією аудиту організації: сама організація, учасники, проєкти, ендпоінти, підписки, джерела, призначення, API-ключі та записи аудиту.

  • Payload туди не входять. Події, доставки й спроби завеликі, щоб зібрати їх в один документ. Скажіть про це кожному, хто відповідає цим файлом на запит суб’єкта даних.
  • Записів аудиту — не більше 10 000. Коли обмеження спрацьовує, auditLogsTruncated дорівнює true, а auditLogsTotal показує справжню кількість.

Уся організація. Власник видаляє її через DELETE /api/v1/orgs/{orgId}, і це прибирає все, що їй належить. Журнал аудиту свідомо зберігається, щоб можна було показати, що видалення відбулося.

Обліковий запис однієї людини. Людина видаляє його сама через DELETE /api/v1/auth/me:

  • Ідентифікаційні дані замінюються, а в обліковий запис більше ніколи не можна увійти. Усі сесії закриваються, усі членства видаляються.
  • Організація, де людина була єдиним учасником, видаляється разом із нею.
  • Запит відповідає 409, якщо людина — останній власник організації, де ще є інші учасники. Спершу треба передати власність.

Обидва видалення й експорт фіксуються в журналі аудиту.