Crashlytics से जुड़ी समस्या हल करने और अक्सर पूछे जाने वाले सवाल

आपको Firebase कंसोल में, समस्याएं टेबल में दी गई समस्याओं के लिए, दो अलग-अलग फ़ॉर्मैट दिख सकते हैं. साथ ही, आपको अपनी कुछ समस्याओं में "वैरिएंट" नाम की सुविधा भी दिख सकती है. इसकी वजह यहां बताई गई है!

साल 2023 की शुरुआत में, हमने इवेंट को ग्रुप करने के लिए बेहतर विश्लेषण इंजन के साथ-साथ, अपडेट किया गया डिज़ाइन और नई समस्याओं (जैसे, वैरिएंट!) के लिए कुछ बेहतर सुविधाएं लॉन्च की थीं. पूरी जानकारी के लिए, हमारी हाल ही की ब्लॉग पोस्ट पढ़ें. हालांकि, हाइलाइट के बारे में जानने के लिए, यहां पढ़ें.

Crashlytics आपके ऐप्लिकेशन के सभी इवेंट (जैसे, क्रैश, गैर-फ़ैटल, और ANR) का विश्लेषण करता है. साथ ही, इवेंट के ग्रुप बनाता है, जिन्हें समस्याएं कहा जाता है. किसी समस्या में मौजूद सभी इवेंट में एक ही तरह की गड़बड़ी होती है.

इवेंट को इन समस्याओं में ग्रुप करने के लिए, बेहतर विश्लेषण इंजन अब इवेंट के कई पहलुओं को देखता है. इनमें स्टैक ट्रेस में फ़्रेम, अपवाद मैसेज, गड़बड़ी कोड, और प्लैटफ़ॉर्म या गड़बड़ी के टाइप की अन्य विशेषताएं शामिल हैं.

हालांकि, इवेंट के इस ग्रुप में, गड़बड़ी की वजह से स्टैक ट्रेस अलग-अलग हो सकते हैं. अलग-अलग स्टैक ट्रेस का मतलब हो सकता है कि गड़बड़ी की मुख्य वजह अलग है. किसी समस्या में इस संभावित अंतर को दिखाने के लिए, हम अब समस्याओं में वैरिएंट बनाते हैं. हर वैरिएंट, किसी समस्या में उन इवेंट का सब-ग्रुप होता है जिनमें एक ही फ़ेल्योर पॉइंट और एक जैसा स्टैक ट्रेस होता है. वैरिएंट की मदद से, किसी समस्या में सबसे सामान्य स्टैक ट्रेस को डीबग किया जा सकता है. साथ ही, यह भी पता लगाया जा सकता है कि समस्या की वजह अलग-अलग वजहें हैं या नहीं.

इन सुधारों के बाद, आपको ये सुविधाएं मिलेंगी:

• समस्या वाली लाइन में दिखाया गया बेहतर मेटाडेटा
  अब आपके ऐप्लिकेशन में समस्याओं को समझना और उन्हें प्राथमिकता के आधार पर ठीक करना आसान हो गया है.

• डुप्लीकेट समस्याएं कम होती हैं
  लाइन नंबर में बदलाव करने से कोई नई समस्या नहीं होती.

• अलग-अलग वजहों से होने वाली मुश्किल समस्याओं को आसानी से डीबग करना
  किसी समस्या में सबसे सामान्य स्टैक ट्रेस को डीबग करने के लिए, वैरिएंट का इस्तेमाल करें.

• ज़्यादा काम की चेतावनियां और सिग्नल
  नई समस्या का मतलब है कि कोई नया बग है.

• ज़्यादा असरदार खोज
  हर समस्या में, खोजे जा सकने वाले ज़्यादा मेटाडेटा होते हैं. जैसे, अपवाद का टाइप और पैकेज का नाम.

ये सुधार इस तरह रोल आउट किए जा रहे हैं:

• जब हमें आपके ऐप्लिकेशन से नए इवेंट मिलेंगे, तो हम यह जांच करेंगे कि वे किसी मौजूदा समस्या से मेल खाते हैं या नहीं.

• अगर कोई मैच नहीं होता है, तो हम इवेंट पर अपने बेहतर इवेंट-ग्रुपिंग एल्गोरिदम को अपने-आप लागू कर देंगे. साथ ही, नए मेटाडेटा डिज़ाइन के साथ एक नई समस्या बना देंगे.

इवेंट ग्रुप करने की सुविधा में, हमने यह पहला बड़ा बदलाव किया है. अगर आपके पास कोई सुझाव/राय है या आपको कोई समस्या आ रही है, तो कृपया शिकायत दर्ज करके हमें बताएं.

