Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как нам реорганизовать [s]Рабкрин[/s] лог-файл?
|
|||
|---|---|---|---|
|
#18+
Соколинский Борис1. Точная хронология и хронометраж всех действий. Эта задача вообще ортогональна по отношению к логгированию. Ведь фиксировать события можно независимо. От записи в файл. А писать их - асинхронно. Async IO. 2. Запись неоднородной информации Да в логах информация всегда неоднородна. 3. Максимальная надежность работы. По этому вопросу нужно поднимать даже не топик а отдельный форум. Слишком обширный вопрос. 4. Возможность автоматического анализа. В текстовом файле, который сейчас используется, пп.1-3 выполняются, но с п. 4, понятное дело, все плохо - нужно писать кучу парсеров. Каждую запись в лог-файле можно разделить на 2 части. 1) фиксированная. Здесь может быть список mandatory-атрибутов которые есть всегда. И порядок - строгий. Код: sql 1. 2. 2) опциональная. Здесь в формате списка или документа (json/xml) можно добавить какие-то опции, которые на данный момент еще строго не определены. Формат можно упростить. Например для современных парсеров JSon уже можно опускать кавычки. Код: sql 1. Я-бы пошел еще дальше и нормализовал имена и какие-то справочные символы чтоб еще поджать место. Вопрос парсинга такого файла остается открытым ... но принципиально мы ничего не упустили. Вся инфа есть. И если очень нужно - то любой разрабочик средней руки сможет построить по этому отчот. С СУБД, ввиду п. 2-3 в этом месте связываться боязно. Может я чего-то не знаю, и человечество придумало еще какие-то варианты? В СУБД логи писать не надо. Удельная стоимость хранения информации в СУБД всегда выше чем просто на диске. А для современной файловой системы надежность - достаточно высока и бекапить удобно. Кроме того упавшую файловую систему любой админ вам починит. За банку пива. В то время как упавшую БД - только специалист в ней и за бабло поболее. И бэкапить БД вобщем-то сложнее. И контроль за этим процессом должен быть поставлен не "на отъебись" а по настоящему. Журнал. Ответственные. И т.п. Если логи нужны для статистики то ее (статистику) можно накапливать в рилтайме просто ведя учот событий. Это дешево и не требует вообще никаких логов. Я так делал. И сейчас делаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2017, 01:28 |
|
||
|
|

start [/forum/topic.php?fid=16&gotonew=1&tid=1340241]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
162ms |
get topic data: |
8ms |
get first new msg: |
6ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 10ms |
| total: | 256ms |

| 0 / 0 |
