Sytème de logging #78

Closed
opened 2020-10-20 21:54:58 +02:00 by Darks · 12 comments
Owner

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

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](https://flask.palletsprojects.com/en/1.1.x/logging/) est très claire. :)
Darks added the
enhancement
security
labels 2020-10-20 21:55:12 +02:00
Darks added a new dependency 2020-10-20 22:16:28 +02:00
Owner

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

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...
Author
Owner

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

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

> 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. ^^
Author
Owner

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.

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.
Author
Owner

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 :

Dashboard 1

Dashboard 2

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.

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](https://grafana.com/grafana/dashboards/12559) sur la v5 (version locale), ça donne ça : ![Dashboard 1](https://gitea.planet-casio.com/attachments/13ac0d40-7955-4a8b-9964-73c6729af019) ![Dashboard 2](https://gitea.planet-casio.com/attachments/8baa1a50-1a01-4c2d-b92d-3cf116c7b922) 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.
Owner

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

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
Owner

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.

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.
Author
Owner

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.

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

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 ?

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](https://grafana.com/docs/loki/latest/clients/promtail/configuration/?pg=docs#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 ?
Owner

Je suis toujours un peu à la ramasse sur cette partie. Grafana est une super idée à mon avis ne serait-ce que pour se débarasser de Google Analytics, donc avoir les logs dedans serait tout à fait approprié.

Tout est bien en ligne à https://grafana.planet-casio.com/ (cette fois j'arrive à m'y connecter !) mais les 502 sont toujours là, je suppose qu'on ne l'a jamais configuré. @Darks Est-ce que ça te semble possible d'y refaire une passe ?

Je suis toujours un peu à la ramasse sur cette partie. Grafana est une super idée à mon avis ne serait-ce que pour se débarasser de Google Analytics, donc avoir les logs dedans serait tout à fait approprié. Tout est bien en ligne à https://grafana.planet-casio.com/ (cette fois j'arrive à m'y connecter !) mais les 502 sont toujours là, je suppose qu'on ne l'a jamais configuré. @Darks Est-ce que ça te semble possible d'y refaire une passe ?
Owner

Ok, grafana n'avait aucun privilège dans la base de données, c'est pour ça que les requêtes du panel PCv5 échouaient. Je lui ai accordé les droits pour lister et lire les tables :

pcv5-dev=# GRANT USAGE ON SCHEMA public TO grafana;
GRANT
pcv5-dev=# GRANT SELECT ON ALL TABLES IN SCHEMA public TO grafana;
GRANT

Et du coup on peut avoir quelques infos qui ne marchaient pas jusqu'à présent (screenshot).

Cela dit j'en sais pas trop plus, et j'ai pas les droits d'administration du Grafana donc je ne peux essentiellement rien modifier là-bas.

Ok, `grafana` n'avait aucun privilège dans la base de données, c'est pour ça que les requêtes du panel `PCv5` échouaient. Je lui ai accordé les droits pour lister et lire les tables : ``` pcv5-dev=# GRANT USAGE ON SCHEMA public TO grafana; GRANT pcv5-dev=# GRANT SELECT ON ALL TABLES IN SCHEMA public TO grafana; GRANT ``` Et du coup on peut avoir quelques infos qui ne marchaient pas jusqu'à présent (screenshot). Cela dit j'en sais pas trop plus, et j'ai pas les droits d'administration du Grafana donc je ne peux essentiellement rien modifier là-bas.
Author
Owner

Pour les logs d’events v5, cf la PR #136

Pour les logs d’events v5, cf la PR #136
Darks closed this issue 2023-06-20 19:45:30 +02:00
Sign in to join this conversation.
No description provided.