Ведение журнала и мониторинг приложений 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.

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

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

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

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

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

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).

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

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

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

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

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

Last updated on 2026-01-17