Aller au contenu principal
Dernière mise à jour le

Journalisation et Monitoring pour Databricks Apps

Une journalisation et un monitoring efficaces vous aident à détecter les événements de sécurité et à y répondre dans Databricks Apps. Les applications génèrent des logs au niveau de l'application et des logs d'audit de la plateforme, que vous pouvez utiliser pour les diagnostics, le suivi des performances et l'analytique de la sécurité.

Logs d'application​

Pour rendre les logs disponibles dans l'interface utilisateur Databricks Apps ou via l'URL de votre application, votre application doit écrire la sortie vers stdout et stderr.

Accédez aux journaux d’application des manières suivantes :

  • Interface utilisateur des applications : Cliquez sur la tab Logs de l'application pour afficher la sortie standard et les erreurs. Pour en savoir plus, consultez Afficher les détails d'une application Databricks.
  • URL directe : Ajoutez /logz à l'URL de votre application. Par exemple, si l'URL de votre application est https://my-app-1234567890.my-instance.databricksapps.com, les logs sont disponibles à l'adresse https://my-app-1234567890.my-instance.databricksapps.com/logz.
remarque

Databricks ne persiste pas les Logs lorsque le compute de l'application s'arrête. Pour une journalisation persistante, intégrez-vous à des services de journalisation externes ou écrivez les logs dans des volumes ou des tables Unity Catalog.

S’intégrer aux services de journalisation externes​

Pour la journalisation persistante et les capacités de monitoring avancées, utilisez les éléments suivants :

  • Télémétrie d'application (bêta) : Collectez les traces, les logs et les métriques directement dans les tables Unity Catalog. Consultez Configurer la télémétrie pour Databricks Apps.

  • Outils de monitoring des performances des applications (APM) : utilisez New Relic, Datadog ou des outils similaires de monitoring des performances des applications pour collecter et analyser les Logs, les métriques et les traces.

  • Persistance personnalisée des logs : écrire les logs périodiquement vers les volumes ou les tables Unity Catalog pour le stockage à long terme et l'analyse.

Consultez les pratiques de journalisation recommandées pour obtenir des conseils sur le formatage et le contenu des log.

Bonnes pratiques de journalisation recommandées​

Pour intégrer des systèmes de monitoring externes et d'alerte en temps réel :

  • Formatez les logs en JSON ou dans d'autres formats lisibles par machine.

  • Journaliser les événements pertinents pour la sécurité avec le contexte :

    • Événements d'authentification et d'autorisation, y compris l'identité de l'utilisateur et le résultat.
    • Détails d'accès aux données, tels que les noms de catalogue, de schéma et de table
    • Erreurs liées à la sécurité, telles que les jetons non valides, les refus d’autorisation et les activités suspectes

  • Transférez les logs vers des systèmes externes. Intégrer avec des outils APM ou d'agrégation de Logs pour prendre en charge les alertes en temps réel, la réponse aux incidents de sécurité, l'analytique d'utilisation et de performance, et la corrélation avec les Logs système Databricks.

Considérations de sécurité pour la journalisation​

Les applications Databricks sont conçues avec les contrôles intégrés suivants pour empêcher l'exfiltration de données :

  • Accès uniquement via API : les applications ne peuvent accéder aux Ressources Databricks que via les APIs publiques Databricks. Ces APIs sont auditables via les logs de table système.
  • Communication chiffrée : tout le trafic d'API est chiffré à l'aide de TLS 1.2 ou supérieur pour garantir un transfert de données sécurisé.

monitoring de la sécurité avec des tables système​

Databricks capture les audit Logs pour les activités liées aux applications dans la table system.access.audit. Vous pouvez interroger ces Logs pour suivre les actions des utilisateurs, les modifications de configuration d'application et les événements de sécurité.

Utilisez les requêtes suivantes pour surveiller les activités liées à la sécurité et détecter les problèmes potentiels avec vos applications.

Surveiller les modifications des autorisations d'application​

Utilisez cette query pour détecter les modifications d'autorisations d'application :

SQL
-- 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

Identifier les applications avec des périmètres d'API utilisateur​

Utilisez cette requête pour trouver des applications avec des périmètres d'API utilisateur configurés :

SQL
-- 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

Suivre les actions d'autorisation de l'utilisateur​

Utilisez cette query pour lister les actions d'application effectuées avec l'autorisation de l'utilisateur :

SQL
-- 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;

Monitoring opérationnel​

Utilisez les tables système pour surveiller les aspects opérationnels de vos applications, comme les coûts et l'utilisation des ressources.

Surveiller les coûts des applications​

Surveillez les coûts des Databricks Apps à l'aide de la table system.billing.usage. Utilisez la query suivante pour obtenir des informations précises sur les coûts des applications par jour ou par mois :

SQL
-- 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 prend en charge les politiques d'utilisation pour faciliter le suivi des coûts. Pour plus d'informations sur la configuration des politiques d'utilisation, consultez Attribuer l'utilisation avec des politiques d'utilisation serverless.

Surveiller les insights des applications​

info

Bêta

L'onglet Insights est en Bêta.

La tab Insights de la page de détails de l’application affiche l’engagement de l’utilisateur et la disponibilité de l’application.

Suivi des visionneurs​

La table des visionneurs suit les utilisateurs qui accèdent à votre application.

Databricks enregistre un événement de vue lorsqu'un utilisateur accède à l'application via l'URL de l'application ou via l'accès API. Il stocke les données de manière unique par utilisateur, par application. Les visites ultérieures du même utilisateur écrasent son enregistrement précédent plutôt que de créer une nouvelle ligne.

Le dernier Timestamp consulté suit un cycle de refresh de session OAuth de 30 minutes. Plusieurs visites dans la fenêtre de session conservent l'heure de la première visite, mais le premier accès après l'expiration de la session écrase le Timestamp avec la nouvelle heure de visite.

remarque

En bêta, la dernière heure de consultation n'affiche que le temps universel coordonné (UTC).

Disponibilité et état de santé​

Surveillez les signaux de santé suivants pour dépanner la disponibilité de l'application.

  • État de service de l'application : si l'infrastructure Databricks qui prend en charge l'application est disponible. S'il est indisponible, il y a un problème au niveau du service avec la plateforme. Contactez le support Databricks.
  • Disponibilité de l'application : Indique si l'application spécifique répond aux requêtes. Si indisponible, vérifiez les erreurs de déploiement ou les plantages dans votre code.
Sur cette page