Explorez

Nouveau connecteur: Azure Log Analytics

Par Nicolas Jançon

31 janvier 2023 • 4 minutes de lecture

Les choses sont ainsi faites: les métriques les plus difficiles à collecter pour un outil de monitoring d’infrastructure sont toujours cachées au fond des logs. Les logs c’est bien mais il y a des millions voir des milliards de lignes à analyser. Leurs structures sont variées et nécessitent de s’outiller pour les analyser à grande échelle.

Alors les cloud providers ont trouvé une solution en fournissant à la fois des puits de données structurées et un langage pour les interroger. C’est le cas d’Azure avec Azure Log Analytics qui partage son langage requête: Kusto Query Language (KQL) avec Azure Data Explorer (ADX).

Pourquoi utiliser des requêtes Kusto ?

KQL permet tout d’abord d’accéder à la donnée plus rapidement qu’avec d’autres langages SIEM. Cette notion de rapidité permet d’effacer au mieux l’impact que peut parfois représenter la surveillance de systèmes.

Aujourd’hui, les mécanismes internes de Microsoft (Azure, 365, Sentinel, Logs Analytics,…) utilisent tous KQL. Dès lors que l’on travaille avec des environnements cloud Microsoft, il devient donc intéressant de se pencher sérieusement sur cette technologie. KQL est devenu le standard. Bien que les requêtes puissent paraître un peu complexes au début, elles sont au final assez abordables et offrent d’excellentes possibilités.

Commencer à travailler avec KQL nécessite de bien comprendre le workflow: choisir une source de données, faire un filtre, exporter les résultats.

Architecture Azure logs

Que peut-on faire avec les logs Azure ?

Nous pouvons utiliser ces requêtes Kusto pour mettre en évidence différentes choses: découvrir des modèles, identifier des anomalies et des valeurs aberrantes, créer des modèles statistiques, etc.

La supervision transversale IaaS

Le premier cas pratique que l’on peut envisager est la supervision à grande échelle.

Gérer des seuils et des modèles d’alerte est fastidieux. Imaginez: vous avez des milliers de serveurs virtuels. Ne serait-il pas plus simple d’écrire une requête lancée régulièrement remontant une liste des ressources dont la CPU dépasse 90% que de positionner une alerte sur chacune d’entre elles ?

Oui probablement.

En analysant les logs de ces ressources avec la requête Kusto appropriée, on peut facilement mettre en place ce type supervision.

Et pour le PaaS ?

Les logs sont moins structurés que pour le IaaS ce qui est normal compte tenu de la diversité des types de ressources qui ont chacune des fonctions différentes. Les logs ne vont donc pas tant servir à une supervision transversale que d’obtenir des métriques qui ne sont disponibles nulle part ailleurs.

Ecrire une requête compatible avec votre outil de supervision

Une question de philosophie

Pour écrire une requête Kusto exploitable par votre outil de supervision, ce n’est pas qu’une question de format. Il faut d’abord bien comprendre la nature de la donnée que l’outil de supervision est capable d’ingérer.

Un outil de supervision d’infrastructure ne comprend que très peu de chose. Ca se résume en général à un couple nom de métrique, valeur voir une unité, obtenu à chaque « check » et qui finit par produire une information de type time series. La nature de la valeur est habituellement un numérique représentant une grandeur. Il peut aussi s’agir d’un numérique représentant un état que l’on peut convertir en quelque chose de compréhensible par l’humain grâce à une mise en forme. Enfin il peut s’agir d’une chaine de caractères que l’outil de supervision pourra au moins afficher sinon comparer avec une valeur attendue ou non.

Et c’est à peu près tout.

Il va donc falloir concevoir une requête capable de produire des données de cette nature.

Par l’exemple…

Web codes

Voici un premier exemple très simple où nous récupérons les métriques d’un VPS toutes les minutes.

En Kusto:

InsightsMetrics
| where TimeGenerated > ago(1m)
| project Name, Val
| project-rename channel=Name
| project-rename value=Val
| extend unit = "count"
| project channel, value, unit

Résultat produit par Senhub:

