Tu utilises un F5 BIG‑IP VE en production et tu as déjà vu passer dans /var/log/ltm des messages comme "Bandwidth utilization is 1070 Mbps, exceeded 75% of Licensed 1000 Mbps" ? Ces alertes 01010045 indiquent que ton load balancer virtuel a lissé le trafic pendant des bursts critiques, causant des ralentissements ou coupures de nouvelles sessions pour tes applications.
Les compteurs SNMP classiques lissent ces pics sur 10 secondes. Ce tutoriel te montre comment créer un plugin Icinga en Perl qui scrute directement les logs LTM pour détecter en temps réel les dépassements de licence, avec seuils personnalisables, perfdata pour les graphiques et logique d'âge intelligente.
À la fin, tu auras un check prêt à déployer qui te prévient avant que tes utilisateurs ne signalent des problèmes de performance.
Présentation du BIG‑IP VE et de sa licence de bande passante
Un F5 BIG‑IP VE (Virtual Edition) est la version logicielle des appliances F5, qui s’exécute sur un hyperviseur ou dans le cloud tout en offrant les mêmes modules (LTM, ASM, APM, etc.) que les boîtiers physiques.
La différence majeure est que les performances ne dépendent plus du châssis matériel, mais d’une licence qui limite notamment le débit maximal et le nombre de vCPU utilisables par le plan de données (TMM).
Les licences VE sont proposées avec plusieurs paliers de throughput (10 Mbps, 25 Mbps, 200 Mbps, 1 Gbps, 3 Gbps, 5 Gbps, 10 Gbps, etc.) et, pour chaque palier, F5 impose une limite de vCPU, ce qui borne le nombre de threads TMM pouvant traiter le trafic.
Sur une licence 1 Gbps, par exemple, le VE peut atteindre 1 Gbps en entrée et 1 Gbps en sortie (la limite n’est pas un agrégat), mais au‑delà de ce plafond, un policer interne commence à restreindre le débit.
Comprendre le message 01010045 dans /var/log/ltm
Lorsqu’un BIG‑IP VE approche ou dépasse la limite de bande passante définie dans sa licence, il génère un message dans /var/log/ltm de la forme suivante :
Jan 15 11:10:38 BIGIP-CLOUD notice tmm: 01010045:5: Bandwidth utilization is 1070 Mbps, exceeded 75% of Licensed 1000 Mbps.
Ce message est associé à l’identifiant 01010045 et indique que la consommation instantanée de bande passante (ici 1070 Mbps) a été dépassé.
Il ne faut pas prendre en compte le pourcentage dans le log, car ce message est fixe quelque soit le dépassement.
D’après la documentation F5, ce dépassement est calculé sur une fenêtre courte (de l’ordre de 500 ms), ce qui permet de détecter des bursts qui ne seraient pas visibles sur des moyennes plus longues.
Pour les applications hébergées derrière ce BIG‑IP, ces dépassements peuvent se traduire par des symptômes très concrets : ouverture de nouvelles sessions ralentie ou refusée, timeouts lors des pics de charge, voire pertes de paquets et dégradation globale des temps de réponse lorsque le policer de licence entre en action.
Même si les graphiques de performance globaux semblent “propres” sur des moyennes de 5 ou 10 minutes, ces micro‑saturations peuvent suffire à faire basculer la perception utilisateur.
Pourquoi surveiller /var/log/ltm plutôt que des compteurs classiques ?
Les compteurs SNMP ou les statistiques internes du BIG‑IP (Performance Reports, Analytics) reposent généralement sur des moyennes à l’échelle de la seconde ou de la minute, ce qui lisse complètement des bursts très courts mais violents.
À l’inverse, le message 01010045 reflète le point de vue du policer de licence lui‑même : il se déclenche exactement lorsque le moteur considère que la limite de throughput est atteinte ou dépassée, selon sa propre granularité.
Dans ce tutoriel, l’idée est donc de capitaliser sur cette vision “interne” : plutôt que de tenter d’estimer la consommation de bande passante à partir de courbes de débit, on lit directement /var/log/ltm pour récupérer la dernière alerte de licence.
Cela présente plusieurs avantages : on détecte les dépassements fugaces, on récupère le débit exact au moment du pic (1070 Mbps pour 1000 Mbps), et on peut reconstituer l’historique même si le pic est passé au moment où Icinga interroge le BIG‑IP.
Voyons maintenant quelques points de ce script PERL.
Bloc 1 – Connexion SSH au BIG‑IP avec Net::OpenSSH
Le premier bloc important du script consiste à établir une connexion SSH robuste vers le BIG‑IP en utilisant le module Net::OpenSSH. Le script construit une structure d’options qui définit :
- L’utilisateur SSH (admin ou celui passé en argument/variable d’environnement).
- Un timeout global et le comportement en cas de dépassement (kill du master).
- Des options ssh bas niveau : désactivation de StrictHostKeyChecking, fichier known_hosts jetable, ConnectTimeout, ServerAliveInterval, etc.
L’authentification est gérée de façon pragmatique : si un chemin de clé privée est fourni et pointe vers un fichier existant, le script utilise key_path, sinon il bascule sur un mot de passe via l’option password.
my %ssh_opts = (
user => $bigip_user,
timeout => 30,
kill_ssh_on_timeout => 1,
master_opts => [
-o => "StrictHostKeyChecking=no",
-o => "UserKnownHostsFile=/dev/null",
-o => "ConnectTimeout=10",
],
);
$ssh_opts{key_path} = $ssh_key if $ssh_key && -f $ssh_key;
$ssh_opts{password} = $bigip_pass if $bigip_pass;
my $ssh = Net::OpenSSH->new($bigip_host, %ssh_opts);
die "Erreur SSH: ".$ssh->error if $ssh->error;
Enfin, tout ce bloc est encapsulé dans un eval pour convertir toute erreur (mauvais mot de passe, hôte injoignable, timeout) en statut UNKNOWN Icinga propre, avec un message compréhensible dans la sortie du plugin.
Bloc 2 – Extraction de la dernière alerte dans /var/log/ltm
Une fois la connexion SSH établie, le script exécute une commande très ciblée pour aller chercher la dernière alerte liée à la licence :
my $cmd = q{tac /var/log/ltm 2>/dev/null | grep -m1 '01010045:5: Bandwidth utilization' || true};
my $log_line = $ssh->capture($cmd);
Trois points importants à expliquer :
- tac lit le fichier à l’envers, ce qui permet de tomber immédiatement sur les lignes les plus récentes, sans scanner tout le log.
- grep -m1 '01010045:5: Bandwidth utilization' arrête la recherche dès la première occurrence, ce qui rend la commande efficace même sur des fichiers très volumineux.
- || true force un code retour 0 même si grep ne trouve rien, pour éviter que Net::OpenSSH interprète l’absence de correspondance comme une erreur d’exécution.
Le script “trim” ensuite la ligne (suppression des espaces en début/fin) et, en mode debug, affiche le contenu exact et la longueur capturée pour faciliter le diagnostic si le format du log change. Si aucune ligne ne contient “Licensed”, le plugin renvoie immédiatement :
OK - Aucun historique de dépassement de bande passante trouvé dans les logs | bandwidth_percent=0%;75;80;0;150
Ce comportement est volontaire : pas de message dans /var/log/ltm signifie “aucun dépassement enregistré”, et donc aucun problème de licence à signaler à Icinga.
Bloc 3 – Calcul du pourcentage et parsing de la date
Parsing de la ligne de log
Le script exploite le format du message 01010045 pour extraire deux valeurs : le débit utilisé et le débit licencié :
if ($log_line =~ /Bandwidth utilization is (\d+) Mbps.*Licensed (\d+) Mbps/) {
my ($used, $licensed) = ($1, $2);
my $percent = sprintf("%.2f", ($used / $licensed) * 100);
...
}
Cette regex capture d’abord la valeur de débit mesurée (par exemple 1070 Mbps), puis la valeur de la licence (1000 Mbps) pour recalculer un pourcentage “réel” d’utilisation au moment du pic. L’intérêt est double :
if ($log_line =~ /^(\w+\s+\d+\s+\d+:\d+:\d+)/) {
$date_str = $1; # ex: "Jan 15 11:10:38"
}Calcul de l’âge du log sans l’année
C’est la partie la plus “piégeuse” : la date des logs système Linux ne contient pas l’année, il faut donc la reconstruire à partir de l’année courante. La fonction check_log_age procède ainsi :
- Conversion du mois texte en numéro (Jan → 0, Feb → 1, etc.)
- Récupération de l’année courante via localtime(time)
- Construction d’un epoch avec timelocal(sec, min, hour, day, month, year) pour obtenir le timestamp du log dans l’année actuelle
- Calcul de la différence avec l’heure actuelle, en secondes puis en minutes
Si le résultat est trop négatif (par exemple un log “dans le futur” de plus d’une heure), la fonction suppose qu’il s’agit en fait d’un log de l’année précédente (cas typique autour du 1er janvier) et refait le calcul avec year - 1.
Enfin, des garde‑fous supplémentaires empêchent d’accepter des logs trop anciens (plus d’un an) ou avec un âge anormalement négatif. Cela évite des faux positifs d’alertes si l’horloge du BIG‑IP ou du serveur Icinga sont légèrement désynchronisées.
Bloc 4 – Logique de statut Icinga + perfdata
La dernière brique traduit le pourcentage calculé et l’âge du log en un état Icinga (OK/WARNING/CRITICAL/UNKNOWN) et en perfdata exploitable pour la métrologie. Le plugin repose sur deux fenêtres :
- --age-alert (par défaut 5 minutes) : en‑dessous, une alerte est considérée comme “en cours”.
- --age-no-alert (par défaut 10 minutes) : au‑delà, l’alerte est jugée trop ancienne pour impacter l’état courant.
La logique est donc :
- Si l’âge du log est > age-no-alert : état OK, message “dernier dépassement à X % il y a Y minutes”, et perfdata bandwidth_percent=0 pour ne pas polluer les graphes actuels.
- Si l’âge ≤ age-alert : comparaison du pourcentage avec les seuils Icinga : ≥ critical → CRITICAL - Bande passante à XX% (...) - Alerte il y a Y min. ≥ warning → WARNING - Bande passante à XX% (...) - Alerte il y a Y min. Sinon → OK - Bande passante à XX% (...).
- Si l’âge est entre les deux : état OK mais message informatif (“dernier dépassement à X % il y a Y min”) et perfdata à 0 %.
Pour l’export des données vers les graphes, la fonction print_output suit strictement le format attendu par Icinga/Nagios :
print "$message | bandwidth_percent=${percent}%;${warning};${critical};0;150\n";
exit $exit_code;
Tout ce qui se trouve avant le | est le message lisible, tout ce qui est après correspond aux perfdata (nom=valeur;warn;crit;min;max). Le max est fixé à 150 % pour permettre l’affichage de dépassements au‑delà de 100 % dans les courbes.
Voici un exemple des paramètres du script :
FAQ - Surveillance bande passante F5 BIG‑IP VE avec Icinga
1. Pourquoi les graphiques SNMP ne montrent pas les mêmes pics que les logs LTM ?
Les compteurs SNMP (sysStatClientInBps, sysStatServerOutBps) utilisent des moyennes sur 5-10 secondes qui lissent les bursts. Le message 01010045 reflète la vision du policer de licence (500 ms), capturant des micro‑pics invisibles sur les stats moyennées.
2. Le script nécessite-t-il des privilèges SSH particuliers sur le BIG‑IP ?
Non, l'utilisateur admin (ou équivalent) suffit. La commande tac /var/log/ltm | grep ne requiert aucun accès root. Assure-toi juste que SSH est activé (par défaut sur VE) et que /var/log/ltm n'est pas rotable.
3. Que se passe-t-il si aucun message "Licensed" n'est trouvé dans les logs ?
Le script renvoie OK avec bandwidth_percent=0%, ce qui est le comportement attendu : "aucun dépassement de licence enregistré = pas de problème". Les graphes Icinga restent plats à 0%.
4. Comment adapter les seuils --age-alert et --age-no-alert ?
- --age-alert=5 : alerte si le log a moins de 5 min (incident "en cours")
- --age-no-alert=10 : ignore si plus de 10 min (incident terminé) Augmente les valeurs si tes pics sont espacés, diminue si tu veux une réactivité maximale.
5. Le script gère-t-il les changements de licence (200 Mbps → 1 Gbps) ?
Oui, le parsing extrait dynamiquement la valeur licenciée du log (Licensed 1000 Mbps), donc le pourcentage calculé s'adapte automatiquement. Tes seuils Icinga (75/80%) restent cohérents quelle que soit la licence VE.
6. Quelle est la charge du script sur le BIG‑IP VE ?
Négligeable : tac | grep -m1 s'arrête dès la première ligne correspondante (dernière alerte), même sur des logs de plusieurs Go. Exécutable toutes les 60s sans impact sur le TMM ou les performances globales.
7. Comment générer un log de test sur votre F5 BIG-IP pour tester le script ?
Voici une commande pratique pour générer un log dans le fichier /var/log/ltm pour tester le script :
logger -p local0.notice -t tmm '01010045:5: Bandwidth utilization is 1090 Mbps, exceeded 85% of Licensed 1000 Mbps'
Pour aller plus loin
Pour ne pas surcharger cet article avec du code, le script complet (avec commentaires, exemples et options détaillées) est disponible sur mon dépôt GitHub, ci-dessous :
Le code source complet du plugin PERL Icinga est disponible ici :
https://github.com/networkpulse/check-ssh-bigip-utilization-bandwith
En résumé, ce tutoriel t’a montré comment transformer un simple message de log 01010045 dans /var/log/ltm en un indicateur Icinga exploitable, avec une gestion fine des seuils, prise en compte de l’âge de l’alerte et des perfdata prêtes pour les graphes.
Tu disposes maintenant d’une méthode concrète pour détecter les dépassements de licence de bande passante sur un F5 BIG‑IP VE avant que tes utilisateurs ne ressentent les impacts sur leurs applications.
Si tu veux aller plus loin, adapter le code à ton contexte ou simplement l’intégrer tel quel dans ta supervision, tu peux récupérer le script PERL complet directement sur mon dépôt GitHub. Clique sur le lien ci‑dessous, clone le projet, et commence à monitorer la bande passante de tes BIG‑IP VE dès maintenant.
