Bonjour,

petite question conception, vous avez une idée de comment on gère des logs (connexion, opérations sur des objets en base ...) en php ?

Un petit lien sur les solutions conseillées ?

Merci,

Narcisse

Bonjour,
en général les log sont gèrer à l'aide d'une classe instanciée en singleton et à laquelle on injecte un objet d'écriture implémentant une interface.
Ce qui pourrait donner au niveau du code quelque chose ressemblant à ceci :

<?php
$loggger - Logger::getInstance();
$fileWriter = new FileWriter('./logs/myLog.txt'); // objet implementant l'interface IWriter
$logger->setWriter($fileWriter);
$logger->log('Connexion au système');
?>

De cette manière vous pouvez opter pour différentes manière de gerer les log :
FileWriter : écriture dans un fichier
BddWriter : en base de donnée
FirebugWriter : en console firebug
etc...

Ca me plaît bien comme réponse ^^


Merci,

Résolu.

Hey ,

'suis en plein dedans en ce moment, ça tombe bien.
Je dirais que ça dépend de ce que tu attends de ton système de log. Il peut servir de debugger par la même occasion, avec des backtraces etc. Tu peux trouver des priorités de logs (voir RFC 3164, The BSD Syslog Protocol, à la section 4.1.1 PRI Part) ou des catégories. Tu peux aussi filtrer tes logs pour la sortie.

En fait, une fois que tu connais le type de tes logs (alertes, critiques, erreurs etc.), tu peux attaquer les choses sérieuses.
Ton système doit pouvoir écrire vers n'importe quoi, ce que Mojorisin a appelé un writer. Je parlerais plutôt de flux de sorties, car c'est exactement l'idée. Si tu as un système de flux puissant (qui supporte les fichiers, les sockets, les bases de données … bref plusieurs protocoles), tu peux interchanger les objets sans problème.
Vient ensuite le problème lié à la forme des données en sortie. En général, c'est ton flux de sortie qui va déterminer ça, mais pas systématiquement (si on écrit sur php://stdout aucun style n'est défini).

Pour résumer, quand tu fais log($msg, $priority), tu vas enregistrer ton log dans une pile de logs. Tu lui ajoutes des données extra si nécessaire (comme un backtrace tree par exemple). Ensuite, ça passe dans ton flux de sorties, pour être écrit dedans.

Dans la théorie, c'est tout bête. Sauf qu'il faut un système de flux bien foutu. Ainsi que donner la possiblité d'organiser ses logs comme il veut (gérer la taille des logs ? gérer les catégories ? gérer les priorités ? …).

Et si tu veux rentrer dans le théorique, tu peux faire en sorte que ton système arrive à mettre en relation des logs qui a priori n'ont rien à voir, mais qui peuvent provenir du même problème. C'est ce à quoi je travaille actuellement : 2 logs sont émis à des points différents du programme ; est-ce qu'ils sont causés par la même erreur/action ?

Tu peux déjà commencer par le B.A.BA, et tu pourras améliorer le système par la suite.

L'idée c'est à peu près ça non ?

Ça pourrait oui.

Note : j'ai repiqué ça sur pas mal de sites, et y ai mis une très légère touche personnelle (j'aurais du le préciser avant ^^).