{
   "metrics":[
      {
         "channel":"Heartbeat",
         "value":1,
         "unit":"count"
      },
      {
         "channel":"AvailableMB",
         "value":4862.234375,
         "unit":"count"
      },
      {
         "channel":"UtilizationPercentage",
         "value":4.35947904016081,
         "unit":"count"
      },
      {
         "channel":"Status",
         "value":1,
         "unit":"count"
      },
      {
         "channel":"FreeSpacePercentage",
         "value":82.5041931865706,
         "unit":"count"
      },
      {
         "channel":"FreeSpaceMB",
         "value":130851,
         "unit":"count"
      },
      {
         "channel":"ReadsPerSecond",
         "value":0,
         "unit":"count"
      },
      {
         "channel":"WritesPerSecond",
         "value":3.89975033635857,
         "unit":"count"
      },
      {
         "channel":"TransfersPerSecond",
         "value":3.89975033635857,
         "unit":"count"
      },
      {
         "channel":"ReadBytesPerSecond",
         "value":0,
         "unit":"count"
      },
      {
         "channel":"WriteBytesPerSecond",
         "value":31741.9678659914,
         "unit":"count"
      },
      {
         "channel":"BytesPerSecond",
         "value":31741.9678659914,
         "unit":"count"
      },
      {
         "channel":"ReadBytesPerSecond",
         "value":4851.87810796918,
         "unit":"count"
      },
      {
         "channel":"WriteBytesPerSecond",
         "value":3432.47227674577,
         "unit":"count"
      }
   ],
   "message":"Metrics successfully retrieved.",
   "status":"OK",
   "date":1675348657292
}

Dans votre outil de supervision:

Zabbix graph rendering

Logins

On pourrait aussi avoir envie de suivre les connexions utilisateurs pour une période donnée. Azure Log Analytics se connecte à Azure AD, donc on va donc pouvoir interroger la table SigninLogs. En définissant les filtres voulus par date, heure et en choisissant la sortie, on pourrait avoir une requête de ce type:

SigninLogs
| where TimeGenerated between (datetime(2023-01-17) .. datetime(2023-01-27))
| summarize Logins=count() by UserPrincipalName
| order by UserPrincipalName asc

En ajustant un peu les filtres, on pourrait arriver à celle-ci:

SigninLogs
| where TimeGenerated between (datetime(2023-01-17) .. datetime(2023-01-27))
| where LocationDetails contains "Nantes"
| where AuthenticationRequirement =~ 'singleFactorAuthentication'
| where UserDisplayName =~ "Max Durand"
| where AppDisplayName =~ "Azure Portal"
| project UserId, UserPrincipalName, UserType, Location

Conclusion

Le Senhub fournit avec ce connecteur un véritable couteau suisse du monitoring Azure. Nous ne sommes désormais plus limités aux seuls métriques proposés par les APIs Azure mais avons la capacité:

d’accéder à des données non disponible via les APIs
d’agencer ces informations selon des besoins particuliers
d’envisager une autre façon de gérer son alerting à grande échelle

Ce n’est qu’un début. Il est déjà plus que probable que nous améliorons notre connecteur avec la prise en compte des workbooks et la mise à disposition de requêtes standards pour vous permettre de créer votre monitoring encore plus rapidement !

Le Senhub en quelques mots

Créé par des experts du monitoring IT pour leurs clients, le Senhub étend la capacité des outils de monitoring d’infrastructure en fournissant des connecteurs riches et puissants vers de nombreux fournisseurs Cloud.

Pour en savoir plus: https://senhub.io

Connecteurs Tout sur le Senhub

you-can-have-a-look-to-senhub-right-now-2

Vous pouvez jeter un œil au Senhub,
Maintenant

Une preuve de concept vaut toutes les grandes explications. Vous pouvez essayer Senhub dès maintenant et sans engagement.

Créez simplement votre compte (aucune carte de crédit n’est requise) et commencez à surveiller vos assets Cloud avec votre propre outil de monitoring IT.

Si vous avez des questions, envoyez-nous un courriel à contact@senhub.io ou chatter directement avec un de nos helpers.

Essayez en Live