VMware Aria Operations for Logs, anciennement vRealize Log Insight, reste un composant utile lorsque l’on exploite un cluster vSphere et que l’on veut éviter de diagnostiquer les incidents uniquement à partir de journaux dispersés entre les hôtes ESXi, vCenter Server, les appliances de sauvegarde et les équipements réseau ou de stockage. Son rôle n’est pas de remplacer la supervision métrique : il centralise, indexe et corrèle des événements textuels afin de réduire le temps nécessaire pour passer d’une alerte à une cause probable.

Dans une infrastructure vSphere moderne, cette centralisation prend de l’importance avec la multiplication des couches : vCenter Server Appliance, clusters ESXi, vSAN éventuel, baies SAN ou NAS, commutateurs, pare-feu, solutions de sauvegarde, services d’identité et outils de sécurité. Un même incident peut produire des indices à plusieurs endroits. Une perte temporaire de chemin de stockage, par exemple, peut être visible dans vmkernel.log sur plusieurs hôtes, dans les événements vCenter, puis dans les journaux de la baie. Sans plateforme de collecte, reconstituer cette chronologie reste manuel et incomplet.

Le rôle d’Aria Operations for Logs dans un cluster vSphere

Aria Operations for Logs collecte principalement les journaux Syslog émis par les composants VMware et par des systèmes tiers. Une fois reçus, les messages sont indexés et rendus recherchables. La plateforme apporte ensuite plusieurs fonctions pratiques pour l’exploitation :

Il faut distinguer cette approche de celle d’Aria Operations. Aria Operations travaille surtout à partir de métriques, de relations entre objets et de modèles de capacité ou de performance. Il peut détecter une hausse anormale de latence de datastore, une saturation CPU ou une pression mémoire. Aria Operations for Logs répond plutôt à la question : quels messages précis ont été émis au moment où la latence a augmenté ?

Cette distinction est particulièrement importante lors des incidents intermittents. Un problème de multipathing FC ou iSCSI peut ne durer que quelques secondes. Les graphes de performance peuvent confirmer une anomalie, tandis que les messages APD, PDL, NMP, HBA ou vmhba dans les logs ESXi aideront à identifier le mécanisme.

Préparer l’architecture et installer l’appliance

Pour une installation simple, Aria Operations for Logs est déployé sous la forme d’une appliance virtuelle OVA. En production, l’architecture doit être dimensionnée en fonction du volume journalier, de la durée de rétention, de la recherche concurrente et du nombre de sources. Un petit environnement peut fonctionner avec un nœud unique ; une plateforme d’exploitation critique doit prévoir un cluster de nœuds, une stratégie de sauvegarde et une capacité de stockage suffisante.

Avant le déploiement, définir au minimum les éléments suivants :

La synchronisation horaire mérite une attention particulière. Si les horodatages divergent entre vCenter, ESXi et les équipements externes, la corrélation devient trompeuse. Dans les analyses de bascule HA ou de perte de stockage, quelques minutes de décalage suffisent à inverser une relation de cause à effet. Pour aller plus loin, consultez le comparatif Prometheus, Grafana et Aria Operations.

Après import de l’OVA depuis le client vSphere, démarrer l’appliance et ouvrir son interface HTTPS. L’assistant initial permet de configurer l’identité du nœud, les paramètres réseau, le stockage et le compte d’administration. Dans le cas d’un cluster, le premier nœud est initialisé comme nœud principal, puis les suivants rejoignent le cluster au moyen de la procédure proposée par l’interface.

Pour les environnements soumis à des exigences de sécurité, éviter de conserver le certificat auto-signé fourni par défaut. Importer un certificat signé par l’autorité de certification interne ou publique appropriée, avec les noms DNS réellement utilisés. Vérifier également les algorithmes TLS autorisés, la journalisation des accès d’administration et la configuration des comptes locaux ou fédérés.

Le dimensionnement ne doit pas être réduit à la taille de disque initiale. La donnée indexée, les champs extraits, les recherches fréquentes et la rétention ont un impact direct. Il est préférable de commencer par mesurer le débit réel d’événements généré pendant une période représentative, incluant les sauvegardes, les mises à jour et les incidents simulés. La rétention réglementaire peut aussi justifier un export vers une plateforme d’archivage plutôt qu’une conservation indéfinie dans l’appliance.

Configurer les sources vSphere et la collecte Syslog

La première étape opérationnelle consiste à connecter vCenter Server à Aria Operations for Logs. Cette intégration facilite la découverte des hôtes ESXi et l’accès aux contenus VMware adaptés. Selon la version déployée, elle s’effectue depuis l’administration d’Aria Operations for Logs ou via l’interface de gestion vCenter.

La centralisation des journaux accélère le diagnostic d'incident.
La centralisation des journaux accélère le diagnostic d'incident.