अगर आपको ब्रेडक्रंब लॉग नहीं दिख रहे हैं, तो हमारा सुझाव है कि आप अपने ऐप्लिकेशन के कॉन्फ़िगरेशन में Google Analytics देखें. पक्का करें कि आपने ये ज़रूरी शर्तें पूरी की हों:

• आपने अपने Firebase प्रोजेक्ट में, Google Analytics को चालू किया हो.

• आपने Google Analytics के लिए, डेटा शेयर करने की सुविधा चालू की है. Analytics में डेटा शेयर करने की सेटिंग मैनेज करना में जाकर, इस सेटिंग के बारे में ज़्यादा जानें

• आपने अपने ऐप्लिकेशन में, . इस SDK टूल को Crashlytics SDK टूल के साथ जोड़ना ज़रूरी है.

• आपने अपने ऐप्लिकेशन में इस्तेमाल किए जाने वाले सभी प्रॉडक्ट के लिए, इस्तेमाल किए हैं.

अगर आपको वेलोसिटी से जुड़ी चेतावनियां नहीं दिख रही हैं, तो पक्का करें कि आपने

अगर आपको क्रैश-फ़्री मेट्रिक (जैसे, क्रैश-फ़्री उपयोगकर्ता और सेशन) नहीं दिख रही हैं या अविश्वसनीय मेट्रिक दिख रही हैं, तो ये देखें:

• पक्का करें कि आपने

• पक्का करें कि डेटा इकट्ठा करने की सेटिंग, क्रैश-फ़्री मेट्रिक की क्वालिटी पर असर न डाल रही हों:

  • अगर आपने क्रैश की अपने-आप होने वाली रिपोर्टिंग की सुविधा बंद करके, ऑप्ट-इन रिपोर्टिंग की सुविधा चालू की है, तो क्रैश की जानकारी सिर्फ़ उन उपयोगकर्ताओं से Crashlytics को भेजी जा सकती है जिन्होंने डेटा इकट्ठा करने की सुविधा के लिए साफ़ तौर पर ऑप्ट-इन किया है. इसलिए, क्रैश-फ़्री मेट्रिक की सटीक जानकारी पर असर पड़ेगा, क्योंकि Crashlytics के पास सिर्फ़ उन उपयोगकर्ताओं के क्रैश की जानकारी होती है जिन्होंने ऑप्ट-इन किया है, न कि सभी उपयोगकर्ताओं के क्रैश की जानकारी. इसका मतलब है कि क्रैश-फ़्री मेट्रिक भरोसेमंद नहीं हो सकतीं और इनसे आपके ऐप्लिकेशन की पूरी स्थिरता का पता नहीं चलता.

  • अगर आपने डेटा अपने-आप इकट्ठा होने की सुविधा बंद की है, तो डिवाइस पर कैश मेमोरी में सेव की गई रिपोर्ट को Crashlytics पर भेजने के लिए, sendUnsentReports का इस्तेमाल किया जा सकता है. इस तरीके का इस्तेमाल करने पर, Crashlytics को क्रैश डेटा भेजा जाएगा, लेकिन सेशन डेटा नहीं. इस वजह से, क्रैश-फ़्री मेट्रिक के लिए, कंसोल चार्ट में कम या शून्य वैल्यू दिखती हैं.

क्रैश-फ़्री मेट्रिक को समझना लेख पढ़ें.

नोट की मदद से, प्रोजेक्ट के सदस्य किसी खास समस्या के बारे में सवाल पूछ सकते हैं, स्टेटस के बारे में अपडेट दे सकते हैं वगैरह.

जब कोई प्रोजेक्ट में शामिल व्यक्ति कोई नोट पोस्ट करता है, तो उसे उसके Google खाते के ईमेल पते से लेबल किया जाता है. यह ईमेल पता, नोट के साथ उन सभी प्रोजेक्ट सदस्यों को दिखता है जिनके पास नोट देखने का ऐक्सेस है.

यहां बताया गया है कि नोट देखने, लिखने, और मिटाने के लिए, किस तरह का ऐक्सेस ज़रूरी है:

• प्रोजेक्ट के जिन सदस्यों के पास इनमें से कोई भी भूमिका है वे मौजूदा नोट देख सकते हैं और उन्हें मिटा सकते हैं. साथ ही, किसी समस्या के बारे में नए नोट लिख सकते हैं.

  • प्रोजेक्ट का मालिक या एडिटर, Firebase एडमिन, क्वालिटी एडमिन या Crashlytics एडमिन

• प्रोजेक्ट के जिन सदस्यों के पास इनमें से कोई भूमिका है वे किसी समस्या पर पोस्ट किए गए नोट देख सकते हैं. हालांकि, वे नोट को मिटा या लिख नहीं सकते.

  • प्रोजेक्ट व्यूअर, Firebase व्यूअर, क्वालिटी व्यूअर या Crashlytics व्यूअर

