Sentry-javascript: ऑफ़लाइन रिपोर्टिंग के लिए निर्देश?

क्या आप पता लगा सकते हैं कि उपयोगकर्ता ऑफ़लाइन है या नहीं?

यदि ऐसा है, तो घटनाओं को एकत्र करना और उन्हें कतारबद्ध करना असंभव नहीं होगा। जब उपयोगकर्ता वापस ऑनलाइन हो जाता है, तो उन्हें फिर से Raven.captureException माध्यम से भेजें।

मैं शायद इसमें मदद कर सकता हूं कि यह कैसे काम करेगा या इसमें मदद करने के लिए एक हुक जोड़ सकता है।

बढ़िया, सहयोग के लिए धन्यवाद। मैं उपयोगकर्ता को ऑनलाइन होने का पता लगा सकता था, यहां तक ​​​​कि केवल संतरी पहुंच योग्यता का परीक्षण भी कर सकता था। इसके लिए मैं ट्रांसमिशन विफलता की घटनाओं को सुन सकता था, लेकिन फिर कैसे पुनः प्रयास करें?

captureException का उपयोग करने के बारे में, यह ठीक होगा, लेकिन मैं उत्कृष्ट हैंडलर रेवेन को अनचाहे अपवादों के लिए प्रदान करना चाहता हूं। मुझे रेवेन त्रुटि का पता लगाने और त्रुटि संचरण के बीच कुछ मध्य तर्क जोड़ने की आवश्यकता होगी

हाँ, लेम्मे इस बारे में सोचें। मुझे लगता है कि एक अच्छा तरीका है कि हम या तो इसे रेवेन-जेएस में स्वचालित रूप से समर्थन दे सकते हैं, या इसे करने के लिए एक हुक प्रदान कर सकते हैं। मुझे लगता है कि यह उचित है।

मैं भी वही कार्यक्षमता की तलाश में हूं। दस्तावेज़ों की जांच करने के बाद ऐसा लगता है कि 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. उन तरीकों का वादा करना (मेह)
4. विफलता पर घटनाओं को ट्रिगर करना (कहां?) और उस घटना को फिर से भेजने का प्रयास करने के लिए घटना डेटा में पर्याप्त संदर्भ प्रदान करना

आपके पास संभवतः एक ऑफ़लाइन संग्रहण सुविधा होनी चाहिए ताकि त्रुटि संदेश बाद में समय पर भेजे जा सकें। संभवत: उपयोगकर्ता द्वारा ऐप को बंद करने और बाद में ऑनलाइन रहते हुए इसे फिर से खोलने के बाद भी। "ऑफ़लाइन पहले" दृष्टिकोण के समान:
http://offlinefirst.org/

मुझे एक ही मुद्दे का सामना करना पड़ा है। सबसे पहले, मैं इसे उसी तरह हल करना चाहता था जैसे मैं एक सेवा कार्यकर्ता के साथ ऑफ़लाइन google-analytics समस्या को कैसे हल कर रहा हूं। 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 से सहमत हूं। मैं वास्तव में थोड़ा आश्चर्यचकित था कि यह पहले से ही रेवेन का हिस्सा नहीं था क्योंकि यह कई अन्य अच्छे तरीकों से बहुत प्रभावशाली है। किसी ऐप के आर्किटेक्चर के आधार पर, संभावित रूप से त्रुटियों का एक गैर-तुच्छ प्रतिशत हो सकता है जो ऑफ़लाइन होने का परिणाम है। बहुत सारे कार्यान्वयन में उन पर रिपोर्ट करने में सक्षम होना बहुत महत्वपूर्ण है।

तो मेरा वोट यह है कि इसे बेक किया जाना चाहिए और स्वचालित होना चाहिए। जब संतरी को संदेश भेजने में कोई त्रुटि होती है, तो संदेश को संग्रहीत किया जाना चाहिए और बाद में पुन: प्रयास किया जाना चाहिए (या तो टाइमर पर, किसी ईवेंट पर, या यहां तक ​​कि केवल अगले संदेश प्रसारण पर यदि आप इसे सरल रखना चाहते हैं)।

साथ ही, "डीडीएन" लेबल का क्या अर्थ है?

मैं वास्तव में थोड़ा आश्चर्यचकित था कि यह पहले से ही रेवेन का हिस्सा नहीं था क्योंकि यह कई अन्य अच्छे तरीकों से बहुत प्रभावशाली है। किसी ऐप के आर्किटेक्चर के आधार पर, संभावित रूप से त्रुटियों का एक गैर-तुच्छ प्रतिशत हो सकता है जो ऑफ़लाइन होने का परिणाम है।

एकदम निष्पक्ष। लेकिन मुझे यकीन नहीं है कि इसे डिफ़ॉल्ट रूप से किया जाना चाहिए। ऐसे कई परिदृश्य हैं जहां, यदि कोई स्क्रिप्ट लोड नहीं होती है, तो ऐप काम नहीं करेगा चाहे कुछ भी हो। और मैं कहूंगा कि ज्यादातर ऐप सीधे-सीधे ऑफ़लाइन काम नहीं करते हैं, और उम्मीद नहीं करते हैं। यह अच्छा अभ्यास है या नहीं यह दूसरी बात है।

यह इस प्रकार है कि हम डिफ़ॉल्ट रूप से AJAX त्रुटियों को लॉग क्यों नहीं करते हैं, भले ही रेवेन उपयोगकर्ताओं के एक अच्छे हिस्से ने ऐसा करने के लिए कोड लिखा हो। लेकिन हम इसे आसान बनाने की कोशिश करेंगे _यदि आप चाहते हैं_। और मैं यहां वही काम करना चाहूंगा।

