Sentry-javascript: [دعوة لتقديم الملاحظات] خارطة الطريق لـ Sentry JavaScript SDK v7

كانت أكبر مخاوفي دائمًا هي أن مكتبة تسجيل الأخطاء الخاصة بي هي واحدة من أكبر مكتبات الطرف الثالث. لقد فكرت غالبًا في التحميل البطيء لـ Sentry بعد 5-10 ثوانٍ من تحميل الصفحة الأولى للحصول على نتيجة أفضل لسرعة الصفحة ، لذلك أنا متحمس جدًا لأنك تتناول هذا الأمر ❤️

بالنسبة لي ، فإن الهدف drastically reduce overall bundle size هو أيضًا الهدف الأكثر أهمية.

مرحبا،

تقليل الحجم الكلي للحزمة بشكل كبير

أنا أقوم بإجراء 1+ لهذا ، في حالة تغيير هذا أي شيء. وسأضيف هذا: في تطبيق الويب الخاص بي ، تستغرق تهيئة Sentry 30 مللي ثانية (على جهاز كمبيوتر سريع) ، وهو ما يعد كثيرًا جدًا بالنسبة لمسجل التشخيص ، وفي تطبيق React Native ، يكون الأمر أسوأ بشكل ملحوظ ، لأن حزمة (Metro) غير قادر على اهتزاز الشجرة ، لذلك يستورد Sentry عددًا ضخمًا من الملفات _78 ملفًا ، ويساهم أيضًا بشكل ملموس (بنسبة قليلة) في وقت بدء التشغيل.

مرحبًا ، فقط بعض البيانات من React Native:

تم عرض ملف تعريف هذا على iPhone X. يستغرق Sentry 54 مللي ثانية عند الإطلاق - ~ 40 فقط لاستيراد الجزء الأكبر من الملفات ، ~ 15 لتهيئة كود JS. أضف إلى ذلك ما يقرب من 30 مللي ثانية تمنع الخيط الرئيسي لتهيئة الجانب الأصلي ، وهناك بعض الوقت غير المحسوب في lexing / parsing Sentry's JS (الذي يوجد منه الكثير) - أظن أن 5-15 مللي ثانية ، لكن لم يتم القياس بدقة. إجمالاً - 90-100 مللي ثانية - يمثل 15٪ من إجمالي الوقت لبدء تشغيل تطبيقي!

سؤال رائع! أرغب في رؤية المزيد من خيارات التسجيل المرنة (أو كيفية المستندات) لتطبيقات الإنتاج حيث لا ترغب في تعريض المستخدم لأي وحدة تحكم مدونة ، ولكنك تريد التقاطها كفتات تنقل. يمكن أن يحل هذا مشكلات مثل https://github.com/getsentry/sentry/issues/12618 و https://github.com/getsentry/sentry-javascript/issues/1883.

ربما يمكن أن تتكامل فتات الخبز Sentry مع مكتبة التسجيل مثل debug أو loglevel . يبدو هذا كحالة استخدام شائعة لتطبيقات الإنتاج ، وربما يكون مدعومًا بالفعل ببعض أساليب DIY ، ولكن ليس من الواضح حقًا ما إذا كان هذا ممكنًا بناءً على المستندات الحالية. (أو إذا كان الأمر كذلك وقد فاتني بطريقة ما ، فسأكون ممتنًا لأي نصائح). شكرا!

مرحبًا ، لديّ توصية حول تهيئة SDK.

بدلاً من استدعاء Sentry.init بالخيارات ، يمكن أن تتحقق SDK تلقائيًا من SentryOptions مثل المتغير العام المسمى لجلب معرف DSN وخيارات أخرى.

نقوم بتحميل ملفات JS ديناميكيًا عند الحاجة ويصعب تتبع حدث تحميل حزمة js في الطلبات عبر النطاقات أو مشكلات الشبكات. التحقق من هذا المتغير تلقائيًا من شأنه أن يساعد في ذلك ولن تحتاج إلى استدعاء دالة init بشكل حصري.

_SDK فشل في إرسال إشارة event_

أرغب في الحصول على إشارة إلى أن capureEvent فشل في إرسال طلب - لذلك يمكن وضعه في قائمة الانتظار وإعادة المحاولة لاحقًا.

سيكون هذا مفيدًا حقًا للتطبيقات غير المتصلة بالإنترنت (تطبيقات الويب التقدمية).

هناك مواقف يكون فيها المتصفح في حالة اتصال بالإنترنت ، ولكن يفشل طلب الشبكة بسبب عدم استقرار الاتصال / انتهاء المهلة (على سبيل المثال ، السفر في مناطق منخفضة ذات تغطية شبكة رديئة).

