Partager via

Configurer le runtime d’intégration auto-hébergé (SHIR) pour la collection Log Analytics

  • Article

S’APPLIQUE À : Azure Data Factory Azure Synapse Analytics

Conseil

Essayez Data Factory dans Microsoft Fabric, une solution d’analyse tout-en-un pour les entreprises. Microsoft Fabric couvre tous les aspects, du déplacement des données à la science des données, en passant par l’analyse en temps réel, l’aide à la décision et la création de rapports. Découvrez comment démarrer un nouvel essai gratuitement !

Prérequis

Un espace de travail Log Analytics disponible est requis pour cette approche. Nous vous recommandons de noter l’ID et la Clé d’authentification de l’espace de travail de votre espace de travail Log Analytics, car vous risquez d’en avoir besoin dans certains scénarios. Cette solution augmente le nombre de données envoyées à l’espace de travail Log Analytics et a un impact faible sur le coût global. Poursuivez la lecture pour plus d’informations sur la procédure de réduction d’une quantité de données au minimum.

Objectifs et scénarios

Centralisez les événements et les données des compteurs de performances dans votre espace de travail Log Analytics. La machine virtuelle hébergeant le SHIR doit d’abord être instrumentée de manière appropriée. Choisissez l’un des deux principaux scénarios ci-dessous.

Instrumentation de machines virtuelles locales

L’article Installer l’agent Log Analytics sur des ordinateurs Windows décrit la procédure d’installation du client sur un ordinateur virtuel généralement hébergé localement. Il peut s’agir d’un serveur physique ou d’une machine virtuelle hébergée sur un hyperviseur géré par le client. Comme mentionné dans la section préalable, lors de l’installation de l’agent Log Analytics, vous devez fournir l’ID et la clé d’espace de travail Log Analytics pour finaliser la connexion.

Instrumenter des machines virtuelles Azure

L’approche recommandée pour instrumenter un SHIR basé sur une machine virtuelle Azure consiste à utiliser des insights de machine virtuelle comme décrit dans l’article Activer la vue d’ensemble des insights de machine virtuelle. Il existe plusieurs façons de configurer l’agent Log Analytics lorsque le SHIR est hébergé sur une machine virtuelle Azure. Toute les options sont décrites dans l’article Vue d’ensemble de l’agent Log Analytics.

Configurer le journal des événements et la capture des compteurs de performances

Cette étape explique la procédure de configuration des journaux de l’observateur d’événements ainsi que des compteurs de performances à envoyer à Log Analytics. Les étapes décrites ci-dessous sont courantes, quelle que soit la façon dont l’agent a été déployé.

Sélectionner les journaux de l’observateur d’événements

Tout d’abord, vous devez collecter les journaux de l’observateur d’événements relatifs au SHIR, comme décrit dans l’article Collecter les sources de données du journal des événements Windows avec l’agent Log Analytics agent dans Azure Monitor.

Il est important de noter que lorsque vous choisissez les journaux des événements à l’aide de l’interface, il est normal de ne pas voir tous les journaux qui peuvent exister sur un ordinateur. Ainsi, les deux journaux dont nous avons besoin pour la surveillance SHIR ne s’affichent pas dans cette liste. Si vous tapez le nom de journal exactement tel qu’il apparaît sur la machine virtuelle locale, il sera capturé et envoyé à votre espace de travail Log Analytics.

Le nom du journal des événements que vous devez configurer est le suivant :

  • Connecteurs – Runtime d’intégration
  • Runtime d’intégration

Capture d’écran de la sélection des journaux pertinents SHIR avec des erreurs et des avertissements vérifiés.

Important

En laissant le niveau d'Information activé, vous augmentez considérablement le volume de données dans le cas où vous avez un grand nombre d’hôtes du SHIR déployés et un plus grand nombre d’analyses. Nous vous suggérons vivement de ne conserver que les erreurs et avertissements.

Sélectionner les compteurs de performances

Dans le même volet de configuration, vous pouvez cliquer sur Compteurs de performances Windows pour sélectionner les compteurs de performances individuels à envoyer à Log Analytics.

Important

Gardez à l’esprit que les compteurs de performances sont, par nature, un flux de données continu. Par conséquent, il est essentiel de prendre en compte l’impact de la collecte de données sur le coût total de votre déploiement Azure Monitor/Log Analytics. À moins qu’un budget autorisé d’ingestion de données n’ait été accordé et qu’une ingestion constante de données n’ait été autorisée et budgétisée à cette fin, la collecte des compteurs de performances ne doit être configurée que pour une période définie afin d’établir une ligne de base des performances.

