Personellement j'suis pas grand fan de Big Brother, je trace les connexions (IP, étude du nom d'hote pour chasser les proxy pas discrets, du nombre de forwarded dans la même optique) avec un coefficient de suspectabilité, je log les erreurs pi basta (avec dedans les tentatives échouées d'accès à des trucs sensibles qu'un joueur normal est pas censé toucher). Les logs dans des fichiers textes, les accès directement dans la bdd de joueurs.

Après je pense pas qu'il faille tomber dans la sur-surveillance, parce que bon au final 'faudra bien qu'un bonhomme se coltine les 150 écrans de logs pour y chercher les transactions pas nettes (bin oui, si tu savais reconnaitre une transaction pas nette par le code, t'aurais implanté la condition directement dans ton code plutot que dans un script secondaire de vérification non ? A moins que tu ne chasses les actions sur-représentées parce qu'un ou plusieurs joueurs en abusent, mais bon si t'es pas radin avec les joueurs qui avouent les failles qu'ils trouvent t'ne aura bien un pour venir te voir ...).

Pour la vérification par l'admin, des sauvegardes récentes (ca aussi c'est plutot efficace comme système de logs ... Et en plus c'est utile en cas de crash ou d'abus de faille) dans lesquelles aller farfouiller ca suffit selon moi (parce que bon là dedans aussi tu peux repérer les suspects à la main ...). Et une communauté soudée et honnète

Pour ma part, je considère les logs, les traces et le suivi des utilisateurs comme importants mais je distingue les 3.

Pour moi une trace sert au débuggage de l'application.
Les traces indiquent ce par quoi passe le code et permet de suivre toutes les actions.
Les traces sont stockés dans des fichiers textes horodatés et j'ai un fichier par Objet.

Voici un exemple de trace généré

Et voici la classe "Tracer"

Et voici dans le code comment les traces sont appellées

Et dans un fichier de configuration, il y a une variable qui permet d'activer ou non les traces ($_GLOBALS['config']['debug'] = true; ).
Quand le débuggage est fini et que l'application part en environnement de PROD, il vaut mieux commenter les appels aux traces pour améliorer les performances mais il vaut mieux pas les supprimer car en cas de bug, il suffit de décommenter pour suivre ce qui se passe.


D'un autre côté, j'ai les logs qui remontent des problèmes sur l'application en environnement de PROD.
Chaque comportement non prévu déclenche un processus d'alerte avec un niveau de criticité.
En fonction du niveau de la criticité, une réaction a lieu :
- envoi d'une exception
- log dans un fichier
- envoi d'un mail à l'administrateur
avec la possibilité de faire toutes les réactions à la fois.

Pour cela, j'utilise un design pattern : "Chain of Responsability" [http://en.wikipedia.org/wiki/Chain-of-re...ty_pattern]
Le principe est en gros le suivant : si un alerte de niveau 1 est déclenché alors une exception est levée, si l'alerte est de nievau 2 alors on écrit dans un log et on lève une exception et si elle est de nievau 3 alors on effectue les 3 actions.


Pour finir, il y a le suivi des actions d'un utilisateur.
Là, pas de mystère, j'historise toutes les actions effectuées par les utilisateurs.
Chaque action représente un ordre envoyé au système, cette ordre est stockée et il contient une liste de paramètre dont la signification change selon la nature de l'ordre.
J'ai ensuite une interface de visualisation de ces historiques, en filtrant sur les joueurs et/ou le type d'ordre (construction, achat, attaque, déplacement,...)


Et au fianl, il vaut mieux prévoir un petit script à part déclenché par crontab qui va archiver/purger les traces et les historiques.

tu remplace tes | par des "," et tu as un csv