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 :
- Apps UI : Cliquez sur le Logs tab de l’application pour afficher la sortie standard et les erreurs. Pour en savoir plus, consultez Afficher les détails d'une application Databricks.
- Direct URL : ajoutez
/logzà l'URL de votre application. Par exemple, si l'URL de votre application esthttps://my-app-1234567890.my-instance.databricksapps.com, les logs sont disponibles à l'adressehttps://my-app-1234567890.my-instance.databricksapps.com/logz.
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.
Les entrées de log sont regroupées par source. Dans l’onglet Logs , utilisez le filtre Source pour afficher ou masquer les entrées de chaque source :
- App : sortie standard de votre application.
- System : messages de la plateforme concernant le cycle de vie de l'application, tels que le déploiement et le startup.
- Build : résultat de l'installation des dépendances et de la compilation de votre application.
- HTTP : HTTP access logs pour les requêtes traitées par votre application. Consultez HTTP access logs.
Logs d'accès HTTP
Bêta
Les HTTP access logs sont en bêta.
Databricks Apps consigne une entrée de log d’accès HTTP pour chaque requête traitée 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 des erreurs de votre application.
Les access logs capturent à la fois les requêtes authentifiées et non authentifiées, y compris les requêtes rejetées avant d’atteindre votre application, telles que celles qui échouent lors de l’autorisation. Puisque les requêtes rejetées sont enregistrées dans les logs, vous pouvez auditer les tentatives d’autorisation échouées en tant qu’événements de sécurité.
Les limites suivantes s'appliquent aux éléments enregistrés dans les Logs :
- Pour protéger les données sensibles, les query string sont supprimées du chemin de la requête, de sorte que les jetons ou autres valeurs sensibles passées en tant que query parameter ne sont pas consignés dans les Logs.
- Pour réduire le bruit, les requêtes internes à la plateforme, telles que les rappels d'authentification et les vérifications d'état, sont exclues.
En cas de forte charge, Databricks peut supprimer certaines entrées d’access log. Lorsque des entrées sont supprimées, le log comprend un message intégré qui indique le nombre d’entrées supprimées.
Format d’entrée de log : chaque entrée utilise le format de log combiné Apache. L’entrée suivante est un exemple :
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 la forme d'un tiret (-).
Champ | Exemple | Description |
|---|---|---|
IP du client |
| Adresse IP du client ayant effectué la demande. |
Utilisateur |
| Utilisateur authentifié, ou |
Horodatage |
| Date et heure de réception de la requête. |
Courbe de requête |
| Méthode HTTP, chemin de la requête avec la chaîne de query supprimée et protocole. |
Code de statut |
| Code de statut de réponse HTTP. |
Taille de la réponse |
| Taille du corps de la réponse, en octets. |
Referer |
| Valeur de l'en-tête de requête |
Agent utilisateur |
| Valeur de l'en-tête de requête |
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 des traces, des logs et des métriques directement dans les tables Unity Catalog. Voir Configurer la télémétrie pour Databricks Apps.
-
Outils d'Application Performance Monitoring (APM) : utilisez New Relic, Datadog ou des outils d'application performance monitoring similaires pour collecter et analyser les logs, les métriques et les traces.
-
Persistance des logs personnalisés : écrivez régulièrement des logs dans des volumes ou des tables Unity Catalog pour un stockage et une analyse à long terme.
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 :
-- 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 :
-- 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 :
-- 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 :
-- 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
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.
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.