Projet

Général

Profil

Development #23471

ajout du support de logs structurés vers journald

Ajouté par Benjamin Dauvergne il y a 11 mois. Mis à jour il y a 2 mois.

Statut:
Solution déployée
Priorité:
Normal
Assigné à:
Catégorie:
-
Début:
27 avr. 2018
Echéance:
% réalisé:

100%

Patch proposed:
Oui

Description

  • utiliser python-systemd
  • capitaliser nos champs structurés (journald l'exige :/ )

0002-hobo-do-not-clobber-the-resolved-user-in-RequestCont.patch Voir (732 octets) Benjamin Dauvergne, 27 avr. 2018 00:57

0001-debian-add-journald-support-to-debian_config_common-.patch Voir (2,79 ko) Benjamin Dauvergne, 27 avr. 2018 00:57

journal.py.diff Voir (28,1 ko) Benjamin Dauvergne, 04 déc. 2018 20:37

0001-hobo-do-not-clobber-the-resolved-user-in-RequestCont.patch Voir (732 octets) Benjamin Dauvergne, 05 déc. 2018 13:59

0002-debian-add-journald-support-to-debian_config_common-.patch Voir (13,9 ko) Benjamin Dauvergne, 05 déc. 2018 13:59

Révisions associées

Révision 203b8894 (diff)
Ajouté par Benjamin Dauvergne il y a 2 mois

hobo: do not clobber the resolved user in RequestContextFilter (#23471)

Révision ffaeb450 (diff)
Ajouté par Benjamin Dauvergne il y a 2 mois

debian: add journald support to debian_config_common (fixes #23471)

Historique

#1 Mis à jour par Benjamin Dauvergne il y a 11 mois

  • 0001 : assez évident
  • 0002 : bug introduit en #11316, même si je ne sais pas si la fonctionnalité de passer explicitement un user aux appels de log est utilisée.

#2 Mis à jour par Benjamin Dauvergne il y a 11 mois

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).

#3 Mis à jour par Emmanuel Cazenave il y a 11 mois

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).

#4 Mis à jour par Benjamin Dauvergne il y a 11 mois

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).

#5 Mis à jour par Benjamin Dauvergne il y a 11 mois

  • Fichier 0001-tests_multitenant-PEP8ness-and-cleanup-23471.patch ajouté
  • Fichier 0002-use-pg_advisory_lock-to-prevent-running-cronjobs-dur.patch ajouté

#6 Mis à jour par Benjamin Dauvergne il y a 11 mois

  • Fichier 0002-use-pg_advisory_lock-to-prevent-running-cronjobs-dur.patch supprimé

#7 Mis à jour par Benjamin Dauvergne il y a 11 mois

  • Fichier 0001-tests_multitenant-PEP8ness-and-cleanup-23471.patch supprimé

#8 Mis à jour par Emmanuel Cazenave il y a 11 mois

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.

#9 Mis à jour par Benjamin Dauvergne il y a 11 mois

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).

#10 Mis à jour par Benjamin Dauvergne il y a 11 mois

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',

#11 Mis à jour par Thomas Noël il y a 11 mois

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 ;)

#12 Mis à jour par Benjamin Dauvergne il y a 11 mois

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).

#13 Mis à jour par Benjamin Dauvergne il y a 11 mois

  • Priorité changé de Normal à Bas

à voir plus tard (ou si quelqu'un se sent, backporter juste python-systemd).

#14 Mis à jour par Benjamin Dauvergne il y a 3 mois

  • Priorité changé de Bas à Normal

Comme on est pas loin de passer à stretch, je remonte.

#15 Mis à jour par Frédéric Péters il y a 3 mois

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

#17 Mis à jour par Benjamin Dauvergne il y a 3 mois

Un petit topo sur les limitations :
  • 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().

#18 Mis à jour par Frédéric Péters il y a 3 mois

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 :/

#19 Mis à jour par Benjamin Dauvergne il y a 3 mois

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.

#20 Mis à jour par Benjamin Dauvergne il y a 3 mois

Le diff entre journal.py 230 (jessie) et 234 (stretch-backports), il n'y a vraiment que JournalHandler.emit() qui a changé (en dehors de choses concernant la lecture des logs).

#21 Mis à jour par Benjamin Dauvergne il y a 3 mois

Voilà, j'ai backporté le handler de systemd 234 dans hobo.journal et j'ai ajouté un test en utitilisant le systemd local, lancer les tests nécessite d'avoir libsystemd-dev d'installer sur le système pour pouvoir installer systemd-python 234 depuis pypi.

#22 Mis à jour par Benjamin Dauvergne il y a 3 mois

  • Tracker changé de Bug à Development

#23 Mis à jour par Frédéric Péters il y a 2 mois

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).

#24 Mis à jour par Frédéric Péters il y a 2 mois

  • Statut changé de Solution proposée à Solution validée

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

Bon en fait je relis et c'est juste ce fichier mais la dépendance à python-systemd existe quand même; bon, ok.

(aucune idée de comment ça sera exploité derrière).

#25 Mis à jour par Benjamin Dauvergne il y a 2 mois

  • % réalisé changé de 0 à 100
  • Statut changé de Solution validée à Résolu (à déployer)

#26 Mis à jour par Frédéric Péters il y a 2 mois

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF