Dernière modification le 16 avril 2022
Dans la boucle interne de l’Intent-Based Networking, il y a la partie « Intent Fulfillment » qui consiste à partir d’une Source de Vérité unique pour générer des configurations en direction des équipements (directement vers les équipements ou en passant pas une station de management) à l’aide d’un ensemble de programme et la partie « Intent Assurance » qui comprend, entre autre, le « Monitoring ».
Que ce soit dans ou en dehors de la démarche NetDevOps , le chapitre « Monitoring », qui comprend l’observabilité du réseau, est souvent mal compris et mal pris en compte.
Lorsque le sujet de la visibilité du réseau est abordé, la plupart des professionnels pensent à la surveillance du réseau en terme de monitoring traduit par « surveillance ». Les outils de monitoring fournissent une vue centralisée de la santé opérationnelle de l’infrastructure sous-jacente.
Les protocoles et technologies courants de surveillance du réseau incluent entre autre : SNMP (Simple Network Management Protocol), NetFlow, sFlow et syslog. Ils se retrouvent dans des produits aussi divers que Grafana/Prometheus, Zabbix, sFlow-RT, ntopng, Graylog…
La surveillance du réseau nécessite généralement une intervention humaine pour établir le comportement normal du réseau et du trafic. Ensuite, des outils de surveillance identifient et alertent les équipes sur les modifications du comportement attendu. Par exemple, les équipes peuvent utiliser SNMP pour référencer le comportement de débit d’une liaison réseau critique au fil du temps. Une fois que les administrateurs ont déterminé le comportement de base, l’outil de surveillance peut les alerter lorsque le comportement de débit dépasse ce qui est typique.
Alors que le monitoring fournit toutes les données et mesures pertinentes nécessaires à la gestion d’un réseau, les grands réseaux peuvent créer trop de données et trop d’alertes à gérer à l’aide de processus manuels. Lorsque cela se produit, les administrateurs réseau ne traitent pas correctement les alertes. Cela peut conduire à un réseau qui devient moins optimal au fil du temps.
L’observabilité a tendance à moins se concentrer sur les composants réseau eux-mêmes, mais plutôt sur l’expérience du point de vue de l’utilisateur final. C’est ce que les tests d’acceptation visent à couvrir dans le mode Agile. Elle met davantage l’accent sur la surveillance des mesures de performances d’une extrémité d’une connexion à l’autre, par opposition à la surveillance de chaque périphérique réseau individuel entre les deux extrémités.
Les outils d’observabilité du réseau fournissent également une analyse plus approfondie, à l’aide de méthodes automatisées, et cherchent à trouver la cause première d’un problème de performance réseau. S’ils sont correctement mis en œuvre, les outils d’observabilité peuvent considérablement accélérer le temps nécessaire à la résolution des problèmes de réseau.
Des techniques telles que la télémétrie (Telemetry), l’inspection approfondie des paquets (Deep Packet Inspection) et l’IA (Artifcial Intelligence) sont de plus en plus intégrées dans les outils d’observabilité pour aider à comprendre pourquoi un utilisateur, un groupe ou une organisation entière rencontre des problèmes liés au réseau.
Les outils d’observabilité du réseau peuvent s’appuyer sur les données collectées avec le monitoring et offrent une approche plus efficace et évolutive pour maintenir la bonne santé d’un réseau. Ainsi, les outils d’observabilité peuvent convenir aux équipes réseau qui atteignent leur limite de fatigue de surveillance du réseau ou aux organisations qui souhaitent passer à un modèle informatique allégé.
Dans cette série d’articles sur l’observabilité du réseau, je vous propose de découvrir deux outils. L’un d’eux est l’outil commercial abouti IP Fabric offrant une totale autonomie dans l’analyse du réseau et des API pour déclencher et utiliser les résultats des analyses.
Le deuxième est l’outil communautaire Suzieq écrit en Python et porté par une société commerciale.
