Les logs Meraki sont très pratiques pour comprendre ce qui s’est passé sur un réseau : un client WiFi qui ne s’associe plus, un port de switch qui change d’état, un bail DHCP, une alerte de sécurité, une modification de configuration, etc.

Mais il y a un point important à connaître : tous les logs Meraki ne se conservent pas de la même manière, ni pendant la même durée. Et lorsqu’on cherche un événement ancien dans le Dashboard, il faut savoir si l’on parle d’un événement lié à un client ou d’un événement lié à un équipement Meraki.

Ce qu’il faut retenir

  • Dans Network-wide > Monitor > Event log, Meraki distingue notamment les événements liés aux clients et ceux liés aux appareils Meraki.
  • Les device event logs sont conservés jusqu’à 3 mois dans le Dashboard.
  • Les client event logs peuvent remonter jusqu’à 12 mois, mais il faut rechercher un client précis pour consulter les événements entre 3 et 12 mois.
  • Une recherche générale d’événements plus vieux que 3 mois peut donc afficher “No matching events found”, même si des logs clients existent encore.
  • L’export Dashboard est limité : on ne peut pas télécharger plus de 1000 événements à la fois.
  • Pour une conservation longue durée, pour de l’audit ou pour une exploitation SIEM, il faut prévoir un serveur syslog.

Deux familles de logs à ne pas confondre

Dans un réseau Meraki, on peut simplifier en distinguant deux grands types de logs d’événements.

Les logs d’événements clients concernent les terminaux connectés au réseau : PC, téléphones, tablettes, imprimantes, scanners, équipements IoT, terminaux métiers. Ce sont les événements utiles pour comprendre la vie d’un client réseau : association WiFi, authentification, attribution DHCP, connexion à un SSID, changements de connectivité, etc.

Les logs d’événements d’appareils Meraki concernent les équipements d’infrastructure : points d’accès MR, switches MS, appliances MX, gateways, etc. Ils aident à diagnostiquer ce qui se passe côté réseau : redémarrage, perte de connectivité, événement de port, événement VPN, changement d’état, alerte sécurité, information système.

La différence est importante, car la profondeur d’historique n’est pas la même.

Combien de temps les logs sont-ils disponibles ?

D’après la documentation Meraki, le Dashboard peut conserver les device event logs jusqu’à 3 mois et les client event logs jusqu’à 12 mois. Concrètement, si vous cherchez “ce qui s’est passé sur ce switch il y a 6 mois”, le Dashboard ne sera probablement pas suffisant. Si vous cherchez “ce qui est arrivé à ce client précis il y a 6 mois”, la recherche peut encore fonctionner, à condition de filtrer sur ce client.

Meraki précise aussi que certains tableaux de logs, dont le Change Log et l’Event Log, sont surtout limités par un nombre d’entrées. Même si des durées sont affichées par type de donnée, Meraki ne garantit l’activité de journalisation que sur 30 jours pour les Change Logs et Event Logs. C’est une nuance à garder en tête pour les environnements très actifs.

Quelques repères utiles issus de la page “Dashboard Data Availability” :

Type de donnéeDisponibilité indiquée
Event Log réseau12 mois
Connected Clients List3 mois
Change Log organisation24 mois hors EU, 12 mois en EU
Login Attempts12 mois, via demande au support Meraki
Client Association Table WiFi1 an
Client RSSI2 heures
IDS Event Logs MX15 jours
Switch Port Usage2 mois

Cette granularité montre bien qu’il ne faut pas parler de “la rétention Meraki” comme d’une valeur unique. La durée dépend du type de donnée, de la famille produit, de la région d’hébergement du Dashboard, et parfois du volume d’entrées.

Pourquoi une recherche ancienne peut ne rien afficher

Le cas classique est le suivant : on ouvre Network-wide > Monitor > Event log, on utilise le champ Before pour revenir plusieurs mois en arrière, et le Dashboard répond qu’il n’y a aucun événement correspondant.