अगर आपका प्रोजेक्ट Google Mobile Ads SDK टूल के साथ-साथ Crashlytics का इस्तेमाल करता है, तो हो सकता है कि अपवाद हैंडलर को रजिस्टर करते समय, क्रैश रिपोर्टर रुकावट डाल रहे हों. इस समस्या को ठीक करने के लिए, disableSDKCrashReporting को कॉल करके Mobile Ads SDK टूल में क्रैश रिपोर्टिंग की सुविधा बंद करें.

Crashlytics को BigQuery से लिंक करने के बाद, आपके बनाए गए नए डेटासेट अपने-आप अमेरिका में सेव हो जाते हैं. भले ही, आपके Firebase प्रोजेक्ट की लोकेशन कुछ भी हो.

जब आपने पहले ही समस्या को बंद कर दिया हो, लेकिन Crashlytics को एक नई रिपोर्ट मिले कि समस्या फिर से आ गई है, तो समस्या फिर से आ गई है. Crashlytics, इन समस्याओं को अपने-आप फिर से खोलता है, ताकि आप अपने ऐप्लिकेशन के हिसाब से इनका समाधान कर सकें.

यहां एक उदाहरण दिया गया है, जिसमें बताया गया है कि Crashlytics किसी समस्या को रिग्रेशन के तौर पर कैसे कैटगरी में बांटता है:

1. Crashlytics को पहली बार, क्रैश "A" के बारे में क्रैश रिपोर्ट मिलती है. Crashlytics उस क्रैश से जुड़ी समस्या (समस्या "A") खोलता है.
2. आपने इस गड़बड़ी को तुरंत ठीक कर दिया, "A" समस्या को बंद कर दिया, और फिर अपने ऐप्लिकेशन का नया वर्शन रिलीज़ कर दिया.
3. समस्या को बंद करने के बाद, Crashlytics को "A" समस्या के बारे में एक और शिकायत मिलती है.
   • अगर रिपोर्ट किसी ऐसे ऐप्लिकेशन वर्शन से है जिसके बारे में Crashlytics को पहले से पता था, तो Crashlytics उस समस्या को फिर से होने वाली समस्या के तौर पर नहीं लेगा. इसका मतलब है कि उस वर्शन ने किसी भी क्रैश के लिए क्रैश रिपोर्ट भेजी थी. समस्या बंद रहेगी.
   • अगर रिपोर्ट किसी ऐसे ऐप्लिकेशन वर्शन से मिली है जिसके बारे में Crashlytics नहीं जानता था, तो Crashlytics यह मान लेगा कि समस्या फिर से आ गई है और वह समस्या को फिर से खोल देगा.

जब कोई समस्या फिर से दिखने लगती है, तो हम आपको इसकी सूचना देते हैं. साथ ही, समस्या के लिए एक रिग्रेशन सिग्नल जोड़ते हैं. इससे आपको पता चलता है कि Crashlytics ने समस्या को फिर से खोला है. अगर आपको हमारे रिग्रेशन एल्गोरिदम की वजह से, किसी समस्या को फिर से खोलना नहीं है, तो उसे बंद करने के बजाय "म्यूट" करें.

अगर कोई रिपोर्ट ऐप्लिकेशन के किसी पुराने वर्शन से है और आपने समस्या को ठीक करने के बाद, उस वर्शन से कभी भी क्रैश की कोई रिपोर्ट नहीं मिली है, तो Crashlytics को लगता है कि समस्या फिर से आ गई है. ऐसे में, वह समस्या को फिर से खोल देगा.

यह स्थिति तब हो सकती है, जब आपने किसी गड़बड़ी को ठीक करके, अपने ऐप्लिकेशन का नया वर्शन रिलीज़ कर दिया हो, लेकिन आपके ऐप्लिकेशन के पुराने वर्शन का इस्तेमाल करने वाले उपयोगकर्ता अब भी उस गड़बड़ी से परेशान हों. अगर आपने समस्या को ठीक करने के बाद, उनमें से किसी पुराने वर्शन से कभी क्रैश की कोई रिपोर्ट नहीं भेजी है और उन उपयोगकर्ताओं को गड़बड़ी का सामना करना पड़ता है, तो उन क्रैश रिपोर्ट से, पहले से मौजूद समस्या फिर से ट्रिगर हो जाएगी.

अगर आपको हमारे रेग्रेशन एल्गोरिदम की वजह से, किसी समस्या को फिर से खोलना नहीं है, तो उसे बंद करने के बजाय "म्यूट" करें.