يوجد تكامل في وضع عدم الاتصال ولكنه يعتمد على الأحداث المتصلة بالإنترنت وغير المتصلة والتي لا تكفي لتغطية هذه الحالة.

قد تتسبب أخطاء الشبكة في قيام التطبيق الذي لا يعتبر مثل هذا الموقف بإلقاء أخطاء لا يتم تسجيلها بواسطة Sentry وتختفي فقط في الفراغ.

لدي مشروع هو PWA ولا أحصل على أحداث عندما يكون التطبيق غير متصل بالإنترنت ، ولا توجد طريقة لإجراء مزامنة خلفية في عامل الخدمة ، لأنه غير مسجل في مجال إدخال الحارس.

تضمين التغريدة
من المفترض أن يكون هذا ممكنًا مع Workbox وهو المكون الإضافي لـ
يبدو أنه يعمل بشكل جيد ، كما أن تاريخ الحدث هو وقت حدوث الخطأ.

// service-worker.js
import { registerRoute } from 'workbox-routing'
import { NetworkOnly } from 'workbox-strategies'
import { BackgroundSyncPlugin } from 'workbox-background-sync'

registerRoute(
  new RegExp('^https://[^\\.]+\\.ingest\\.sentry\\.io/api/.*$'),
  new NetworkOnly({
    plugins: [
      new BackgroundSyncPlugin('project-name/sentry-event-queue', {
        maxRetentionTime: 7 * 24 * 60, // 7 days
      })
    ],
  }),
  'POST'
)

مرحبًا ، أحب أن أرى مخططًا لـ drastically reduce overall bundle size . لدينا مشروع gatsby + preact ويشغل الحارس حوالي 28٪ من حجم الحزمة الرئيسية (27 كيلوبايت من 95 كيلوبايت). نحاول جعل حزمة js لكل صفحة أقل من 90 كيلوبايت حتى يتمكن تطبيقنا من أداء أفضل في المناطق الريفية ذات الاتصالات السيئة. سيساعد حجم SDK الحارس الأصغر بشكل كبير كثيرًا.

لماذا لا تسقط دعم IE11 أيضًا؟ ستنهي العديد من المواقع الكبيرة ، بما في ذلك Microsoft ، دعم هذا المتصفح بحلول نهاية العام. بالطبع السؤال هو ما إذا كان هذا يؤثر حقًا على حجم المكتبة.

kamilogorek أي فكرة متى قد يأتي

أتفق أيضًا مع @ xr0master وأعتقد أنه يجب إسقاط دعم IE بالكامل بما في ذلك IE11 في الإصدار الجديد.

ما هي أكبر نقاط الضعف عند استخدام SDK؟

• استيراد. لكن أعتقد أن هذا يتماشى مع "قابلية اهتزاز الشجرة" ، أو النمطية.

// This is not nice, as it doesn't get auto-completion when importing
import * as Sentry from '@sentry/browser'

// This is better, but has given me problems on Sentry 5.x
import { captureException } from '@sentry/browser'

• تصحيح أخطاء الاستدعاء. قد يكون الأمر واضحًا من منظور كيفية تنفيذ تطبيق Sentry ، ولكن يبدو أن كل console.log ينشأ من instruments.js:1 ، وهو أمر غير مفيد أثناء التصحيح. نظرًا لأن console.trace مبالغة ، انتهى بي الأمر بكتابة فتات الخبز يدويًا في console.log للحصول على معلومات حول ما يتم تسجيله حاليًا.

ما هي أكثر الميزات التي تفتقدها؟

دعم الصحة .

هل هناك خطط لاستخدام AsyncLocalStorage على إصدارات Node التي تدعمها؟

لذلك قمنا بشحن 6.0.0 اليوم ، مع عدم وجود تغييرات كبيرة إلى جانب إرسال بيانات الجلسة افتراضيًا. تضمين التغريدة
لقد غيرت عنوان هذه المشكلة إلى الإصدار 7 والذي يجب أن يعكس ذلك بشكل أفضل.

سيكون من الرائع الكشف عن تكامل إطار العمل بشكل منفصل عن Sentry.init . قد يكون هذا العنوان # 3232 ، حيث يتم تحميل Vue بشكل كسول ، وبالتالي لا يمكن ضمان وجوده في وقت تهيئة الحارس. شيء مثل Sentry.configureVue(Vue) والذي يمكن استدعاؤه في وقت تحميل Vue.

تكامل جهاز التوجيه التفاعلي لدعم تحميل وتفريغ تطبيق رد فعل ثانوي داخل نفس المستند باستدعاء كسول ، باستخدام جهاز توجيه خاص به ومسارات أكثر تحديدًا