Ведение журнала и мониторинг приложений Databricks

Эффективное ведение журнала и мониторинг помогают обнаруживать и реагировать на события безопасности в Приложениях Databricks. Приложения создают журналы уровня приложения и журналы аудита платформы, которые можно использовать для диагностики, отслеживания производительности и аналитики безопасности.

Журналы приложений

Чтобы журналы стали доступны в пользовательском интерфейсе Databricks Apps или через URL-адрес вашего приложения, приложение должно записывать выходные данные в stdout и stderr.

Получите доступ к журналам приложений следующим образом:

Интерфейс приложений: Нажмите на вкладку «Журналы » для просмотра стандартного вывода и ошибок. Дополнительные сведения см. в разделе "Просмотр сведений о приложении Databricks".
Прямой URL-адрес: добавление /logz к URL-адресу приложения. Например, если URL-адрес приложения https://my-app-1234567890.my-instance.databricksapps.com, журналы доступны по https://my-app-1234567890.my-instance.databricksapps.com/logz.

Замечание

Azure Databricks не сохраняет журналы при завершении работы вычислений приложения. Для постоянного ведения журнала интегрируйте с внешними службами ведения журнала или записывайте журналы в томах или таблицах каталога Unity.

Записи в журнале группируются по источнику. Во вкладке «Журналы » используйте фильтр «Источник », чтобы показать или скрыть записи из каждого источника:

Приложение: стандартный вывод из вашего приложения.
Система: Сообщения платформы о жизненном цикле приложения, такие как развертывание и запуск.
Build: Вывод из установки зависимостей и создания приложения.
HTTP: Журналы доступа HTTP для запросов, обслуживаемых вашим приложением. См. журналы доступа к HTTP.

Логи доступа к HTTP

Databricks Apps записывает запись в журнале HTTP-доступа для каждого запроса, который выполняет ваше приложение. Эти записи отображаются в источнике HTTP на вкладке «Журналы» и по адресу /logz, наряду со стандартным выводом и стандартным потоком ошибок вашего приложения.

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

Для того, что зарегистрировано, применяются следующие ограничения:

Для защиты конфиденциальных данных строки запросов удаляются из пути запроса, поэтому токены или другие чувствительные значения, переданные как параметры запроса, не ведутся в лог.
Для уменьшения шума исключаются внутренние запросы платформы, такие как обратные вызовы аутентификации и проверки работоспособности.

Под сильной нагрузкой Azure Databricks может потерять некоторые записи в журнале доступа. Когда записи отпадают, в журнале появляется встроенное сообщение, сообщающее о числе отброшенных записей.

Формат записи в журнале: Каждая запись использует формат Apache Combined Log Format. Ниже приведён пример записи:

203.0.113.10 - jane.doe@example.com [23/Jul/2026:15:04:05 +0000] "GET /api/data HTTP/1.1" 200 1234 "https://apps.example.com/" "Mozilla/5.0"

Каждая запись содержит следующие поля в следующем порядке: Пустые поля отображаются как дефис (-).

Поле	Example	Описание
IP-адрес клиента	`203.0.113.10`	IP-адрес клиента, выполнившего запрос.
User	`jane.doe@example.com`	Аутентифицированный пользователь или `-` для неаутентифицированного запроса.
Timestamp	`[23/Jul/2026:15:04:05 +0000]`	Дата и время получения запроса.
Линия запроса	`"GET /api/data HTTP/1.1"`	метод HTTP, путь запроса с удаленной строкой запроса и протокол.
Код состояния	`200`	Код состояния HTTP-ответа.
Размер ответа	`1234`	Размер тела ответа — в байтах.
Реферер	`"https://apps.example.com/"`	Значение заголовка запроса `Referer`.
Агент пользователя	`"Mozilla/5.0"`	Значение заголовка запроса `User-Agent`.

Интеграция с внешними службами ведения журнала

Для постоянного ведения журнала и расширенных возможностей мониторинга используйте следующее:

Телеметрия приложений (Beta): собирайте трассы, журналы и метрики напрямую в таблицы Unity Catalog. См. статью "Настройка телеметрии для приложений Databricks".
Инструменты мониторинга производительности приложений (APM): используйте New Relic, Datadog или аналогичные инструменты мониторинга производительности приложений для сбора и анализа журналов, метрик и трассировок.
Пользовательское сохранение журналов: Периодически записывайте журналы в тома или таблицы Unity Catalog для долгосрочного хранения и анализа.

См. Рекомендованные практики ведения журнала для получения рекомендаций по форматированию и содержимому.

Мониторинг безопасности с помощью системных таблиц

Azure Databricks записывает журналы аудита для действий, связанных с приложениями, в таблице system.access.audit. Эти журналы можно запросить для отслеживания действий пользователей, изменений конфигурации приложения и событий безопасности.

Используйте следующие запросы, чтобы отслеживать действия, связанные с безопасностью, и обнаруживать потенциальные проблемы с приложениями.

Мониторинг изменений разрешений приложения

