Produits Entr'ouvert » Hobo

Il faut backporter python-systemd 234 de testing pour que ce soit utile (la version 233 dans jessie-backports/stretch ne transmet pas le contenu complet de record.__dict__ à journald).

Est-ce qu'avec ça on peut bien filtrer les logs de journald par unit ?

Ici tu laisses de coté les loggers 'sentry.errors' et 'py.warnings' qui utilisent encore le handler syslog.

Idélament je serai d'abord pour tester une solution plus radicale : se passer de python-systemd. Si systemd est présent, remplacer partout le handler syslog par un handler stdout ou stderr. Par défaut systemd envoie tout à journald. A voir si ça pollue pas trop dans un terminal lors de commandes de management. Il nous manque aussi quelques unit file (hobo n'en a pas).

Emmanuel Cazenave a écrit :

Est-ce qu'avec ça on peut bien filtrer les logs de journald par unit ?

Oui, ça ne peut pas bloquer ça, il y a toujours la unit citée dans les enregistrements journald, ce qui est moche c'est que via syslog on a le choix du formatage alors qu'avec le passage journald->syslog on a forcément comme nom de programme /usr/bin/gunicorn parce que c'est journald qui formate de façon uniforme "$date $user $program".

Ici tu laisses de coté les loggers 'sentry.errors' et 'py.warnings' qui utilisent encore le handler syslog.

Bien vu je vais corriger ça.

Idélament je serai d'abord pour tester une solution plus radicale : se passer de python-systemd. Si systemd est présent, remplacer partout le handler syslog par un handler stdout ou stderr. Par défaut systemd envoie tout à journald. A voir si ça pollue pas trop dans un terminal lors de commandes de management. Il nous manque aussi quelques unit file (hobo n'en a pas).

Ça me va d'aller d'abord vers ce que tu dis mais là mon objectif c'était d'avoir des logs structurés, donc de pouvoir filtrer au niveau journald par tenant, utilisateur, uuid, etc... et de le faire en plus sur le serveur qui centralise tous les logs, ainsi on peut voir l'activité sur l'ensemble de la plate-forme d'un client (si on avait en plus un champ "PLATFORM" en provenance de hobo ce serait top).

Ici tu laisses de coté les loggers 'sentry.errors' et 'py.warnings' qui utilisent encore le handler syslog.

Peut-être que quelque chose m'échappe mais j'ai l'impression qu'en l'état ça ne marche pas : il faut que le filter 'request_context' soit ajouté à ton handler pour qu'on ait les infos contextuelles qui vont bien.

Aussi j'avais pas vu la première fois, mais le monkeypatch de python-systemd ...

Thomas dit aussi que c'est une galère pas possible, voir impossible de backporter python-systemd.

Bon ben tant pis alors, ça aurait été beau (Thomas si tu peux dire les soucis que tu entrevois pour le backport, genre si ça changeait un jour qu'on le sache).

Je réponds quand même au reste.

Emmanuel Cazenave a écrit :

Ici tu laisses de coté les loggers 'sentry.errors' et 'py.warnings' qui utilisent encore le handler syslog.

Peut-être que quelque chose m'échappe mais j'ai l'impression qu'en l'état ça ne marche pas : il faut que le filter 'request_context' soit ajouté à ton handler pour qu'on ait les infos contextuelles qui vont bien.

Oui tu as raison.

Aussi j'avais pas vu la première fois, mais le monkeypatch de python-systemd ...

Ils mettent une contrainte un peu chiante sur le nommage des attributs du record, on peut s'en passer si on change le nommage dans request_context, mais faut changer aussi les chaînes de formatage dans ce cas, qui font référence explicitement à ces propriétés.

            'format': '%(application)s %(levelname)s %(tenant)s %(ip)s %(user)s %(request_id)s'
                      ' %(message)s',

Benjamin Dauvergne a écrit :

Bon ben tant pis alors, ça aurait été beau (Thomas si tu peux dire les soucis que tu entrevois pour le backport, genre si ça changeait un jour qu'on le sache).

Backbackporter systemd sur jessie me semble déraisonnable. Utiliser le backport sur stretch beaucoup moins. Reste qu'il faut passer à stretch, donc django 1.11. Ce patch devra sans doute attendre encore un peu ;)

J'ai l'impression que tu sous-entends que ça demande de backporter systemd (je n'avais pas conscience que ça en faisait partie, mais en voyant le numéro de version ça devient logique).

Tu aurais une branche rebasée à pousser en wip ?

Rebasé (aucun conflit), poussé, http://git.entrouvert.org/hobo.git/log/?h=wip/23471-ajout-du-support-de-logs-structures-vers-journald

• systemd récent (strech-backports) parce que sinon python-systemd (qui est généré par le même paquet source que systemd) ne prend pas en compte les autres champs

sd_journal_send() may be used to submit structured log entries to the system journal. It takes a series of format strings, each immediately followed by their associated parameters, terminated by NULL. The strings passed should be of the format "VARIABLE=value". The variable name must be in uppercase and consist only of characters, numbers and underscores, and may not begin with an underscore. (All assignments that do not follow this syntax will be ignored.)

• on est obligé de mettre en majuscule tous nos champs avant de les passer à l'API systemd sinon ils sont ignorés, ça passe malheureusement par du monkeypatching, mais on pourrait aussi faire proprement de l'héritage pour modifier JournalHandler.emit() mais comme il s'y passe pas mal de chose c'est plus simple de monkeypatché la fonction systemd.journal.send().

systemd récent (strech-backports)

J'avais raté ça, ça reste pour moi pas folichon de devoir suivre les changements/bugs de systemd dans stretch-backports :/

Frédéric Péters a écrit :

systemd récent (strech-backports)

J'avais raté ça, ça reste pour moi pas folichon de devoir suivre les changements/bugs de systemd dans stretch-backports :/

systemd n'est pas important c'est le paquet python-systemd qui pose problème, si on backporte le fix en question ça peut aller aussi (l'implémentation de JournalHandler.emit() uniquement), on peut aussi s'en sortir en copiant le fichier journal.py dans hobo.

Le hobo/journal.py qui est copié de systemd, tu pourrais le taper dans un vendor/systemd/journal.py, genre ?

-        from graypy import GELFHandler
+        from systemd import journal

et ce bout-là serait alors à changer en from .vendor.systemd, ou ce que tu auras choisi.

+ if os.path.exists('/run/systemd/journal/socket'):

Juste tester /run/systemd/journal peut-être ? (pour tester que systemd est utilisé, la bonne pratique est de tester /run/systemd/systemd/, pas les trucs à l'intérieur, je me dis que pour journald ça peut être pareil).