Tasmota, le micrologiciel de remplacement de Theo Arends pour le Sonoff Basic et de nombreux autres commutateurs WiFi, enregistre les messages d'erreur et d'information sur le port série et sur la console de son serveur Web par défaut. Il peut aussi transmettre les messages vers un serveur de journalisation compatible avec le protocole syslog serveur. Les messages y seront stockés et pourront ensuite être consultés. Bien que cela soit particulièrement utile pour ce qui est des messages d'erreur, ce n'est pas le comportement par défaut, mais cela est facilement corrigé.

La deuxième partie de la journalisation des messages de Tasmota ou de toute autre application consiste à rendre accessible un serveur syslog. Comme mon système de domotique roule sur un Raspberry Pi toujours en marche, il est judicieux d’utiliser son service syslog nommé rsyslog.

Table des matières

1. Activer UDP dans rsyslog
2. Activer la journalisation dans Tasmota
3. Plus à propos de rsyslog

Activer UDP dans rsyslog

Suivant la norme, le micrologiciel Tasmota à recours au protocole de transport UDP sur le port 514 pour la journalisation. Par conséquent, le fichier de configuration de rsyslog doit être modifié pour permettre la réception des datagrammes UDP. Pour ce faire, supprimez le symbole de commentaire, #, devant les lignes concernant la « réception UDP ». J'ai utilisé l'éditeur nano pour modifier le fichier.

Sur les systèmes plus anciens, le fichier de configuration est complètement différent. La version originale de ce billet, écrite à l'époque de Debian Jessie, pourrait être utile dans ce cas.

Ensuite, le service doit être redémarré pour que le fichier de configuration modifié soit utilisé.

Pour vérifier, j'ai énuméré les 10 dernières entrées du fichier journal des services.

Cela confirme que le service a été redémarré et qu'il devrait maintenant recevoir des messages UDP sur le réseau. Ceci est facilement vérifié si logger est installé sur une machine Linux sur le réseau local.

Affichons le contenu du fichier journal syslog pour vérifier que le message avait bien été reçu par le Raspberry Pi.

Il est amusant et plus utile d'ajouter l'option --follow (ou -f).

Alors, tail reset activé et affiche les nouveaux messages de journalisation au fur et à mesure qu'ils sont reçus. Pour quitter tail, activez la combinaison CtrlC.

Dans Windows, l'utilitaire logger de Adiscon pourrait être utilisé d'une manière similaire. Tout d'abord, l'invite de commande (cmd) doit être invoquée pour pouvoir utiliser l'utilitaire de ligne de commande.

Notez les différents commutateurs de ligne de commande. En plus l'URL zeronconf, rapsberrypi.local, n'a pas pu être résolue dans Windows 10 s'exécutant dans un Virtual Box d'Oracle. Néanmoins, le test a fonctionné. Il se peut que certaines applications graphiques effectuent la même tâche sous Windows . Je n’ai pas eu le temps ni l’inclination de faire des recherches au-delà du premier utilitaire que j’ai trouvé. D'ailleurs, Adiscon a des liens étroits avec le projet rsyslog (l'actionnaire majoritaire et président de la société est Rainer Gerhards, créateur du logiciel), de sorte que son utilitaire pourrait être considéré comme « officiel ».

Activer la journalisation dans Tasmota

L’interface Web d’un périphérique exécutant le micrologiciel de Tasmota de Theo Arends peut être utilisée pour activer la journalisation des messages syslog. Comme d'habitude, l'interface est accessible avec un navigateur Web en entrant l'adresse IP du périphérique ou son URL <hostname>.local si cette fonction mDNS est activée dans le microprogramme et si le système d'exploitation prend en charge zeronconf.

1. Dans la page principale, cliquez sur le bouton Configuration (panneau de gauche sur la figure ci-dessus).
2. Dans la page de configuration, cliquez sur le bouton Configure Logging (panneau central ci-dessus).
3. Dans la page Logging parameters (panneau de droite), entrez l'adresse IP du serveur syslog ou son nom s'il est possible de le résoudre.
4. Vérifiez que le port Syslog correspond au port choisi dans le fichier de configuration de rsyslog. J'ai conservé port par défaut qui est 514.
5. Entrez le niveau de priorité syslog des messages à envoyer. Je suggère le le fixé à 1 Error afin d'éviter d'inonder le système de journalisation avec des messages provenant du dispositif.
6. Enfin, n'oubliez pas d'appuyer sur le bouton Save (Enregistrer).

