#78 Sytème de logging

Sur la v4.3 on a ce truc magnifique ajouté par Ziqumu : https://dev.planet-casio.com/admin/log-viewer/logs (je mets celui de dev parce que celui de prod marche pas là tout de suite, je ne sais pas pourquoi).

En termes de sécurité/légalité, je pense que les actions qui font planter le serveur sont au moins aussi importantes que les actions légitimes faites sur le site, donc je propose de commencer par là. Ce n'est pas ce qui demande le plus d'effort, mais c'est qui impose le plus de contraintes parce que Flask doit pouvoir enregistrer ses erreurs dans le système. Le Logging de Flask est pas mal déjà.

Du reste, ok pour noter ce qui se passe, mais à cause du RGPD il faut faire attention à ne pas enregistrer n'importe comment les IPs. Je ne connais pas exactement les limites...

Déjà je pense qu'il serait bien de séparer les logs applicatifs des logs utilisateurs.

Par log applicatif, j'entends les erreurs de code, les cas où une valeur renvoyée par un module est chelou, etc. En gros tout ce qui est lié à l'application en tant que telle. Ça correspond au log viewer que tu as cité.

Actuellement les logs applicatifs sont déjà gérés par le service uwsgi@pc(-dev), on peut éventuellement les compléter avec des entrées peut être plus pertinentes, mais de manière générale y'a déjà pas mal d'infos actuellement (surtout en cas d'erreur 500), le plus important selon moi serait de pouvoir mettre en place l'équivalent du log viewer là dessus. Il me semble que l'app Flask a déjà un objet æpp.logger qui permet d'ajouter des entrées à ce fichier de logs.

Pour les logs utilisateurs, ça correspond aux actions réalisées. La loi nous impose de les stocker pour 1 an ou 15 jours (suivant qui on écoute, la France ou l'Europe), et ce n'est pas soumis au RGPD. Je ne sais pas si toutes les données qu'on souhaite récupérer sont légalement obligatoires, mais on peut s'appuyer là dessus pour légitimser le traitrement. Dans tous les cas ce sont les logs qui correspondent à l'ancienne table pc_actions, et qui permettent de faire de la modération, surveillance, etc. de toutes les activités du site. Ce qui englobe de manière non exhaustive : post/modification/suppression de contenu, connexion au site, connexion en tant que (vandalisme), etc.

Il faudrait que ces logs soient dans un fichier ou service séparé. D'une part ça permet de séparer les accès aux deux types de logs, et d'autre part c'est plus simple à gérer pour la visualisation ou l'export. Un moyen pas trop complexe peut être d'ajouter un second logger à l'application, par exemple app.user_log.

À coté de ça, je vais sûrement faire quelques tests à base de Fluentd/MongoDB/Grafana, ou autre suite pour aggréger les logs, les stocker de manière tournante et les visualiser.

Actuellement les logs applicatifs sont déjà gérés par le service uwsgi@pc(-dev) (...)

Dans ce cas-là c'est un (très) bon début. Effectivement je dirais pas non à un outil pour agréger les logs, visualiser/filtrer ce qu'il faut, etc.

Je suis d'accord sur le reste. ^^

Tu peux accéder aux logs de l'application via journalctl -xeu uwsgi@pc-dev sur le VPS. Si y'a une page qui lève une exception, t'aura la trace complète dedans. Ce qui n'empêche pas d'ajouter des warning/info/debug si on veut plus de verbosité à certains endroits (je pense au temps des requêtes SQL qui peut être intéressant de tracer) il faut l'ajouter à la main.

Retex sur la gestion des logs avec la suite Promtail + Loki + Grafana : TL;DR y'a de l'idée.

• Promtail est un agent qui va lire les fichiers de log
• Loki est une BDD orientée logs, qui se charge du stockage et de la restitution via LogQL
• Grafana affiche les données correspondant à des requêtes LogQL

Les trois logiciels sont édités par Grafana Labs, tous sont dans les dépots d'Arch (❤)

La configuration est assez simple, ressemble beaucoup au mode de fonctionnement de Telegraf/InfluxDB. J'ai pas regardé si ça faisait du logrotate par contre, mais je suppose que oui.

Pour le fun, j'ai setup un dashboard communautaire sur la v5 (version locale), ça donne ça :

Si ça vous va, je peux setup la toolchain sur le VPS demain soir, uniquement sur les logs Nginx + uwsgi dans un premier temps. On pourra faire de jolis dashboards par la suite. L'avantage majeur que j'y vois, c'est que tout le monitoring se gèrerait via Grafana. Statistiques d'utilisation du site en prime, donc on n'utiliserait plus GoAccess, qui de toute façon est dans sa version Web une plaie à mettre en place.

Concernant les problématiques RGPD des logs d'accès, on peut configurer Nginx pour ne pas récupérer trop d'infos.

J'ai pas trop d'idée initiale de quels outils utiliser, donc puisque tu as cherché je te fais confiance, n'hésite pas.

... juste, y'a un thème clair sur cette chose ? xD