Логи

Имеющийся механизм логов никуда не годится.

Нужно:

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

Честно говоря помоему стандарт дефакто log4j и изобретать сдесь не стоит. (Хотя Sun и изобретает.)
Под твои требования вполне подойдет. Хотя можно доводить и то что есть сейчас.

Да логи делать надо... сегодня наблюдаю:
1129029547593 WARNING 16 net.sf.l2j.gameserver.model.L2MerchantInstance possible client hacker: VeRzIvUl attempting to buy from GM shop! < Ban him!
Что это, когда это, с какого IP...
или вот:
1129152824093 WARNING 1299 net.sf.l2j.loginserver.Logins hacking detected from ip:192.168.0.105 .. adding IP to banlist
за что бан, за подбор паролей? тогда к какому акаунту... опятьже во сколько... (приходят уроды и начинают подбирать пароли в клубе, а потом весь клуб в бан лист попадает... вот сижу теперь и думаю открывать им доступ с клуба к мировым сервакам или как....)

немешало бы их расширить и сделать удобочитаемое время... чтоб хоть было чем аргументировать бан

В принципе, при все бедности класса lib.Log, он вполне для этой цели подходит. Просто нужно будет логи на него переводить с детальными текстами

Надо четко разделить 2 проблемы
1.Нас не устраивает нынешняя система логирования.( Если конечно неустраивет, может просто нужно научится ей пользоваться, доку соответсвующую написать.)
2.В сервере плохо прописаны сами сообшения журнализации. Их мало или не там где надо или непонятно что означают.

Возможно Эти задачи надо разделить.
P.S. Пункт 2 огромная работа которая может затронуть весь сервер. Пересмотреть и поправить все практически невозможно. Может нужно сформулировать задачу подругому: составить правила как и чего писать в логи. Ну и в дальнейшем этому следовать и походу дела подправлять что уже есть.
ИМХО

А нельзя ли писать логи в MySQL базу в некотором стандартном виде?
Например таком:
время_действия код_действий X_координата Y_координата Z_координата имя_деятеля имя_цели параметр_1 ... параметр_n.

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

Логи в SQL в данном частном случае писать не шибко удобно ИМХО, куда лучше - в файлы. Для ручной и скриптовой работы с ними лучше.

Balancer:

Логи в SQL в данном частном случае писать не шибко удобно ИМХО, куда лучше - в файлы. Для ручной и скриптовой работы с ними лучше.

 

Да действительно, я ступил, нет особого смысла писать в базу. Парсить файлы можно ничуть не хуже SQl.
А в каком формате их тогда писать в файл?

Да, вдогонку, чтобы не забылось.

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

В том то и дело, что логгировать нужно много параметров. И количество полей в таблице в данном случае будет разрастаться с неимоверной скоростью. Помоему проще будет причесать нынешнюю систему вывода ошибок. Сделать несколько файлов, один для информации о действиях игроков, другой для внутренних ошибок сервера, в третий, например, класть поданые админом команды (типа кто рестартил и когда рестартил), ну и т.д.

iFTP:

В том то и дело, что логгировать нужно много параметров. И количество полей в таблице в данном случае будет разрастаться с неимоверной скоростью. Помоему проще будет причесать нынешнюю систему вывода ошибок. Сделать несколько файлов, один для информации о действиях игроков, другой для внутренних ошибок сервера, в третий, например, класть поданые админом команды (типа кто рестартил и когда рестартил), ну и т.д.

 

Мне кажется надо логировать в таблицу причём в ней будет несколько жёстко фиксированых полей:
тип лога или id лога

имя чара сделавшего действие или(и) его id. При некоторых типах логов(например "монстр убил игрока") этот параметр может означать id монстра.

имя чара на которого было совершено действие или(и) его id. При некоторых типах логов(например "игрок использовал скилл на") этот параметр может означать id монстра.

Object id вещи тоже можно вынести в отдельное поле(оно конечно будет использоваться не во всех логах но это очень важный параметр по нему будет часто производиться поиск и поэтому лучше сделать его отдельным)

и несколько не фиксированных полей (1-2 строковых и 5-8 числовых наверное) в которых в зависимости от типа лога будут записываться разные параметры(количество вещей количество отнятых hp, id клана, уровень энчанта итд).

Такая схема используется в L2off. По моему довольно удачно и удобно.

Кстати, подробный лог действий игрока, наконец, позволит оценить количество и интенсивность тех или иных операций на сервере, чтобы можно было решить, что можно расширять скриптами (гибкость) или писать на Java (скорость)

я в принципе давно закончил с logd, сделал как в ворованом сервере:
- logd работает как standalone process(можно на другой машине даже пускать)
- события (system,event,chat) сливаются в него через сокеты
- он немедленно сливает их в файл с флушем

потом можно подкачать все это в базу, но я пишу в логи не все, а то, что мне интересно
вызывается просто как LogServerClient.getInstance().addEvent(int logid,L2PcInstance actor,String data)
еще есть addChat & addSystem

