Перейти к основному содержанию

Обзор

После установки вашего приложения в других рабочих областях вам нужно знать, когда оно перестаёт работать. Twenty записывает происходящее с вашим приложением на платформе и показывает это в двух местах:
  • Страница мониторинга регистрации вашего приложения для вас как владельца приложения с агрегированными данными по всем установкам.
  • Журналы рабочей области для администраторов каждой рабочей области, установившей ваше приложение, ограниченные их собственной рабочей областью.

Откройте страницу мониторинга

Перейдите в Settings → Developers → Apps, откройте своё приложение, затем нажмите View monitoring на вкладке General. Вам нужно разрешение API keys & webhooks в рабочей области, которой принадлежит регистрация приложения. Выберите период в заголовке: последние 2 часа, 24 часа, 7 дней, 30 дней или 90 дней. Данные хранятся 90 дней. Без права Audit logs отображаются только последние 2 часа.

Что показывает страница

Подсчёты точны: учитывается каждый отклонённый запрос и каждое пропущенное задание, даже если в журналах ниже сохраняется только одна строка в минуту.

Что записывается

Каждое из событий ниже учитывается на странице мониторинга. Каждое из них также записывает журналы приложения в рабочую область, где оно произошло, с указанием source, откуда оно поступило: Сбои из-за лимита скорости и маршрутов сервера могут повторяться много раз в секунду, поэтому для каждой установки, функции и кода ошибки в журналах сохраняется одна строка в минуту. На странице мониторинга по-прежнему учитывается каждое вхождение.

Журналы рабочей области

Администраторы рабочей области, установившей ваше приложение, видят те же события только для своей рабочей области в разделе Settings → General → Logs. Они могут фильтровать по источнику, например чтобы вывести только сбои INSTALL или лимиты скорости. Направляйте пользователей туда, когда они сообщают о проблеме: код ошибки и сообщение подскажут, где искать. Для собственного сервера разработки команда twenty app logs передаёт журналы функций в терминал в реальном времени. См. CLI.

Как интерпретировать сигналы

  • Ошибки резко возрастают сразу после выпуска: сравните версии в таблице Versions, затем исправьте проблему и опубликуйте более новую версию. См. Публикация.
  • К запросам API применяется ограничение скорости: ваше приложение слишком часто вызывает API. Выполняйте чтение и запись пакетно и не вызывайте API в тесных циклах.
  • К заданиям применяется ограничение скорости: триггеры событий базы данных или cron срабатывают быстрее, чем задания могут быть поставлены в очередь. Сузьте триггер, например с помощью updatedFields в триггере databaseEvent, или выполняйте работу за меньшее количество более крупных запусков. См. Логические функции.
  • Сбои установки или обновления: проверьте свои хуки установки. Сообщение об ошибке записывается вместе со сбоем.
  • Медленные функции: высокая длительность на 95-м процентиле указывает на функцию, которую стоит профилировать или разделить.