Sentry-javascript: Избавьтесь от ignoreErrors

Я дёрну с 1.1

У меня куча ошибок, которые я игнорирую. Почему это удаляется? Например, я постоянно получал ошибку, которую я, наконец, отследил как случайный плагин Firefox, который генерировал ложную ошибку. Я ничего не мог с этим поделать - поэтому добавил его в ignoreErrors.

@jeremyhaile Не ignoreUrls вместо этого? Если нет, я оставлю это при себе. У меня создалось впечатление, что этим никто не пользовался, и это просто добавляло раздувания. :)

Хм - хороший вопрос. Если я добавлю URL-адрес типа " http://static.ak.facebook.com/ " для ignoreUrls, игнорирует ли он все ошибки, возникающие из любого каталога / файла, который начинается с этого URL-адреса?

ignoreUrls принимает массив шаблонов регулярных выражений. Так что вы можете делать все, что хотите. :)

@jeremyhaile В частности: https://github.com/getsentry/raven-js/blob/master/src/raven.js#L374

Хорошо - я собираюсь попробовать удалить ignoreErrors из нашей конфигурации и посмотреть, какие ошибки я начинаю получать, и позволяет ли ignoreUrls игнорировать их или нет. Я дам вам знать, что я нашел.

Да, я уже сталкиваюсь с ошибками, которые я не могу (или не хочу исправлять) и которые нельзя исключить с помощью ignoreUrls. Вот одна такая ошибка IE, которую я уже получаю. Рекомендуемое исправление в соответствии с Microsoft - «обновить до IE8». URL отображается как URL моей страницы, что я, очевидно, не хочу исключать. http://support.microsoft.com/kb/927917?wa=wsignin1.0

@jeremyhaile Достаточно

Нет проблем - оцените быстрые ответы!

Было бы неплохо, если бы ignoreErrors использовал регулярные выражения, такие как ignoreUrls, вместо строк точного соответствия. В некоторых случаях я сталкиваюсь с ошибками, к которым прикреплен странный код ошибки, который не всегда совпадает с номером. Или ошибки, которые содержат одну и ту же строку, но имеют разные префиксы в разных браузерах.

+1 к предложению @jeremyhaile - либо использование ignoreErrorPatterns поможет уменьшить несколько бит шума, вводимого расширением / ISP, который я вижу на нашем общедоступном сайте.

Введенный ISP шум

Это звучит неплохо. : +1:

Я за регулярные выражения. Как вы думаете, имеет ли смысл объединить эти две опции в одну, которая работает как с URL-адресами, так и с именами сообщений?

Или они все же должны быть отдельными?

Я думаю, что если бы он был отдельным, было бы менее запутанно - иначе он
кажется почти уверенным, что кто-то откроет проблему, потому что их регулярное выражение
совпали больше, чем они ожидали.

Мне нравится идея переименовать его, чтобы было понятно, что вы
предоставление является регулярным выражением или явной проверкой наличия строки vs.
regexp, чтобы решить, следует ли тестировать, используя == или .test() чтобы избежать сюрпризов.

Я согласен хранить его отдельно - я не могу вспомнить случаев, когда я бы явно не писал регулярное выражение для URL-адреса и сообщения. Также - если я пишу регулярное выражение URL, неэффективно сравнивать его с каждым сообщением.

Мне также нравится ваша идея проверить, является ли это строкой или регулярным выражением, прежде чем проводить сравнение.

У меня проблема с ignoreErrors (возможно, исправлена ​​с помощью регулярного выражения?), Когда я получаю сотни ""ошибки в Sentry. Но мой ignoreErrors установлен на:
ignoreErrors: ['', ......]

На сервере написано:


9 минут назад javascript

Есть идеи, почему это не было бы отфильтровано? Дайте мне знать, если я должен открыть для этого отдельный вопрос. (и, возможно, проблема с регулярным выражением)

@jeremyhaile Можете выделить для этого отдельную тему?

Я отменил это предупреждение об устаревании. Это просто плохая идея. :)

Спасибо за введение, ребята!