Bien qu'il soit logique de définir la priorité des messages de journalisation à 1 Error, il serait difficile de vérifier que tout fonctionne correctement. Réglez donc le niveau temporairement sur 2 Info. Puis cliquez sur le bouton Save. Pour tester, il suffit d'allumer et d'éteindre l'appareil. Cela peut être fait dans la page d'accueil de son site web, ou en appuyant sur le bouton de l'appareil lui-même ou en utilisant un logiciel domotique. Pour vous assurer que tout fonctionne, consultez le fichier journal de l'utilisateur sur le serveur.

Les informations doivent également apparaître dans un autre fichier journal : /var/log/syslog.

Quand le bon fonctionnement sera confirmé, revenez à Configure Logging et définissez le Syslog level sur 1 Error. N'oubliez pas de cliquer également sur le bouton Save.

Plus à propos de rsyslog

Ce fut surprenant de constater le peu d’information disponible au sujet de rsyslog sur le Raspberry Pi. Il semblait que beaucoup ont choisi de le remplacer par syslog-ng. Comme il s’agissait de ma première incursion dans le monde de syslog, j’ai décidé de me familiariser avec le service installé par défaut avant de le remplacer. Après tout, les personnes qui s’occupent de Debian doivent avoir une bonne raison pour leur choix. Vous pouvez lire ce que l'auteur de rsyslog a dit sur le sujet en juillet 2007 : [W]hy does the world need another syslogd? (aka rsyslog vs. syslog-ng).

La version de rsyslog installé avec la plus récente image de Raspberry Pi OS (32-bit) Lite datée du 8 août 2020 est 8.1901.

Rendue disponible le 22 janvier 2019, cette version de rsyslog n'est pas la plus récente. Une nouvelle devenait disponible il y a peine cinq jours: v8.2010.0. Ceci étant dit, la version 8.1901, qui est la dernière qu'on retrouve dans le référentiel Raspbian, est tout à fait convenable.

Certains s'inquiétaient de l'utilisation de la mémoire dans rsyslog. Le Wiki du projet, qui n'est plus disponible, notait que le service est une application de multiple fils d'exécution (multithread) dont la pile de chaque fil peut occuper jusqu'à 8 Mo de mémoire. L'énorme limite sur la taille de la pile des fils d'exécution reste en vigueur dans la version actuelle de rsyslog dans Raspbian Buster / Raspberry Pi OS.

J'ai simplement ignoré le problème au cours des deux dernières années et demie, sans conséquences négatives pour autant que je sache. J'ai essayé de suivre les instructions de Jesse Johnson sur la limitation de la taille de la pile des fils d'exécution, comme décrit dans son article intitulé Reducing memory usage of rsyslog, mais cela a échoué. Apparemment, le fichier /etc/default/rsyslog est ignoré par le gestionnaire de services systemd. Je pense que le correctif proposé concernait les systèmes Linux utilisant le gestionnaire de services init.

En mars de cette année, Reimer Prochnow, qui est beaucoup plus compétent que moi, m'envoyait un courriel avec des instructions sur la manière correcte de définir la limite de la taille des piles des fils d'exécution. Commencez par créer un fichier de configuration supplémentaire de service avec la taille de pile maximale souhaitée.

Rechargez ensuite les fichiers de configuration du service et redémarrez le service.

Enfin, vérifiez que la limite est appliquée.

Succès! Espérons que fixer une limite à la taille de la pile des fils d'exécution du service rsyslog ne sera pas préjudiciable; le temps nous le dira.

Dans un article récent, Avoid overly-large in memory queues Rainer Gerhards nous enjoint d'éviter un autre problème de mémoire. Malheureusement, c'est au-dessus de ma tête. Comme précédemment, je vais simplement ignorer ceci, en espérant que les paramètres par défaut fonctionnent.

Certains sont inquiets au sujet des fichiers journaux enregistrés sur des cartes SD en raison du nombre limité de cycles d'écriture pouvant être effectués sur ces périphériques de mémoire. Il semble exister une divergence d’opinions entre ceux qui calculent l’impact théorique de tous ces ajouts aux journaux, qui est apparemment négligeable, et ceux qui insistent sur le fait qu’ils ont perdu une carte SD à cause du trop grand nombre d’écritures. Comme ce dernier pourrait très bien être un exemple d' argument post hoc ergo propter, j'ai décidé de ne pas m'inquiéter de l'usure des cartes SD. En plus, je suis paresseux et ne rien faire me va très bien.