Notes
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.
Les règles de collecte de données (DCR) déterminent comment collecter et traiter les données de télémétrie envoyées à Azure. Certaines règles de collecte de données sont créées et gérées par Azure Monitor, tandis que vous pouvez créer d’autres pour personnaliser la collecte de données pour vos besoins particuliers. Cet article décrit certaines bonnes pratiques qui doivent être appliquées lors de la création de vos propres DCR.
Lorsque vous créez une DCR, certains aspects doivent être pris en compte comme suit :
- Type de données collectées, également appelée type de source de données (performances, événements)
- Machines virtuelles cibles auxquelles la DCR est associée
- Destination des données collectées
La prise en compte de tous ces facteurs est essentielle pour une bonne organisation DCR. Tous les points ci-dessus ont un impact sur l’effort de gestion DCR ainsi que sur la consommation des ressources pour le transfert et le traitement de configuration.
Étant donné la granularité native, qui permet à une DCR donnée d’être associée à plusieurs machines virtuelles cibles et inversement, il est important de garder les DCR aussi simples que possible en utilisant le moins de sources de données possible. Il est également important de conserver la liste des éléments collectés dans chaque source de données maigre et orientée vers l’étendue d’observabilité.
Pour clarifier ce qu’une étendue d’observabilité peut être, pensez-y comme votre limite logique préférée pour collecter des données. Par exemple, une étendue possible peut être un ensemble de machines virtuelles exécutant des logiciels (par exemple, SQL Server) nécessaires pour une application spécifique, ou des compteurs de système d’exploitation de base ou des événements définis par vos administrateurs informatiques. Il est également possible de créer des étendues similaires dédiées à différents environnements (développement, test, production) pour se spécialiser encore plus.
En fait, il n’est pas idéal et même pas recommandé de créer une DCR unique contenant toutes les sources de données, éléments de collecte et destinations pour implémenter l’observabilité. Dans le tableau suivant, il existe plusieurs recommandations qui pourraient aider à mieux planifier la création et la maintenance de DCR :
| Catégorie | Meilleure pratique | Explication | Zone d’impact |
|---|---|---|---|
| Collecte de données | Définissez l’étendue d’observabilité. | La définition de l’étendue d’observabilité est essentielle pour une gestion et une organisation de l'étendue d’observabilité DCR plus aisées et réussies. Il aide à clarifier quels sont les besoins de la collection et sur quelle machine virtuelle cible elle doit être réalisée. Comme expliqué précédemment, une étendue d’observabilité peut être un ensemble de machines virtuelles exécutant des logiciels communs à une application spécifique, un ensemble d’informations courantes pour le service informatique, etc. Par exemple, la collecte des compteurs de performances du système d’exploitation de base, tels que l’utilisation du processeur, la mémoire disponible et l’espace disque libre, peut être considérée comme une étendue pour votre gestion informatique centrale. | Le fait de ne pas avoir une étendue clairement définie n’apporte pas de clarté et ne permet pas une gestion appropriée. |
| Créez des règles de collecte de données spécifiques à l’étendue de l’observabilité. | La création de contrôleurs de domaine distincts en fonction de l’étendue d’observabilité est essentielle pour faciliter la maintenance. Il vous permet d'associer facilement les DCRs aux machines virtuelles cibles pertinentes. | Pourquoi créer une base de données unique qui collecte des compteurs de performances du système d’exploitation ainsi que des compteurs de serveur web et des compteurs de base de données ensemble ? Cette approche force chaque machine virtuelle associée à transférer, traiter et exécuter la configuration qui se trouve en dehors de l’étendue. Elle nécessite également davantage d’efforts lorsque la configuration DCR doit être mise à jour. Réfléchissez à la gestion d’un modèle qui inclut des entrées inutiles ; cette situation est inférieure à l’idéal et laisse place aux erreurs. | |
| Créez DCR spécifique au type de source de données dans les étendues d’observabilité définies. | La création de règles de collecte de données distinctes pour les performances et les événements aide à gérer la configuration et l’association à la précision en fonction des machines cibles. Par exemple, la création d’un DCR pour collecter les événements et les compteurs de performances peut entraîner une approche non optimale. Il peut arriver qu’un ordinateur donné (ou un ensemble d’ordinateurs) ne dispose pas des journaux d’événements ou des compteurs de performances configurés dans la DCR. Dans ce cas, les machines virtuelles sont forcées de traiter et d’exécuter une configuration qui n’est pas nécessaire en fonction du logiciel installé sur celui-ci. | Ne pas utiliser de règles de collecte de données différentes oblige chaque machine virtuelle associée à transférer, traiter et exécuter la configuration qui pourrait ne pas être applicable en fonction du logiciel installé. Une consommation excessive de ressources de calcul et des erreurs dans la configuration du traitement peut se produire à l’origine de l’absence de réponse de l’agent Azure Monitor (AMA ). De plus, la collecte de données inutiles augmente les coûts d’ingestion des données. | |
| Destination des données | Créez différentes DCR en fonction de la destination. | Les DCR (Data Collection Rules) ont la capacité d'envoyer des données simultanément à plusieurs destinations différentes, comme Azure Monitor Metrics et Azure Monitor Logs. Avoir des exigences de contrôle des données spécifiques à la destination est utile pour gérer les exigences en matière de souveraineté ou de législation sur les données. Étant donné que la conformité peut nécessiter l’envoi de données uniquement aux référentiels autorisés créés dans des régions autorisées, le fait que différents contrôleurs de domaine autorisent un ciblage de destination plus précis. | Si vous ne séparez pas les DCR en fonction de la destination des données, cela peut entraîner une non-conformité avec la gestion des données, la protection des données personnelles et les exigences d’accès. Cela peut également entraîner une collecte de données inutile, ce qui entraîne des coûts inattendus. |
Les principes mentionnés précédemment constituent une base pour créer votre propre approche de gestion DCR qui équilibre la facilité de maintenance, la facilité de réutilisation, la granularité et les limites de service. Les contrôleurs de domaine ont également besoin d’une gouvernance partagée pour minimiser la création de silos et la duplication inutile du travail.