Используйте этот запрос для обнаружения изменений разрешений приложения:

-- Monitor all app permission modifications in the last 30 days
WITH permission_changes AS (
  SELECT
    event_date,
    workspace_id,
    request_params.request_object_id AS app_name,
    user_identity.email AS modified_by,
    explode(from_json(
      request_params.access_control_list,
      'array<struct<user_name:string,group_name:string,permission_level:string>>'
    )) AS permission
  FROM system.access.audit
  WHERE action_name = 'changeAppsAcl'
    AND event_date >= current_date() - 30
)
SELECT
  event_date,
  app_name,
  modified_by,
  permission.user_name,
  permission.group_name,
  permission.permission_level
FROM permission_changes
ORDER BY event_date DESC

Идентификация приложений с пользовательскими областями API

Используйте этот запрос для поиска приложений с настроенными областями пользовательского API.

-- Find apps created or updated in the last 30 days with user API scopes configured
SELECT
  event_date,
  get_json_object(request_params.app, '$.name') AS app_name,
  user_identity.email AS creator_email,
  get_json_object(request_params.app, '$.user_api_scopes') AS user_api_scopes
FROM system.access.audit
WHERE
  action_name IN ('createApp', 'updateApp')
  AND get_json_object(request_params.app, '$.user_api_scopes') IS NOT NULL
  AND event_date >= current_date() - INTERVAL 30 DAYS

Отслеживание действий авторизации пользователей

Используйте этот запрос для перечисления действий приложения, выполненных с авторизацией пользователя:

-- List app actions performed on behalf of users in the last 30 days
WITH obo_events AS (
  SELECT
    event_date,
    workspace_id,
    audit_level,
    identity_metadata.acting_resource AS app_id,   -- OAuth App ID or name
    user_identity.email AS user_email,             -- Logged-in user
    service_name,
    action_name
  FROM system.access.audit
  WHERE event_date >= current_date() - 30
    AND identity_metadata.acting_resource IS NOT NULL
)
SELECT
  event_date,
  app_id,
  user_email,
  service_name,
  action_name,
  audit_level,
  COUNT(*) AS event_count
FROM obo_events
GROUP BY
  event_date, app_id, user_email, service_name, action_name, audit_level
ORDER BY event_date DESC;

Операционный мониторинг

Используйте системные таблицы для мониторинга операционных аспектов приложений, таких как затраты и использование ресурсов.

Мониторинг затрат на приложение

Отслеживайте затраты Databricks Apps с помощью таблицы system.billing.usage. Используйте следующий запрос, чтобы получить точные сведения о затратах для приложений в день или месяц:

-- Get Databricks Apps cost by app per day for the last 30 days
SELECT
  us.usage_date,
  us.usage_metadata.app_id,
  us.usage_metadata.app_name,
  SUM(us.usage_quantity) AS dbus,
  SUM(us.usage_quantity * lp.pricing.effective_list.default) AS dollars
FROM
  system.billing.usage us
LEFT JOIN system.billing.list_prices lp
  ON lp.sku_name = us.sku_name
  AND us.usage_start_time BETWEEN lp.price_start_time AND COALESCE(lp.price_end_time, NOW())
WHERE
  billing_origin_product = 'APPS'
  AND us.usage_unit = 'DBU'
  AND us.usage_date >= DATE_SUB(NOW(), 30)
GROUP BY ALL

Databricks Apps поддерживает политики использования для отслеживания затрат. Сведения о настройке политик использования см. в разделе " Использование атрибутов" с бессерверными политиками использования.

Мониторинг аналитики приложений

Это важно

Вкладка "Аналитика" находится в бета-версии.

На вкладке "Аналитика" на странице сведений о приложении отображается взаимодействие пользователей и доступность приложений.

Отслеживание зрителей

Таблица "Просмотрщики" отслеживает, какие пользователи получают доступ к вашему приложению.

Azure Databricks записывает событие представления, когда пользователь обращается к приложению по URL-адресу приложения или через доступ к API. Он сохраняет данные как уникальные для каждого пользователя на каждое приложение. Последующие посещения того же пользователя перезаписывают предыдущую запись, а не создают новую строку.

Последняя просматриваемая метка времени следует 30-минутным циклом обновления сеанса OAuth. Несколько посещений в окне сеанса сохраняют начальное время посещения, но первый доступ после истечения срока действия сеанса перезаписывает метку времени с новым временем посещения.

Замечание

В бета-версии последнее просмотренное время отображается только в согласованном универсальном времени (UTC).

Состояние работоспособности и времени работы

Отслеживайте следующие сигналы работоспособности, чтобы устранить неполадки с доступностью приложений.

Работоспособность службыApp: доступна ли инфраструктура Azure Databricks, поддерживающая приложение. В случае недоступности платформы возникает проблема уровня обслуживания. Обратитесь в службу поддержки Databricks.
Доступность приложений: обслуживает ли конкретное приложение запросы. Если он недоступен, проверьте наличие ошибок развертывания или сбоев в коде.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-09-17