De nombreux clients nous ont demandé comment contrôler les connexions à l’aide de l’Internet Control Message Protocol, aussi appelé ping, et l’OpenTelemetry Collector. « Pour quoi faire ?! », pourraient demander certains d’entre vous. « Les années 90 ont appelé et veulent récupérer leur ICMP », diront d’autres ; mais l’une des raisons pourrait être que cela permet de renoncer à la création et à l’entretien de scripts complets. Et au début, cela peut faire gagner toute une journée de travail (et préserver votre santé mentale à long terme).
Le ping traditionnel peut beaucoup nous apprendre à propos de l’état de notre infrastructure. Surtout quand nous ne connaissons pas tous les détails des composants entre deux terminaux. Le ping nous permet d’évaluer la situation et de justifier la rengaine habituelle « C’est si lent... ». Les données obtenues avec une seule mesure sont très peu nombreuses, mais les conclusions que vous pouvez tirer de mesures à moyen et à long terme aident à identifier les dégradations temporaires de manière précoce et à les signaler.
Voici comment nous procédons :
vous installez d’abord le Splunk OpenTelemetry Collector (par ex. sur Github ici). Vous trouverez ici les consignes pour le système d’exploitation concerné.
Vous disposez ainsi de tous les composants nécessaires pour collecter la latence, le taux de drop et l’écart-type d’un ping.
Il vous suffit à présent de décrire les hôtes auxquels envoyer une commande ping sur agent_config.yaml (sous Linux, vous le trouverez généralement ici : /etc/otel/collector/). Pour ce faire, utilisez la saisie suivante dans le domaine du destinataire :
receivers:
…
smartagent/myping:
type: collectd/custom
template: |
LoadPlugin ping
Host "10.202.11.101"
...
Les informations figurant ici sur collectd.org permettent de configurer le ping de manière encore plus détaillée. Vous devez alors saisir ces informations complémentaires dans la balise du plugin, à l’endroit où l’hôte a été configuré.
Explication :
ici, nous avons créé un « receiver » dans l’OTel Collector. Celui-ci contient des données du smartagent et se nomme myping. Le nom du smartagent peut être choisi presque à volonté. Nous configurons le smartagent par le biais de l’OTel Collector de manière à ce qu’il doive utiliser collectd. Et nous indiquons aussi au collectd qu’il doit télécharger le plugin ping. Tous les composants (smartagent, collectd, ping Plugin) ont été fournis avec l’installation du Splunk OpenTelemetry Collector.
Remarque : pourquoi autant de composants ?
Tant que les fonctionnalités susmentionnées ne sont pas disponibles dans l’OpenTelemetry Collector standard, nous les fournissons par le biais de la distribution de Splunk, le Splunk OpenTelemetry Collector.
Pour finir, il faut encore intégrer le nouveau destinataire créé dans le pipeline des métriques, dans le service. Cela se fait dans l’agent de configuration agent_config.yaml un peu plus bas :
service:
...
pipelines:
...
metrics:
receivers: [..., smartagent/myping]
...
Vous pouvez créer autant de destinataires de ping que nécessaire. Mais dans tous les cas, assurez-vous que le nom et la référence sont corrects.
Après l’installation standard du Splunk OpenTelemetry Collectors, les métriques sont envoyées sur Splunk Infrastructure Monitoring (IM) dans Splunk Observability Cloud. Vous trouverez très facilement les métriques via le Metric Finder (navigation à gauche) quand vous cherchez le mot-clé « ping » dans le champ de recherche. Les métriques ping.[HOST] (latence), ping_droprate.[HOST] et ping_stddev.[HOST] (écart-type) apparaissent alors dans les résultats. Le HOST fait référence à la cible que nous avons indiquée sous l’entrée de l’hôte dans le fichier de configuration. Si vous voulez savoir quel hôte était la source du ping, vous trouverez cette information dans la balise de l’hôte sur la métrique. Cela permet d’utiliser l’hôte source comme dimension d’évaluation de la métrique. Par exemple quand vous voulez envoyer une commande ping à une cible à partir de sources différentes.
En outre, ces métriques peuvent être visualisées normalement sur des tableaux de bord et utilisées pour émettre des alertes via Outlier Detection ou Historical Anomaly.
Cette procédure vous permet de créer très rapidement et simplement votre propre réseau d’agents ping sur une base open source.
Résolution des problèmes dans Linux :
Si rien n’arrive dans votre Splunk Observability Cloud, veuillez vérifier dans les logs (Linux : sudo journalctl -u splunk-otel-collector -n 100 -f) si le ping a pu être exécuté. Si vous y voyez un message d’erreur indiquant « operation not permitted », exécutez ce qui suit :
- getcap /usr/bin/ping
(output:/usr/bin/ping = cap_net_admin,cap_net_raw+p) - sudo setcap cap_net_raw+ep /usr/lib/splunk-otel-collector/agent-bundle/bin/collectd
- restart service.
Si vous souhaitez plus d’informations ou d’autres exemples, n’hésitez pas à nous contacter.
