ради этого платить абонентку?
может и удобно, но есть нишевые инструменты. если zidium начинает втаскивать в себя все, что можно — возникает логичный вопрос — для этого раздувается команда или падает качество компонентов?
плохо организованная сборка метрик может откусить не малую часть ресурсов. видел проект, в котором при отключении профилирования расходы падали процентов на 15. это действительно задача на порядки сложнее, чем насобирать 100500 http запросов.
одно окно это удобно, но и 2 как-то проблем не вызовут.
я его использую в unity3d. там своя система логгирования.
Вот из этого фрагмента можно было бы понять что чьим плагином тут является:
разумеется. а еще можно было назвать статью как-то более четко. например, "использование zidium для логгирования ошибок". я думал это статья, а не кроссворд со скрытыми загадками.
а так сейчас поиск "логгирование с NLog" будет выводить сюда.
из-за того, что в статье 90 процентов почему-то посвящено не настройке NLog, а Zidium, я получил ложное представление об этом инструменте. посчитал, что NLog это часть Zidium и ассоциировал их как единое целое.
на самом деле вопрос носил смысл "чем предложенное лучше/хуже Sentry". именно в таком виде. извиняюсь, что возникло недопонимание. когда говорят колесо, а тычат пальцем в телегу — не видя ранее ни того, ни другого не запутаться трудно.
плюсов я откровенно не увидел. из минусов — нет локальной версии, странные ограничения на объемы нотификаций.
Именно такую схему работы реализовывает расширение NLog для системы мониторинга Zidium.
де-факто статья не об NLog, а о его связке с zidium. здесь показано как связаться с этой тулой. но нет ни настроек уровней, ни записей в консоль/файл. по самой настройке NLog здесь нет практически НИЧЕГО.
Вообще-то, вы первым решили сравнить два разных продукта.
ложь. я попросил разницу между тем, что в статье и Sentry.
Вам не приходило в голову что не каждый программист в мире пишет на Java?
я пишу на десятке языков. C# в арсенале есть. не вижу особых проблем в понимании похожих синтаксисов.
каких-то глубоких знаний java здесь не требуется.
но для простоты я мог бы оперировать псевдоязыком — надеюсь вы не стали бы просить тогда писать строго на C#?
То есть вы предполагете что в проекте уже есть какой-то логгер, к которому можно прицепить аппендер.
если его нет, но это по всей видимости десктопный калькулятор, которому логи ни к чему. в наше время нет приложений, который зарабатывают деньги и при этом не пишут логов. так что да — я предполагаю, что система логгирования уже есть. а если ее нет — она должна быть добавлена обязательно первым же делом.
NLog — это и есть та самая библиотека, которая дает программисту логгеры и аппендеры
за это пояснение спасибо. теперь понял. а то по тону статьи выглядит так, будто это часть zidium. что-то вроде его плагинов.
полностью согласен, что я не правильно понял назначение этого инструмента и провел ложные аналогии.
меня выше спрашивали про log4j. он есть. носит название log4net.
принципиальной разницы с версией java практически нет. а уж влияния на внешние инструменты тем более.
ps я так и не увидел ответа чем же Sentry хуже/лучше связки NLog + Zidium
вместо этого собеседник старается заглушить вопрос своим "а нафига вам Sentry если есть log4j?".
может быть вы ответите — а нафига нам NLog если есть log4j? аргументы "он раскладывает все по полочкам" приняты mayorovp не были.
был такой форум… звался javatalks.
когда-то довольно активный… знаете на чем они погорели и почему от них ушла большая часть аудитории? модераторы начали вместо ответов говорить "посмотри в гугле".
зачем мне идти в поисковик, читать документацию, если меня интересует краткий ответ на мой вопрос и статья посвящена этой системе?
все что есть в этой статье в гугле есть — так может быть она и не нужна по вашей логике? если вы не можете ответить на мой вопрос — подождите пока до вопроса дойдут компетентные люди.
я погуглил что такое zidium когда стало ясно, что статья более с рекламным уклоном, нежели с желанием просвятить сообщество относительно новой альтернативной методики логгирования. честно говоря наколенная поделка на первый взгляд и интерес к нему угас как таковой. хранить логи на стороне неприемлемо от слова "совсем".
мог и вовсе не знать что такое log4j
нуууу… в этом случае и говорить не о чем. не знание азов лечится только книгами или практикой хотя бы на уровне джуна-стажера. это как человек, не знающий что-такое git.
ps не смотря на то, что вы по 2 раза задаете одни и те же вопросы — я же не считаю, что передо мной идиотские вопросы, задаваемые троллем? хотя исправляемый текст в цитатах якобы на меня наводит на такую мысль.
я ответил, что вы сравниваете два разных продукта. "зачем нам шурупы, когда есть гвозди?". действительно, а зачем? (это риторический вопрос — ответа не требуется) аналогия с машиной и прицепом очевидно слишком сложна.
в первом же примере кода есть строчка using System;
ключ может быть и в переменных окружения. (не знаю есть ли реально такая возможность у NLog)
его назначение только одно — чтобы система логгирования "узнала" отправителя.
какого-либо доступа он не даст.
зачем сопровождать? какой-нибудь типовой jenkins годами можно не трогать — все работает. никто не заставляет вас добавлять туда модные фичи если они не нужны.
если приложение маленькое и логов мало — разграничить по уровню можно для начала.
Sentry в бесплатном тарифе имеет ограничение One user, не получится использовать в команде.
а зачем вам несколко пользователей если приложение на 1 виртуальный сервер? логи можно и под одной учеткой смотреть. не привязывать к AD и все.
лог не более 200 Мб в день на бесплатном аккаунте. ни о чем, честно говоря.
до 2000 ошибок в день против 10к на бесплатном тарифе в облаке и безлимите в локальной инсталяции. если все плохо — эти 2000 ошибок набегут очень быстро и всю вторую половину дня придется куковать. если все хорошо — лимит за сутки не перенесется.
установка на локальные сервера строго платная и обсуждается отдельно. для бизнеса хранение логов «где-то там» далеко не всегда подойдет.
инструмент несомненно интересный, но я даже личные приложения предпочитаю держать в максимально замкнутой системе.
15 минут + навыки по докеру… несколько инстансов?
если вы не можете найти ресурсов на 1 сервер — значит и приложение не такое уж огромное или просто нерентабельное.
я не предлагал отказаться от других систем логгирования в пользу агрегатора данных.
изначальный вопрос был именно чем Nlog лучше уже имеющегося популярного решения Sentry.
сравнивать log4j и Sentry столь же корректно, как автомобиль и прицеп — функции схожие, но не тождественные. если есть возможность — лучше иметь и то и другое.
вы же не станете держать в одном проекте logback и log4j про запас? это уже практически одинаковые инструменты.
откуда здесь «облачный»? Zidium должен быть установлен на той же машине, что и приложение? из статьи мне показалось, что это не так.
Sentry ставится на отдельный сервер. в том числе и докером. арендовать хостинг не обязательно.
встроенный баг-треккер вроде в чистой Sentry отсутствует, но вот назначить ошибку на человека и пометить ее исправленной как в типовой таске — это есть.
самой лучшей плюшкой на мой взгляд является отправка на почту нотификации по подписке, что добавилось что-то новое. не надо сидеть и обновлять страницу.
ну а зачем использовать info-файл, если есть DEBUG? иногда просто нужно посмотреть что происходило в системе без разграничений по времени события. редко, но случается.
это разные инструменты. один пишет все, второй шлет нотификации на инциденты и группирует события.
это за тем же, зачем включают создания dump-файла на падении jvm. чтобы было.
при наличии и Sentry и log4j однозначно все выбирают удобную админку вместо простыни. log4j лишь страховка например на случай отсутствия сети или на момент перезапуска Sentry.
есть переменные окружения.
кроме того, этот ключ вероятнее всего можно поменять «на лету».
да и максимум, что уронят — систему логгирования на стороннем сервере. само приложение от этого не пострадает. (если, конечно, его не держат там же, где и отладочный инструментарий)
стоп… настройка NLog ведется не из приложения, а из личного кабинета?
каков принцип приема данных?
при повышении требований вы отказываетесь принимать данные или выполняется доступ к приложению с его перенастройкой?
кстати, аналогичная настройка и у Sentry -там тоже можно принимать хоть все info.
выше я еще спрашивал про прожорливость админки. подскажите, пожалуйста, как система почувствует себя на микрокомпьютере с минимумом ресурсов (кто-то типа 1 core 2GHz + 256 ram)
поясняю принцип работы Sentry. В общем абстрактном проекте в вакууме.
есть некое приложение. оно еще мааааленькое. логов там мало. потом кто-то понимает, что если сделать его большим — оно принесет чемодан денег и начинают его выращивать.
Все это время приложение пишет логи… там много мусора. сообщения о том, что пользователь успешно авторизовался… сообщения о том, что пользователь просмотрел 101 страницу с их полным списком… все это пишется log4j-подобным логгером в файл.
приходит админ и видит этот бардак… распиливает логи по уровням — в один все, в другой debug, в третий error. дышать становится легче…
приложение растет… разлетается в инстансы облака… работает на 3-4 машинах и собирать эти файлы уже проблема…
одна и та же ошибка, на которую нет времени потому что она не критична, повторяется каждые 2 минуты и полностью забивает лог-файлы. найти в error-логе одну новую ошибку среди 200 уже известных проблема.
а потом наконец-то до кого-то доходит, что можно прикрутить Sentry.
делается это оооочень трудным путем.
— добавляется maven-зависимость
— добавляется запись о новом аппендере в файл-конфиг уже существующего и работающего логгера приложения
теперь как только что-то попадает на отправку в логи — оно идет и в файл и в Sentry.
настраиваем уровень логов для Sentry-appender (он использует ravenClient внутри себя — во всяком случае для варианта http-нотификаций.)
заходим в Sentry и видим что-то типа
все ошибки разложены по полочкам. в любую можно зайти и посмотреть stacktrace.
отличие от log4j в том, что там просто простыня из всего подрят без какой-то группировки и типизирования. на 300 ошибок может быть 297 одного типа и 3 критических. поверьте — найти эти 3 будет нереально. в Sentry это будет всего ДВЕ строки с количеством инцидентов.
точно!
зато в каждом будет инструмент, занимающийся своим делом, заточенный только на свою задачу, да еще и бесплатно.
ради этого платить абонентку?
может и удобно, но есть нишевые инструменты. если zidium начинает втаскивать в себя все, что можно — возникает логичный вопрос — для этого раздувается команда или падает качество компонентов?
плохо организованная сборка метрик может откусить не малую часть ресурсов. видел проект, в котором при отключении профилирования расходы падали процентов на 15. это действительно задача на порядки сложнее, чем насобирать 100500 http запросов.
одно окно это удобно, но и 2 как-то проблем не вызовут.
на самом деле можно и даже проще.
zabbix? зато платить не потребуется. и метрики и статус сервера. и локальное по без выноса непонятно к кому.
upd вижу, что у него беда с dotnet. не подойдет. но возможно все-таки есть смысл не стягивать на одну систему все?
я его использую в unity3d. там своя система логгирования.
разумеется. а еще можно было назвать статью как-то более четко. например, "использование zidium для логгирования ошибок". я думал это статья, а не кроссворд со скрытыми загадками.
а так сейчас поиск "логгирование с NLog" будет выводить сюда.
из-за того, что в статье 90 процентов почему-то посвящено не настройке NLog, а Zidium, я получил ложное представление об этом инструменте. посчитал, что NLog это часть Zidium и ассоциировал их как единое целое.
на самом деле вопрос носил смысл "чем предложенное лучше/хуже Sentry". именно в таком виде. извиняюсь, что возникло недопонимание. когда говорят колесо, а тычат пальцем в телегу — не видя ранее ни того, ни другого не запутаться трудно.
плюсов я откровенно не увидел. из минусов — нет локальной версии, странные ограничения на объемы нотификаций.
де-факто статья не об NLog, а о его связке с zidium. здесь показано как связаться с этой тулой. но нет ни настроек уровней, ни записей в консоль/файл. по самой настройке NLog здесь нет практически НИЧЕГО.
ложь. я попросил разницу между тем, что в статье и Sentry.
я пишу на десятке языков. C# в арсенале есть. не вижу особых проблем в понимании похожих синтаксисов.
каких-то глубоких знаний java здесь не требуется.
но для простоты я мог бы оперировать псевдоязыком — надеюсь вы не стали бы просить тогда писать строго на C#?
если его нет, но это по всей видимости десктопный калькулятор, которому логи ни к чему. в наше время нет приложений, который зарабатывают деньги и при этом не пишут логов. так что да — я предполагаю, что система логгирования уже есть. а если ее нет — она должна быть добавлена обязательно первым же делом.
за это пояснение спасибо. теперь понял. а то по тону статьи выглядит так, будто это часть zidium. что-то вроде его плагинов.
полностью согласен, что я не правильно понял назначение этого инструмента и провел ложные аналогии.
меня выше спрашивали про log4j. он есть. носит название log4net.
принципиальной разницы с версией java практически нет. а уж влияния на внешние инструменты тем более.
ps я так и не увидел ответа чем же Sentry хуже/лучше связки NLog + Zidium
вместо этого собеседник старается заглушить вопрос своим "а нафига вам Sentry если есть log4j?".
может быть вы ответите — а нафига нам NLog если есть log4j? аргументы "он раскладывает все по полочкам" приняты mayorovp не были.
был такой форум… звался javatalks.
когда-то довольно активный… знаете на чем они погорели и почему от них ушла большая часть аудитории? модераторы начали вместо ответов говорить "посмотри в гугле".
зачем мне идти в поисковик, читать документацию, если меня интересует краткий ответ на мой вопрос и статья посвящена этой системе?
все что есть в этой статье в гугле есть — так может быть она и не нужна по вашей логике? если вы не можете ответить на мой вопрос — подождите пока до вопроса дойдут компетентные люди.
я погуглил что такое zidium когда стало ясно, что статья более с рекламным уклоном, нежели с желанием просвятить сообщество относительно новой альтернативной методики логгирования. честно говоря наколенная поделка на первый взгляд и интерес к нему угас как таковой. хранить логи на стороне неприемлемо от слова "совсем".
ps не смотря на то, что вы по 2 раза задаете одни и те же вопросы — я же не считаю, что передо мной идиотские вопросы, задаваемые троллем? хотя исправляемый текст в цитатах якобы на меня наводит на такую мысль.
я ответил, что вы сравниваете два разных продукта. "зачем нам шурупы, когда есть гвозди?". действительно, а зачем? (это риторический вопрос — ответа не требуется) аналогия с машиной и прицепом очевидно слишком сложна.
действительно редкость для кода на C++
какая библиотека вам понравится — по алфавиту и полочкам или сваленная в кучу из самосвала посреди двора?
выше я уже отвечал на этот вопрос.
ключ может быть и в переменных окружения. (не знаю есть ли реально такая возможность у NLog)
его назначение только одно — чтобы система логгирования "узнала" отправителя.
какого-либо доступа он не даст.
уже увидел, что selfhost версия у зидиума платная. интересовала именно она. совершенно не подходит — логи на стороне хранить желания нет ни малейшего.
зачем сопровождать? какой-нибудь типовой jenkins годами можно не трогать — все работает. никто не заставляет вас добавлять туда модные фичи если они не нужны.
если приложение маленькое и логов мало — разграничить по уровню можно для начала.
а зачем вам несколко пользователей если приложение на 1 виртуальный сервер? логи можно и под одной учеткой смотреть. не привязывать к AD и все.
до 2000 ошибок в день против 10к на бесплатном тарифе в облаке и безлимите в локальной инсталяции. если все плохо — эти 2000 ошибок набегут очень быстро и всю вторую половину дня придется куковать. если все хорошо — лимит за сутки не перенесется.
установка на локальные сервера строго платная и обсуждается отдельно. для бизнеса хранение логов «где-то там» далеко не всегда подойдет.
инструмент несомненно интересный, но я даже личные приложения предпочитаю держать в максимально замкнутой системе.
если вы не можете найти ресурсов на 1 сервер — значит и приложение не такое уж огромное или просто нерентабельное.
изначальный вопрос был именно чем Nlog лучше уже имеющегося популярного решения Sentry.
сравнивать log4j и Sentry столь же корректно, как автомобиль и прицеп — функции схожие, но не тождественные. если есть возможность — лучше иметь и то и другое.
вы же не станете держать в одном проекте logback и log4j про запас? это уже практически одинаковые инструменты.
Sentry ставится на отдельный сервер. в том числе и докером. арендовать хостинг не обязательно.
встроенный баг-треккер вроде в чистой Sentry отсутствует, но вот назначить ошибку на человека и пометить ее исправленной как в типовой таске — это есть.
самой лучшей плюшкой на мой взгляд является отправка на почту нотификации по подписке, что добавилось что-то новое. не надо сидеть и обновлять страницу.
это разные инструменты. один пишет все, второй шлет нотификации на инциденты и группирует события.
это за тем же, зачем включают создания dump-файла на падении jvm. чтобы было.
при наличии и Sentry и log4j однозначно все выбирают удобную админку вместо простыни. log4j лишь страховка например на случай отсутствия сети или на момент перезапуска Sentry.
кроме того, этот ключ вероятнее всего можно поменять «на лету».
да и максимум, что уронят — систему логгирования на стороннем сервере. само приложение от этого не пострадает. (если, конечно, его не держат там же, где и отладочный инструментарий)
каков принцип приема данных?
при повышении требований вы отказываетесь принимать данные или выполняется доступ к приложению с его перенастройкой?
кстати, аналогичная настройка и у Sentry -там тоже можно принимать хоть все info.
выше я еще спрашивал про прожорливость админки. подскажите, пожалуйста, как система почувствует себя на микрокомпьютере с минимумом ресурсов (кто-то типа 1 core 2GHz + 256 ram)
есть некое приложение. оно еще мааааленькое. логов там мало. потом кто-то понимает, что если сделать его большим — оно принесет чемодан денег и начинают его выращивать.
Все это время приложение пишет логи… там много мусора. сообщения о том, что пользователь успешно авторизовался… сообщения о том, что пользователь просмотрел 101 страницу с их полным списком… все это пишется log4j-подобным логгером в файл.
приходит админ и видит этот бардак… распиливает логи по уровням — в один все, в другой debug, в третий error. дышать становится легче…
приложение растет… разлетается в инстансы облака… работает на 3-4 машинах и собирать эти файлы уже проблема…
одна и та же ошибка, на которую нет времени потому что она не критична, повторяется каждые 2 минуты и полностью забивает лог-файлы. найти в error-логе одну новую ошибку среди 200 уже известных проблема.
а потом наконец-то до кого-то доходит, что можно прикрутить Sentry.
делается это оооочень трудным путем.
— добавляется maven-зависимость
— добавляется запись о новом аппендере в файл-конфиг уже существующего и работающего логгера приложения
теперь как только что-то попадает на отправку в логи — оно идет и в файл и в Sentry.
настраиваем уровень логов для Sentry-appender (он использует ravenClient внутри себя — во всяком случае для варианта http-нотификаций.)
заходим в Sentry и видим что-то типа
(оригинал взят отсюда)
все ошибки разложены по полочкам. в любую можно зайти и посмотреть stacktrace.
отличие от log4j в том, что там просто простыня из всего подрят без какой-то группировки и типизирования. на 300 ошибок может быть 297 одного типа и 3 критических. поверьте — найти эти 3 будет нереально. в Sentry это будет всего ДВЕ строки с количеством инцидентов.