zabbix:

- события (system,event,chat) сливаются в него через сокеты

 

А чем мотивированно такое решение?

- тем что логд крутится в отдельном процессе а не потоке
- тем что вызов LogServerClient::add* разблокируется сразу после отсылки
- тем что я буду в итоге держать это на разных машинах

аналогичную хрень(отдельный сервер) начал делать для мобов, пока только спавн сделал
в итоге приходится переписывать SelectorThread и Ко под свои нужды

Возвращаясь к нашим баранам.

Что нужно логгировать и каков должен быть формат логов? Собираюсь делать так:

Log.info("Text") - в лог пишутся время записи, текст, текущий игрок, его координаты
Log.fine("Text", L2Object) - дополнительно пишется объект и его координаты (это может быть target, может быть дропнутая вещь и т.п.)
Log.warning(....)

И т.д. с разным уровнем логгирования.

В конфиге можно будет динамически менять уровень логгирования системы.

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

Объект будет храниться в текстовом виде, обеспечение этого вида должно будет выполняться методом классов, что-нибудь типа String toLog() { .. }

Что ещё?

...

Кстати, в Java можно как-то узнать класс метода, из которого вызывали нашу статическую функцию? Грубо говоря, получить тип объекта с вершины стека возвратов?

по собственному опыту(не раз пригодилось) - писать действие числом, схожие действия объединять в диапазоны
потом легоко выковыриваю логи положим торговли/обмена из базы запросом
SELECT * FROM 2005_10_27_logd WHERE actor = 'cheater' AND logid >= 100 AND logid <= 110

соответственно, для действий трейда в магазине, приватсторе и эксчейнджа выставлены номера с 100 до 110, и все как на ладоне

Всё равно действия в линеечку не развернёшь И всегда можно использовать 'WHERE action IN (a1, a2, a3)'

развернешь, то что оф генерит раскладывается по полочкам одним запросом

насчет как узнать - например так:

        public static class CurrentClassGetter extends SecurityManager {
                public String getClassName() {
                        return getClassContext()[1].getName();
                }
        }
...
System.err.println("Usage: " + new CurrentClassGetter().getClassName() + usage);

Действие лучше действительно писать числом. И разбивать их в диапазоны. Логи чара скажем 3xx логи вещей 4xx логи чата 7xx ну итд. Честное слово так гораздо проще и удобнее.

Log.info("Text") - в лог пишутся время записи, текст, текущий игрок, его координаты

 

Какой текст? Вообще не совсем понятен предполагаемый формат лога. Вот скажем лог
"Игрок gamer(id - 66666666) передал 1000 аден(obj_id адены- 7777777) игроку CoolGamer(id - 8888888)"
в моём представление должен быть строкой таблицы примерно такого вида:
| 413 | gamer | 66666666 |CoolGamer|8888888|7777777|x y z| | | |57 |1000| |
Здесь 413 - код действия "игрок A передал вещь игроку B". Как и все логи транзикций вещей начинается с 4. Далее идут 4 фисированных поля - actor, actor_id, target,target_id(в некоторых типах логов они будут пустыми особенно target). Далее идёт поле с obj id вещи(оно тоже фисированное). Дальше 1-3 полей для строк и 2-7 полей для чисел. Необходимо конечно заранее условиться какие из этих полей что будут значить в зависимости от типа лога. Скажем можно условиться что для всех логов транзикций с вещами первое поле будет id типа вещи а второе её количество. Тогда запросом log_id>400 AND log_id<500 and num1=57 and num2>10000 мы получим все транзикции адены с количеством адены более 10000. Вот так я себе это представляю. Для работы с такими логами лучше иметь какой-то специализированный вьювер который бы преобразовывал их к человеческому виду. Вот так я себе всё это представляю.

до тех пор пока для выделения objectid для айтемов юзается idfactory это useless

Zzahar> в моём представление должен быть строкой таблицы примерно такого вида:
Zzahar> | 413 | gamer | 66666666 |CoolGamer|8888888|7777777|x y z| | | |57 |1000| |

а дата/время?

по-моему первой строкой должно быть, и где-то в конфиге настраиваться формат, типа выставил:
LOG_DATE_FORMAT = "YYMMDD HH:MM:SS"

и получи во всех логах в начале строки.
Я бы конечно хотел подробный конфиг файл для возможности включить и выключить лог для каждого действия.
типа
LOG_DROP_ITEM = "enable","413","item.log"
LOG_GIVE_ITEM = "enable","412","item.log"
LOG_BUY_ITEM = "disable","411","item.log"

ну и так на каждую строку логов

--
Sergey Kulik aka Saboteur

А я предлагаю сделать отдельный лог-файл для каждого игрока.

Styx> А я предлагаю сделать отдельный лог-файл для каждого игрока.

Для каждого игрока, для каждой цели, для каждого района координат... Всё это может функция SELECT у mysql