Ce comportement peut être normal. Meraki explique qu’une recherche générale au-delà de 3 mois ne retrouve pas les événements d’appareils, car ceux-ci sont conservés seulement jusqu’à 3 mois. Pour interroger les client event logs entre 3 et 12 mois, il faut renseigner le champ client et relancer la recherche.

Autre limite pratique : l’export Dashboard ne permet pas de télécharger plus de 1000 événements en une fois. Pour un incident large, une période longue ou un réseau très bavard, il faut réduire la fenêtre de recherche ou passer par une collecte syslog.

Pourquoi mettre en place un serveur syslog

Le Dashboard Meraki est excellent pour l’exploitation quotidienne : recherche rapide, diagnostic courant, investigation ponctuelle. Mais il ne remplace pas une stratégie de journalisation longue durée.

Un serveur syslog sert à recevoir une copie des événements envoyés par les équipements Meraki. Meraki indique que l’on peut l’utiliser avec les MX, MR et MS, avec des rôles différents selon les familles : event logs, flux, URLs, alertes IDS sur MX, événements Air Marshal côté WiFi, etc.

Dans la pratique, syslog devient utile dès que l’on veut :

  • conserver des logs au-delà des limites du Dashboard
  • centraliser les événements de plusieurs réseaux ou organisations
  • envoyer les logs vers un SIEM
  • corréler les événements Meraki avec des logs firewall, serveur, NAC, Active Directory ou EDR
  • répondre à des besoins d’audit, de conformité ou d’investigation après incident
  • conserver les preuves même si un appareil est déplacé ou remplacé.

Il faut cependant dimensionner correctement le stockage. Les logs de flux, par exemple, peuvent générer beaucoup de volume. Il faut aussi décider quels rôles syslog activer : tout envoyer “au cas où” peut coûter cher en stockage et rendre l’analyse plus bruyante.

Attention : le Dashboard ne stocke pas le trafic utilisateur

La page Meraki sur la disponibilité des données rappelle un point souvent mal compris : le Cloud Meraki stocke des données de gestion et des données analytiques, mais ne stocke pas le trafic utilisateur lui-même. La navigation web, les flux applicatifs internes ou le trafic utilisateur transitent par les liens réseau du client, pas par le Cloud Meraki.

Autrement dit, un log Meraki peut indiquer qu’un client s’est connecté, qu’un flux a été observé ou qu’un événement de sécurité a été généré. Il ne faut pas en déduire que Meraki conserve une copie complète des communications utilisateur.

Ce que BoucheCousue recommande

Pour un petit réseau, les logs Dashboard suffisent souvent au support quotidien. Pour un réseau critique, multi-sites ou soumis à des obligations d’audit, il faut prévoir une politique de logs dès le déploiement.

Notre recommandation est simple :

  • documenter les durées de rétention réellement nécessaires
  • identifier les événements utiles par famille d’équipement
  • activer syslog uniquement sur les rôles pertinents
  • envoyer les logs vers une plateforme capable de rechercher, corréler et archiver
  • tester les recherches avant le premier incident sérieux
  • vérifier régulièrement que les logs arrivent toujours.

Le piège classique consiste à découvrir les limites de rétention le jour où l’on cherche un événement vieux de plusieurs mois. À ce moment-là, si syslog n’était pas en place, il est trop tard.

Conclusion

Les logs Meraki sont simples à consulter, mais leur rétention demande un minimum de méthode. Les événements d’appareils Meraki sont utiles pour diagnostiquer l’infrastructure, les événements clients permettent de suivre l’historique d’un terminal, et les deux n’ont pas les mêmes limites de conservation.

Pour l’exploitation courante, le Dashboard est généralement suffisant. Pour l’audit, la conformité, la sécurité ou l’historique long, un serveur syslog devient indispensable.

BoucheCousue accompagne les entreprises dans la conception, le déploiement et l’exploitation de réseaux Cisco Meraki : architecture, supervision, journalisation, sécurité, WiFi, switching et SD-WAN. Si vous voulez fiabiliser votre exploitation Meraki ou structurer votre collecte de logs, contactez-nous pour en parler.

Sources