Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Important
Cette fonctionnalité est en préversion privée. Pour l’essayer, contactez votre Azure Databricks contact.
Les journaux de trafic réseau étendus enregistrent le trafic réseau sortant depuis les ressources de calcul serverless Azure Databricks. Par défaut, la table système des événements d’accès réseau sortant enregistre uniquement les requêtes que les contrôles de sortie serverless refusent. Avec des journaux de trafic réseau étendus, il enregistre aussi les requêtes autorisées, ce qui vous permet de voir où vos charges de travail sans serveur se connectent et de dépanner la connectivité.
Les journaux étendus du trafic réseau ajoutent également une table de journaux de flux qui enregistre la quantité de données envoyées et reçues par les ressources de calcul serverless pour chaque adresse IP de destination. Les deux capacités utilisent les tables système suivantes :
| Capacité | Table système | Description |
|---|---|---|
| Événements d’accès réseau sortants autorisés | system.access.outbound_network |
Ajoute des requêtes sortantes autorisées à la table existante des requêtes refusées. |
| Journaux de flux de trafic sortant | system.access.outbound_traffic |
Enregistre les octets envoyés et reçus par adresse IP de destination, agrégés en intervalles d’une minute. |
Les journaux de flux de trafic sortant n’enregistrent que le trafic acheminé via une passerelle réseau privée.
Pour interroger les journaux, voir Interroger les journaux de trafic réseau étendu.
Cas d’utilisation
Utiliser les journaux de trafic réseau étendus pour :
- Étudiez l’activité réseau : Voyez à quelles destinations vos charges de travail serverless ont accédé, quand et depuis quel espace de travail.
- Affiner les stratégies réseau : identifiez les destinations rarement consultées et décidez de les supprimer de vos listes d’autorisation de sortie serverless.
- Dépanner la connectivité : Déterminer si les contrôles de sortie serverless ont permis ou refusé une requête.
- Étudiez les coûts réseau : Identifiez les destinations interrégionales, internet et privées accessibles par des charges de travail serverless.
- Optimisez la connectivité de stockage : Trouvez des destinations de stockage fréquemment consultées qui pourraient bénéficier d’une connectivité privée ou d’être dans la même région que vos charges de travail.
- Mesurer les volumes de trafic : Voir combien de données l’informatique serverless envoie et reçoit à chaque destination via une passerelle réseau privée.
- Détecter une activité inhabituelle : Trouver des destinations avec un volume de trafic inattendument élevé.
Fonctionnement
Événements d’accès réseau autorisés
L’extension des journaux de trafic réseau ajoute des événements ALLOWED à la table existante system.access.outbound_network. Cette table enregistre les événements d’accès réseau sortants issus de charges de travail serverless, y compris les entrepôts SQL, les jobs, les pipelines Lakeflow, les applications Databricks et les terminaux Model Serveing. Les événements autorisés couvrent les requêtes vers le stockage cloud, les destinations internet et les ressources accessibles via la connectivité privée. Pour le schéma complet de la table, voir la référence de la table système d’événements d’accès réseau.
La access_type colonne indique le résultat de chaque événement :
| Value | Description |
|---|---|
ALLOWED |
L’accès au réseau sortant était autorisé. Disponible uniquement avec des journaux de trafic réseau étendus. |
DROP |
L’accès au réseau sortant a été refusé par les contrôles d’egress serverless en mode d’application. |
DRY_RUN_DENIAL |
L’accès au réseau sortant aurait été refusé par les contrôles d’egress serverless, mais était autorisé car la politique était en mode simulation. |
Les valeurs access_type et destination_type enregistrées pour une requête dépendent de la destination et du mode de votre politique de sortie sans serveur :
| Requête réseau | Sortie sans restriction | Mode simulation | Mode Appliqué |
|---|---|---|---|
| Accès au stockage autorisé | ALLOWED / DNS |
Non connecté | ALLOWED / STORAGE |
| Accès au stockage en violation de la politique | Sans objet | DRY_RUN_DENIAL / DNS |
DROP / STORAGE |
| Accès autorisé aux ressources VNet | ALLOWED / DNS |
ALLOWED / DNS |
ALLOWED / DNS |
| Accès aux ressources VNet en violation de la politique | Sans objet | DRY_RUN_DENIAL / DNS |
DROP / DNS |
| Accès internet autorisé | ALLOWED / DNS |
ALLOWED / DNS |
ALLOWED / DNS |
| Accès Internet en violation de la politique | Sans objet | DRY_RUN_DENIAL / DNS |
DROP / DNS |
Pour les événements autorisés DNS , destination contient le nom de domaine ou le nom d’hôte de stockage. Pour les événements autorisés STORAGE , destination contient le nom d’hôte et le chemin de stockage. Les adresses IP de destination résolues sont dans dns_event.rdata ou storage_event.rdata. Ces champs sont vides pour les événements refusés.
Journaux de flux de trafic sortant
Le tableau system.access.outbound_traffic enregistre les volumes de trafic agrégés, et non les requêtes individuelles. Azure Databricks regroupe le trafic en intervalles fixes d’une minute qui commencent et se terminent à la minute exacte. Dans chaque intervalle, le trafic avec le même espace de travail, la même adresse IP de destination et la même méthode de connexion est combiné en un seul enregistrement, avec la somme des octets envoyés et reçus.
Par exemple, le trafic entre 12:05:00 et 12:06:00 produit un enregistrement avec period_start_time = 12:05:00 et period_end_time = 12:06:00. L’heure de début est inclusive et l’heure de fin est exclusive. Ces horodatages indiquent les frontières d’intervalle, et non les heures des premier et dernier paquets. Les intervalles sans trafic ne produisent pas d’enregistrements.
Le system.access.outbound_traffic tableau comporte le schéma suivant :
| Column | Type de données | Description |
|---|---|---|
event_id |
string | Identifiant unique pour l’enregistrement de trafic agrégé. |
account_id |
string | ID du compte Azure Databricks d’où provenait le trafic. |
workspace_id |
string | ID de l’espace de travail d’où provenait le trafic. |
destination_ip |
string | Adresse IP de destination. |
received_bytes |
bigint | Le total d’octets reçus par le calcul serverless pendant l’intervalle. |
sent_bytes |
bigint | Octets totaux envoyés par le calcul serverless pendant l’intervalle. |
connection_type |
string | Type de connectivité utilisé. La valeur est PRIVATE. |
connection_method |
string | Méthode de connectivité utilisée. La valeur est PRIVATE_NETWORK_GATEWAY. |
period_start_time |
timestamp | Début inclus de l’intervalle d’une minute. |
period_end_time |
timestamp | Fin exclusive de l’intervalle d’une minute. |
Comment les tables se rapportent
system.access.outbound_network vous indique le nom d’hôte de destination ou l’emplacement de stockage d’une requête.
system.access.outbound_traffic vous 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 de compte, l’ID de l’espace de travail et l’adresse IP de destination résolue, et vérifiez que l’horodatage de l’événement d’accès event_time se situe dans l’intervalle du journal de flux. Les deux tables ont des valeurs event_id indépendantes, donc ne faites pas de jointure sur event_id.
Ces correspondances sont des corrélations basées sur l’adresse IP et l’heure. Ils ne lient pas un événement d’accès à une connexion réseau spécifique. Lorsque plusieurs noms d’hôte se résolvent vers la même adresse IP, chaque nom correspond aux mêmes enregistrements de flux.
Limitations
Les journaux de trafic réseau étendus présentent les limitations suivantes :
- Les événements autorisés ne sont pas enregistrés pour les accès aux modèles externes depuis les points de terminaison Model Serving.
- Les événements autorisés ne sont pas enregistrés pour l’accès au stockage depuis les espaces de travail dont les contrôles de sortie sans serveur sont en mode simulation.
- Les événements autorisés ne sont pas enregistrés pour les accès au stockage interne de l’espace de travail, comme les artefacts MLflow et dbt.
- Les événements autorisés ne sont pas enregistrés pour l’accès au stockage du fournisseur OpenSharing.
- Le trafic autorisé provenant de charges de travail qui durent moins d’une minute est moins susceptible d’être enregistré, en particulier pour les charges de travail planifiées et non interactives ainsi que pour les espaces de travail avec des politiques de sortie non restreintes.
- Les journaux de flux de trafic sortant n’enregistrent que le trafic acheminé via une passerelle réseau privée. Le trafic utilisant d’autres connexions privées ou une sortie vers l’Internet public n’est pas enregistré.
- Les journaux de flux de trafic sortant n’enregistrent pas le trafic provenant d’Agent Bricks, Unity Gateway ou des dossiers Git.
Ces limitations n’affectent pas la manière dont les contrôles de sortie serverless sont appliqués ni comment les requêtes refusées sont enregistrées.
Questions fréquemment posées
Les questions suivantes abordent les comportements courants que vous pouvez observer dans les journaux de trafic réseau étendus.
Dois-je activer les contrôles du trafic sortant serverless pour utiliser les journaux étendus du trafic réseau ?
No. Les événements d’accès au réseau sortant autorisés sont également enregistrés pour les espaces de travail avec des politiques de sortie serverless non restreintes.
Pourquoi les événements d’accès réseau apparaissent-ils après la fin d’une charge de travail ?
Azure Databricks peut continuer à accéder au stockage après la fin d’une charge de travail, par exemple pour maintenir les journaux Delta ou les métadonnées. 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 s’arrêtent après l’arrêt de l’instance de calcul serverless.
Pourquoi est-ce que je vois des noms d’hôte inconnus dans mes journaux d’accès réseau ?
Certaines destinations enregistrées sont des ressources gérées par Azure Databricks utilisées pour les opérations de plateforme :
| Motif de nom d’hôte | Purpose |
|---|---|
databricks-prewarm-datasets* |
Améliore les temps de démarrage du calcul sans serveur. |
dbstorage* |
Azure Databricks stockage par défaut. |
system-tables* |
Accès aux jeux de données par défaut. |
Si vous voyez d'autres noms d'hôte que vous ne reconnaissez pas, contactez votre équipe de compte Azure Databricks.
Combien de temps faut-il pour que les journaux de trafic réseau apparaissent ?
La plupart des événements d’accès réseau sortants apparaissent dans les 15 minutes suivant la demande. La latence peut varier, et Azure Databricks ne fournit pas d'accord de niveau de service (SLA) de latence pour ces journaux.
Pourquoi ne puis-je pas trouver un journal de flux correspondant pour un événement d’accès réseau autorisé ?
Les journaux de flux n’enregistrent que le trafic acheminé via une passerelle réseau privée, donc les requêtes autorisées utilisant une autre connectivité n’ont pas de journal de flux correspondant. Un journal de flux manquant ne signifie pas que la requête a échoué ou qu’aucune donnée n’a été transférée.