Здравствуйте, Буравчик, Вы писали:

Б>Поделитесь полезными советами про логи

Б>1. Писать в лог чем больше, тем лучше.
Б>Больше данных — легче разобраться с проблемами.
Б>НО...! Ведь если на каждый чих писать в лог, потом в этих логах ничего не найти.

вообще много логов не будет, потому что программистам их лень писать.
Просто следить чтобы в цикле всякую хрень в лог не фигачило. Что обязательго логгировать,
так это все внешние вызовы (входящие и исходящие) и все эксепшены.
Еще есть уровни логгирования.

Б>2. Использовать машиночитаемый формат сообщений (json)

Бред, imho

Б>3. Рекомендуют записывать контекст.

Б>Просто сообщение "был такой то exception" не катит, т.к. не понятно с каким пользователем/действием/запросом это было связано.
Б>Нужно записывать запрос к серверу, имя пользователя, id сессии и т.п.

Б>НО...! В процессе выполнения "главной задачи" (обработки запроса/транзакции) обычно задача разделяется на меньшие задачи (формирует запросы к базе, выполняется дополнительная обработка данных и т.п.). Эти меньшие задачи тоже нужно отслеживать (логгировать). К ним дописывать тот же контекст, т.е. дублировать/протаскивать контекст в сообщениях? С другой стороны, если вообще не указывать контекст, то как связать эту внутреннюю подзадачу с "главным" запросом при разборе проблем.

Да, вообще это проблема. Пусть не контекст, так хотя бы время, с максимальной точностью.
Для http есть глобальный контекст вызова (входящего). Он так или иначе доступен.
Нафига это вообще надо — если несколько вызовов обрабатываются параллельно и пишут в один лог,
Чтобы можно было разобраться что к чему относится.

Б>4. Держать все логи рядом (вместе)
Б>Это понятно. Но иногда выделяют отдельные лог файлы для ошибок, например. Также удобно собирать логи с нескольких машин где-то на удаленном сервере.

Пофик

Б>5. Собирать метрики

Б>Например, времени выполнения запросов, процент отказов и т.п.
Б>НО.... Чтобы такое делать надо вообще отдельную подсистему писать — для расчета этих метрик. Как это на практике, непонятно.

Б>Как ЭТО происходит у вас? Поделитесь своими практиками/правилами?

Как на практике. Недавно запустили AppDynamics (https://www.appdynamics.com)

Оно подключается отладчиком, или скриптом, или модулем, ко всем работающим приложениям и базам компании и монитрит все транзакции, скидывая данные в один центр с нормальной навигацией (с графами вызовов)

Можно отследить грохнувшуюся операцию от того что на сервере х юзер нажал на кнопку, потом упала хранимка в какой-то базе y, вызванная через 5 промежуточных сервисов (половина rest, половина wcf). Эта штука также меряет все тайминги и показывает изменения в них.

Здравствуйте, Буравчик, Вы писали:

Б>Поделитесь полезными советами про логи

Б>1. Писать в лог чем больше, тем лучше.
Б>Больше данных — легче разобраться с проблемами.
Б>НО...! Ведь если на каждый чих писать в лог, потом в этих логах ничего не найти.

вообще много логов не будет, потому что программистам их лень писать.
Просто следить чтобы в цикле всякую хрень в лог не фигачило. Что обязательго логгировать,
так это все внешние вызовы (входящие и исходящие) и все эксепшены.
Еще есть уровни логгирования.

Б>2. Использовать машиночитаемый формат сообщений (json)

Бред, imho

Б>3. Рекомендуют записывать контекст.

Б>Просто сообщение "был такой то exception" не катит, т.к. не понятно с каким пользователем/действием/запросом это было связано.
Б>Нужно записывать запрос к серверу, имя пользователя, id сессии и т.п.

Б>НО...! В процессе выполнения "главной задачи" (обработки запроса/транзакции) обычно задача разделяется на меньшие задачи (формирует запросы к базе, выполняется дополнительная обработка данных и т.п.). Эти меньшие задачи тоже нужно отслеживать (логгировать). К ним дописывать тот же контекст, т.е. дублировать/протаскивать контекст в сообщениях? С другой стороны, если вообще не указывать контекст, то как связать эту внутреннюю подзадачу с "главным" запросом при разборе проблем.

Да, вообще это проблема. Пусть не контекст, так хотя бы время, с максимальной точностью.
Для http есть глобальный контекст вызова (входящего). Он так или иначе доступен.
Нафига это вообще надо — если несколько вызовов обрабатываются параллельно и пишут в один лог,
Чтобы можно было разобраться что к чему относится.

Б>4. Держать все логи рядом (вместе)
Б>Это понятно. Но иногда выделяют отдельные лог файлы для ошибок, например. Также удобно собирать логи с нескольких машин где-то на удаленном сервере.

Пофик

Б>5. Собирать метрики

Б>Например, времени выполнения запросов, процент отказов и т.п.
Б>НО.... Чтобы такое делать надо вообще отдельную подсистему писать — для расчета этих метрик. Как это на практике, непонятно.

Б>Как ЭТО происходит у вас? Поделитесь своими практиками/правилами?

Как на практике. Недавно запустили AppDynamics (https://www.appdynamics.com)

Оно подключается отладчиком, или скриптом, или модулем, ко всем работающим приложениям и базам компании и монитрит все транзакции, скидывая данные в один центр с нормальной навигацией (с графами вызовов)

Можно отследить грохнувшуюся операцию от того чтов приложени х юзер нажал на кнопку y, до момента когда потом упала хранимка в какой-то базе, вызванная через 5 промежуточных сервисов (половина rest, половина wcf). Показывает стеки вызовов, как внутри приложения, так и между приложениями, для баз — выполняемый sql. Также все тайминги операций и изменения в них.

В общем для мониторинга — пока выглядит довольно неплохо.