Partager via

Journalisation et surveillance des applications Databricks

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

Journaux d’activité d’application

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

Accédez aux journaux d’application de la manière suivante :

  • Interface utilisateur des applications : Dans la page détails de l’application, cliquez sur l’onglet Journaux pour afficher la sortie et l’erreur standard. Pour plus d’informations, 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 sur https://my-app-1234567890.my-instance.databricksapps.com/logz.

Remarque

Azure Databricks ne conserve pas les journaux lorsque le calcul de l’application s’arrête. Pour la journalisation persistante, intégrez-les à des services de journalisation externes ou écrivez des journaux dans des volumes ou des tables de catalogue Unity.

Intégrer à des services de journalisation externes

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

  • Outils APM (Application Performance Monitoring) : Utilisez New Relic, Datadog ou des outils de surveillance des performances d’application similaires pour collecter et analyser les journaux, les métriques et les traces.
  • Persistance des journaux personnalisée : Écrivez régulièrement des journaux dans des volumes ou des tables de catalogue Unity pour le stockage et l’analyse à long terme.

Consultez les pratiques de journalisation recommandées pour obtenir des conseils sur la mise en forme et le contenu du journal.

Pour intégrer des systèmes d’alerte en temps réel et de supervision externe :

  • Mettre en forme les journaux d’activité dans JSON ou d’autres formats pouvant être analysés par l’ordinateur.
  • 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 de l’accès aux données, tels que le catalogue, le schéma et les noms de tables
    • Erreurs liées à la sécurité, telles que les jetons non valides, les refus d’autorisation et l’activité suspecte
  • Transférer des journaux vers des systèmes externes. Intégrez des outils d’agrégation de journaux ou APM pour prendre en charge les alertes en temps réel, la réponse aux incidents de sécurité, l’utilisation et l’analytique des performances, et la corrélation avec les journaux système Azure Databricks.

Considérations relatives à la sécurité pour la journalisation des événements

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

  • Accès à l’API uniquement : les applications peuvent uniquement accéder aux ressources Azure Databricks via des API Azure Databricks publiques. Ces API sont auditables via les journaux de table système.
  • Communication chiffrée : tout le trafic d’API est chiffré à l’aide de TLS 1.2 ou version ultérieure pour garantir un transfert de données sécurisé.

Surveillance de la sécurité avec des tables système

Azure Databricks capture les journaux d’audit des activités liées à l’application dans la table system.access.audit. Vous pouvez interroger ces journaux pour suivre les actions des utilisateurs, les modifications de configuration des applications 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 d’autorisation d’application

Utilisez cette requête pour détecter les modifications d’autorisation d’application :

-- 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 étendues d’API utilisateur

Utilisez cette requête pour rechercher des applications avec des étendues d’API utilisateur configurées :

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

Utilisez cette requête pour répertorier les actions d’application effectuées avec l’autorisation utilisateur :

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

Supervision opérationnelle

Utilisez des tables système pour surveiller les aspects opérationnels de vos applications, tels que le coût et l’utilisation des ressources.

Surveiller les coûts de l’application

Surveillez les coûts databricks Apps à l’aide de la system.billing.usage table. Utilisez la requête suivante pour obtenir des informations de coût précises pour les applications par jour ou mois :

-- 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 stratégies budgétaires pour faciliter le suivi des coûts. Pour plus d’informations sur la configuration des politiques budgétaires, consultez l’usage des attributs avec des politiques budgétaires sans serveur.

Surveiller les informations sur les applications

Important

L’onglet Insights est en version bêta.

L’onglet Insights de la page détails de l’application affiche l’engagement des utilisateurs et la disponibilité des applications.

Suivi de la visionneur

La table Visionneurs enregistre des utilisateurs accédant à votre application.

Azure Databricks enregistre un événement d’affichage lorsqu’un utilisateur accède à l’application via l’URL de l’application ou via l’accès à l’API. Il stocke les données en tant qu’uniques par utilisateur, par application. Les visites suivantes par le même utilisateur remplacent leur enregistrement précédent plutôt que de créer une nouvelle ligne.

Le dernier horodatage consulté suit un cycle d’actualisation de session OAuth de 30 minutes. Plusieurs visites dans la fenêtre de session conservent l’heure de visite initiale, mais le premier accès après l’expiration de la session remplace l’horodatage avec la nouvelle heure de visite.

Remarque

En version bêta, la dernière heure consultée affiche uniquement le temps universel coordonné (UTC).

Temps de fonctionnement et état de santé

Surveillez les signaux de santé suivants pour résoudre les problèmes de disponibilité des applications.

  • App Service Health : indique si l’infrastructure Azure Databricks prenant en charge l’application est disponible. S’il n’est pas disponible, il existe un problème de niveau de service avec la plateforme. Contactez le support Databricks.
  • Disponibilité de l’application : indique si l’application spécifique répond aux demandes. Si cela n'est pas disponible, vérifiez s'il y a des erreurs de déploiement ou des plantages dans votre code.
  • Last updated on