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.