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