|
|
|
Логер
|
|||
|---|---|---|---|
|
#18+
Сергей АрсеньевИдеальная система логирования должна обеспечивать следующие возможности - не выполнение своего кода, кода заданный уровень сообщения не требуется (в том числе связанные с генерацией строки); - переключение необходимый уровень сообщений на лету без остановки приложения; - мультиплицированной раскладку сообщений по разным журналам; - ротацию журналов с разными правилами для разных сообщений (например info удаляются из файла через два часа, а error держатся месяц, но лучше не только по уровням) - генерация различных событий по данным журнала (как-то количество обращений к системе в минуту превысило порог) - запуска различных триггеров по событиям - легкость в настройке и управлении - не допускать утечки информации. Странно только почему ее до сих пор никто не сделал. Для начала бы системы логгирования научились бы не выдавать внутреннее API (все эти методы trace/debug/warn/error etc), в которые можно запихнуть сообщение, а человеческие методы. Просто сейчас, когда нужны очень подробные сообщения, добавление сообщений мусорит код. А именно Код: java 1. 2. 3. 4. Когда можно Код: java 1. 2. 3. 4. Пока решением этой задачи ни один мейнстрим логгер не озабочен и единственный известный (мне) проект, который эту проблему решает это JBoss Logging . Никогда правда его не использовал и оборачивал все логгеры руками (jboss logging это автоматизирует). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2014, 22:51 |
|
||
|
Логер
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньев - ротацию журналов с разными правилами для разных сообщений (например info удаляются из файла через два часа, а error держатся месяц, но лучше не только по уровням) Это возможно реализовать на базе некоторых Appenders вроде JDBC-шного. Удаление-же из текстового файла (коим является лог в 99% случаев) INFO-сообщений мне представляется сомнительным занятием. Никто так не делает и это не является best-practices нигде. Сергей Арсеньев - запуска различных триггеров по событиям Каждая предметная область имеет свою терминологию. Java на уровне языка и на уровне машины не имеет возможностей. В скобках замечу что "триггер" в системотехнике и триггер в базах данных это совершенно разные вещи. Поэтому требуется пояснение ЧТО такое триггер в данном примере и как мы его должны(можем) реализовать применительно к логгированию. Лучше с примерами и исходным кодом. Сергей Арсеньев - не допускать утечки информации. Подобные требования предъявляют к софту когда проверяют его на пригодность к работе в особых услових или в особых ведомствах. Сертификация там... соответствие ГОСТ-ам. Могу предположить что софт который сертифицируется на безопасность оперирует такими сущностями как принципал, сертификат, ключ, подпись e.t.c. Я не знаю библиотек логгирования которые-бы это использовали. Вобщем как-то всё это мимо кассы. Чес слово мимо кассы. Не стоит вешать на логгирование всяких собак. У него (логгирования) весьма узкие задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2014, 23:13 |
|
||
|
Логер
|
|||
|---|---|---|---|
|
#18+
schwaДля начала бы системы логгирования научились бы не выдавать внутреннее API (все эти методы trace/debug/warn/error etc), в которые можно запихнуть сообщение, а человеческие методы. Просто сейчас, когда нужны очень подробные сообщения, добавление сообщений мусорит код.Шаблон "Фасад (декоратор)" Никакая библиотека не может предусмотреть не то что "всех вариантов", но даже "часто используемые" - слишком уж различаются потребности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2014, 23:16 |
|
||
|
Логер
|
|||
|---|---|---|---|
|
#18+
авторТо-то, смотрю, все выкинули апач. Несомненно, из-за его xml-подобного конфига. Доля nginx неуклонно растет, а доля апача неуклонно снижается. В nginx конфиг как раз не xml. Хотя, разумеется, дело тут не в формате конфига. авторА в винде - так не считается. Именно поэтому существует jsvc для nix-ов и procrun - для виндов. Никогда о них раньше не слышал. Почитал - оказалось что оба считают stdout процесса его логом. авторЭто удобно пока всё, что нужно админу - информационные сообщения о запуске-остановке сервиса и предупреждения о нехватке (какого-нибудь) пула. Почему? Например, чтобы настроить какое-нибудь информирование об ошибках сервиса по SMS, как раз удобно если логи от всех серверов и демонов оказываются в одном месте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2014, 23:38 |
|
||
|
Логер
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪкак раз удобно если логи от всех серверов и демонов оказываются в одном месте. каким образом? одно место - это ОДНА папка? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2014, 00:01 |
|
||
|
Логер
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪНикогда о них раньше не слышал. Почитал - оказалось что оба считают stdout процесса его логом.Вообще-то, оба перенаправляют два стандартных потока вывода в файлы. Их вообще не колышет лог там или цитаты из библии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2014, 09:42 |
|
||
|
Логер
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪПочему? Например, чтобы настроить какое-нибудь информирование об ошибках сервиса по SMS, как раз удобно если логи от всех серверов и демонов оказываются в одном месте.И как это противоречит тому, что одно место удобнее пока событий немного? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2014, 09:43 |
|
||
|
Логер
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovschwaДля начала бы системы логгирования научились бы не выдавать внутреннее API (все эти методы trace/debug/warn/error etc), в которые можно запихнуть сообщение, а человеческие методы. Просто сейчас, когда нужны очень подробные сообщения, добавление сообщений мусорит код.Шаблон "Фасад (декоратор)" Никакая библиотека не может предусмотреть не то что "всех вариантов", но даже "часто используемые" - слишком уж различаются потребности. Вот поэтому в java 100500 оберток над элементарной задачей - ведь можно написать декоратор. В итоге каждая команда на каждом проекте его пишет... Сколько уже пытаются написать логгер для java 15 лет или больше? И каждый раз пишут очередной фасадик. Задача системы логгирования предоставить инфраструктуру(за 15 лет-то уже можно было бы научиться куда угодно писать сообщения) и УДОБНЫЙ интерфейс для ее использования. Нет ни одной причины, чтобы в 2014 году из Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. не генерить код для логгера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2014, 11:04 |
|
||
|
Логер
|
|||
|---|---|---|---|
|
#18+
schwaНет ни одной причины, чтобы в 2014 году из Код: java 1. 2. 3. 4. 5. 6. 7. не генерить код для логгера.Дъявол, как обычно, кроется в многоточиях. Протоколирование требуется для того, чтобы выдать (краткую) информацию о работе приложения и обеспечить "посмертную" отладку. Первую задачу, худо-бедно, могут решить аннотации, а вот вторую ... Если "фигня случилась", а всё что у нас есть - отладочный лог, то в этом логе должно быть подробное отражения состояния системы. Которое может быть сколь угодно сложным и запутанным. Если бы существовал способ автоматизации этого процесса, то первое для чего он был бы использован - заменить программистов кодогенератором. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2014, 12:14 |
|
||
|
Логер
|
|||
|---|---|---|---|
|
#18+
Я бы добавил насчет удобных логгеров. Имеет смысл использовать оба варианта названий логгеров - и по пакетам, и специальные именные логгеры. Логгеры по пакетам используются, где нужно вывести строчку "на всякий случай" - для упрощения поиска ошибок. А именные заворачиваются в враппер: Код: java 1. 2. 3. 4. 5. 6. Примерно так ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2014, 09:20 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=38787390&tid=2126385]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
72ms |
get topic data: |
13ms |
get forum data: |
5ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
| others: | 235ms |
| total: | 413ms |

| 0 / 0 |
