Logs de trafic réseau étendus
Aperçu
Cette fonctionnalité est en aperçu privé. Pour l’essayer, veuillez contacter votre interlocuteur Databricks.
Les logs de trafic réseau étendus enregistrent le trafic réseau sortant du compute serverless Databricks. Par default, la table système des événements d’accès réseau sortant enregistre uniquement les requêtes refusées par les contrôles de sortie serverless. Avec les logs de trafic réseau étendus, elle enregistre également les requêtes autorisées, ce qui vous permet de voir où vos charges de travail serverless se connectent et de résoudre les problèmes de connectivité.
Les logs de trafic réseau étendus ajoutent également une table des logs de flux qui enregistre la quantité de données que le compute serverless envoie à chaque adresse IP de destination et en reçoit. Les deux fonctionnalités utilisent les tables système suivantes :
Compétence | Table système | Description |
|---|---|---|
Événements d’accès autorisé au réseau sortant |
| Ajoute les demandes sortantes autorisées à la table existante des demandes refusées. |
Logs de flux du trafic sortant |
| Enregistre les octets envoyés et reçus par adresse IP de destination, agrégés en intervalles d’une minute. |
Les logs de flux du trafic sortant enregistrent uniquement le trafic acheminé via une passerelle réseau privée.
Pour query les Logs, consultez Query extended network traffic Logs.
Cas d’utilisation
Utilisez les logs de trafic réseau étendus pour :
-
Examinez l’activité réseau : découvrez les destinations auxquelles vos charges de travail serverless ont accédé, à quel moment et depuis quel workspace.
-
Affiner les stratégies réseau : recherchez les destinations rarement utilisées, et déterminez s’il faut les supprimer de vos listes d’autorisation de sortie serverless.
-
Résoudre les problèmes de connectivité : déterminez si les contrôles de sortie Serverless ont autorisé ou refusé une requête.
-
Analyser les coûts réseau : identifiez les destinations interrégionales, Internet et privées auxquelles les charges de travail serverless accèdent.
-
Optimisez la connectivité du stockage : repérez les destinations de stockage fréquemment utilisées qui pourraient bénéficier d’une connectivité privée ou du fait de se trouver dans la même région que vos charges de travail.
-
Mesurer les volumes de trafic : voir quelle quantité de données le compute serverless envoie à chaque destination et reçoit de chacune d’elles via une passerelle réseau privée.
-
Détecter une activité inhabituelle : trouver les destinations présentant des volumes de trafic supérieurs aux attentes.
Comment ça marche
Événements d’accès réseau autorisés
Les logs de trafic réseau étendus ajoutent ALLOWED événements à la table system.access.outbound_network existante. Cette table consigne les événements d’accès sortant au réseau depuis les charges de travail serverless, notamment les SQL Warehouse, les Job, LakeFlow Pipelines, Databricks Apps et les Model Serving Endpoint. Les événements autorisés couvrent les requêtes vers le stockage cloud, les destinations Internet et les ressources accessibles via une connectivité privée. Pour consulter le schéma complet de la table, voir Référence de la table système des événements d’accès réseau.
La colonne access_type indique le résultat de chaque événement :
Valeur | Description |
|---|---|
| L’accès réseau sortant a été autorisé. Disponible uniquement avec les logs de trafic réseau étendus. |
| L’accès réseau sortant a été refusé par les contrôles de sortie serverless en mode appliqué. |
| L’accès réseau sortant aurait été refusé par les contrôles de sortie serverless, mais il a été autorisé parce que la stratégie était en mode d’exécution à blanc. |
Les valeurs access_type et destination_type enregistrées pour une requête dépendent de la destination et du mode de votre stratégie de sortie serverless :
Requête réseau | Sortie sans restriction | Mode simulation | Mode appliqué |
|---|---|---|---|
Accès au stockage autorisé |
| Non journalisé |
|
Accès au stockage qui enfreint la stratégie | Non applicable |
|
|
Accès autorisé aux ressources Virtual Private Cloud (VPC) |
|
|
|
Accès aux ressources Virtual Private Cloud (VPC) qui enfreint la politique | Non applicable |
|
|
Accès Internet autorisé |
|
|
|
Accès Internet qui enfreint la politique | Non applicable |
|
|
Pour les événements DNS autorisés, destination contient le nom de domaine ou le Hostname de stockage. Pour les événements STORAGE autorisés, destination contient le Hostname et le chemin de stockage. Les adresses IP de destination résolues se trouvent dans dns_event.rdata ou storage_event.rdata. Ces champs sont vides pour les événements refusés.
Logs de flux de trafic sortant
La table system.access.outbound_traffic enregistre les volumes de trafic agrégés, et non les demandes individuelles. Databricks regroupe le trafic en intervalles fixes d’une minute qui start et se terminent à la minute. Dans chaque intervalle, le trafic ayant le même workspace, la même adresse IP de destination et la même méthode de connexion est combiné en un seul enregistrement, et les octets envoyés et reçus sont additionnés.
Par exemple, le trafic entre 12:05:00 et 12:06:00 génère un enregistrement avec period_start_time = 12:05:00 et period_end_time = 12:06:00. L’heure de start est incluse et l’heure de fin est exclue. Ces Timestamp marquent les limites de l’intervalle, et non les heures des premiers et derniers paquets. Les intervalles sans trafic ne génèrent pas d’enregistrements.
La table system.access.outbound_traffic présente le schéma suivant :
Colonne | Type de données | Description |
|---|---|---|
| chaîne | Identifiant unique de l’enregistrement de trafic agrégé. |
| chaîne | ID du compte Databricks à l’origine du trafic. |
| chaîne | ID du workspace d’où provient le trafic. |
| chaîne | Adresse IP de destination. |
| bigint | Nombre total d’octets reçus par le compute serverless pendant l’intervalle. |
| bigint | Nombre d’octets envoyés par le compute serverless au cours de l’intervalle. |
| chaîne | Type de connectivité utilisé. La valeur est |
| chaîne | Méthode de connectivité utilisée. La valeur est |
| Horodatage | Start inclusif de l’intervalle d’une minute. |
| Horodatage | Fin exclusive de l’intervalle d’une minute. |
Relations entre les tables
system.access.outbound_network indique le Hostname de destination ou l’emplacement de stockage d’une requête. system.access.outbound_traffic indique l’adresse IP de destination, la méthode de connexion et le nombre d’octets transférés.
Pour les corréler, faites correspondre l’ID du compte, l’ID du workspace et l’adresse IP de destination résolue, puis vérifiez que event_time de l’événement d’accès se trouve dans l’intervalle du log de flux. Les deux tables ont des valeurs event_id indépendantes ; ne les joignez donc pas sur event_id.
Ces correspondances sont des corrélations basées sur l’adresse IP et l’heure. Ils ne relient pas un événement d’accès à une connexion réseau spécifique. Lorsque plusieurs hostnames sont résolus vers la même adresse IP, chaque hostname correspond aux mêmes enregistrements de flux.
Limitations
Les logs de trafic réseau étendus présentent les limitations suivantes :
-
Les événements autorisés ne sont pas consignés pour l’accès à des modèles externes depuis des Endpoint de Model Serving.
-
Les événements autorisés ne sont pas enregistrés pour les accès au stockage depuis les Workspace dont les contrôles de sortie Serverless sont en mode simulation.
-
Les événements autorisés ne sont pas consignés pour l’accès au stockage interne au workspace, comme les artefacts MLflow et dbt.
-
Les événements autorisés ne sont pas consignés pour l’accès au stockage du fournisseur OpenSharing.
-
Le trafic autorisé provenant de charges de travail exécutées pendant moins d’environ une minute est moins susceptible d’être consigné, en particulier dans le cas des charges de travail planifiées et non interactives, ainsi que des Workspace dont les politiques de sortie ne sont pas restrictives.
-
Les logs de flux du trafic sortant enregistrent uniquement le trafic acheminé via une passerelle réseau privée. Le trafic qui utilise une autre connectivité privée ou une sortie vers l’Internet public n’est pas journalisé.
-
Les logs de flux de trafic sortant n’enregistrent pas le trafic provenant d’Agent Bricks, de Unity Gateway ou des dossiers Git.
Ces limitations n’ont pas d’incidence sur l’application des contrôles de sortie Serverless ni sur la journalisation des requêtes refusées.
Questions fréquemment posées
Les questions suivantes portent sur les comportements courants que vous pourriez observer dans les logs étendus du trafic réseau.
Ai-je besoin des contrôles de sortie serverless pour utiliser les logs de trafic réseau étendus ?
Non. Les événements d’accès au réseau sortant autorisé sont également enregistrés pour les Workspace dotés de politiques d’accès sortant Serverless sans restriction.
Pourquoi des événements d’accès réseau apparaissent-ils après la fin d’une charge de travail ?
Databricks peut continuer à accéder au stockage après la fin d’une charge de travail, par exemple pour conserver les logs ou les métadonnées Delta. Ces requêtes peuvent générer des événements d’accès réseau lorsqu’aucune charge de travail utilisateur n’est en cours. Les événements cessent après l’arrêt de l’instance de compute serverless.
Pourquoi est-ce que je vois des Hostnames inconnus dans mes logs d’accès réseau ?
Certaines destinations consignées sont des ressources gérées par Databricks utilisées pour les opérations de la plateforme :
Motif de Hostname | Usage |
|---|---|
| Améliore les temps de Startup du Serverless compute. |
| Stockage par default de Databricks. |
| Accès aux datasets d’exemple default. |
Si vous voyez d’autres Hostname que vous ne reconnaissez pas, contactez l’équipe de votre compte Databricks.
Combien de temps faut-il pour que les logs de trafic réseau apparaissent ?
La plupart des événements d’accès au réseau sortant apparaissent dans les 15 minutes suivant la demande. La latence peut varier, et Databricks ne fournit pas d’accord de niveau de service (SLA) concernant la latence de ces logs.
Pourquoi ne puis-je pas trouver de log de flux correspondant à un événement d’accès réseau autorisé ?
Les logs de flux enregistrent uniquement le trafic acheminé via une passerelle de réseau privé ; les requêtes autorisées qui utilisent une autre connectivité n’ont donc aucun log de flux correspondant. L’absence d’un log de flux ne signifie pas que la requête a échoué ni qu’aucune donnée n’a été transférée.