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 de l'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 des manières suivantes :

Interface utilisateur des applications : cliquez sur l’onglet Journaux de l’application pour afficher la sortie standard et la sortie d’erreur. Pour plus d’informations, consultez Afficher les détails d’une application Databricks.
URL directe : Ajouter /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 Unity Catalog.

Les entrées de journal sont regroupées par source. Dans l’onglet Journaux , utilisez le filtre Source pour afficher ou masquer les entrées de chaque source :

Application : Sortie standard de votre application.
Système : Messages de la plateforme concernant le cycle de vie de l’application, tels que le déploiement et le démarrage.
Build : Résultat issu de l’installation de dépendances et de la construction de votre application.
HTTP : journaux d’accès HTTP pour les requêtes traitées par votre application. Voir les journaux d’accès HTTP.

Journaux d’accès HTTP

Databricks Apps enregistre une entrée de journal d’accès HTTP pour chaque requête servie par votre application. Ces entrées apparaissent sous la source HTTP dans l’onglet Logs et à l’URL /logz , aux côtés de la sortie standard et de l’erreur de votre application.

Les journaux d’accès capturent à la fois les requêtes authentifiées et non authentifiées, y compris celles rejetées avant d’atteindre votre application, comme celles qui ne sont pas autorisées. Comme les requêtes rejetées sont enregistrées, vous pouvez auditer les tentatives d’autorisation ratées sous forme d’événements de sécurité.

Les limites suivantes s’appliquent à ce qui est enregistré :

Pour protéger les données sensibles, les chaînes de requête sont supprimées du chemin de requête, de sorte que les jetons ou autres valeurs sensibles transmises comme paramètres de requête ne sont pas enregistrés.
Pour réduire le bruit, les requêtes internes à la plateforme, telles que les rappels d’authentification et les contrôles de santé, sont exclues.

En cas de charge importante, Azure Databricks peut supprimer certaines entrées de journal d’accès. Lorsque les entrées sont supprimées, le journal inclut un message en ligne indiquant le nombre d’entrées supprimées.

Format d’entrée de journal : Chaque entrée utilise le format combiné de journal Apache. Voici un exemple d’entrée :

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"

Chaque entrée contient les champs suivants, dans l’ordre. Les champs vides apparaissent sous forme de trait d’union (-).

Champ	Example	Description
IP du Client	`203.0.113.10`	Adresse IP du client qui a effectué la requête.
Utilisateur	`jane.doe@example.com`	Utilisateur authentifié, ou `-` pour une demande non authentifiée.
Timestamp	`[23/Jul/2026:15:04:05 +0000]`	Date et heure de réception de la demande.
Ligne de requête	`"GET /api/data HTTP/1.1"`	Méthode HTTP, chemin de requête sans la chaîne de requête supprimée, et protocole.
Code de statut	`200`	Code d’état de la réponse HTTP.
Taille de la réponse	`1234`	Taille du corps de la réponse, en octets.
Référant	`"https://apps.example.com/"`	Valeur de l’en-tête `Referer` de requête.
Agent utilisateur	`"Mozilla/5.0"`	Valeur de l’en-tête `User-Agent` de requête.

Intégrer à des services de journalisation externes

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

Télémétrie d’application (Bêta) : collectez les traces, journaux et métriques directement dans les tables Unity Catalog. Consultez Configurer la télémétrie pour Databricks Apps.
Outils de surveillance de la performance des applications (APM) : Utilisez New Relic, Datadog ou des outils similaires de surveillance des performances des applications pour collecter et analyser les journaux, métriques et traces.
Persistance des journaux personnalisés : Écrire périodiquement des journaux dans des volumes ou tables du catalogue Unity pour un stockage et une analyse à long terme.

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

Pratiques de loggage recommandées

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 avec des outils de gestion des performances d'applications (APM) ou d'agrégation de journaux pour prendre en charge les alertes en temps réel, la réponse aux incidents de sécurité, l'analyse de l'utilisation et des performances, ainsi que la corrélation avec les journaux système d'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 API uniquement : les applications peuvent uniquement accéder aux ressources Azure Databricks via des API de 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 périmètres 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 des Applications Databricks en utilisant 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 d’utilisation pour faciliter le suivi des coûts. Pour en savoir plus sur la configuration des stratégies d’utilisation, consultez Utilisation des attributs avec des stratégies d’utilisation 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 visionneuse

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.