Какие дополнительные преимущества может предоставить Sentry.IO по сравнению с Application Insights для ASP.NET Core?
Наша компания рассматривает возможность внедрения Sentry.IO для нашего приложения ASP.NET Core, и я пытаюсь понять, какие дополнительные преимущества он может предложить по сравнению с нашей текущей настройкой с Application Insights.
Вот каковы их аргументы:
Фильтрация ошибок 401. Мы сталкиваемся с множеством ошибок 401 в Application Insights, в основном из-за того, что токены JWT истекают по утрам. Они сказали, что это усложняет отслеживание реальных проблем, и я сказал им, что они могут отфильтровать их, исключив код ответа на запрос! = 401, но мне любопытно, предлагает ли Sentry.IO более эффективный или автоматизированный способ. справиться с этим?
Типы исключений по количеству: Они сказали, что им нужно видеть типы исключений по количеству. Например, если наше приложение внезапно выдает новую ошибку 400, которую мы раньше не видели, нам необходимо обнаружить ее и получить уведомление об этом. Это все еще возможно в Application Insights, и я им об этом рассказал.
Интересно, есть ли реальный аргумент, который в каком-то аспекте сделал бы Sentry.IO чем-то большим, чем Application Insights?
Ответы 1
Важным отличием является то, что Sentry не является инструментом ведения журналов. Он объединяет события с отпечатками пальцев (по умолчанию на основе трассировки стека) в «проблемы» и предупреждает вас о новых проблемах. Конечно, вы можете настроить оповещения и для других условий, помимо новых проблем.
Он направлен на сбор максимального количества типов ошибок, которые могут возникнуть в вашем приложении, и сообщает о них с обширным контекстом, который может помочь вам отладить происходящее. Включая строки кода, а также окружающий исходный код, даже если PDB не поставляются с окончательным приложением (в SDK Sentry есть задача msbuild, которая может загружать PDB в Sentry для символизации на стороне сервера). А также возможный коммит, вызвавший эту ошибку.
Фильтрация ошибок 401
Sentry не фиксирует события для обработанных запросов, которые привели к статусу 401. Он фиксирует любую ошибку в вашем коде, что приводит к 500. Например, если это было необработанное исключение, созданное в промежуточном программном обеспечении. Или ошибка, которая была обработана ExceptionHandler . Или также ошибки в Task, которые не были перехвачены вашим кодом UnobservedTaskException. И другие подобные ошибки.
Кроме того, он может фиксировать ошибки, если вы используете блокировку вызовов на асинхронных конечных точках.
И ошибки HTTP-клиента (если вы используете HttpClient или HttpClientFactory): https://docs.sentry.io/platforms/dotnet/guides/aspnetcore/configuration/http-client-errors/
В ASP.NET Core вам просто нужно согласиться, нажав options.CaptureFailedRequests = true;, поскольку обработчик добавляется автоматически.
И вы можете настроить, какие коды статуса вы хотите добавить (например, если вы хотите подписаться на диапазон 400: options.FailedRequestStatusCodes.Add((400, 499));. Но я понимаю, что это именно то, чего вы не хотите, и по умолчанию НЕ фиксируется ~400). .
Он также работает в приложениях, скомпилированных Native AOT, включая ASP.NET Core. См.: https://sentry.engineering/blog/should-you-could-you-aot
(Я из Application Insights). Вы также можете отфильтровать 401 непосредственно из кода с помощью TelemetryProcessor. Тогда их вообще собирать не будут.