НО...! Ведь если на каждый чих писать в лог, потом в этих логах ничего не найти.
2. Использовать машиночитаемый формат сообщений (json)
Рекомендация вроде ясна, удобно в дальнейшем анализировать.
Вот только куда ни посмотришь на логи, везде обычная строка, без key-value или json
3. Рекомендуют записывать контекст.
Просто сообщение "был такой то exception" не катит, т.к. не понятно с каким пользователем/действием/запросом это было связано.
Нужно записывать запрос к серверу, имя пользователя, id сессии и т.п.
НО...! В процессе выполнения "главной задачи" (обработки запроса/транзакции) обычно задача разделяется на меньшие задачи (формирует запросы к базе, выполняется дополнительная обработка данных и т.п.). Эти меньшие задачи тоже нужно отслеживать (логгировать). К ним дописывать тот же контекст, т.е. дублировать/протаскивать контекст в сообщениях? С другой стороны, если вообще не указывать контекст, то как связать эту внутреннюю подзадачу с "главным" запросом при разборе проблем.
4. Держать все логи рядом (вместе)
Это понятно. Но иногда выделяют отдельные лог файлы для ошибок, например. Также удобно собирать логи с нескольких машин где-то на удаленном сервере.
5. Собирать метрики
Например, времени выполнения запросов, процент отказов и т.п.
НО.... Чтобы такое делать надо вообще отдельную подсистему писать — для расчета этих метрик. Как это на практике, непонятно.
Как ЭТО происходит у вас? Поделитесь своими практиками/правилами?
Здравствуйте, Буравчик, Вы писали:
Б>Поделитесь полезными советами про логи
Б>1. Писать в лог чем больше, тем лучше. Б>Больше данных — легче разобраться с проблемами. Б>НО...! Ведь если на каждый чих писать в лог, потом в этих логах ничего не найти.
вообще много логов не будет, потому что программистам их лень писать.
Просто следить чтобы в цикле всякую хрень в лог не фигачило. Что обязательго логгировать,
так это все внешние вызовы (входящие и исходящие) и все эксепшены.
Еще есть уровни логгирования.
Б>2. Использовать машиночитаемый формат сообщений (json)
Бред, imho
Важно чтобы лог можно было отфильтровать (по времени допустим, или там по юзеру)
json вообще не уперся, если обычный текст фильтруется (каждая строчка содержит таймстемп и юзера)
Б>3. Рекомендуют записывать контекст.
Б>Просто сообщение "был такой то exception" не катит, т.к. не понятно с каким пользователем/действием/запросом это было связано. Б>Нужно записывать запрос к серверу, имя пользователя, id сессии и т.п.
Б>НО...! В процессе выполнения "главной задачи" (обработки запроса/транзакции) обычно задача разделяется на меньшие задачи (формирует запросы к базе, выполняется дополнительная обработка данных и т.п.). Эти меньшие задачи тоже нужно отслеживать (логгировать). К ним дописывать тот же контекст, т.е. дублировать/протаскивать контекст в сообщениях? С другой стороны, если вообще не указывать контекст, то как связать эту внутреннюю подзадачу с "главным" запросом при разборе проблем.
Да, вообще это проблема. Пусть не контекст, так хотя бы время, с максимальной точностью.
Для http есть глобальный контекст вызова (входящего). Он так или иначе доступен.
Нафига это вообще надо — если несколько вызовов обрабатываются параллельно и пишут в один лог,
Чтобы можно было разобраться что к чему относится.
Б>4. Держать все логи рядом (вместе) Б>Это понятно. Но иногда выделяют отдельные лог файлы для ошибок, например. Также удобно собирать логи с нескольких машин где-то на удаленном сервере.
Пофик
Б>5. Собирать метрики
Б>Например, времени выполнения запросов, процент отказов и т.п. Б>НО.... Чтобы такое делать надо вообще отдельную подсистему писать — для расчета этих метрик. Как это на практике, непонятно.
Б>Как ЭТО происходит у вас? Поделитесь своими практиками/правилами?
Оно подключается отладчиком, или скриптом, или модулем, ко всем работающим приложениям и базам компании и монитрит все транзакции, скидывая данные в один центр с нормальной навигацией (с графами вызовов)
Можно отследить грохнувшуюся операцию от того чтов приложени х юзер нажал на кнопку y, до момента когда потом упала хранимка в какой-то базе, вызванная через 5 промежуточных сервисов (половина rest, половина wcf). Показывает стеки вызовов, как внутри приложения, так и между приложениями, для баз — выполняемый sql. Также все тайминги операций и изменения в них.
В общем для мониторинга — пока выглядит довольно неплохо.
Здравствуйте, Буравчик, Вы писали:
Б>Поделитесь полезными советами про логи.
Б>Что пишут умные люди:
Б>1. Писать в лог чем больше, тем лучше.
Б>Больше данных — легче разобраться с проблемами.
Б>НО...! Ведь если на каждый чих писать в лог, потом в этих логах ничего не найти.
Не нужно на каждый чих, нужно чтобы можно было понять контекст выполнения при выкидывании ошибки, а так же чтобы можно было построить метрики по параметрам выполнения, если только не заведено отдельного решения для метрик.
Б>2. Использовать машиночитаемый формат сообщений (json)
Б>Рекомендация вроде ясна, удобно в дальнейшем анализировать. Б>Вот только куда ни посмотришь на логи, везде обычная строка, без key-value или json
Это у вас так. Одно время я поработал в МС на написании сервисов и в моем отделе как раз был принят такой подход со структурированным логгингом. Это на порядок улучшало работу с логами — можно было строить довольно сложные запросы вида "сколько запросов с таким и таким параметром привело к ошибке такого типа.
Б>3. Рекомендуют записывать контекст.
Б>Просто сообщение "был такой то exception" не катит, т.к. не понятно с каким пользователем/действием/запросом это было связано. Б>Нужно записывать запрос к серверу, имя пользователя, id сессии и т.п.
Б>НО...! В процессе выполнения "главной задачи" (обработки запроса/транзакции) обычно задача разделяется на меньшие задачи (формирует запросы к базе, выполняется дополнительная обработка данных и т.п.). Эти меньшие задачи тоже нужно отслеживать (логгировать). К ним дописывать тот же контекст, т.е. дублировать/протаскивать контекст в сообщениях? С другой стороны, если вообще не указывать контекст, то как связать эту внутреннюю подзадачу с "главным" запросом при разборе проблем.
Нужен глобальный ID ассоциированный с запросом пользователя и локальные ID ассоциированые с запросами к зависимостям. Этого достаточно.
Эти две вещи можно объединить например так.
Б>4. Держать все логи рядом (вместе)
Б>Это понятно. Но иногда выделяют отдельные лог файлы для ошибок, например. Также удобно собирать логи с нескольких машин где-то на удаленном сервере.
Не вижу большого смысла. Информационные сообщения могут быть настолько же важны.
Б>5. Собирать метрики
Б>Например, времени выполнения запросов, процент отказов и т.п. Б>НО.... Чтобы такое делать надо вообще отдельную подсистему писать — для расчета этих метрик. Как это на практике, непонятно.
Можно совместить с логами, это работает наиболее эффективно.
Б>Как ЭТО происходит у вас? Поделитесь своими практиками/правилами?
Здравствуйте, Буравчик, Вы писали:
Б>Поделитесь полезными советами про логи.
Тема очень интересная, но почему-то никто о ней не говорит и книжек "как правильно делать логгирование и что такое ELK" я не видел. Даже подумываю статью на тему запилить.
Вкратце о типах логов, как я их понимаю:
— аудит. Это структурированные логи, содержащие как минимум название операции, параметры операции и результат операции. Большинство, или даже все, поля аудит лога стандартизированы. Эти логи обычно выгружаются в отчетную систему и используются для аналитики типа "какие фичи нашего приложения самые популярные" и "кто удалил данные"
— трафик. Содержат текст запроса и ответа (в разумных пределах). Незаменимы для расследования проблем, но могут занимать много места и содержать секретные данные, вроде паролей и номеров кредитных карт.
— метрики. Агрегированные, обычно с окном в одну минуту, численные показатели работы приложения. Самые популярные — кол-во запросов в секунду, кол-во ошибок в секунду, объем свободной памяти и т.п. Нужны для изучения поведения приложения на проде и для расследования сбоев. Бессмысленны, если нет софта для построения графиков по метрикам.
— трассировка. id вызывающей стороны, тип операции, время выполнения операции. Очень важны для изучения быстродействия в распределенных системах. Пример: https://github.com/openzipkin/zipkin . В рабоче-крестьянском софте часто достаточно добавлять время выполнения запроса в аудит лог.
— текстовые логи.
Попробую покомментировать по пунктам:
Б>1. Писать в лог чем больше, тем лучше. Б>Больше данных — легче разобраться с проблемами.
Больше данных — хорошая мысль, НО — если у вас 1 тыс запросов в секунду, это сколько мегабайт в час на диск получается? Еще есть соображение персональных или секурных данных — они не должны попадать в лог. Уровень логгирования в продакшне — дело сугубо индивидуальное, но нужно стремиться иметь хотя бы логи аудита
Б>НО...! Ведь если на каждый чих писать в лог, потом в этих логах ничего не найти.
А что там хочется найти? Наверное, ошибки, которые нужно расследовать? И логи, которые относятся к запросу, вызвавшему ошибку? Это решается культурой разработки(писать в ERROR только важные ошибки) и наличием RequestId в логах.
Б>2. Использовать машиночитаемый формат сообщений (json) Б>Рекомендация вроде ясна, удобно в дальнейшем анализировать. Б>Вот только куда ни посмотришь на логи, везде обычная строка, без key-value или json
Здесь важен баланс — текстовые логи сложно парсить, json-логи нечитаемы без сооответствующего софта.
Б>3. Рекомендуют записывать контекст. Б>Просто сообщение "был такой то exception" не катит, т.к. не понятно с каким пользователем/действием/запросом это было связано. Б>Нужно записывать запрос к серверу, имя пользователя, id сессии и т.п.
Б>НО...! В процессе выполнения "главной задачи" (обработки запроса/транзакции) обычно задача разделяется на меньшие задачи (формирует запросы к базе, выполняется дополнительная обработка данных и т.п.). Эти меньшие задачи тоже нужно отслеживать (логгировать). К ним дописывать тот же контекст, т.е. дублировать/протаскивать контекст в сообщениях? С другой стороны, если вообще не указывать контекст, то как связать эту внутреннюю подзадачу с "главным" запросом при разборе проблем.
Да, протаскивать и дублировать, в тяжелых случаях логи можно отфильтровать по подсистеме, если, конечно, подсистемы пишут в лог свое название.
Б>4. Держать все логи рядом (вместе) Б>Это понятно. Но иногда выделяют отдельные лог файлы для ошибок, например. Также удобно собирать логи с нескольких машин где-то на удаленном сервере.
Зависит от наличия централизованной системы сбора логов. В микросервисной архитектуре это необходимо, в монолитах может быть удобнее несколько файлов логов.
Б>5. Собирать метрики Б>Например, времени выполнения запросов, процент отказов и т.п. Б>НО.... Чтобы такое делать надо вообще отдельную подсистему писать — для расчета этих метрик. Как это на практике, непонятно.
Есть готовые библиотеки для метрик, которые умеют собирать стандартные метрики и агрегировать пользовательские в мин/макс/среднее/персентили
Б>Как ЭТО происходит у вас? Поделитесь своими практиками/правилами?
Важно понимать, какием образом логи потом будут использоваться, и логгировать так, чтобы упростить последующее чтение логов. Разделять программные ошибки (NPE) с клиентскими (валидаторы) и админскими (недоступна база). Использовать requestId, чтобы найти запрос по ошибке и ошибку по запросу.
Хорошо помогает использование собственной обертки для логгирования c методами типа logValidationFailed/logUnexpectedError/logRemoteError/итп с запретом логгировать напрямую через логгер.
Здравствуйте, Буравчик, Вы писали:
Б>Поделитесь полезными советами про логи.
Нужно собирать такую информацию которая позволить воспроизводить проблемы на стенде.
Б>Что пишут умные люди: Б>1. Писать в лог чем больше, тем лучше.
На одном проекте писались все входы и выходы из функция + дополнительные логи. В какой-то момент придумали сделать циклический буфер и во время проблемы дампить только его чтобы не нагружать систему. Этим продумктом был софтсвитч . Б>Больше данных — легче разобраться с проблемами. Б>НО...! Ведь если на каждый чих писать в лог, потом в этих логах ничего не найти.
Если знать куда глдяеть, то всё находится. Б>2. Использовать машиночитаемый формат сообщений (json)
Как по мне, так для машиночитаемого формата тебе нужно будет потом написать тулзу которая это всё бдует машиночитать. Б>3. Рекомендуют записывать контекст.
Да. Б>4. Держать все логи рядом (вместе) Б>Это понятно. Но иногда выделяют отдельные лог файлы для ошибок, например. Также удобно собирать логи с нескольких машин где-то на удаленном сервере.
Не обязательно, но нужен способ получить их все в одно место для обработки 1-2 командами. Б>5. Собирать метрики
Метрики это || штука. Их надо собирать всегда по многим параметрам чтобы потом понимать и разные юзкейзы использования системы, и вести статистику, и смотреть какие, сколько и где были проблемы. Б>НО.... Чтобы такое делать надо вообще отдельную подсистему писать — для расчета этих метрик. Как это на практике, непонятно.
Да. Можно сделать микросервис который будет именно что получать метрики из разных точек управления и отправлять на сервера. Б>Как ЭТО происходит у вас? Поделитесь своими практиками/правилами?
Много логов с разным уровнем, всякие дебаг-фишки вроде снятия сетевого дампа и т.п, метрики тоже есть вроде падений, перезагрузок, рост памяти и т.п., в общем, всё стандартно.
Здравствуйте, Буравчик, Вы писали:
Б>1. Писать в лог чем больше, тем лучше. Б>Больше данных — легче разобраться с проблемами. Б>НО...! Ведь если на каждый чих писать в лог, потом в этих логах ничего не найти.
Как сложилось у нас.
Руководствоваться полезностью логов для решения проблем. Не общей мыслью, что чем больше тем полезнее. А смотрим на конкретную часто (или потенциально критичную хоть и не часто) возникающую проблему и думаем что стоит писать. Постепенно, с таким подходом для всех значимых кэйсов добавите логи с нужной инфой.
Б>2. Использовать машиночитаемый формат сообщений (json) Б>Рекомендация вроде ясна, удобно в дальнейшем анализировать. Б>Вот только куда ни посмотришь на логи, везде обычная строка, без key-value или json
структура у лога будет в любом случае (кроме простейших), хотя бы минимально: дата-время, уровень, подсистема, тип события, сообщение, +набор произвольных параметров.
и в более менее серьёзно используемом продукте логов будет не мало, глазами там искать будет неудобно — однозначно понадобятся фильтрации/выборки по параметрам логов, а это значит что лучше машиночитаемый.
Вариантов тулов масса. Можете в бд писать, можете в csv. ДЛя csv логов, есть отличная тулса — LogParser
Б>3. Рекомендуют записывать контекст.
тут уже были рекомендации, можно записывать некий ид-запроса (контекста), а в начале (при его создании) трэйс — с подробной инфой о нём.
если практика покажет, что удобно что-то дублировать — добавите.
Б>4. Держать все логи рядом (вместе) Б>Это понятно. Но иногда выделяют отдельные лог файлы для ошибок, например.
если у вас будет тулса для просмотра с фильтрациями/выборками — то удобнее вместе.
Б>5. Собирать метрики Б>Например, времени выполнения запросов, процент отказов и т.п. Б>НО.... Чтобы такое делать надо вообще отдельную подсистему писать — для расчета этих метрик. Как это на практике, непонятно.
метрики это по сути инфо-логи, если есть точки когда что-то сняли (время обработки всего реквеста, какого-то действия, запроса к БД и тп) — логируйте как инфо-лог.
Здравствуйте, scf, Вы писали:
scf>Здравствуйте, Буравчик, Вы писали:
Б>>Поделитесь полезными советами про логи.
scf>Тема очень интересная, но почему-то никто о ней не говорит и книжек "как правильно делать логгирование и что такое ELK" я не видел. Даже подумываю статью на тему запилить. scf>Вкратце о типах логов, как я их понимаю:
scf>- аудит. Это структурированные логи, содержащие как минимум название операции, параметры операции и результат операции. Большинство, или даже все, поля аудит лога стандартизированы. Эти логи обычно выгружаются в отчетную систему и используются для аналитики типа "какие фичи нашего приложения самые популярные" и "кто удалил данные"
Уточнение: аудит обычно содержит данные о взаимодействии с нашей системой снаружи. В классике — это лог действий пользователя. То есть прямо вот одно действие — одна строка.
Если там под капотом происхолит стопятьсот действий — их в этот лог не пишем: аудит хранится для того, чтобы понять, кто виноват. И очень важно логгировать user identity.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Контекст удобно инициализировать при начале обработки запроса, хранить в thread-local переменной и чистить при завершении. Тогда никуда ничего протаскивать не надо, всё доступно всем подзадачам. Более того, все java-logging фрэймворки умеют с таким контекстом работать и автоматически дописывать его к сообщениям, т.е. подзадачам даже и знать про него не надо. Ещё нужно не забывать пробрасывать его в другие потоки, если задача в пул передаётся или в очередь.
Б>1. Писать в лог чем больше, тем лучше. Б>Больше данных — легче разобраться с проблемами. Б>НО...! Ведь если на каждый чих писать в лог, потом в этих логах ничего не найти.
С хорошими инструментами, может быть, и можно найти. Например, писать лог в Elasticsearch, а в нём делать запросы.
Вот только не просядет ли производительность? Все эти логи небесплатны в смысле ресурсов сервера.
Б>2. Использовать машиночитаемый формат сообщений (json) Б>Рекомендация вроде ясна, удобно в дальнейшем анализировать. Б>Вот только куда ни посмотришь на логи, везде обычная строка, без key-value или json
Ага, вот IdentityServer4, который, казалось бы, рекомендуется лучшими собаководами.
Лог
[16:25:31.31 Information] IdentityServer4.Hosting.IdentityServerMiddleware
Invoking IdentityServer endpoint: IdentityServer4.Endpoints.AuthorizeEndpoint for /connect/authorize
[16:25:31.31 Information] IdentityServer4.ResponseHandling.AuthorizeInteractionResponseGenerator
Showing login: User is not authenticated
Не знаю, как и назвать. Б>3. Рекомендуют записывать контекст.
Да, глобальный контекст запроса. Б>5. Собирать метрики Б>НО.... Чтобы такое делать надо вообще отдельную подсистему писать — для расчета этих метрик. Как это на практике, непонятно.
Использовать готовые решения. Например, писать в Prometheus и анализировать в Grafana.
Здравствуйте, Буравчик, Вы писали:
Б>Поделитесь полезными советами про логи.
Б>Что пишут умные люди:
Б>1. Писать в лог чем больше, тем лучше.
Б>Больше данных — легче разобраться с проблемами.
Б>НО...! Ведь если на каждый чих писать в лог, потом в этих логах ничего не найти.
Сделать разные уровни логирования. В коде при выводе в лог указывать минимальный уровень, при котором выводится сообщение. Сообщения об ошибках писать всегда. Тогда при тестировании и отладке можно будет включить очень подробное логирование, а при эксплуатации — менее подробный уровень логирования. Это особенно актуально для систем, работающих 24/7 с высокой нагрузкой, т.к. очень подробное логирование может сильно нагружать диски и быть узким местом в производительности системы в целом.
Б>2. Использовать машиночитаемый формат сообщений (json)
Б>Рекомендация вроде ясна, удобно в дальнейшем анализировать. Б>Вот только куда ни посмотришь на логи, везде обычная строка, без key-value или json
Обычно логи люди читают. Машиночитаемый формат удобен для автоматизации анализа логов, но нужна ещё будет утилита, что бы людям смотреть было удобнее.
Б>3. Рекомендуют записывать контекст.
Б>Просто сообщение "был такой то exception" не катит, т.к. не понятно с каким пользователем/действием/запросом это было связано. Б>Нужно записывать запрос к серверу, имя пользователя, id сессии и т.п.
Можно при ловле исключения писать стек вызовов в лог и дополнительную информацию, которая может понадобиться (сессия, пользователь, дамп запроса к серверу).
Б>4. Держать все логи рядом (вместе)
Б>Это понятно. Но иногда выделяют отдельные лог файлы для ошибок, например. Также удобно собирать логи с нескольких машин где-то на удаленном сервере.
Ещё ротацию логов сделать.
Б>5. Собирать метрики
Б>Например, времени выполнения запросов, процент отказов и т.п. Б>НО.... Чтобы такое делать надо вообще отдельную подсистему писать — для расчета этих метрик. Как это на практике, непонятно.
Писать время с точностью до микро- или наносекунд и писать код возврата. Затем сделать автоматический анализатор для подсчёта времени обработки одного подключения и процента отказов.
Б>>2. Использовать машиночитаемый формат сообщений (json)
bnk>Бред, imho bnk>Важно чтобы лог можно было отфильтровать (по времени допустим, или там по юзеру) bnk>json вообще не уперся, если обычный текст фильтруется (каждая строчка содержит таймстемп и юзера)
Имеется в виду, что сейчас для поиска по логам используют ElastiSearch а у него любовь в JSON.
Тут проблема не логировать, а искать в логах. Когда у тебя несколько сотен пользовательей за сутки — это одно (проблемы писка нет).
А если у тебя сотни миллионов пользователей, то проблемы в поиске логов — есть.
Здравствуйте, Буравчик, Вы писали:
Б>Поделитесь полезными советами про логи.
Б>Что пишут умные люди:
Б>1. Писать в лог чем больше, тем лучше. Б>Больше данных — легче разобраться с проблемами.
Несколько уровней логирования. Структурированные логи (JSON), поиск через elastisearch.
Б>НО...! Ведь если на каждый чих писать в лог, потом в этих логах ничего не найти.
Б>2. Использовать машиночитаемый формат сообщений (json)
Б>Рекомендация вроде ясна, удобно в дальнейшем анализировать. Б>Вот только куда ни посмотришь на логи, везде обычная строка, без key-value или json
Смотри ответ на пунтк №1.
Б>3. Рекомендуют записывать контекст. Б>Просто сообщение "был такой то exception" не катит, т.к. не понятно с каким пользователем/действием/запросом это было связано. Б>Нужно записывать запрос к серверу, имя пользователя, id сессии и т.п.
Без этого ни как. HttpContext, Сессия и пр. — нужно логировать, без контекста — нет лога.
Б>НО...! В процессе выполнения "главной задачи" (обработки запроса/транзакции) обычно задача разделяется на меньшие задачи (формирует запросы к базе, выполняется дополнительная обработка данных и т.п.). Эти меньшие задачи тоже нужно отслеживать (логгировать). К ним дописывать тот же контекст, т.е. дублировать/протаскивать контекст в сообщениях? С другой стороны, если вообще не указывать контекст, то как связать эту внутреннюю подзадачу с "главным" запросом при разборе проблем.
Контекст + уровни логирования.
Б>4. Держать все логи рядом (вместе) Б>Это понятно. Но иногда выделяют отдельные лог файлы для ошибок, например. Также удобно собирать логи с нескольких машин где-то на удаленном сервере.
В микросервисной архитектуре у тебя могут быть как локальные логи, а потом собирать агрегировать логи, так и централизованный лог. Это на твой вкус.
Б>5. Собирать метрики Б>Например, времени выполнения запросов, процент отказов и т.п. Б>НО.... Чтобы такое делать надо вообще отдельную подсистему писать — для расчета этих метрик. Как это на практике, непонятно.
Тут уже до фига всего автоматизировано: ApplicationInsight and etc.
Здравствуйте, Буравчик, Вы писали:
Б>Как ЭТО происходит у вас? Поделитесь своими практиками/правилами?
Копаю в сторону JSON. Обнаружил утилиту jq — очень удобно работать с jsonlines (удобный отбор, преобразования)
Подумалось еще вот что:
Добавление данных в каждое сообщение лога
Возможно удобно иметь конструкцию, которая бы позволяла добавлять в каждое сообщение некоторую информацию (например, request_id)
with log.context(request_id='...') as inner_log:
# здесь во все JSON-лог сообщения будет добавляться предопределенный ключ request_id
inner_log.info()
inner_log.debug()
Сообщений в логе в зависимости от exception
Также интересна возможность запись в лог дополнительные сообщения только при условии необработанного exception, сокращая debug-сообщений на production.
При обычной работе попадут только info сообщения и выше, а если произойдет исключение, то добавятся еще и debug сообщения автоматически, чтобы упростить отладку
with log.context() as inner_log:
try:
inner_log.info()
# это сообщение попадет в лог, только если будет брошен exception
inner_log.debug()
except:
inner_log.dump_debug() # указание логгеру вывести debug сообщения
По-моему оба пункта отсутствуют в стандартных логгерах.
В каких библиотеках логгирования реализовано ли что-то подобное? (Язык не важен)
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, Буравчик, Вы писали:
Б>>Как ЭТО происходит у вас? Поделитесь своими практиками/правилами?
Б>Копаю в сторону JSON. Обнаружил утилиту jq — очень удобно работать с jsonlines (удобный отбор, преобразования)
Б>Подумалось еще вот что:
Б>Добавление данных в каждое сообщение лога
Более того, все java-logging фрэймворки умеют с таким контекстом работать и автоматически дописывать его к сообщениям, т.е. подзадачам даже и знать про него не надо. Ещё нужно не забывать пробрасывать его в другие потоки, если задача в пул передаётся или в очередь.
Б>Сообщений в логе в зависимости от exception
Прикольная фича, но есть два непонятных момента
— когда очистятся запомненные дебаги, если исключение не случилось?
— в каком порядке попадут в лог info(), debug(), info(), exception ? Дебаг после обоих инфо? Или он всё в памяти кэширует? А если всё кэшируется до поры до времени, то будет нарушен порядок сообщений из двух разных потоков?
Здравствуйте, bzig, Вы писали:
Б>>Добавление данных в каждое сообщение лога
B>Более того, все java-logging фрэймворки умеют с таким контекстом работать и автоматически дописывать его к сообщениям, т.е. подзадачам даже и знать про него не надо. Ещё нужно не забывать пробрасывать его в другие потоки, если задача в пул передаётся или в очередь. B>
Спасибо, нашел. Похоже, в java это называется Mapped Diagnostic Context. Посмотрю.
Б>>Сообщений в логе в зависимости от exception
B>Прикольная фича, но есть два непонятных момента
B>- когда очистятся запомненные дебаги, если исключение не случилось?
Очистятся при выходе из блока (при завершении контекста).
B>- в каком порядке попадут в лог info(), debug(), info(), exception ? Дебаг после обоих инфо? Или он всё в памяти кэширует? А если всё кэшируется до поры до времени, то будет нарушен порядок сообщений из двух разных потоков?
Изначально считал, что дебаг появится после инфо. Проблема порядка решается сохранением времени генерирования сообщения, по нему можно восстановить цепочку при анализе.
Можно все сообщения кэшировать, а записывать только в конце. Этот вариант удобен, что сообщения "не путаются", но длительность контекста может очень большой — вплоть до срока запуска приложения (от старта до завершения). Тогда вообще никаких логов не будет. Но на "коротких" дистанциях (обработка одного запроса, одна транзакция) этот метод был бы, наверное, предпочтительнее.
В общем, думаю, что будет лучше, если будет выбор.
B>>- в каком порядке попадут в лог info(), debug(), info(), exception ? Дебаг после обоих инфо? Или он всё в памяти кэширует? А если всё кэшируется до поры до времени, то будет нарушен порядок сообщений из двух разных потоков?
Б>Изначально считал, что дебаг появится после инфо. Проблема порядка решается сохранением времени генерирования сообщения, по нему можно восстановить цепочку при анализе.
Самому по файлу глазами восстанавливать может быть долго, а "| sort" медленно. Получается, надо какие-то агрегаторы использовать, вроде Splunk.
Б>Можно все сообщения кэшировать, а записывать только в конце. Этот вариант удобен, что сообщения "не путаются", но длительность контекста может очень большой — вплоть до срока запуска приложения (от старта до завершения). Тогда вообще никаких логов не будет. Но на "коротких" дистанциях (обработка одного запроса, одна транзакция) этот метод был бы, наверное, предпочтительнее.
Ещё никаких логов не будет, если умрёт — а это могут быть самые важные логи, чтобы понять куда дошла обработка. Опять же, отложенная запись не решает проблему перепутывания сообщений из разных потоков, а конкурентная обработка сама по себе может быть источником проблем.
Б>В общем, думаю, что будет лучше, если будет выбор.
Конкретно в Яве я про такое не слышал, но написать свой наследник от логера, кэшировать дебаги и сбрасывать в лог, если пришлось писать сообщение об ошибке — довольно простая задача. До сих пор ни кем не решана думаю как раз и из-за "перепутывания". Лог ведь может писаться по дням или даже по часам или с ограничением по размеру — так что отложенные записи могут попасть совсем не в тот файл, что был бы при своевременной записи.
B>Конкретно в Яве я про такое не слышал, но написать свой наследник от логера, кэшировать дебаги и сбрасывать в лог, если пришлось писать сообщение об ошибке — довольно простая задача. До сих пор ни кем не решана думаю как раз и из-за "перепутывания". Лог ведь может писаться по дням или даже по часам или с ограничением по размеру — так что отложенные записи могут попасть совсем не в тот файл, что был бы при своевременной записи.
Хотя вру, непростая. Все распространённые явовские логеры время ставят при записи в файл, а не при передаче сообщения логеру, так что или отказываться от стандартной фичи простановки времени и делать всё самому или время будет неправильное.
Что можно было бы сделать — кэшировать дебаги, если логеру пришлось писать ошибку, но присвоить ей какой-нибудь номер на лету и дописать время к дебагам и сбросить в отдельный файл с этим номером. А для этих отдельных файлов иметь свой Layout, который не ставит время, так что у дебагов будет правильное время, но файл будет отдельный.
Здравствуйте, bzig, Вы писали:
B>Самому по файлу глазами восстанавливать может быть долго, а "| sort" медленно. Получается, надо какие-то агрегаторы использовать, вроде Splunk.
jq умеет сортировать по ключу. Вполне можно обойтись им в консоли.
B>Конкретно в Яве я про такое не слышал, но написать свой наследник от логера, кэшировать дебаги и сбрасывать в лог, если пришлось писать сообщение об ошибке — довольно простая задача. До сих пор ни кем не решана думаю как раз и из-за "перепутывания".
Я и хочу для себя написать враппер (на питоне). Но хотел посмотреть что уже придумали, чтобы не изобретать велосипед и не наступать на грабли.
B>Лог ведь может писаться по дням или даже по часам или с ограничением по размеру — так что отложенные записи могут попасть совсем не в тот файл, что был бы при своевременной записи.
Да, действительно, не учитывал таких проблем, спасибо.
Для себе решил сделать, как и говорил, два варианта:
— Синхронноый, когда дебаг сообщения будут добавляться вперемешку с инфо сообщениями. Будет использоваться на коротких промежутках (секунды)
— Отложенный, когда дебаг сообщения будут добавляться после инфо сообщений. Будет использоваться на длинных промежутках (минуты и часты).
Попробую, что получится.
Еще мысль. Можно debug сообщения писать в отдельный файл. Если exception не было, то файл стирать. Если был — переносить дебаг сообщения в основной лог.
Но, думаю, на prod сервере это будет не очень хорошо с точки зрения производительности (ввиду большого количества дебаг сообщений). Собственно, по этой причине дебаг и отключают.
Б>Еще мысль. Можно debug сообщения писать в отдельный файл. Если exception не было, то файл стирать. Если был — переносить дебаг сообщения в основной лог. Б>Но, думаю, на prod сервере это будет не очень хорошо с точки зрения производительности (ввиду большого количества дебаг сообщений). Собственно, по этой причине дебаг и отключают.
Ага, только что написал об этом в отдельном сообщении
Здравствуйте, Буравчик, Вы писали:
Б>Поделитесь полезными советами про логи.
Б>Как ЭТО происходит у вас? Поделитесь своими практиками/правилами?
Использовать индексацию/анализ логов. Можно коммерческий продукта типа Splunk, можно ELK stack и т п
Писать контекстно-специфичные вещи в лог
Писать только то что необходимо. Запись хранение и индексация логов вещи не бесплатные
Использовать простой формат для логов (никакого json). json увеличивает в разы стоимость их обработки.
error/fatal это то, чего происходить не должно. Логгируется в отдельный файл, любая запись в этом файле это баг, который надо исправлять.
warn это то, чего происходить не должно при нормальной работе. Например если есть HTML-форма, с неё приходит дата в формате дд.мм.гггг, а реально пришло что-то другое. Т.е. формально это не баг, система работает как положено, но реально что-то не то происходит. Тоже отдельный файл, который мониторится но он не обязан быть пустым.
info это все действия-изменения, произошедшие с системой. Чтобы видеть что там вообще происходит. Обычно в консоль пускается именно это. Залогинился, создал запись, удалил запись и тд. Эдакий примитивный аудит, чтобы если что, можно было быстро понять что там происходило с логической точки зрения.
debug это уже отладка. Логгируется в отдельный файл, хранится например за последнюю неделю, который обычно не смотрится, используется для багов. Каких-то правил нет, главное не генерировать слишком много информации, чтобы не влияло на общую скорость работы и не забивало диск.
trace — самая подробная отладка, которая не включается в обычном режиме. Можно включить для конкретного модуля если вдруг не хватает остальной информации. Тот же debug но без ограничений.
Формат — обычные текстовые файлы. Пока не ощущал необходимости в каких-то специальных продуктах для логов, но если вдруг надо, какая разница, это же всё тривиально настраивается.
Контекст — user ID и user IP. Ну и имя потока, конечно. Этого хватает, чтобы вычленить действия именно этого юзера. Честно говоря и имени потока хватает, я этой новомодной асинхронностью не пользуюсь, но если вдруг понадобится, можно изобрести какой-нибудь request ID.
Здравствуйте, Kernan, Вы писали:
Б>>Что пишут умные люди: Б>>1. Писать в лог чем больше, тем лучше. K>На одном проекте писались все входы и выходы из функция + дополнительные логи. В какой-то момент придумали сделать циклический буфер и во время проблемы дампить только его чтобы не нагружать систему. Этим продумктом был софтсвитч .
Вот кстати мне этого не хватает в библиотеках для логгирования. Я в логах указываю начало запроса, конец запроса. Они всю информацию по запросу держат в памяти, в случае ошибки создаётся файл инцидента, в который все логи всех уровней, относящиеся к запросу, запишутся. Самому такое велосипедить долго и скучно, а вот готовым функционалом я бы пользовался с удовольствием.
Здравствуйте, vsb, Вы писали:
vsb>error/fatal это то, чего происходить не должно. Логгируется в отдельный файл, любая запись в этом файле это баг, который надо исправлять.
Здравствуйте, VladiCh, Вы писали:
VC>Использовать простой формат для логов (никакого json). json увеличивает в разы стоимость их обработки.
Почему увеличивает стоимость обработки? Вроде разница небольшая для обработки — что строка текста, что строка json. Искать по подстроке можно в обоих вариантах. Но в json можно быстро искать по сложным условиям, а в обычном текст — нет. В json легко собрать статистику, а в обычном тексте придется писать парсеры.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Kernan, Вы писали:
Б>>>Что пишут умные люди: Б>>>1. Писать в лог чем больше, тем лучше. K>>На одном проекте писались все входы и выходы из функция + дополнительные логи. В какой-то момент придумали сделать циклический буфер и во время проблемы дампить только его чтобы не нагружать систему. Этим продумктом был софтсвитч .
vsb>Вот кстати мне этого не хватает в библиотеках для логгирования. Я в логах указываю начало запроса, конец запроса. Они всю информацию по запросу держат в памяти, в случае ошибки создаётся файл инцидента, в который все логи всех уровней, относящиеся к запросу, запишутся. Самому такое велосипедить долго и скучно, а вот готовым функционалом я бы пользовался с удовольствием.
Здравствуйте, Буравчик, Вы писали:
Б>>>>Что пишут умные люди: Б>>>>1. Писать в лог чем больше, тем лучше. K>>>На одном проекте писались все входы и выходы из функция + дополнительные логи. В какой-то момент придумали сделать циклический буфер и во время проблемы дампить только его чтобы не нагружать систему. Этим продумктом был софтсвитч .
vsb>>Вот кстати мне этого не хватает в библиотеках для логгирования. Я в логах указываю начало запроса, конец запроса. Они всю информацию по запросу держат в памяти, в случае ошибки создаётся файл инцидента, в который все логи всех уровней, относящиеся к запросу, запишутся. Самому такое велосипедить долго и скучно, а вот готовым функционалом я бы пользовался с удовольствием.
Б>Да, мне тоже такое интересно, писал об этом здесь
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, VladiCh, Вы писали:
VC>>Использовать простой формат для логов (никакого json). json увеличивает в разы стоимость их обработки.
Б>Почему увеличивает стоимость обработки? Вроде разница небольшая для обработки — что строка текста, что строка json. Искать по подстроке можно в обоих вариантах. Но в json можно быстро искать по сложным условиям, а в обычном текст — нет. В json легко собрать статистику, а в обычном тексте придется писать парсеры.
Тупо парсинг дороже. На больших объемах может быть заметно. А преимущества прямого нет, никто не мешает логи в виде ключей-значений хранить грубо говоря через запятую. Не понял причем тут поиск по сложным условиям. Текстовые логи точно также разбираются на ключи-значения и индексируются.
Здравствуйте, Буравчик, Вы писали:
Б>Возможно удобно иметь конструкцию, которая бы позволяла добавлять в каждое сообщение некоторую информацию (например, request_id)
Б>
Б>with log.context(request_id='...') as inner_log:
Б> # здесь во все JSON-лог сообщения будет добавляться предопределенный ключ request_id
Б> inner_log.info()
Б> inner_log.debug()
Б>
Спустя некоторое время добавлю. Такая возможность есть в structlog для питон. Умеет создавать логи на json, привязывать контекст и др.
Здравствуйте, bnk, Вы писали:
bnk>json вообще не уперся, если обычный текст фильтруется (каждая строчка содержит таймстемп и юзера)
У JSON есть такое преимущество, что разным частям системы проще иметь одинаковое понимание, где есть одна запись, а где две.
Недавно решал проблему когда наши многострочные логи в Sumo разрывало на разные временные интервалы (потому что первая строка имеет таймстемп и Sumo его парсит, а остальные строки -- не имеют и Sumo им назначает таймстемп прибытия).
Можно регулярными выражениями в Sumo настроить, чтобы оно их обратно склеило или доработать логгирование в приложении, чтоб оно каждую строку отдельно форматировало (но это дополнительный мусор в логах), но с JSON таких проблем нет.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Kernan, Вы писали:
Б>>>Что пишут умные люди: Б>>>1. Писать в лог чем больше, тем лучше. K>>На одном проекте писались все входы и выходы из функция + дополнительные логи. В какой-то момент придумали сделать циклический буфер и во время проблемы дампить только его чтобы не нагружать систему. Этим продумктом был софтсвитч .
vsb>Вот кстати мне этого не хватает в библиотеках для логгирования. Я в логах указываю начало запроса, конец запроса. Они всю информацию по запросу держат в памяти, в случае ошибки создаётся файл инцидента, в который все логи всех уровней, относящиеся к запросу, запишутся. Самому такое велосипедить долго и скучно, а вот готовым функционалом я бы пользовался с удовольствием.
в одном из C# проектов я использовал такой подход:
void SomeFunction()
{
using (xxx)
{
// Function body
}
}
xxx -- вначале писал название ф-ции, которая запускается, а после выполнения Function body, что ф-ция успешно завершена
Здравствуйте, Буравчик, Вы писали:
Б>Как ЭТО происходит у вас? Поделитесь своими практиками/правилами?
У меня есть софтина для управления технологическим процессом, там ведение журнала — требование заказчика.
Чтобы если попрёт брак, можно было посмотреть, во сколько минут-секунд на каком участке сколько было вольт, ампер и градусов.
Кроме этого пишу все моменты принятия решений, типа "произошло событие такое-то, реагируем действием таким-то".
Также пишу действия оператора, его лазания в конфигурации, выдачу и сброс сообщений об ошибках и т.п.
Короче говоря — всё, что может помочь в разбирательствах, когда что-то пошло не так.
Основной журнал с цифирью вольты-амперы-входа-выхода-регистры пишется в CSV, чтобы в экселе было удобно смотреть/фильтровать.
Доп. информация о том, что при этом происходило в программе, копится в буферную строку и дописывается в последнее поле.
Вот как-то так.
Б>2. Использовать машиночитаемый формат сообщений (json)
Логи надо держать в текстовом формате, что бы можно было посмотреть данные в любом тектовом редакторе
или стандартными утилитами для просмотра логов: cat, grep на любом компьютере будь-то домашний пк
или сервер с минимальным набором программ.
json сам по себе г-формат для данных(нельзя писать комментарии и т.д), не говоря о том что бы исспользовать его для логов.
Підтримати Україну у боротьбі з країною-терористом.
Здравствуйте, #John, Вы писали:
Б>>2. Использовать машиночитаемый формат сообщений (json)
J>Логи надо держать в текстовом формате, что бы можно было посмотреть данные в любом тектовом редакторе
json нормально читается текстовым редактором и понимается человеком
J>или стандартными утилитами для просмотра логов: cat, grep на любом компьютере будь-то домашний пк J>или сервер с минимальным набором программ.
Логи пишутся обычно в jsonlines. С этим форматом прекрасно работает cat и grep
J>json сам по себе г-формат для данных(нельзя писать комментарии и т.д), не говоря о том что бы исспользовать его для логов.
Комментарии в логах не нужны.
А вот анализировать логи становится удобно. Например с помощью утилиты jq
У нас логи только в отладочных версиях. В релизных нельзя.
Уровни логирования настраиваются. Максимальный 5-ый уровень срёт в лог по гигу за 5 мин.
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
МД>У нас логи только в отладочных версиях. В релизных нельзя.
МД>Уровни логирования настраиваются. Максимальный 5-ый уровень срёт в лог по гигу за 5 мин.
А как происходит отключение логирования в релизах?
Есть ли в ваших процедурах логирования обработка исключений?
Например, если не удалось открыть файл лога, что произойдет?
Будет ли выброшено исключение?
Какой модуль приложения это исключение будет обрабатывать?
Здравствуйте, #John, Вы писали:
Б>>2. Использовать машиночитаемый формат сообщений (json) J>Логи надо держать в текстовом формате, что бы можно было посмотреть данные в любом тектовом редакторе
Есть мнение, что их стоит держать в бинарном формате что позволяет им быть компактными, не нагружать сервер, легко обрабатываться автоматическими тулазами.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, Буравчик, Вы писали:
Б>Поделитесь полезными советами про логи.
Логи — это отдельная и очень важная задача встречающаеся от микроконтролёров до глобальных сервисов. В некоторых случаях записи в логах могут иметь денежные и юридические последствия. В больших конторах есть специальные отделы занимающиеся исключительно анализом логов. В некоторых програмных продуктах время потраченное на разработку софта связанного с логами может занимать до 50% разработки. А в специальных случаях (см. черные ящики) все 100%. Нельзя говорить о лучших практиках логирования вообще. Это как спросить о лучших практиках программирования не уточняя ни язык, ни область задач.
Здравствуйте, B0FEE664, Вы писали:
BFE>В больших конторах есть специальные отделы занимающиеся исключительно анализом логов. В некоторых програмных продуктах время потраченное на разработку софта связанного с логами может занимать до 50% разработки.
Различаешь ли ты в этом сбор собственно логов, аналитики, метрики, телеметрии?
Здравствуйте, Qbit86, Вы писали:
Q>Различаешь ли ты в этом сбор собственно логов, аналитики, метрики, телеметрии?
Нет, потому что обычно всеми этими задачами занимаются одни и те же люди в том смысле, что сами решают, что записывать в логи и какие модели аналитики на этих логах строить. Скажем, задача логирования положения по GPS в мобильном телефоне и логирование покупок билетов на сайте различаются кардинально, но и то и другое называют логами в обиходной речи. Конечно, возможна специальная терминоголия, типа 'журнал действий пользователя', 'трекинг', 'телеметрия', 'журналирование событий' и т.д.. Сути это не меняет: последовательная запись событий или их отсутствия.
ЗЫ Я никогда не работал в платёжных/банковсих системах. Возможно, что там аналитики выделены в отдельную команду.
Здравствуйте, B0FEE664, Вы писали:
BFE> Скажем, задача логирования положения по GPS в мобильном телефоне и логирование покупок билетов на сайте различаются кардинально, но и то и другое называют логами в обиходной речи. Конечно, возможна специальная терминоголия, типа 'журнал действий пользователя', 'трекинг', 'телеметрия',
Охохо, в gps приемниках и вообще в gnss, логированние это чуть ли не 90% всего дела, собственно вообще все 100%. Ради ентого их и изобрели.
А так с тезисом выше полностью согласен. Где-то ради логирования все затевается, т.е. это и есть бизнес задача, а где-то так, между делом.
Стандартный на данный момент подход для работы с логами для средних проектов следующий:
1. Использовать логгеры без блокировки и с развитыми средствами настройки. Для Java это logback и log4j v2
2. Логи пишутся в стандартном формате, обязательно писать время, тред, уровень логгировния, correlationId
Наиболее популярный формат для сбора логов — jsonl (т.е. json без переноса строк).
3. Использование MDC для прокидывания correlationId обязательно, для корутин используются специальные обвязки.
4. Сбор логов обязательно централизованный. Стандартный стек — fluentbit/filebit -> elastic/clickhouse -> kibana/lighthouse
Для малых проектов проще elastic, для крупнее — clickhouse (впрочем, по мне всегда удобнее clickhouse)
5. При выборе инструмента передачи логов стоит смотреть на поддержку multiline для Java Exceptions
6. Пока логов меньше 100K строк в секунду с системы — экономить на уровне логирования смысла нет.
7. Слишком подробного логирования не бывает. При анализе проблем на продакшене кроме логов ничего нет.
8. Метрики собираются отдельными инструментами (см. metrics, telegraf, Prometheus) и показываются через Grafana etc
9. Время выполнения запросов и дерево межесервисных вызовов собираются отдельно через Jaeger или аналогичные инструменты
Для задач аудита и контроля возможна постообработка логов или создание отдельных потоков логов.
Для PCI DSS систем есть свои особенности, но те, кто их разрабатывают обычно и так все знают.
Хранить логи долго обычно не нужно, исключения приходят от бизнеса (в банках бывает и по три года нужно хранить)
Хранение логов в виде файлов на локальном диске, чтение их руками — допустимо только для очень маленьких проектов.
Но лучше и в этом случае скидывать их в централизованное хранилище.
С вопросами — лучше всего спросить вменяемого (дев)опса или в телеграмчике.
Б>>>>Что пишут умные люди: Б>>>>1. Писать в лог чем больше, тем лучше. K>>>На одном проекте писались все входы и выходы из функция + дополнительные логи. В какой-то момент придумали сделать циклический буфер и во время проблемы дампить только его чтобы не нагружать систему. Этим продумктом был софтсвитч .
vsb>>Вот кстати мне этого не хватает в библиотеках для логгирования. Я в логах указываю начало запроса, конец запроса. Они всю информацию по запросу держат в памяти, в случае ошибки создаётся файл инцидента, в который все логи всех уровней, относящиеся к запросу, запишутся. Самому такое велосипедить долго и скучно, а вот готовым функционалом я бы пользовался с удовольствием.
Б>Да, мне тоже такое интересно, писал об этом здесь
. Чтобы, в лог сыпались info и warning, а в случае errors добавились все debug и trace.
Б>На питоне таких логгеров нет (не знаю). А у тебя какой язык?
Легко. Наслtдуешься от обычного Logger'а и переопределяешь error и critical (а по необходимости и остальные уровни), где всё нужное и вытаскиваешь.
Б>>>2. Использовать машиночитаемый формат сообщений (json)
J>>Логи надо держать в текстовом формате, что бы можно было посмотреть данные в любом тектовом редакторе
Б>json нормально читается текстовым редактором и понимается человеком
J>>или стандартными утилитами для просмотра логов: cat, grep на любом компьютере будь-то домашний пк J>>или сервер с минимальным набором программ.
Б>Логи пишутся обычно в jsonlines. С этим форматом прекрасно работает cat и grep
Зависит от их размера. Видел я, когда в журнал падали такие по 100кб "сообщения", в них даже Elastic Search хреново что искал.
Здравствуйте, Ватакуси, Вы писали:
Б>>На питоне таких логгеров нет (не знаю). А у тебя какой язык? В>Легко. Наслtдуешься от обычного Logger'а и переопределяешь error и critical (а по необходимости и остальные уровни), где всё нужное и вытаскиваешь.
Оказывается, такой логгер в питоне есть. Называется structlog
Здравствуйте, Ватакуси, Вы писали:
В>Зависит от их размера. Видел я, когда в журнал падали такие по 100кб "сообщения", в них даже Elastic Search хреново что искал.
Пока делаю так:
— основной лог пишется в json
— дополнительно ошибки пишутся в plain text
Здравствуйте, Буравчик, Вы писали:
Б>Поделитесь полезными советами про логи.
Б>Что пишут умные люди: Б>1. Писать в лог чем больше, тем лучше. Б>Больше данных — легче разобраться с проблемами.
Да.
Б>НО...! Ведь если на каждый чих писать в лог, потом в этих логах ничего не найти.
А не надо в файлы грепать. Есть Graylog и подобные, там найти. Если правильно класть конечно.
Б>2. Использовать машиночитаемый формат сообщений (json)
Б>Рекомендация вроде ясна, удобно в дальнейшем анализировать. Б>Вот только куда ни посмотришь на логи, везде обычная строка, без key-value или json
Json не json пофиг главное что условный Graylog распарсить смог
Б>3. Рекомендуют записывать контекст.
Обязательно.
Б>Просто сообщение "был такой то exception" не катит, т.к. не понятно с каким пользователем/действием/запросом это было связано. Б>Нужно записывать запрос к серверу, имя пользователя, id сессии и т.п.
Б>НО...! В процессе выполнения "главной задачи" (обработки запроса/транзакции) обычно задача разделяется на меньшие задачи (формирует запросы к базе, выполняется дополнительная обработка данных и т.п.). Эти меньшие задачи тоже нужно отслеживать (логгировать). К ним дописывать тот же контекст, т.е. дублировать/протаскивать контекст в сообщениях? С другой стороны, если вообще не указывать контекст, то как связать эту внутреннюю подзадачу с "главным" запросом при разборе проблем.
Есть MDC https://logback.qos.ch/manual/mdc.html припомощи него достаточно просто протаскивать контекст логгирования.
Б>4. Держать все логи рядом (вместе) Б>Это понятно. Но иногда выделяют отдельные лог файлы для ошибок, например. Также удобно собирать логи с нескольких машин где-то на удаленном сервере.
Да, надо все логи консолидировать в 1 месте, запрос на 100500 машин может быть распараллелен.
Не надо логов ошибок, атрибута хватит.
Б>5. Собирать метрики
Б>Например, времени выполнения запросов, процент отказов и т.п. Б>НО.... Чтобы такое делать надо вообще отдельную подсистему писать — для расчета этих метрик. Как это на практике, непонятно.
А чего в этом такого? Можно AOP в руки и понеслась.
Б>Как ЭТО происходит у вас? Поделитесь своими практиками/правилами?
Все как ты написал приблизительно, там нет никакого рокет сайнс.
.
