Sytème de logging #78

Les actions effectuées sur le site ne sont pas logguées.

En cas de pépin (spam, attaque, demande légale, etc.), nous ne sommes pas en mesure de dire qui a fait quoi et comment.

Le système de logging permet d'avoir plus d'informations sur les évènements.

Selon moi, ça doit inclure tous les évènements qui modifient les contenus (création + édition). La consultation n'est pas utile et déjà réalisée par les logs de Nginx.

Faut qu'on se mette d'accord pour un format de log, et qu'on truffe en conséquence le code existant.

Flask utilise le module de base, la documentation est très claire. :)

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.

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.

Screenshot_2021-03-09 Loki v2 Web Analytics Dashboard for NGINX - Grafana(1).png

145 KiB

Screenshot_2021-03-09 Loki v2 Web Analytics Dashboard for NGINX - Grafana.png

220 KiB

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

Je pense que je pourrais mettre le log applicatif en place. @Darks Est-ce que tu peux voir comment récupérer ça dans Grafana ?

Accessoirement Grafana renvoie 502 dans les requêtes sur les analytics de la v5, je suppose qu'un service est pas actif.

Il ne me semble pas avoir configuré Loki/Promtail sur le VPS. J'ai sûrement copié/collé mon dashboard local sur l'instance du VPS, d'où les 502.

Si ça te va je peux planifier une install d'ici la fin de la semaine prochaine.

Aah, oui maintenant que tu me le rappelles c'était effectivement le cas.

Je veux bien, si tu peux. De ce que je vois dans Configuring Promtail, on peut lire des fichiers statiques, logs systemd, syslog, et d'autres. Je suppose donc qu'on peut récupérer le log uwsgi par systemd pour les 500 en prod, le deployment.log pour les déploiements, et donc si je configure un logger dans Flask pour produire soit un fichier soit des trucs sur la sortie uwsgi c'est acceptable ?