Sentry-javascript: اتجاهات للإبلاغ في وضع عدم الاتصال؟

هل يمكنك اكتشاف ما إذا كان المستخدم غير متصل؟

إذا كان الأمر كذلك ، فلن يكون من المستحيل جمع الأحداث وترتيبها في قائمة الانتظار. عندما يعود المستخدم إلى الاتصال بالإنترنت ، أرسله عبر Raven.captureException مرة أخرى.

ربما يمكنني المساعدة في كيفية عمل ذلك أو إضافة خطاف للمساعدة في ذلك.

عظيم ، شكرا على التعاون. يمكنني اكتشاف وجود المستخدم عبر الإنترنت حتى مجرد اختبار إمكانية الوصول إلى Sentry. لهذا يمكنني الاستماع إلى أحداث فشل الإرسال ، ولكن كيف يمكنني إعادة المحاولة؟

حول استخدام captureException ، سيكون ذلك جيدًا ، لكني أرغب في الاحتفاظ بمعالج الغراب الممتاز الذي يوفر الاستثناءات غير المعالجة. سأحتاج إلى إضافة بعض المنطق الأوسط بين كشف خطأ الغراب ونقل الخطأ

نعم ، lemme فكر في هذا. أعتقد أن هناك طريقة لطيفة يمكننا من خلالها إما دعم هذا تلقائيًا في raven-js ، أو توفير وسيلة لفعل ذلك. أعتقد أن هذا عادل.

أنا أبحث عن نفس الوظيفة أيضًا. بعد فحص المستندات ، يبدو أن الحل قد يكون استخدام shouldSendCallback ، شيء من هذا القبيل:

shouldSendCallback: function(data) {
  localStorage['queued-errors'] = (localStorage['queued-errors'] || []).push(data);
  return false;
}

ثم استمع إلى اتصال الشبكة وقم بمعالجة قائمة الانتظار باستخدام Raven.captureException :

window.addEventListener('online', checkAndProcessQueue);

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

أرى بعض الطرق الممكنة لهذا:

