Сообщение Re: Logging. Лучшие практики от 22.09.2018 17:10
Изменено 22.09.2018 17:23 bnk
Re: Logging. Лучшие практики
Здравствуйте, Буравчик, Вы писали:
Б>Поделитесь полезными советами про логи
Б>1. Писать в лог чем больше, тем лучше.
Б>Больше данных — легче разобраться с проблемами.
Б>НО...! Ведь если на каждый чих писать в лог, потом в этих логах ничего не найти.
Для этого есть уровни логгирования.. а вообще много логов не будет, потому что программистам их лень писать.
Просто следить чтобы в цикле всякую хрень в лог не фигачило. Что обязательго логгировать,
так это все внешние вызовы (входящие и исходящие) и все эксепшены
Б>2. Использовать машиночитаемый формат сообщений (json)
Б>Рекомендация вроде ясна, удобно в дальнейшем анализировать.
Б>Вот только куда ни посмотришь на логи, везде обычная строка, без key-value или json
Бред
Б>3. Рекомендуют записывать контекст.
Б>Просто сообщение "был такой то exception" не катит, т.к. не понятно с каким пользователем/действием/запросом это было связано.
Б>Нужно записывать запрос к серверу, имя пользователя, id сессии и т.п.
Б>НО...! В процессе выполнения "главной задачи" (обработки запроса/транзакции) обычно задача разделяется на меньшие задачи (формирует запросы к базе, выполняется дополнительная обработка данных и т.п.). Эти меньшие задачи тоже нужно отслеживать (логгировать). К ним дописывать тот же контекст, т.е. дублировать/протаскивать контекст в сообщениях? С другой стороны, если вообще не указывать контекст, то как связать эту внутреннюю подзадачу с "главным" запросом при разборе проблем.
Да, это проблема. Пусть не контекст, так хотя бы время, с максимальной точностью.
Б>4. Держать все логи рядом (вместе)
Б>Это понятно. Но иногда выделяют отдельные лог файлы для ошибок, например. Также удобно собирать логи с нескольких машин где-то на удаленном сервере.
Пофик
Б>5. Собирать метрики
Б>Например, времени выполнения запросов, процент отказов и т.п.
Б>НО.... Чтобы такое делать надо вообще отдельную подсистему писать — для расчета этих метрик. Как это на практике, непонятно.
Б>Как ЭТО происходит у вас? Поделитесь своими практиками/правилами?
Как на практике. Недавно запустили AppDynamics (https://www.appdynamics.com)
Оно подключается отладчиком, или скриптом, или модулем, ко всем работающим приложениям и базам компании и монитрит все транзакции, скидывая данные в один центр с нормальной навигацией (с графами вызовов)
Можно отследить грохнувшуюся операцию от того что на сервере х юзер нажал на кнопку, потом упала хранимка в какой-то базе y, вызванная через 5 промежуточных сервисов (половина rest, половина wcf). Эта штука также меряет все тайминги и показывает изменения в них.
Б>Поделитесь полезными советами про логи
Б>1. Писать в лог чем больше, тем лучше.
Б>Больше данных — легче разобраться с проблемами.
Б>НО...! Ведь если на каждый чих писать в лог, потом в этих логах ничего не найти.
Для этого есть уровни логгирования.. а вообще много логов не будет, потому что программистам их лень писать.
Просто следить чтобы в цикле всякую хрень в лог не фигачило. Что обязательго логгировать,
так это все внешние вызовы (входящие и исходящие) и все эксепшены
Б>2. Использовать машиночитаемый формат сообщений (json)
Б>Рекомендация вроде ясна, удобно в дальнейшем анализировать.
Б>Вот только куда ни посмотришь на логи, везде обычная строка, без key-value или json
Бред
Б>3. Рекомендуют записывать контекст.
Б>Просто сообщение "был такой то exception" не катит, т.к. не понятно с каким пользователем/действием/запросом это было связано.
Б>Нужно записывать запрос к серверу, имя пользователя, id сессии и т.п.
Б>НО...! В процессе выполнения "главной задачи" (обработки запроса/транзакции) обычно задача разделяется на меньшие задачи (формирует запросы к базе, выполняется дополнительная обработка данных и т.п.). Эти меньшие задачи тоже нужно отслеживать (логгировать). К ним дописывать тот же контекст, т.е. дублировать/протаскивать контекст в сообщениях? С другой стороны, если вообще не указывать контекст, то как связать эту внутреннюю подзадачу с "главным" запросом при разборе проблем.
Да, это проблема. Пусть не контекст, так хотя бы время, с максимальной точностью.
Б>4. Держать все логи рядом (вместе)
Б>Это понятно. Но иногда выделяют отдельные лог файлы для ошибок, например. Также удобно собирать логи с нескольких машин где-то на удаленном сервере.
Пофик
Б>5. Собирать метрики
Б>Например, времени выполнения запросов, процент отказов и т.п.
Б>НО.... Чтобы такое делать надо вообще отдельную подсистему писать — для расчета этих метрик. Как это на практике, непонятно.
Б>Как ЭТО происходит у вас? Поделитесь своими практиками/правилами?
Как на практике. Недавно запустили AppDynamics (https://www.appdynamics.com)
Оно подключается отладчиком, или скриптом, или модулем, ко всем работающим приложениям и базам компании и монитрит все транзакции, скидывая данные в один центр с нормальной навигацией (с графами вызовов)
Можно отследить грохнувшуюся операцию от того что на сервере х юзер нажал на кнопку, потом упала хранимка в какой-то базе y, вызванная через 5 промежуточных сервисов (половина rest, половина wcf). Эта штука также меряет все тайминги и показывает изменения в них.
Re: Logging. Лучшие практики
Здравствуйте, Буравчик, Вы писали:
Б>Поделитесь полезными советами про логи
Б>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). Эта штука также меряет все тайминги и показывает изменения в них.