Здравствуйте, 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 в руки и понеслась.
Б>Как ЭТО происходит у вас? Поделитесь своими практиками/правилами?
Все как ты написал приблизительно, там нет никакого рокет сайнс.
.