Ensuite, configurer les hôtes ESXi pour envoyer leurs événements Syslog vers la plateforme. Le protocole UDP est simple à mettre en œuvre, mais il n’offre ni garantie de livraison ni chiffrement. En production, privilégier TCP, ou TLS lorsque l’environnement et la version le permettent. Le choix dépend aussi des contraintes de compatibilité et des mécanismes de collecte disponibles.

Exemple avec PowerCLI pour définir une cible Syslog TCP sur l’ensemble des hôtes d’un cluster :

Connect-VIServer -Server vcsa.lab.local

$cluster = Get-Cluster -Name "Cluster-Production"
$syslogTarget = "tcp://aria-logs.lab.local:514"

Get-VMHost -Location $cluster | ForEach-Object {
    Set-VMHostAdvancedConfiguration -VMHost $_ `
        -Name "Syslog.global.logHost" `
        -Value $syslogTarget

    Get-VMHostService -VMHost $_ |
        Where-Object { $_.Key -eq "TSM-SSH" } |
        Out-Null
}

La modification est généralement prise en compte rapidement, mais il faut valider la réception réelle dans l’interface d’Aria Operations for Logs. Rechercher le nom d’un hôte ESXi, puis générer un événement contrôlé, par exemple une opération de maintenance planifiée ou une connexion administrative autorisée. Ne pas considérer la configuration terminée tant que les messages hostd, vpxa et vmkernel ne sont pas visibles.

Une configuration directe depuis l’ESXi Shell peut aussi être utile pour un diagnostic ciblé :

esxcli system syslog config set --loghost='tcp://aria-logs.lab.local:514'
esxcli system syslog reload
esxcli system syslog config get

L’ouverture du flux réseau doit être validée entre les VMkernel de gestion des ESXi et l’appliance de logs. Dans une conception segmentée, le trafic Syslog ne doit pas nécessairement emprunter le même réseau que vMotion ou le stockage. L’important est de documenter le chemin, les règles de filtrage et les dépendances DNS.

Ne limitez pas la collecte à ESXi. Les sources suivantes apportent souvent une valeur immédiate :

Pour les systèmes non VMware, le format Syslog facilite l’intégration. Les journaux Windows peuvent nécessiter un agent ou un collecteur compatible. Dans tous les cas, normaliser les noms d’hôtes et maintenir un inventaire des sources est essentiel : une recherche efficace dépend de métadonnées cohérentes.

Construire des alertes utiles sur le stockage et HA

Une plateforme de logs échoue souvent non pas parce qu’elle ne collecte rien, mais parce qu’elle produit trop d’alertes peu exploitables. Une alerte doit être associée à une action claire : ouvrir un ticket, vérifier un équipement précis, collecter des éléments de preuve ou escalader vers une équipe donnée.

Pour le stockage, les événements critiques ESXi à surveiller comprennent notamment les pertes de chemin, les indisponibilités de périphérique, les messages liés à l’adaptateur HBA et les erreurs de connectivité iSCSI ou NFS. Les termes exacts varient selon le protocole et les versions, mais les recherches initiales peuvent inclure : Pour aller plus loin, consultez la sécurisation d’un cluster.

source=esxi AND (
  "All Paths Down" OR
  "Permanent Device Loss" OR
  "Lost access to volume" OR
  "NMP" OR
  "vmhba" OR
  "iSCSI" OR
  "NFS"
)

Cette requête n’est pas encore une bonne alerte. Elle doit être affinée pour éviter les faux positifs, par exemple lors d’un retrait de LUN planifié, d’une maintenance de baie ou d’une opération de mise à jour. Une stratégie robuste consiste à combiner plusieurs conditions :

  1. détecter le pattern critique ;
  2. regrouper les événements par hôte et par datastore ou périphérique ;
  3. déclencher uniquement si plusieurs occurrences surviennent dans une fenêtre courte ;
  4. enrichir la notification avec l’hôte, le datastore, le chemin concerné et un lien vers la recherche ;
  5. prévoir une fenêtre de maintenance qui inhibe les alertes attendues.

Pour les échecs ou événements HA, rechercher les messages provenant de fdm, le composant VMware High Availability, ainsi que les événements vCenter liés à l’isolation d’hôte, au redémarrage de VM et à la perte de heartbeat. Un point important : un redémarrage HA n’est pas systématiquement un défaut HA. Il peut être la conséquence d’une perte d’alimentation, d’un problème réseau, d’une panne matérielle ou d’une indisponibilité de datastore.

Exemple de recherche de départ :

source=vcsa OR source=esxi AND (
  "fdm" OR
  "Host is isolated" OR
  "vSphere HA" OR
  "failover" OR
  "restart virtual machine"
)

Créer ensuite plusieurs alertes plutôt qu’une alerte générique unique :

Les alertes les plus critiques doivent intégrer une notion de contexte. Par exemple, un unique message de perte de heartbeat peut résulter d’un incident réseau bref. En revanche, la même condition accompagnée d’une hausse d’erreurs réseau, d’une indisponibilité de datastore ou de plusieurs hôtes affectés justifie une priorité supérieure.

