powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Как нам реорганизовать [s]Рабкрин[/s] лог-файл?
1 сообщений из 26, страница 2 из 2
Как нам реорганизовать [s]Рабкрин[/s] лог-файл?
    #39547708
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Соколинский Борис1. Точная хронология и хронометраж всех действий.

Эта задача вообще ортогональна по отношению к логгированию. Ведь фиксировать события
можно независимо. От записи в файл. А писать их - асинхронно. Async IO.

2. Запись неоднородной информации

Да в логах информация всегда неоднородна.

3. Максимальная надежность работы.

По этому вопросу нужно поднимать даже не топик а отдельный форум. Слишком обширный вопрос.
4. Возможность автоматического анализа.
В текстовом файле, который сейчас используется, пп.1-3 выполняются, но с п. 4, понятное дело, все плохо - нужно писать кучу парсеров.

Каждую запись в лог-файле можно разделить на 2 части.
1) фиксированная. Здесь может быть список mandatory-атрибутов которые есть всегда. И порядок - строгий.
Код: sql
1.
2.
2017-11-04 00:13:21.098374;Sensor1;U=2.4;C=0.22
2017-11-04 00:13:22.345;Sensor2;U=2.0;C=0.0



2) опциональная. Здесь в формате списка или документа (json/xml) можно добавить какие-то опции, которые
на данный момент еще строго не определены. Формат можно упростить. Например для современных
парсеров JSon уже можно опускать кавычки.
Код: sql
1.
2017-11-04 00:13:21.098374;Sensor1;U=2.4;C=0.22;{protocol:tcp{port1:1001,port2:1002,comment:"Cisco"}}


Я-бы пошел еще дальше и нормализовал имена и какие-то справочные символы чтоб еще поджать место.
Вопрос парсинга такого файла остается открытым ... но принципиально мы ничего не упустили. Вся инфа
есть. И если очень нужно - то любой разрабочик средней руки сможет построить по этому отчот.

С СУБД, ввиду п. 2-3 в этом месте связываться боязно.
Может я чего-то не знаю, и человечество придумало еще какие-то варианты?
В СУБД логи писать не надо. Удельная стоимость хранения информации в СУБД всегда выше
чем просто на диске. А для современной файловой системы надежность - достаточно высока
и бекапить удобно. Кроме того упавшую файловую систему любой админ вам починит. За банку пива. В то время
как упавшую БД - только специалист в ней и за бабло поболее. И бэкапить БД вобщем-то сложнее. И контроль
за этим процессом должен быть поставлен не "на отъебись" а по настоящему. Журнал. Ответственные. И т.п.

Если логи нужны для статистики то ее (статистику) можно накапливать в рилтайме просто ведя учот событий.
Это дешево и не требует вообще никаких логов. Я так делал. И сейчас делаю.
...
Рейтинг: 0 / 0
1 сообщений из 26, страница 2 из 2
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Как нам реорганизовать [s]Рабкрин[/s] лог-файл?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]