1. خيار retry لكل مثيل أو لكل رسالة ، والذي قد يحدد عدد مرات إعادة محاولة إرسال الأحداث ، وعدد مرات المحاولة قبل الاستسلام ، وما إلى ذلك.
2. استدعاء / رد (استدعاءات) على الطرق captureException(), sendMessage () `، وما إلى ذلك ، والتي يتم تشغيلها عند النجاح / الفشل
3. التعهد بهذه الأساليب (MEH)
4. بدء الأحداث (أين؟) عند الفشل وتوفير سياق كافٍ في بيانات الحدث لمحاولة إعادة إرسال هذا الحدث

من المحتمل أن يكون لديك مرفق تخزين غير متصل بالإنترنت حتى يمكن إرسال رسائل الخطأ لاحقًا في الوقت المناسب. ربما حتى بعد إغلاق المستخدم للتطبيق وإعادة فتحه لاحقًا أثناء الاتصال بالإنترنت. على غرار نهج "وضع عدم الاتصال أولاً":
http://offlinefirst.org/

لقد واجهت نفس المشكلة. في البداية ، كنت أرغب في حلها بشكل مشابه لكيفية حل مشكلة تحليلات google غير المتصلة بالإنترنت مع عامل خدمة . تم شرح النهج جيدًا بواسطة Google هنا .

ومع ذلك ، عند استهداف كوردوفا ، قد لا يكون عامل الخدمة متاحًا.
وهناك حاجة إلى حل _hacky_. لقد توصلت إلى هذا:

https://gist.github.com/oliviertassinari/73389727fe58373eef7b63d2d2c5ce5d

import raven from 'raven-js';
import config from 'config';

const SENTRY_DSN = 'https://[email protected]/YYYY';

function sendQueue() {
  const sentryOffline = JSON.parse(window.localStorage.sentryOffline);

  if (sentryOffline.length > 0) {
    raven._send(sentryOffline[0]);
  }
}

// ... 

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

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

أيضًا ، ما المقصود بعلامة "DDN"؟

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

عادل تماما. لكنني لست متأكدًا من أنه يجب أن يتم ذلك بشكل افتراضي. هناك العديد من السيناريوهات حيث ، إذا لم يتم تحميل البرنامج النصي ، فلن يعمل التطبيق مهما كان الأمر. وأود أن أقول إن معظم التطبيقات فقط بشكل مباشر لا تعمل في وضع عدم الاتصال ، ولا تتوقع ذلك. سواء كانت هذه ممارسة جيدة أم لا ، فهذا شيء آخر.

إنه نوع من سبب عدم تسجيل أخطاء AJAX افتراضيًا ، على الرغم من أن جزءًا كبيرًا من مستخدمي Raven قد كتبوا تعليمات برمجية للقيام بذلك. لكننا سنحاول تسهيل القيام بذلك _ إذا أردت_. وأود أن أفعل نفس الشيء هنا.

أيضًا ، ما المقصود بعلامة "DDN"؟

لست متأكدا. @ mattrobenolt؟

مطلوب قرار التصميم. :)

لست متأكدًا من أنه يجب أن يتم ذلك بشكل افتراضي.

يا هذا منطقي.

لكننا سنحاول تسهيل القيام بذلك إذا أردت. وأود أن أفعل نفس الشيء هنا.

لذا ، من أجل المساعدة في اتخاذ قرار التصميم ، إليك بعض الأفكار:

إذا فهمت المستندات بشكل صحيح ، فإن خيار التكوين transport يسمح للشخص بالتحكم بشكل أساسي في الجزء الأخير من خط الأنابيب حيث يرسل Sentry البيانات إلى الخادم ويصبح مسؤولاً عن إجراء هذا الإرسال. في هذه الحالة ، يبدو أن هذا هو أفضل مكان لإضافته إلى قائمة انتظار غير متصلة بالإنترنت. بدلاً من إرسال البيانات إلى الخادم ، أرسلها إلى قائمة انتظار يتم تحميلها إلى الخادم في الخلفية. سيكون هذا إذا كان شخص ما يكتب الكود الخاص به لتحقيق ذلك.

في سياق مماثل ، هل سيكون من السهل أيضًا كشف خيار التكوين ( includeOffline ؟) الذي من شأنه أن يحل محل نقل HTTP الافتراضي بقائمة انتظار رسمية قادرة على عدم الاتصال بشبكة Raven؟

• لتوافق المستعرض ، ربما قم بتخزين قائمة الانتظار في localStorage واجعلها تتحقق من الاتصال عند انتهاء المهلة.
• للحصول على أداء واستقرار أفضل ، ربما يمكنك الاستفادة من العاملين في الخدمة لإدارة قائمة الانتظار حتى يمكن تحميل الأخطاء بعد إغلاق الصفحة. ولكن هل من الجرأة بعض الشيء أن تقوم مكتبة المرافق بتدوير عمال الخدمة الخاصين بها في هذه المرحلة؟

وقد بنيت هذه الوظيفة الآن بطريقة ما للغراب؟

Freundschaft لا ، ليس بعد. كما أفهمها ، سيتعين عليك الآن تجاوز الخيار transport أو استخدام shouldSendCallback لإنشاء قائمة انتظار لإرسالها لاحقًا.

cudasteve شكرا!
شخص ما حصل على تنفيذ عينة العمل؟ إذا لم يكن الأمر كذلك ، فسأحاول كتابة واحدة ونشرها هنا

Freundschaft سيكون هذا مفيدًا جدًا. نحن نواجه نفس المشكلة

++ 1 من فضلك

+1

+1

حلنا:

مرر shouldSendCallback إلى Raven init

إذا لم يكن هناك اتصال ، فإن logStorageService سيحفظ بيانات الحدث

var options = {
    ...
    shouldSendCallback: function(data) {
        if (connectionStatus.check() && Raven.isSetup()) {
            return true;
        } else {
            // store log data somewhere
            logStorageService.set(data);
            return false;
        }
    }
    ...
};

Raven.config(SENTRY_KEY, options).install();

قائمة الانتظار تحاول إرسال السجلات

تقوم قائمة الانتظار بتشغيل هذا الرمز كل 25 ثانية ، وفي النهاية يتم تسليم جميع الأحداث إلى Sentry

queue.enqueue(function () {
                    logStorageService
                        .getKeys()
                        .then(function (keys) {
                            if (keys && keys[0]) {
                                logStorageService
                                    .get(keys[0])
                                    .then(function (log) {
                                        Raven.captureMessage('', log);
                                        logStorageService.remove(keys[0]);
                                    });
                            }
                            ...
                        });
                });

أظهرت بعض الأمثلة أعلاه استدعاءً لوظيفة "خاصة". ومع ذلك ، لا يمكنني الاتصال بـ Raven._sendProcessedPayload أو Raven._send .

بالنظر إلى شفرة المصدر الخاصة بك ، فأنا لست متأكدًا حتى من كيفية إنشاء Raven () ككائن. لا أرى أغنية "Raven () الجديدة" في أي مكان.

كيف يمكنني استدعاء هذه الوظائف؟

بغض النظر ، حدثت المشكلة فقط عندما يكون raven.min.js وليس raven.js لذلك هذا السؤال يجيب.

لذلك ، بحثت عن الاسم المصغر للوظيفة _sendProcessedPayload وإليك ما انتهى بي الأمر في الكود الخاص بي (في الوقت الحالي):

  /**
   * HACK: Using a private function that gets minified!
   * Pinned Raven-js to version 3.8.1.
   */
  Raven._sendProcessedPayload = Raven._sendProcessedPayload || Raven.Y;

  ...

  function processQueue(items) {
    // Stop if we're not online.
    if (!canSend())
      return;
    // Process the given items or get them from the queue.
    items = items || queue.getItems();
    if (!items || items.length < 1)
      return;
    // First in, first out.
    var next = items.shift();
    // Send the next item.
    Raven._sendProcessedPayload(next, function processed(error) {
      // If no errors, save the queue and process more items.
      if (!error) {
        queue.save(items);
        processQueue(items);
      }
    });
  }

  function shouldSend(data) {
    if (canSend())
      return true;
    if (data.extra.retry)
      return false;
    data.extra.retry = true;
    queue.add(data);
    return false;
  }

  ...

  setInterval(processQueue, OFFLINE_QUEUE_TIMEOUT);

هذا أبعد ما يكون عن المثالية بسبب HACK الرهيب وأيضًا لأنه يمكن التقاط المزيد من الأخطاء أثناء معالجة قائمة الانتظار هذه ، لذلك سيتم إرسالها خارج الترتيب ...

ملاحظة أخيرة لهذا اليوم: أعتقد أنه يجب عليك جعل _sendProcessedPayload عامًا. يتم التقاطه بشكل صحيح حيث يخرج _send عندما يُرجع shouldSendCallback خطأ ، لذا فهو الخيار الواضح للاتصال إذا كنت تريد إعادة محاولة إرسال ...

ومع ذلك ، لا أحب أنه يعدل الحمولة. لذا ، فهي ليست الطريقة المثالية.

هل تمت إضافة هذه الميزة إلى المكتبة حتى الآن.

واجهت حاجة لهذا اليوم لأن لدي ميزة قادرة على عدم الاتصال بالإنترنت. أقوم بتخزين جميع بياناتي الخاصة باستخدام indexdb ، ولكن سيكون من الجيد أن يكون لديك وظيفة خارج الصندوق دون اتصال بالإنترنت لـ Sentry. إذا كان بإمكانه استخدام قاعدة البيانات المحلية الخاصة به لتخزين الأحداث ، وتحاول تغييرات الشبكة بشكل دوري / على الشبكة إرسال ومسح db الذي سيكون مفيدًا للغاية.

يتم تناولها هنا https://github.com/getsentry/raven-js/pull/1165

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

لا أرى أي خيار من هذا القبيل في captureException