La notification peut être transmise par e-mail, webhook ou intégration ITSM, selon les connecteurs disponibles dans l’environnement. Éviter de publier directement chaque ligne de log dans un outil de ticketing. Il vaut mieux envoyer un résumé avec une recherche enregistrée, une période temporelle précise et les attributs permettant au destinataire de qualifier l’incident.

Une recherche ciblée dans les logs révèle la cause d'un problème.
Une recherche ciblée dans les logs révèle la cause d'un problème.

Corréler Aria Operations et Aria Operations for Logs

L’intégration avec Aria Operations vise à rapprocher les métriques de performance et les événements textuels. Concrètement, lorsqu’Aria Operations détecte un symptôme sur un objet vSphere, l’administrateur peut accéder à des logs associés depuis le contexte de cet objet ou de la période concernée, selon les versions et les connecteurs configurés.

Le bénéfice est concret dans plusieurs cas :

La configuration doit être vérifiée à deux niveaux. D’abord, les objets vCenter doivent être correctement inventoriés dans Aria Operations : vCenter, datacenters, clusters, hôtes, datastores et VM. Ensuite, les sources de logs doivent utiliser des noms et horodatages cohérents. Si Aria Operations connaît un hôte sous son FQDN tandis que les logs utilisent uniquement un nom court ou une adresse IP, les liens de corrélation peuvent être incomplets.

Définir quelques procédures de diagnostic répétables est recommandé. Par exemple, pour une alerte de stockage :

  1. identifier dans Aria Operations les datastores, hôtes et VM affectés ;
  2. relever la fenêtre temporelle de début de dégradation ;
  3. ouvrir la recherche Aria Operations for Logs sur cette période ;
  4. filtrer d’abord par les hôtes concernés ;
  5. élargir ensuite aux baies, switches et composants de sauvegarde ;
  6. conserver la recherche ou exporter les éléments utiles au dossier d’incident.

Cette méthode réduit les recherches au hasard et rend les analyses comparables entre équipes.

Alternatives open source : Loki et ELK

Le coût de licence, l’orientation produit ou les contraintes d’indépendance peuvent conduire à choisir une solution open source. Deux familles sont fréquemment évaluées : Grafana Loki et la pile Elastic, souvent appelée ELK même si les composants et licences ont évolué.

Grafana Loki adopte une approche d’indexation principalement fondée sur les labels plutôt que sur l’indexation complète de chaque mot de chaque message. Cette conception peut limiter les coûts d’indexation et s’intègre naturellement à Grafana pour les recherches, tableaux de bord et alertes. Pour des logs ESXi, un collecteur tel que rsyslog, syslog-ng, Fluent Bit ou Grafana Alloy peut recevoir le Syslog, enrichir les messages avec des labels comme site, cluster, host ou environment, puis les envoyer vers Loki. Pour aller plus loin, consultez l’administration quotidienne d’ESXi.

La prudence est nécessaire avec les labels à forte cardinalité. Ne pas utiliser comme labels des identifiants uniques, des UUID de VM ou des messages complets. Ces valeurs doivent rester dans le contenu du log, faute de quoi les performances et les coûts peuvent se dégrader fortement.

La pile Elastic fournit une recherche très riche, avec Elasticsearch pour l’indexation, Logstash ou des collecteurs Beats/Elastic Agent pour l’ingestion et Kibana pour la visualisation. Elle convient bien lorsque l’analyse plein texte, les pipelines d’enrichissement et les corrélations complexes sont prioritaires. En contrepartie, l’exploitation est plus exigeante : gestion du cycle de vie des index, capacité mémoire, partitionnement, sauvegardes, sécurité, montée de version et coût de stockage.

Un chemin de collecte générique vers Elastic peut s’appuyer sur syslog-ng ou Logstash :

input {
  tcp {
    port => 514
    type => "esxi-syslog"
  }
}

filter {
  if [type] == "esxi-syslog" {
    mutate {
      add_field => { "platform" => "vsphere" }
    }
  }
}

output {
  elasticsearch {
    hosts => ["https://elasticsearch.example.local:9200"]
    index => "vsphere-logs-%{+YYYY.MM.dd}"
  }
}

Le choix ne doit pas se limiter au prix de licence. Aria Operations for Logs apporte une intégration vSphere directe, des contenus prêts à l’emploi et une administration homogène pour les organisations déjà équipées de la suite Aria. Loki ou Elastic peuvent réduire la dépendance à l’écosystème VMware, mais transfèrent une partie de la charge vers la conception, l’exploitation et le maintien en conditions opérationnelles de la plateforme de logs.

Quelle que soit la solution retenue, les fondamentaux restent identiques : horodatage fiable, transport sécurisé, normalisation des sources, rétention maîtrisée, alertes actionnables et tests réguliers. Une centralisation de logs qui n’est jamais consultée avant un incident est un simple dépôt de données. Une plateforme utile est celle dont les recherches, tableaux de bord et alertes sont intégrés aux procédures quotidiennes d’exploitation.