साथ ही, "डीडीएन" लेबल का क्या अर्थ है?

पक्का नहीं। @mattrobenolt?

डिजाइन निर्णय की जरूरत है। :)

मुझे यकीन नहीं है कि इसे डिफ़ॉल्ट रूप से किया जाना चाहिए।

हां यह समझ में आता है।

लेकिन अगर आप चाहें तो हम इसे आसान बनाने की कोशिश करेंगे। और मैं यहां वही काम करना चाहूंगा।

इसलिए, डिज़ाइन निर्णय लेने में मदद करने के हित में, यहाँ कुछ विचार दिए गए हैं:

अगर मैं दस्तावेज़ों को सही ढंग से समझ रहा हूं, तो transport कॉन्फ़िगरेशन विकल्प मूल रूप से पाइपलाइन के अंतिम भाग को नियंत्रित करने की अनुमति देता है जहां संतरी सर्वर को डेटा भेजता है और उस संचरण को करने के लिए जिम्मेदार हो जाता है। उस स्थिति में, यह ऑफ़लाइन कतार प्लग इन करने के लिए सबसे अच्छी जगह की तरह लगता है। सर्वर को डेटा भेजने के बजाय, इसे एक कतार में भेजें जो सर्वर पर पृष्ठभूमि में अपलोड हो। ऐसा तब होगा जब कोई ऐसा करने के लिए अपना कोड लिख रहा हो।

इसी तरह, क्या एक कॉन्फ़िगरेशन विकल्प ( includeOffline ?)

• ब्राउज़र संगतता के लिए, शायद कतार को स्थानीय स्टोरेज में संग्रहीत करें और इसे टाइमआउट पर कनेक्शन की जांच करें।
• बेहतर प्रदर्शन और स्थिरता के लिए, शायद सेवा कर्मचारियों को कतार का प्रबंधन करने के लिए लाभ उठाएं ताकि पृष्ठ बंद होने के बाद भी त्रुटियां अपलोड की जा सकें। लेकिन क्या इस बिंदु पर एक उपयोगिता पुस्तकालय के लिए अपने स्वयं के सेवा कर्मियों को कताई करना थोड़ा अभिमान है?

क्या यह कार्यक्षमता अब किसी तरह रेवेन में बनाई गई है?

@Freundschaft नहीं, अभी नहीं। जैसा कि मैं इसे समझता हूं, अभी के लिए आपको transport विकल्प को ओवरराइड करना होगा या बाद में भेजने के लिए एक कतार बनाने के लिए shouldSendCallback करना होगा।

@cudasteve धन्यवाद!
किसी को एक कामकाजी नमूना कार्यान्वयन मिला है? यदि नहीं तो मैं एक लिखने और इसे यहाँ पोस्ट करने का प्रयास करूँगा

@Freundschaft यह बहुत मददगार होगा। हम एक ही समस्या का सामना कर रहे हैं

++1 कृपया

+1

+1

हमारा समाधान:

रेवेन init . को shouldSendCallback करें

यदि कोई कनेक्शन नहीं है, तो 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 सेकंड में इस कोड को सक्रिय करती है, अंततः संतरी को सभी ईवेंट वितरित करती है

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.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);

यह भयानक हैक के कारण आदर्श से बहुत दूर है और इसलिए भी कि जब मैं इस कतार को संसाधित कर रहा हूं, तो अधिक त्रुटियां पकड़ी जा सकती हैं, इसलिए उन्हें क्रम से बाहर भेज दिया जाएगा ...

आज के लिए इस पर अंतिम नोट: मुझे लगता है कि आपको _sendProcessedPayload सार्वजनिक करना चाहिए। जब shouldSendCallback झूठी वापसी करता है, तो यह ठीक वहीं से शुरू होता है, जहां से _send बाहर निकलता है, इसलिए यदि आप किसी भेजने का फिर से प्रयास करना चाहते हैं तो कॉल करना स्पष्ट विकल्प है...

हालांकि, मुझे यह पसंद नहीं है कि यह पेलोड को संशोधित करता है। तो, यह आदर्श तरीका नहीं है।

क्या यह सुविधा अभी तक पुस्तकालय में जोड़ी गई है।

मुझे आज इसकी आवश्यकता पड़ी क्योंकि मेरे पास एक ऑफ़लाइन सक्षम सुविधा है। मैं indexdb का उपयोग करके अपना सारा डेटा संग्रहीत करता हूं लेकिन संतरी के लिए ऑफ़लाइन कार्यक्षमता से बाहर होना अच्छा होगा। यदि यह घटनाओं को संग्रहीत करने के लिए अपने स्वयं के स्थानीय डेटाबेस का उपयोग कर सकता है और समय-समय पर/नेटवर्क परिवर्तनों पर डीबी को भेजने और साफ़ करने का प्रयास करता है जो सुपर उपयोगी होगा।

यहां संबोधित किया गया https://github.com/getsentry/raven-js/pull/1165

अगर मैं ऑनलाइन आने पर बाद में भेजने के लिए अपवाद संग्रहीत करता हूं, तो क्या मेरे लिए अपवादों पर टाइमस्टैम्प सेट करने का कोई तरीका है कि यह इंगित करने के लिए कि वे अब नहीं हुए जब मैं उन्हें संतरी को भेज रहा हूं, लेकिन किसी बिंदु पर भूतकाल? मुझे लगता है कि मैं इसे अतिरिक्त में जोड़ सकता हूं, लेकिन वास्तविक टाइमस्टैम्प सेट करने में सक्षम होना अच्छा होगा।

मुझे captureException में ऐसा कोई विकल्प नहीं दिख रहा है