Dans l’interface, lorsque vous la configurez pour la première fois, un ensemble de compteurs suggéré est recommandé. Sélectionnez ceux qui s’appliquent au type d’analyse des performances que vous souhaitez effectuer. % UC et Mémoire disponible sont des compteurs couramment analysés, mais d’autres, comme Consommation de bande passante réseau, peuvent être utiles dans les scénarios où le volume de données est important et la bande passante ou la durée d’exécution est limitée.

Capture d’écran de l’interface de sélection de compteur dans le Portail Azure.

Afficher les événements et les données des compteurs de performances dans Log Analytics

Pour savoir comment analyser les données de monitoring dans les journaux Azure Monitor ou le magasin Log Analytics en utilisant le Langage de requête Kusto (KQL), consultez Requêtes Kusto.

Les deux tables dans lesquelles la télémétrie est enregistrée sont respectivement appelées Performances et Événement. La requête suivante vérifie le nombre de lignes pour déterminer si des données circulent. Cela permet de confirmer que l’instrumentation décrite ci-dessus fonctionne.

Exemples de requêtes KQL

Vérifier le nombre de lignes

(
        Event 
        | extend TableName = "Event"
        | summarize count() by TableName
)     
| union
(     
        Perf
        | extend TableName = "Perf"
        | summarize count() by TableName
)

Interroger les événements

Récupérer les 10 premières lignes d’événements
Event
| take 10
Récupérer le nombre d’événements par gravité du message
Event
| summarize count() by EventLevelName
Afficher un graphique à secteurs du nombre selon la gravité du message
Event
| summarize count() by EventLevelName
| render piechart
Récupérer toutes les erreurs avec une chaîne de texte particulière

Ici, nous recherchons tous les messages contenant le mot déconnecté.

Event
| where RenderedDescription has "disconnected"
Recherche de plusieurs tables pour un mot clé sans connaître le schéma

La commande de recherche est utile lorsqu’on ne sait pas quelle colonne contient les informations. Cette requête retourne toutes les lignes des tables spécifiées qui ont au moins une colonne contenant le terme recherché. Le mot est déconnecté dans cet exemple.

search in (Perf, Event) "disconnected"
Récupérer tous les événements d’un journal spécifique

Dans cet exemple, nous affinons la requête dans le journal intitulé Connecteurs – Runtime d’intégration.

Event 
| where EventLog == "Connectors - Integration Runtime"
Les intervalles de temps permettent de limiter les résultats d’une requête

Cette requête utilise la même requête que ci-dessus, mais limite les résultats à ceux datant de 2 jours ou moins.

Event 
| where EventLog      == "Connectors - Integration Runtime"
  and   TimeGenerated >= ago(2d)

interroger les données du compteur de performances

Récupérer les 10 premiers relevés de compteur de performances
Perf
| take 10
Récupérer un compteur spécifique avec des contraintes de temps
Perf
| where     TimeGenerated >= ago(24h)
        and ObjectName    == "Network Adapter"
        and InstanceName  == "Mellanox ConnectX-4 Lx Virtual Ethernet Adapter"
        and CounterName   == "Bytes Received/sec"

Les compteurs de performances sont hiérarchiques par nature, n’oubliez donc pas d’avoir suffisamment de prédicats where dans votre requête pour ne sélectionner que le compteur spécifique dont vous avez besoin.

Récupérer au 95e centile pour un compteur donné classé par tranches de 30 minutes au cours des dernières 24 heures

Cet exemple correspond à tous les compteurs d’une carte réseau spécifique.

Perf
| where     TimeGenerated >= ago(24h)
        and ObjectName    == "Network Adapter"
        and InstanceName  == "Mellanox ConnectX-4 Lx Virtual Ethernet Adapter"
| project TimeGenerated, Computer, ObjectName, InstanceName, CounterName, CounterValue
| summarize percentile(CounterValue, 95) by bin(TimeGenerated, 30m), Computer, ObjectName, InstanceName, CounterName
Les variables permettent de réutiliser le code

Ici, nous définissons le nom d’objet et le nom de compteur comme une variable afin de ne pas devoir modifier le corps de la requête KQL pour apporter des modifications ultérieures à ces sélections.

let pObjectName  = "Memory"; // Required to select the right counter
let pCounterName = "Available MBytes"; // Required to select the right counter
Perf
| where Type == "Perf" and ObjectName == pObjectName and CounterName == pCounterName
| project TimeGenerated, Computer, CounterName, CounterValue
| order by TimeGenerated asc 
| summarize Value=max(CounterValue) by CounterName, TimeStamps=TimeGenerated

Contenu connexe