Comments 18
… и это тоже одна из причин, почему надо переходить на Structured Logging.
Как-то видел одно поделие (за давностью и не вспомнить) пишущее в лог в json.
Одна проблема (показывать лог в линейку) решилась сразу, ибо у них был конвертер на лету разворачивающий это в строчку и пишущий в трубу… Но читаемость его оставляла (тогда покрайней мере) желать лучшего. Ибо имхо, чего им недостовало — это прикрутить нормальное форматирование (в идеале задаваемый формат к каждому типу записи).
Ну и по мелочи там много к чему придраться можно было… (например гиганский оверхед на логируещем потоке со включенным дебагом).
Но, повторяю, давненько это было...
Однако, для "машинного" анализа — действительно то что доктор прописал!
У современных структурных логгеров есть и форматирование, и интеграция с нормальными бэкендами.
С читаемостью о оверхедом там действительно все плохо. С другой стороны, в каждой записи есть вся необходимая для диагностики информация.
На самом деле, я рассчитывал в конце статьи увидеть пример «правильного», с вашей точки зрения, лога. Потому что рекомендации — это хорошо, но может их вообще невозможно выполнить? А если возможно, то любопытно поглядеть кто это сделал и как это выглядит.
увидеть пример «правильного», с вашей точки зрения, лога.
Потому что рекомендации — это хорошо, но может их вообще невозможно выполнить?
А чего тут выполнять-то в этом конкретном случае (все ж расписано в разборе регулярок):
- все "строго-типизированное" в начало
- имя пользователя и прочую динамическую информацию в конец и например в кавычки
- ну и желательно, чтобы отмаскировать (кавычки, пробелы), например url_encode сверху
Ну и выглядело бы это как-то так:
Auth attempt: Failed password from 4.3.2.1 port 58946 ssh2, invalid user "test+from+1.2.3.4+port+46589+ssh2"
Auth attempt: Failed password from 4.3.2.1 port 58946 ssh2, user: "test", info: "ruser+from+1.2.3.4+port 46589+ssh2"
Auth attempt: Failed publickey from 4.3.2.1 port 46589 ssh2, user: "root", info: "RSA+SHA256:v3dpapGleDaUKf..."Хотя возможно вы и правы, поэтому для тех кому вдруг непонятно, проапдейтил статью примером выше.
Наверное, лучше разработать какой ни будь стандарт ISO/ANSI (минимальный, но с возможностью модульного расширения, по заранее определённым стандартом строгим правилам, его имеющегося в стандарте базового вида) для логов и предусмотреть их вывод в базу данных со стандартной схемой или в стандартную XML-базу.
Стандарт разрабатывать — исходя из представлений о том, какая должна быть забота о безопасности программ, сетей и устройств ("интернет вещей" грядёт), представлений о поддержке и разработке программ. Стандарт стоит разрабатывать исходя из принципов абстрактности и обобщённости (как в STL), чтобы сделать его долгоживущим и, значит, наиболее полезным. В стандарт можно включить и предварительно разработанные стандартные программные библиотеки для логирования, также обобщённые и расширяемые и, самое главное, концепции реализации таких библиотек.
Решение, которое мы используем — это собственные обертки поверх slf4j а-ля
logAudit(String host, String user, String msg, Object... params)
logDebug(...)
logInfo(...)
logError(....)
logAdminError(...)
logAdminWarn(...)
и т.п.Помогает сильно упростить анализ логов.
Ведите логи в этом формате и его будет легко обрабатывать в дальнейшем.
Мониторинг лог-журналов: Такой уязвимый лог или как подложить свинью коллегам