Увы я не могу оценить Вашу ссылку без регистрации st.com. Для дебага это может быть удобно - бесспорно.
Но телеметрия рассмотренная в этой статье - это возможность собирать данные в поле, с множества устройств, активировать и деактивировать счетчики удаленно, с частотой больше чем 1мс и без зависимости от проприетарных инструментов. На сколько я знаю помимо телеметрии библиотека предоставляет так же логирование с функциями с перменными числом аргументов, но без форматирования на целевом процессоре.
Т.е. вы приводите пример хорошего дебаггера, а автор пример инструментов мониторинга систем в дикой среде и без привязки к конкретному производителю.
Спасибо, я не принимаю на свой счет, вижу, что у Вас богатый опыт, Вы приводите свои примеры из практики, не сомневаюсь, что для ваших случаев эти утверждения были истины.
Смысл моего этого замечания на самом деле был в том, что log4cxx
Опыт показывает, что при наличии опыта и мотивации можно кастомизировать почти все :) Вопрос чаще всего стоит во времени. Но вы правы эти логеры не так сложны в кастомизации при наличии опыта.
Это большой миф, что синхронное логгирование может что-то там замедлить.
Видимо зависит от области, устройств и тд, так как если вы пишете только ошибки и время от времени распечатываете какие то значения то никакого вреда от синхронного логгера не будет. Если речь идет о тысячах в секунду то уже приходится считать.
На прошлой работе люди писали по 30-40 тысяч сообщений в секунду в нормальном режиме и порядка 2.5M под нагрузкой (разработка железа и софта к нему), синхронный логгер такого просто не вытянет, физически. Если у вас маленькое линукс устройство и нужно логировать каждый чих — тоже нет смысла даже пытаться прикрутить синхронный логер, процессор будет обслуживать только его.
Пересчет одного лог вызова в наносекунды дело бессмысленное если у вас 3 лог строчки в секунду и очень полезное если вы занимаетесь трассированием.
Я что пытаюсь сказать — зависит от области где вы применяете и самое главное как.
Вы зря путаете логгирование и перехват исключений. Одно другое никак не заменяет.
Хотел лишь сказать, что они друг друга очень неплохо дополняют и сброс важных буферов в случае краша дело полнезное, будь то синхронный логер пишущий в свой внутренний буфер и сбрасывающий время от времени в файл или асихнронный.
А уж краш дамп если он есть — даст фору логу и приличную в плане «поймать и убить».
Распечатывание стека при падении в самом падающем приложении
Согласен, под виндой страшный ужас, под Линуксом — достаточно легко.
Тех же анализаторов логов можно за 10 минут наверное с десяток нагуглить
Да, вы правы, софта такого рода много, да и самому его сделать не сложно.
Еще раз спасибо за отзыв и комментарии и поменьше Вам случае зачитывания логов по телефону :) А логеры… зависит от области, знаний, способов применения, наличия сети и кучи других факторов, в любом случае никого не хотел обидеть, а только дать некий срез по десяткам критериев.
Задача статьи сравнить логеры с точки зрения их простоты использования. Возможно для Вас это 30 минут работы, для другого инженера не знакомого с логером — это несколько дней плюс тестирование и исправления и все это при наличии желания, особенно если можно взять что-то другое где функция доступна из коробки.
Так же странно, что синхронность отнесена к недостаткам
Я не смог отнести к достоинствам тот факт, что синхронный логер может приостановить выполнение вашей программы на длительное время только потому, что обращается к файлу, а HDD скажем занят. Для домашних проектов это не ограничение, для серьезных проектов — лучше не иметь таких случайных задержек плюс существенное падение производительности в случае интенсивного логирования.
Обычно наоборот в случае падения приложения самые интересные логи они в самом конце. А если они не успеют сброситься на диск, то беда беда
Перехват падений в этом случае решает проблему, можно даже стэк распечатать или сохранить краш дамп — самый простой способ найти и исправить дефект в разумные сроки.
logMX
Утилита стоит денег если используется профессионально.
Спасибо за комментарий, статья поправлена. Скорее это минус ибо препятствует безболезненной замене одного логера другим, нужно будет выпиливать все руками и тестировать каждый вызов лог функции.
Вы правы — это снизит время компиляции.
В статье я постарался рассказать о том какие особенности у каждого логера и какие дополнительные действия нужно предпринять чтоб интеграция и использование принесли желаемую пользу.
Сейчас на очереди Boost.Log, как его закончу постараюсь найти время и посмотреть в сторону предложенного вами проекта.
Изучение каждого логера занимает существенное время, Boost например занял чуть больше недели и еще не закончен.
Если я не ошибаюсь Вы являетесь одним из контрибьюторов этого проекта — если это так и вы готовы помочь мне с ответами на некоторые вопросы связанные с предложенным вами логером (что существенно сократит время на вычитку документации и исходников) — пожалуйста скиньте в личку контактный е-мэйл.
Всего наилучшего!
Как раз стояла цель не заниматся кастомизацией, а взять и использовать, так что кроме теста производительности в условиях равного потребления памяти никаких спец настроек не применялось. Все по умолчанию.
Увы я не могу оценить Вашу ссылку без регистрации st.com. Для дебага это может быть удобно - бесспорно.
Но телеметрия рассмотренная в этой статье - это возможность собирать данные в поле, с множества устройств, активировать и деактивировать счетчики удаленно, с частотой больше чем 1мс и без зависимости от проприетарных инструментов. На сколько я знаю помимо телеметрии библиотека предоставляет так же логирование с функциями с перменными числом аргументов, но без форматирования на целевом процессоре.
Т.е. вы приводите пример хорошего дебаггера, а автор пример инструментов мониторинга систем в дикой среде и без привязки к конкретному производителю.
Опыт показывает, что при наличии опыта и мотивации можно кастомизировать почти все :) Вопрос чаще всего стоит во времени. Но вы правы эти логеры не так сложны в кастомизации при наличии опыта.
Видимо зависит от области, устройств и тд, так как если вы пишете только ошибки и время от времени распечатываете какие то значения то никакого вреда от синхронного логгера не будет. Если речь идет о тысячах в секунду то уже приходится считать.
На прошлой работе люди писали по 30-40 тысяч сообщений в секунду в нормальном режиме и порядка 2.5M под нагрузкой (разработка железа и софта к нему), синхронный логгер такого просто не вытянет, физически. Если у вас маленькое линукс устройство и нужно логировать каждый чих — тоже нет смысла даже пытаться прикрутить синхронный логер, процессор будет обслуживать только его.
Пересчет одного лог вызова в наносекунды дело бессмысленное если у вас 3 лог строчки в секунду и очень полезное если вы занимаетесь трассированием.
Я что пытаюсь сказать — зависит от области где вы применяете и самое главное как.
Хотел лишь сказать, что они друг друга очень неплохо дополняют и сброс важных буферов в случае краша дело полнезное, будь то синхронный логер пишущий в свой внутренний буфер и сбрасывающий время от времени в файл или асихнронный.
А уж краш дамп если он есть — даст фору логу и приличную в плане «поймать и убить».
Согласен, под виндой страшный ужас, под Линуксом — достаточно легко.
Да, вы правы, софта такого рода много, да и самому его сделать не сложно.
Еще раз спасибо за отзыв и комментарии и поменьше Вам случае зачитывания логов по телефону :) А логеры… зависит от области, знаний, способов применения, наличия сети и кучи других факторов, в любом случае никого не хотел обидеть, а только дать некий срез по десяткам критериев.
Задача статьи сравнить логеры с точки зрения их простоты использования. Возможно для Вас это 30 минут работы, для другого инженера не знакомого с логером — это несколько дней плюс тестирование и исправления и все это при наличии желания, особенно если можно взять что-то другое где функция доступна из коробки.
Я не смог отнести к достоинствам тот факт, что синхронный логер может приостановить выполнение вашей программы на длительное время только потому, что обращается к файлу, а HDD скажем занят. Для домашних проектов это не ограничение, для серьезных проектов — лучше не иметь таких случайных задержек плюс существенное падение производительности в случае интенсивного логирования.
Перехват падений в этом случае решает проблему, можно даже стэк распечатать или сохранить краш дамп — самый простой способ найти и исправить дефект в разумные сроки.
Утилита стоит денег если используется профессионально.
В статье я постарался рассказать о том какие особенности у каждого логера и какие дополнительные действия нужно предпринять чтоб интеграция и использование принесли желаемую пользу.
Изучение каждого логера занимает существенное время, Boost например занял чуть больше недели и еще не закончен.
Если я не ошибаюсь Вы являетесь одним из контрибьюторов этого проекта — если это так и вы готовы помочь мне с ответами на некоторые вопросы связанные с предложенным вами логером (что существенно сократит время на вычитку документации и исходников) — пожалуйста скиньте в личку контактный е-мэйл.
Всего наилучшего!