К имеющемуся проекту потребовался логер, понятный пользователю.
И вот передо мной встал вопрос, а как организовать такой логгер. Единственное, что я точно определил, что там должны будет храниться не только системные сообщения и запросы в БД, но и понятные пользователю сообщения т.е. он не знает даже, что такое База данных.

1. Основные модерациооные действия происходят через запрос к базе данных. Так вот, хватит ли мне для полного контроля сохранять все операции с БД и файлами. Или есть еще функции, которые следует контролировать? 
2. Сколько по времени следует хранить логии?
3. Где стоит хранить логии? Записей много, а модерация самая элементарная.
4. Как их стоит представлять пользователю?

Должен отметить, что логии будут просматриваться не в ручную, конечно для этого будет специальный модуль.

В идеальной реализации системы логирования будут использоваться Аспектно-Ориентированное программирование и Syslog или БД

http://phpaspect.org/
http://ru2.php.net/syslog

WolfON, 
Английского мы не знаем :(

Это сообщение отредактировал(а) BuShaRt - 18.5.2007, 12:18

BuShaRt, а очень-очень зря. хороший документации по аспектно-ориентированному программированию на русском языке я не находил. сама эта парадигма, на мой взгляд очень перспективна в создании такого функционала, вроде систем поиска, логирования, обеспечения безопасности и тд.
Можешь почитать вот это:
http://www.cmsdevelopment.com/ru/articles/aosdinphp/

Чтобы не отдаляться от темы, то скажу, что если не нужны особо навороченные фичи и все-такое, то почему-бы просто не перехватывать все запросы на уровне абстракции баз данных, анализировать их и затем всю нужную информацию писать куда надо (через тот-же syslog допустим).

По суте я знаю как реализовать, но тема для меня новая, хотел посоветываться, чтоб знать, какие есть подводные камни.

А как вы предложите перехватывать? В основном коде?

-----
Я как думал, что перед отправкой запроса создавать запись в БД в читабельной форме (на русском) о выполненном действие и некоторой дополнительной информации о дате и т.п.
или
Поставить буфер в классе работы с MySQL, который будет перед выполнением парсить запросы... только в данном случае получаеться туфталогия какая-то, с тем, чтоб парсер не парсил запросы сгенирированные логиром   

Если так, то можно создать триггер в БД на добавление полей, который дополнительную информацию будет записывать в отдельную таблицу.
Или просто писать дополнительную информацию рядом с основной - в скорости от этого не убудет, зато потом можно быстро создавать всякие-разные отчеты.

Как реализовать в коде я идею уже кинул, если, конечно, делать серьезный логгер.
А простой можно и просто выделить пару функций на уровне абстракции бд, а можно и класс написать - тут уж на вкус и цвет..

Подводные камни - потеря производительности. Особенно при использовании БД (лишний инсерт - дорогая операция в мускуле), по этому самое оптимальное решение syslog - за эффективное хранение информации тут будет отвечать непосредственно система.
Да и вообщем-то для ведения логов хватает самого обычного текстового файла.

WolfON, 
А по времени сколько желательно хранить логи? Ведь по суте я думаю если стереть отчеты месячной давности, то от безопастности не не убудет?
Или я ошибаюсь?

BuShaRt, ну это уже ваше личное дело )
Можно месяц, можно два, а можно вообще не удалять.
Компромисс - месяц хранить, а потом в архив

WolfON, 
Ясно.. спасибо 

ЛОГИ!!! я не совсем понял что тебе нужно!!! Если нужно просматривать что именно вводил пользователь в адресной строке (пример: http:⁄⁄mysite.ru⁄index.php?page=<script>alert(‘XSS’)</script>) т.е. для быстрого выяснения через какой баг ваш сайт взломали советую поставить замечательны скрипт носящий название - cnstats, он нетока тебе все покажет но и расскажет какой ипи, во ско-ко... короче поставь и посмотри... непожалеешь....

MoLeX, 
нет, журал действий модераторов... Дабы проследить дыру в безопастности созданную человеческим фактором т.е. отгородиться от соц. инжинеров.

BuShaRt, от человеческого фактора практически невозможно защититься, но есть возможность "догадаться" о взломе. Самый очевидный - при создании отчета выставлять каждому действию или группе действий - степень опасности. Т.е допустим клиент заходит с ip из одной подсети - это нормальное действие у него 0 опасности, но если вдруг пользователь заходит с ip из другой подсети, то ему можно выставить 5 уровень опасности - возможно, что это не он заходит. Или если пользователь часто логиниться, то этим действием тоже выставляется повышенный уровень опасности - допустим 3.
В итоге можно получить таблицу пользователей с уровнем опасности для каждого и таблицу действий.
Ориентируясь на уровень опасности можно уже принимать какие-нибудь меры, допустим принудительная смена пароля.

WolfON, 
Наверно логичней всего продумывать логер под определенный проект. Т.к. вами редставленно средство нелогично в пределах админ системы сайта магазина.

З.ы. именно сайта магазина, а не сайта-магазина.