ज़्यादा विश्लेषण के लिए, अपने Firebase Crashlytics डेटा को BigQuery में एक्सपोर्ट किया जा सकता है. BigQuery की मदद से, BigQuery SQL का इस्तेमाल करके डेटा का विश्लेषण किया जा सकता है. साथ ही, उसे किसी दूसरे क्लाउड सेवा देने वाली कंपनी के पास एक्सपोर्ट किया जा सकता है. इसके अलावा, Google Data Studio में विज़ुअलाइज़ेशन और कस्टम डैशबोर्ड के लिए भी इसका इस्तेमाल किया जा सकता है.
BigQuery में एक्सपोर्ट करने की सुविधा चालू करना
Firebase कंसोल में, इंटिग्रेशन पेज पर जाएं.
BigQuery कार्ड में, लिंक करें पर क्लिक करें.
BigQuery में एक्सपोर्ट करने की सुविधा चालू करने के लिए, स्क्रीन पर दिए गए निर्देशों का पालन करें.
अगर आपको BigQuery में अपने Crashlytics डेटा को रीयल-टाइम में ऐक्सेस करना है, तो स्ट्रीमिंग एक्सपोर्ट पर अपग्रेड करें.
एक्सपोर्ट करने की सुविधा चालू करने पर क्या होता है?
आपने डेटासेट की जगह चुनी है. डेटासेट बनाने के बाद, उसकी जगह को बदला नहीं जा सकता. हालांकि, डेटासेट को किसी दूसरी जगह पर कॉपी किया जा सकता है या मैन्युअल तरीके से किसी दूसरी जगह पर ले जाया जा सकता है, यानी कि इसे फिर से बनाया जा सकता है. ज़्यादा जानने के लिए, मौजूदा एक्सपोर्ट की जगह बदलना लेख पढ़ें.
यह जगह सिर्फ़ BigQuery में एक्सपोर्ट किए गए डेटा पर लागू होती है. साथ ही, इससे Firebase कंसोल के Crashlytics डैशबोर्ड या Android Studio में इस्तेमाल के लिए सेव किए गए डेटा की जगह पर कोई असर नहीं पड़ता.
आपके प्रोजेक्ट के सभी ऐप्लिकेशन डिफ़ॉल्ट रूप से, BigQuery से लिंक होते हैं. साथ ही, बाद में प्रोजेक्ट में जोड़े जाने वाले ऐप्लिकेशन भी अपने-आप BigQuery से लिंक कर दिए जाते हैं. आपके पास BigQuery में डेटा भेजने वाले ऐप्लिकेशन चुनने का विकल्प होता है.
Firebase, आपके डेटा को BigQuery के साथ हर दिन सिंक करने की सुविधा सेट अप करता है.
प्रोजेक्ट को लिंक करने के बाद, आम तौर पर आपको अगले दिन के सिंक होने तक इंतज़ार करना होगा, ताकि आपके डेटा का पहला सेट BigQuery में एक्सपोर्ट किया जा सके.
डेटा हर दिन एक बार सिंक होता है. भले ही, आपने BigQuery में शेड्यूल किया गया कोई भी एक्सपोर्ट सेट अप किया हो. ध्यान दें कि सिंक करने के लिए शेड्यूल किए गए काम के समय और अवधि में बदलाव हो सकता है. इसलिए, हमारा सुझाव है कि एक्सपोर्ट के लिए तय किए गए समय के आधार पर, डाउनस्ट्रीम ऑपरेशन या जॉब शेड्यूल न करें.
Firebase, BigQuery पर आपके मौजूदा डेटा की कॉपी एक्सपोर्ट करता है. एक्सपोर्ट के लिए डेटा का शुरुआती प्रॉपेगेशन होने में 48 घंटे लग सकते हैं.
लिंक किए गए हर ऐप्लिकेशन के लिए, इस एक्सपोर्ट में एक बैच टेबल शामिल होती है. इसमें हर दिन सिंक किए गए डेटा की जानकारी होती है.
आपके पास, BigQuery में डेटा एक्सपोर्ट करने की सुविधा चालू करने के बाद, बैच टेबल के लिए डेटा बैकफ़िल को मैन्युअल तौर पर शेड्यूल करने का विकल्प होता है. यह शेड्यूल, पिछले 30 दिनों तक की डेटा बैच टेबल के लिए या उस तारीख के लिए किया जा सकता है जिस दिन आपने BigQuery में डेटा एक्सपोर्ट करने की सुविधा चालू की थी.
ध्यान दें कि अगर आपने Crashlytics डेटा को एक्सपोर्ट करने की सुविधा, अक्टूबर 2024 के मध्य से पहले चालू की थी, तो डेटा एक्सपोर्ट करने की सुविधा चालू करने से 30 दिन पहले का डेटा भी बैकफ़िल किया जा सकता है.
अगर आपने Crashlytics से BigQuery पर स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू की है, तो लिंक किए गए सभी ऐप्लिकेशन में एक रीयल-टाइम टेबल भी होगी. इसमें लगातार अपडेट होने वाला डेटा शामिल होगा.
BigQuery पर डेटा एक्सपोर्ट करने की सुविधा बंद करने के लिए, Firebase कंसोल में जाकर, अपने प्रोजेक्ट को अनलिंक करें.
BigQuery में कौनसा डेटा एक्सपोर्ट किया जाता है?
Firebase Crashlytics डेटा को BigQuery नाम वाले firebase_crashlytics डेटासेट में एक्सपोर्ट किया जाता है. डिफ़ॉल्ट रूप से, आपके प्रोजेक्ट में मौजूद हर ऐप्लिकेशन के लिए, Crashlytics डेटासेट में अलग-अलग टेबल बनाई जाएंगी. Firebase, टेबल को ऐप्लिकेशन के आइडेंटिफ़ायर के आधार पर नाम देता है. इसमें पीरियड को अंडरस्कोर में बदल दिया जाता है और आखिर में प्लैटफ़ॉर्म का नाम जोड़ दिया जाता है.
उदाहरण के लिए, com.google.test नाम वाले पैकेज वाले Android ऐप्लिकेशन का डेटा, com_google_test_ANDROID नाम वाली टेबल में होगा. इस बैच टेबल को हर दिन एक बार अपडेट किया जाता है. अगर Crashlytics को BigQuery में स्ट्रीमिंग एक्सपोर्ट करने की सुविधा चालू की जाती है, तो Crashlytics का डेटा com_google_test_ANDROID_REALTIME नाम की टेबल में रीयल टाइम में स्ट्रीम किया जाएगा.
टेबल की हर लाइन, ऐप्लिकेशन में हुए किसी इवेंट के बारे में बताती है. इसमें, ऐप्लिकेशन बंद होने की समस्याएं, गड़बड़ियां, और ANR शामिल हैं.
Crashlytics BigQuery में स्ट्रीमिंग एक्सपोर्ट
BigQuery स्ट्रीमिंग की मदद से, Crashlytics डेटा को रीयल टाइम में स्ट्रीम किया जा सकता है. इसका इस्तेमाल, लाइव डेटा की ज़रूरत वाले किसी भी काम के लिए किया जा सकता है. जैसे, लाइव डैशबोर्ड में जानकारी दिखाना, रोल आउट को लाइव देखना या चेतावनियों और कस्टम वर्कफ़्लो को ट्रिगर करने वाली ऐप्लिकेशन की समस्याओं को मॉनिटर करना.
Crashlytics BigQuery में स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू करने पर, बैच टेबल के साथ-साथ आपके पास रीयल टाइम टेबल भी होगी. यहां टेबल के बीच के उन अंतरों के बारे में बताया गया है जिनके बारे में आपको पता होना चाहिए:
| बैच टेबल | रीयलटाइम टेबल |
|---|---|
|
|
बैच टेबल, लंबे समय तक के विश्लेषण और समय के साथ रुझानों की पहचान करने के लिए बेहतरीन है. ऐसा इसलिए, क्योंकि हम इवेंट को लिखने से पहले उन्हें सुरक्षित तरीके से सेव करते हैं. साथ ही, इन्हें 30 दिनों तक टेबल में बैकफ़िल किया जा सकता है*. जब हम आपकी रीयल टाइम टेबल में डेटा डालते हैं, तो हम उसे तुरंत BigQuery में डाल देते हैं. इसलिए, यह लाइव डैशबोर्ड और कस्टम सूचनाओं के लिए सबसे सही है. इन दोनों टेबल के फ़ायदे पाने के लिए, इन्हें स्टिचिंग क्वेरी के साथ जोड़ा जा सकता है.
डिफ़ॉल्ट रूप से, रीयल टाइम टेबल में सेक्शन की समयसीमा 30 दिन होती है. इसमें बदलाव करने का तरीका जानने के लिए, BigQuery दस्तावेज़ में पार्टिशन की समयसीमा सेट करना देखें.
* एक्सपोर्ट के नए इन्फ़्रास्ट्रक्चर पर अपग्रेड करें में, बैकफ़िल की सहायता के बारे में जानकारी देखें.
Crashlytics से BigQuery पर स्ट्रीमिंग एक्सपोर्ट करने की सुविधा चालू करना
Firebase कंसोल में, इंटिग्रेशन पेज पर जाएं.
BigQuery कार्ड में, मैनेज करें पर क्लिक करें.
स्ट्रीमिंग शामिल करें चेकबॉक्स को चुनें.
ऐसा करने से, लिंक किए गए सभी ऐप्लिकेशन के लिए स्ट्रीमिंग की सुविधा चालू हो जाती है.
एक्सपोर्ट किए गए डेटा का क्या किया जा सकता है?
BigQuery में एक्सपोर्ट किए गए डेटा में, क्रैश का रॉ डेटा शामिल होता है. इसमें डिवाइस टाइप, ऑपरेटिंग सिस्टम, अपवाद (Android ऐप्लिकेशन) या गड़बड़ियां (Apple ऐप्लिकेशन), और Crashlytics लॉग के साथ-साथ अन्य डेटा भी शामिल होता है.
इस पेज पर आगे जाकर, देखें कि Crashlytics डेटा का कौनसा हिस्सा एक्सपोर्ट किया गया है और उसकी टेबल का स्कीमा क्या है.
Data Studio टेंप्लेट का इस्तेमाल करना
अपने Data Studio टेंप्लेट में रीयल टाइम डेटा चालू करने के लिए, Data Studio की मदद से, एक्सपोर्ट किए गए Crashlytics डेटा को विज़ुअलाइज़ करना में दिए गए निर्देशों का पालन करें.
व्यू बनाना
BigQuery यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके, क्वेरी को व्यू में बदला जा सकता है. ज़्यादा जानकारी के लिए, BigQuery दस्तावेज़ में व्यू बनाना देखें.
क्वेरी चलाना
यहां दिए गए उदाहरणों में ऐसी क्वेरी दिखाई गई हैं जिन्हें अपने Crashlytics डेटा पर चलाया जा सकता है. इससे, क्रैश इवेंट के डेटा को आसानी से समझी जा सकने वाली खास जानकारी में एग्रीगेट करने वाली रिपोर्ट जनरेट की जा सकती हैं. इस तरह की रिपोर्ट, Firebase कंसोल के Crashlytics डैशबोर्ड में उपलब्ध नहीं होती हैं. इसलिए, ये रिपोर्ट क्रैश डेटा के विश्लेषण और उसे समझने में मदद कर सकती हैं.
पहला उदाहरण: दिन के हिसाब से क्रैश
ज़्यादा से ज़्यादा गड़बड़ियों को ठीक करने के बाद, आपको लगता है कि आपकी टीम अब फ़ोटो शेयर करने वाला नया ऐप्लिकेशन लॉन्च करने के लिए तैयार है. हालांकि, ऐसा करने से पहले आपको पिछले महीने के लिए, हर दिन ऐप्लिकेशन के क्रैश होने की संख्या देखनी है. इससे आपको यह पक्का करने में मदद मिलेगी कि गड़बड़ियों को ठीक करने की प्रोसेस के बाद, ऐप्लिकेशन अब ज़्यादा बेहतर तरीके से काम कर रहा है.
यहां Android ऐप्लिकेशन के लिए क्वेरी का उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, पैकेज के नाम और ANDROID के बजाय, उसके बंडल आईडी और IOS का इस्तेमाल करें.
SELECT COUNT(DISTINCT event_id) AS number_of_crashes, FORMAT_TIMESTAMP("%F", event_timestamp) AS date_of_crashes FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` GROUP BY date_of_crashes ORDER BY date_of_crashes DESC LIMIT 30;
दूसरा उदाहरण: सबसे ज़्यादा क्रैश करने वाले ऐप्लिकेशन ढूंढना
आपको अपने ऐप्लिकेशन में सबसे ज़्यादा होने वाले 10 क्रैश की जानकारी चाहिए, ताकि आप प्रोडक्शन प्लान को प्राथमिकता दे सकें. इसके लिए, आपने ऐसी क्वेरी बनाई है जो डेटा के काम के पॉइंट देती है.
यहां Android ऐप्लिकेशन के लिए क्वेरी का उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, पैकेज के नाम और ANDROID के बजाय, उसके बंडल आईडी और IOS का इस्तेमाल करें.
SELECT DISTINCT issue_id, COUNT(DISTINCT event_id) AS number_of_crashes, COUNT(DISTINCT installation_uuid) AS number_of_impacted_user, blame_frame.file, blame_frame.line FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` WHERE event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(),INTERVAL 168 HOUR) AND event_timestamp < CURRENT_TIMESTAMP() GROUP BY issue_id, blame_frame.file, blame_frame.line ORDER BY number_of_crashes DESC LIMIT 10;
तीसरा उदाहरण: क्रैश होने वाले टॉप 10 डिवाइस
फ़ॉल सीज़न में नए फ़ोन खरीदने का मौका! आपकी कंपनी को पता है कि इसका मतलब यह भी है कि डिवाइस से जुड़ी नई समस्याओं का सीज़न शुरू हो गया है. खास तौर पर, Android के लिए. डिवाइस के साथ काम करने से जुड़ी समस्याओं से पहले से निपटने के लिए, आपने एक क्वेरी बनाई है. इससे उन 10 डिवाइसों की पहचान की जा सकती है जिन पर पिछले हफ़्ते (168 घंटे) में सबसे ज़्यादा क्रैश हुए.
यहां Android ऐप्लिकेशन के लिए क्वेरी का उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, पैकेज के नाम और ANDROID के बजाय, उसके बंडल आईडी और IOS का इस्तेमाल करें.
SELECT device.model, COUNT(DISTINCT event_id) AS number_of_crashes FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` WHERE event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR) AND event_timestamp < CURRENT_TIMESTAMP() GROUP BY device.model ORDER BY number_of_crashes DESC LIMIT 10;
चौथा उदाहरण: कस्टम बटन के हिसाब से फ़िल्टर करना
आप एक गेम डेवलपर हैं और आपको यह जानना है कि आपके गेम के किस लेवल में सबसे ज़्यादा क्रैश आते हैं.
उस आंकड़े को ट्रैक करने के लिए, current_level नाम की एक कस्टम Crashlytics कुंजी सेट की जाती है. साथ ही, हर बार जब उपयोगकर्ता किसी नए लेवल पर पहुंचता है, तो उसे अपडेट किया जाता है.
Swift
Crashlytics.sharedInstance().setIntValue(3, forKey: "current_level");
Objective-C
CrashlyticsKit setIntValue:3 forKey:@"current_level";
Java
Crashlytics.setInt("current_level", 3);
BigQuery में एक्सपोर्ट करने के लिए, उस कुंजी का इस्तेमाल करके, हर क्रैश इवेंट से जुड़ी current_level वैल्यू के डिस्ट्रिब्यूशन की रिपोर्ट करने के लिए क्वेरी लिखी जा सकती है.
यहां Android ऐप्लिकेशन के लिए क्वेरी का उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, पैकेज के नाम और ANDROID के बजाय, उसके बंडल आईडी और IOS का इस्तेमाल करें.
SELECT
COUNT(DISTINCT event_id) AS num_of_crashes,
value
FROM
`PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
UNNEST(custom_keys)
WHERE
key = "current_level"
GROUP BY
key,
value
ORDER BY
num_of_crashes DESCपांचवां उदाहरण: यूज़र आईडी निकालना
आपके पास Android ऐप्लिकेशन का रिलीज़ होने से पहले इस्तेमाल करने का विकल्प है. आपके ज़्यादातर उपयोगकर्ताओं को यह पसंद आया, लेकिन तीन उपयोगकर्ताओं को ऐप्लिकेशन क्रैश होने की समस्या का सामना करना पड़ा. समस्या की पूरी जानकारी पाने के लिए, एक क्वेरी लिखी जाती है. यह क्वेरी, उन उपयोगकर्ताओं के यूज़र आईडी का इस्तेमाल करके, उनके सभी क्रैश इवेंट को खींचती है.
यहां Android ऐप्लिकेशन के लिए क्वेरी का उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, पैकेज के नाम और ANDROID के बजाय, उसके बंडल आईडी और IOS का इस्तेमाल करें.
SELECT *
FROM
`PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
user.id IN ("USER_ID_1", "USER_ID_2", "USER_ID_3")
ORDER BY
user.id
छठा उदाहरण: क्रैश से जुड़ी किसी खास समस्या का सामना कर रहे सभी उपयोगकर्ताओं को ढूंढना
आपकी टीम ने गलती से, बीटा टेस्टर के ग्रुप को एक गंभीर बग रिलीज़ कर दिया है. आपकी टीम, क्रैश की समस्या के आईडी की पहचान करने के लिए, ऊपर दिए गए "सबसे ज़्यादा क्रैश होने की समस्या ढूंढें" उदाहरण में दी गई क्वेरी का इस्तेमाल कर पाई. अब आपकी टीम को ऐप्लिकेशन के उन उपयोगकर्ताओं की सूची निकालने के लिए क्वेरी चलानी है जिन पर इस क्रैश का असर पड़ा है.
यहां Android ऐप्लिकेशन के लिए क्वेरी का उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, पैकेज के नाम और ANDROID के बजाय, उसके बंडल आईडी और IOS का इस्तेमाल करें.
SELECT user.id as user_id
FROM
`PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
issue_id = "ISSUE_ID"
AND application.display_version = "APP_VERSION"
AND user.id != ""
ORDER BY
user.id;सातवां उदाहरण: ऐप्लिकेशन बंद होने की समस्या का असर जिन उपयोगकर्ताओं पर पड़ा उनकी संख्या, देश के हिसाब से बांटी गई
आपकी टीम को नई रिलीज़ रोल आउट करने के दौरान, एक गंभीर गड़बड़ी का पता चला है. क्रैश की समस्या से जुड़े आईडी की पहचान करने के लिए, आपने ऊपर दिए गए "सबसे ज़्यादा क्रैश होने की समस्या ढूंढें" उदाहरण में दी गई क्वेरी का इस्तेमाल किया. आपकी टीम अब यह देखना चाहेगी कि क्या यह क्रैश, दुनिया भर के अलग-अलग देशों में मौजूद उपयोगकर्ताओं को भी हुआ है.
यह क्वेरी लिखने के लिए, आपकी टीम को ये काम करने होंगे:
Google Analytics के डेटा को BigQuery में एक्सपोर्ट करने की सुविधा चालू करें. BigQuery में प्रोजेक्ट का डेटा एक्सपोर्ट करना लेख पढ़ें.
Google Analytics SDK टूल और Crashlytics SDK टूल, दोनों में उपयोगकर्ता आईडी पास करने के लिए, अपने ऐप्लिकेशन को अपडेट करें.
Swift
Crashlytics.sharedInstance().setUserIdentifier("123456789"); Analytics.setUserID("123456789");Objective-C
CrashlyticsKit setUserIdentifier:@"123456789"; FIRAnalytics setUserID:@"12345678 9";Java
Crashlytics.setUserIdentifier("123456789"); mFirebaseAnalytics.setUserId("123456789");ऐसी क्वेरी लिखें जो Google Analytics डेटासेट के इवेंट को Crashlytics डेटासेट के क्रैश से जोड़ने के लिए, यूज़र आईडी फ़ील्ड का इस्तेमाल करती हो.
यहां Android ऐप्लिकेशन के लिए क्वेरी का उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, पैकेज के नाम और
ANDROIDके बजाय, उसके बंडल आईडी औरIOSका इस्तेमाल करें.SELECT DISTINCT c.issue_id, a.geo.country, COUNT(DISTINCT c.user.id) as num_users_impacted FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` c INNER JOIN `PROJECT_ID.analytics_TABLE_NAME.events_*` a on c.user.id = a.user_id WHERE c.issue_id = "ISSUE_ID" AND a._TABLE_SUFFIX BETWEEN '20190101' AND '20200101' GROUP BY c.issue_id, a.geo.country, c.user.id
आठवां उदाहरण: आज तक की पांच सबसे बड़ी समस्याएं
यहां Android ऐप्लिकेशन के लिए क्वेरी का उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, पैकेज के नाम और ANDROID के बजाय, उसके बंडल आईडी और IOS का इस्तेमाल करें.
SELECT issue_id, COUNT(DISTINCT event_id) AS events FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME` WHERE DATE(event_timestamp) = CURRENT_DATE() GROUP BY issue_id ORDER BY events DESC LIMIT 5;
नौवां उदाहरण: DATE से लेकर आज तक की पांच सबसे बड़ी समस्याएं
भरोसेमंद बैच डेटा में रीयल-टाइम जानकारी जोड़ने के लिए, स्टिचिंग क्वेरी की मदद से बैच और रीयल-टाइम टेबल को भी जोड़ा जा सकता है. event_id एक मुख्य कुंजी है. इसलिए, दोनों टेबल से किसी भी सामान्य इवेंट को हटाने के लिए, DISTINCT event_id का इस्तेमाल किया जा सकता है.
यहां Android ऐप्लिकेशन के लिए क्वेरी का उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, पैकेज के नाम और ANDROID के बजाय, उसके बंडल आईडी और IOS का इस्तेमाल करें.
SELECT issue_id, COUNT(DISTINCT event_id) AS events FROM ( SELECT issue_id, event_id, event_timestamp FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME` UNION ALL SELECT issue_id, event_id, event_timestamp FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`) WHERE event_timestamp >= "YYYY_MM_DD" GROUP BY issue_id ORDER BY events DESC LIMIT 5;
BigQuery में Crashlytics स्कीमा को समझना
Crashlytics से BigQuery में डेटा एक्सपोर्ट करने की सुविधा सेट अप करने पर, Firebase हाल ही के इवेंट (क्रैश, गड़बड़ियां, और ANR) एक्सपोर्ट करता है. इनमें लिंक करने से दो दिन पहले तक के इवेंट भी शामिल होते हैं. साथ ही, 30 दिनों तक के डेटा को बैकफ़िल करने का विकल्प भी मिलता है.
इसके बाद, जब तक एक्सपोर्ट की सुविधा बंद नहीं की जाती, तब तक Firebase हर दिन Crashlytics इवेंट एक्सपोर्ट करता है. हर एक्सपोर्ट के बाद, डेटा को BigQuery में उपलब्ध होने में कुछ मिनट लग सकते हैं.
डेटासेट
Crashlytics, Crashlytics के डेटा के लिए BigQuery में एक नया डेटासेट बनाता है. डेटासेट में आपके पूरे प्रोजेक्ट का डेटा शामिल होता है. भले ही, उसमें एक से ज़्यादा ऐप्लिकेशन हों.
टेबल
Crashlytics आपके प्रोजेक्ट में मौजूद हर ऐप्लिकेशन के लिए, डेटासेट में एक टेबल बनाता है. ऐसा तब तक होता है, जब तक आपने उस ऐप्लिकेशन के डेटा को एक्सपोर्ट करने की सुविधा से ऑप्ट आउट नहीं किया है. Firebase, ऐप्लिकेशन के आइडेंटिफ़ायर के आधार पर टेबल को नाम देता है. इसमें पीरियड को अंडरस्कोर में बदल दिया जाता है और आखिर में प्लैटफ़ॉर्म का नाम जोड़ दिया जाता है.
उदाहरण के लिए, पैकेज का नाम com.google.test वाला Android ऐप्लिकेशन का डेटा, com_google_test_ANDROID नाम की टेबल में होगा. साथ ही, रीयलटाइम डेटा (अगर चालू है) com_google_test_ANDROID_REALTIME नाम की टेबल में होगा
टेबल में Crashlytics डेटा का स्टैंडर्ड सेट होता है. साथ ही, इसमें आपके ऐप्लिकेशन में तय की गई कस्टम Crashlytics कुंजियां भी शामिल होती हैं.
लाइन
टेबल की हर लाइन, ऐप्लिकेशन में हुई गड़बड़ी के बारे में बताती है.
कॉलम
टेबल में मौजूद कॉलम, ऐप्लिकेशन के बंद होने, गड़बड़ियों, और ANR के लिए एक जैसे होते हैं. अगर Crashlytics से BigQuery में स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू है, तो रीयल टाइम टेबल में वही कॉलम होंगे जो बैच टेबल में हैं. ध्यान दें कि हो सकता है कि आपकी लाइनों में ऐसे कॉलम हों जो ऐसे इवेंट दिखाते हों जिनमें स्टैक ट्रेस न हों.
एक्सपोर्ट में शामिल कॉलम इस टेबल में दिए गए हैं:
| फ़ील्ड का नाम | डेटा टाइप | ब्यौरा |
|---|---|---|
platform |
स्ट्रिंग | Firebase प्रोजेक्ट में रजिस्टर किया गया ऐप्लिकेशन प्लैटफ़ॉर्म
(मान्य वैल्यू: IOS या ANDROID)
|
bundle_identifier |
स्ट्रिंग | Firebase प्रोजेक्ट में रजिस्टर किए गए ऐप्लिकेशन का यूनीक आइडेंटिफ़ायर (उदाहरण के लिए, com.google.gmailApple प्लैटफ़ॉर्म के ऐप्लिकेशन के लिए, यह ऐप्लिकेशन का बंडल आईडी होता है. Android ऐप्लिकेशन के लिए, यह ऐप्लिकेशन का पैकेज नाम होता है. |
event_id |
स्ट्रिंग | इवेंट का यूनीक आईडी |
is_fatal |
बूलियन | ऐप्लिकेशन क्रैश हुआ या नहीं |
error_type |
स्ट्रिंग | इवेंट में हुई गड़बड़ी का टाइप (उदाहरण के लिए, FATAL,
NON_FATAL, ANR वगैरह) |
issue_id |
स्ट्रिंग | इवेंट से जुड़ी समस्या |
variant_id |
स्ट्रिंग | इस इवेंट से जुड़ा समस्या वैरिएंट ध्यान दें कि सभी इवेंट में समस्या का कोई वैरिएंट नहीं होता. |
event_timestamp |
टाइमस्टैंप | इवेंट कब हुआ |
device |
रिकॉर्ड | वह डिवाइस जिस पर इवेंट हुआ |
device.manufacturer |
स्ट्रिंग | डिवाइस बनाने वाली कंपनी |
device.model |
स्ट्रिंग | डिवाइस का मॉडल |
device.architecture |
स्ट्रिंग | उदाहरण के लिए, X86_32, X86_64, ARMV7,
ARM64, ARMV7S या ARMV7K |
memory |
रिकॉर्ड | डिवाइस के स्टोरेज की स्थिति |
memory.used |
INT64 | इस्तेमाल की गई मेमोरी के बाइट |
memory.free |
INT64 | बचे हुए मेमोरी बाइट |
storage |
रिकॉर्ड | डिवाइस का पर्सिस्टेंट स्टोरेज |
storage.used |
INT64 | इस्तेमाल किया गया स्टोरेज (बाइट में) |
storage.free |
INT64 | बाइट में बचा स्टोरेज |
operating_system |
रिकॉर्ड | डिवाइस पर ओएस की जानकारी |
operating_system.display_version |
स्ट्रिंग | डिवाइस पर ओएस का वर्शन |
operating_system.name |
स्ट्रिंग | डिवाइस पर ओएस का नाम |
operating_system.modification_state |
स्ट्रिंग | डिवाइस में बदलाव किया गया है या नहीं (उदाहरण के लिए, जेलब्रेक किया गया ऐप्लिकेशन MODIFIED और रूट किया गया ऐप्लिकेशन UNMODIFIED है) |
operating_system.type |
स्ट्रिंग | (सिर्फ़ Apple ऐप्लिकेशन के लिए) डिवाइस पर चलने वाले ओएस का टाइप (उदाहरण के लिए,
IOS, MACOS वगैरह) |
operating_system.device_type |
स्ट्रिंग | डिवाइस का टाइप (उदाहरण के लिए, MOBILE, TABLET,
TV वगैरह); इसे "डिवाइस कैटगरी" भी कहा जाता है |
application |
रिकॉर्ड | वह ऐप्लिकेशन जिसने इवेंट जनरेट किया |
application.build_version |
स्ट्रिंग | ऐप्लिकेशन के बिल्ड का वर्शन |
application.display_version |
स्ट्रिंग | |
user |
रिकॉर्ड | (ज़रूरी नहीं) ऐप्लिकेशन के उपयोगकर्ता के बारे में इकट्ठा की गई जानकारी |
user.name |
स्ट्रिंग | (ज़रूरी नहीं) उपयोगकर्ता का नाम |
user.email |
स्ट्रिंग | (ज़रूरी नहीं) उपयोगकर्ता का ईमेल पता |
user.id |
स्ट्रिंग | (ज़रूरी नहीं) उपयोगकर्ता से जुड़ा, ऐप्लिकेशन से जुड़ा आईडी |
custom_keys |
बार-बार रिकॉर्ड करना | डेवलपर के तय किए गए की-वैल्यू पेयर |
custom_keys.key |
स्ट्रिंग | डेवलपर की तय की गई कुंजी |
custom_keys.value |
स्ट्रिंग | डेवलपर की ओर से तय की गई वैल्यू |
installation_uuid |
स्ट्रिंग | एक आईडी, जो किसी यूनीक ऐप्लिकेशन और डिवाइस इंस्टॉलेशन की पहचान करता है |
crashlytics_sdk_versions |
स्ट्रिंग | इवेंट जनरेट करने वाला SDK टूल का Crashlytics वर्शन |
app_orientation |
स्ट्रिंग | उदाहरण के लिए, PORTRAIT, LANDSCAPE,
FACE_UP, FACE_DOWN वगैरह. |
device_orientation |
स्ट्रिंग | उदाहरण के लिए, PORTRAIT, LANDSCAPE,
FACE_UP, FACE_DOWN वगैरह. |
process_state |
स्ट्रिंग | BACKGROUND या FOREGROUND |
logs |
बार-बार रिकॉर्ड करना | Crashlytics लॉगर की मदद से जनरेट किए गए, टाइमस्टैंप वाले लॉग मैसेज. हालांकि, इसके लिए Crashlytics लॉगर की सुविधा चालू होनी चाहिए |
logs.timestamp |
टाइमस्टैंप | लॉग कब बनाया गया था |
logs.message |
स्ट्रिंग | लॉग किया गया मैसेज |
breadcrumbs |
बार-बार रिकॉर्ड करना | टाइमस्टैंप के साथ दिखने वाले Google Analytics ब्रेडक्रंब, अगर चालू हों |
breadcrumbs.timestamp |
टाइमस्टैंप | ब्रेडक्रंब से जुड़ा टाइमस्टैंप |
breadcrumbs.name |
स्ट्रिंग | ब्रेडक्रंब से जुड़ा नाम |
breadcrumbs.params |
बार-बार रिकॉर्ड करना | ब्रेडक्रंब से जुड़े पैरामीटर |
breadcrumbs.params.key |
स्ट्रिंग | ब्रेडक्रंब से जुड़ी पैरामीटर कुंजी |
breadcrumbs.params.value |
स्ट्रिंग | ब्रेडक्रंब से जुड़ी पैरामीटर वैल्यू |
blame_frame |
रिकॉर्ड | वह फ़्रेम जिसकी पहचान क्रैश या गड़बड़ी की मुख्य वजह के तौर पर की गई है |
blame_frame.line |
INT64 | फ़्रेम की फ़ाइल की लाइन नंबर |
blame_frame.file |
स्ट्रिंग | फ़्रेम फ़ाइल का नाम |
blame_frame.symbol |
स्ट्रिंग | हाइड्रेट किया गया सिंबल या अगर हाइड्रेट नहीं किया जा सकता, तो रॉ सिंबल |
blame_frame.offset |
INT64 | बाइनरी इमेज में बाइट ऑफ़सेट, जिसमें कोड मौजूद है Java अपवादों के लिए अनसेट |
blame_frame.address |
INT64 | बाइनरी इमेज में मौजूद वह पता जिसमें कोड Java फ़्रेम के लिए अनसेट है |
blame_frame.library |
स्ट्रिंग | उस लाइब्रेरी का डिसप्ले नेम जिसमें फ़्रेम शामिल है |
blame_frame.owner |
स्ट्रिंग | उदाहरण के लिए, DEVELOPER, VENDOR,
RUNTIME, PLATFORM या SYSTEM |
blame_frame.blamed |
बूलियन | Crashlytics ने यह तय किया है कि क्रैश या गड़बड़ी की वजह यह फ़्रेम है या नहीं |
exceptions |
बार-बार रिकॉर्ड करना | (सिर्फ़ Android के लिए) इस इवेंट के दौरान हुई गड़बड़ियां. नेस्ट किए गए अपवाद, समय के हिसाब से उलटे क्रम में दिखाए जाते हैं. इसका मतलब है कि आखिरी रिकॉर्ड, सबसे पहले दिखाया गया अपवाद है |
exceptions.type |
स्ट्रिंग | अपवाद का टाइप
(उदाहरण के लिए, java.lang.IllegalStateException) |
exceptions.exception_message |
स्ट्रिंग | अपवाद से जुड़ा मैसेज |
exceptions.nested |
बूलियन | आखिरी बार ट्रिगर हुए अपवाद को छोड़कर सभी के लिए True (यानी पहला रिकॉर्ड) |
exceptions.title |
स्ट्रिंग | थ्रेड का टाइटल |
exceptions.subtitle |
स्ट्रिंग | थ्रेड का सबटाइटल |
exceptions.blamed |
बूलियन | अगर Crashlytics यह तय करता है कि अपवाद, गड़बड़ी या क्रैश के लिए ज़िम्मेदार है, तो यह सही होगा |
exceptions.frames |
बार-बार रिकॉर्ड करना | अपवाद से जुड़े फ़्रेम |
exceptions.frames.line |
INT64 | फ़्रेम की फ़ाइल की लाइन नंबर |
exceptions.frames.file |
स्ट्रिंग | फ़्रेम फ़ाइल का नाम |
exceptions.frames.symbol |
स्ट्रिंग | हाइड्रेट किया गया सिंबल या अगर हाइड्रेट नहीं किया जा सकता, तो रॉ सिंबल |
exceptions.frames.offset |
INT64 | बाइनरी इमेज में बाइट ऑफ़सेट, जिसमें कोड मौजूद है Java अपवादों के लिए अनसेट |
exceptions.frames.address |
INT64 | बाइनरी इमेज में मौजूद वह पता जिसमें कोड Java फ़्रेम के लिए अनसेट है |
exceptions.frames.library |
स्ट्रिंग | उस लाइब्रेरी का डिसप्ले नेम जिसमें फ़्रेम शामिल है |
exceptions.frames.owner |
स्ट्रिंग | उदाहरण के लिए, DEVELOPER, VENDOR,
RUNTIME, PLATFORM या SYSTEM |
exceptions.frames.blamed |
बूलियन | Crashlytics ने यह तय किया है कि क्रैश या गड़बड़ी की वजह यह फ़्रेम है या नहीं |
error |
बार-बार रिकॉर्ड करना | (सिर्फ़ Apple के ऐप्लिकेशन के लिए) नुकसान न पहुंचाने वाली गड़बड़ियां |
error.queue_name |
स्ट्रिंग | वह कतार जिसमें थ्रेड चल रहा था |
error.code |
INT64 | ऐप्लिकेशन के कस्टम लॉग किए गए NSError से जुड़ा गड़बड़ी कोड |
error.title |
स्ट्रिंग | थ्रेड का टाइटल |
error.subtitle |
स्ट्रिंग | थ्रेड का सबटाइटल |
error.blamed |
बूलियन | क्या Crashlytics ने यह तय किया है कि गड़बड़ी का मकसद यह फ़्रेम है |
error.frames |
बार-बार रिकॉर्ड करना | स्टैक ट्रेस के फ़्रेम |
error.frames.line |
INT64 | फ़्रेम की फ़ाइल की लाइन नंबर |
error.frames.file |
स्ट्रिंग | फ़्रेम फ़ाइल का नाम |
error.frames.symbol |
स्ट्रिंग | हाइड्रेट किया गया सिंबल या अगर हाइड्रेट नहीं किया जा सकता, तो रॉ सिंबल |
error.frames.offset |
INT64 | कोड वाली बाइनरी इमेज में बाइट ऑफ़सेट |
error.frames.address |
INT64 | बाइनरी इमेज में मौजूद वह पता जिसमें कोड है |
error.frames.library |
स्ट्रिंग | उस लाइब्रेरी का डिसप्ले नेम जिसमें फ़्रेम शामिल है |
error.frames.owner |
स्ट्रिंग | उदाहरण के लिए, DEVELOPER, VENDOR,
RUNTIME, PLATFORM या SYSTEM |
error.frames.blamed |
बूलियन | क्या Crashlytics ने यह तय किया है कि गड़बड़ी का मकसद यह फ़्रेम है |
threads |
बार-बार रिकॉर्ड करना | इवेंट के दौरान मौजूद थ्रेड |
threads.crashed |
बूलियन | थ्रेड क्रैश हुआ है या नहीं |
threads.thread_name |
स्ट्रिंग | थ्रेड का नाम |
threads.queue_name |
स्ट्रिंग | (सिर्फ़ Apple ऐप्लिकेशन के लिए) वह कतार जिस पर थ्रेड चल रहा था |
threads.signal_name |
स्ट्रिंग | उस सिग्नल का नाम जिसकी वजह से ऐप्लिकेशन क्रैश हुआ. यह सिर्फ़ क्रैश हुई नेटिव थ्रेड में मौजूद होता है |
threads.signal_code |
स्ट्रिंग | सिग्नल का कोड, जिसकी वजह से ऐप्लिकेशन क्रैश हुआ; यह सिर्फ़ क्रैश हुई नेटिव थ्रेड पर मौजूद होता है |
threads.crash_address |
INT64 | उस सिग्नल का पता जिसकी वजह से ऐप्लिकेशन क्रैश हुआ; यह सिर्फ़ क्रैश हुई नेटिव थ्रेड में मौजूद होता है |
threads.code |
INT64 | (सिर्फ़ Apple के ऐप्लिकेशन के लिए) ऐप्लिकेशन के कस्टम लॉग किए गए NSError का गड़बड़ी कोड |
threads.title |
स्ट्रिंग | थ्रेड का टाइटल |
threads.subtitle |
स्ट्रिंग | थ्रेड का सबटाइटल |
threads.blamed |
बूलियन | Crashlytics ने यह तय किया है कि क्रैश या गड़बड़ी की वजह यह फ़्रेम है या नहीं |
threads.frames |
बार-बार रिकॉर्ड करना | थ्रेड के फ़्रेम |
threads.frames.line |
INT64 | फ़्रेम की फ़ाइल की लाइन नंबर |
threads.frames.file |
स्ट्रिंग | फ़्रेम फ़ाइल का नाम |
threads.frames.symbol |
स्ट्रिंग | हाइड्रेट किया गया सिंबल या अगर हाइड्रेट नहीं किया जा सकता, तो रॉ सिंबल |
threads.frames.offset |
INT64 | कोड वाली बाइनरी इमेज में बाइट ऑफ़सेट |
threads.frames.address |
INT64 | बाइनरी इमेज में मौजूद वह पता जिसमें कोड है |
threads.frames.library |
स्ट्रिंग | उस लाइब्रेरी का डिसप्ले नेम जिसमें फ़्रेम शामिल है |
threads.frames.owner |
स्ट्रिंग | उदाहरण के लिए, DEVELOPER, VENDOR,
RUNTIME, PLATFORM या SYSTEM |
threads.frames.blamed |
बूलियन | क्या Crashlytics ने यह तय किया है कि गड़बड़ी का मकसद यह फ़्रेम है |
unity_metadata.unity_version |
स्ट्रिंग | इस डिवाइस पर Unity का वर्शन |
unity_metadata.debug_build |
बूलियन | अगर यह डीबग बिल्ड है |
unity_metadata.processor_type |
स्ट्रिंग | प्रोसेसर का टाइप |
unity_metadata.processor_count |
INT64 | प्रोसेसर (कोर) की संख्या |
unity_metadata.processor_frequency_mhz |
INT64 | प्रोसेसर की फ़्रीक्वेंसी, मेगाहर्ट्ज़ में |
unity_metadata.system_memory_size_mb |
INT64 | एमबी में सिस्टम की मेमोरी का साइज़ |
unity_metadata.graphics_memory_size_mb |
INT64 | एमबी में ग्राफ़िक्स मेमोरी |
unity_metadata.graphics_device_id |
INT64 | ग्राफ़िक डिवाइस का आइडेंटिफ़ायर |
unity_metadata.graphics_device_vendor_id |
INT64 | ग्राफ़िक प्रोसेसर के वेंडर का आइडेंटिफ़ायर |
unity_metadata.graphics_device_name |
स्ट्रिंग | ग्राफ़िक डिवाइस का नाम |
unity_metadata.graphics_device_vendor |
स्ट्रिंग | ग्राफ़िक डिवाइस का वेंडर |
unity_metadata.graphics_device_version |
स्ट्रिंग | ग्राफ़िक डिवाइस का वर्शन |
unity_metadata.graphics_device_type |
स्ट्रिंग | ग्राफ़िक्स डिवाइस का टाइप |
unity_metadata.graphics_shader_level |
INT64 | ग्राफ़िक का शेडर लेवल |
unity_metadata.graphics_render_target_count |
INT64 | ग्राफ़िक रेंडरिंग टारगेट की संख्या |
unity_metadata.graphics_copy_texture_support |
स्ट्रिंग | Unity API में बताए गए तरीके के मुताबिक, ग्राफ़िक टेक्सचर को कॉपी करने की सुविधा |
unity_metadata.graphics_max_texture_size |
INT64 | टेक्सचर को रेंडर करने के लिए तय किया गया ज़्यादा से ज़्यादा साइज़ |
unity_metadata.screen_size_px |
स्ट्रिंग | पिक्सल में स्क्रीन का साइज़, जिसे चौड़ाई x ऊंचाई के तौर पर फ़ॉर्मैट किया गया है |
unity_metadata.screen_resolution_dpi |
स्ट्रिंग | फ़्लोटिंग पॉइंट नंबर के तौर पर स्क्रीन की डीपीआई |
unity_metadata.screen_refresh_rate_hz |
INT64 | स्क्रीन की रीफ़्रेश दर, हर्ट्ज़ में |
Data Studio की मदद से, एक्सपोर्ट किए गए Crashlytics डेटा को विज़ुअलाइज़ करना
Google Data Studio, BigQuery में मौजूद आपके Crashlytics डेटासेट को ऐसी रिपोर्ट में बदल देता है जिन्हें पढ़ना और शेयर करना आसान होता है. साथ ही, इन्हें अपनी ज़रूरत के हिसाब से बनाया जा सकता है.
Data Studio का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, Data Studio की शुरुआती गाइड, Data Studio में आपका स्वागत है देखें.
Crashlytics रिपोर्ट टेंप्लेट का इस्तेमाल करना
Data Studio में Crashlytics के लिए एक सैंपल रिपोर्ट होती है. इसमें, एक्सपोर्ट किए गए Crashlytics BigQuery स्कीमा के डाइमेंशन और मेट्रिक का पूरा सेट शामिल होता है. अगर आपने Crashlytics से BigQuery पर स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू की है, तो उस डेटा को Data Studio टेंप्लेट के रीयल टाइम रुझान पेज पर देखा जा सकता है.अपने ऐप्लिकेशन के क्रैश के रॉ डेटा के आधार पर, नई रिपोर्ट और विज़ुअलाइज़ेशन तुरंत बनाने के लिए, सैंपल को टेंप्लेट के तौर पर इस्तेमाल किया जा सकता है:
सबसे ऊपर दाएं कोने में मौजूद, टेंप्लेट का इस्तेमाल करें पर क्लिक करें.
नया डेटा सोर्स ड्रॉप-डाउन में, नया डेटा सोर्स बनाएं चुनें.
BigQuery कार्ड पर, चुनें पर क्लिक करें.
मेरे प्रोजेक्ट > PROJECT_ID > firebase_crashlytics > TABLE_NAME को चुनकर, एक्सपोर्ट किया गया Crashlytics डेटा दिखाने वाली टेबल चुनें.
आपकी बैच टेबल हमेशा चुनने के लिए उपलब्ध होती है. अगर CrashlyticsBigQuery में स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू है, तो रीयल टाइम टेबल चुनी जा सकती है.
कॉन्फ़िगरेशन में जाकर, Crashlytics टेंप्लेट लेवल को डिफ़ॉल्ट पर सेट करें.
नया डेटा सोर्स बनाने के लिए, कनेक्ट करें पर क्लिक करें.
Crashlytics टेंप्लेट पर वापस जाने के लिए, रिपोर्ट में जोड़ें पर क्लिक करें.
आखिर में, Crashlytics Data Studio डैशबोर्ड टेंप्लेट की कॉपी बनाने के लिए, रिपोर्ट बनाएं पर क्लिक करें.
एक्सपोर्ट के नए इंफ़्रास्ट्रक्चर पर अपग्रेड करना
अक्टूबर 2024 के मध्य में, Crashlytics ने BigQuery में Crashlytics डेटा को बैच के तौर पर एक्सपोर्ट करने के लिए, एक नया इन्फ़्रास्ट्रक्चर लॉन्च किया.
सभी Firebase प्रोजेक्ट, 15 सितंबर, 2025 से, बैच एक्सपोर्ट के नए इन्फ़्रास्ट्रक्चर पर अपने-आप अपग्रेड हो जाएंगे. इस तारीख से पहले अपग्रेड किया जा सकता है. हालांकि, पक्का करें कि आपकी BigQuery बैच टेबल, अपग्रेड करने से जुड़ी ज़रूरी शर्तों को पूरा करती हों.
नए इन्फ़्रास्ट्रक्चर पर अपग्रेड किया जा सकता है. हालांकि, पक्का करें कि आपकी BigQuery बैच टेबल, अपग्रेड करने से जुड़ी ज़रूरी शर्तों को पूरा करती हों.
यह पता लगाना कि आपके पास नए इंफ़्रास्ट्रक्चर का ऐक्सेस है या नहीं
अगर आपने अक्टूबर 2024 के मध्य या उसके बाद, एक साथ कई डेटा एक्सपोर्ट करने की सुविधा चालू की है, तो आपका Firebase प्रोजेक्ट, एक्सपोर्ट के नए इन्फ़्रास्ट्रक्चर का अपने-आप इस्तेमाल कर रहा है.
यह देखा जा सकता है कि आपका प्रोजेक्ट किस इंफ़्रास्ट्रक्चर का इस्तेमाल कर रहा है:
Google Cloud कंसोल पर जाएं. अगर आपके "डेटा ट्रांसफ़र कॉन्फ़िगरेशन" पर Firebase Crashlytics with Multi-Region Support का लेबल है, तो इसका मतलब है कि आपका प्रोजेक्ट, एक्सपोर्ट के नए इंफ़्रास्ट्रक्चर का इस्तेमाल कर रहा है.
पुराने एक्सपोर्ट इन्फ़्रास्ट्रक्चर और नए एक्सपोर्ट इन्फ़्रास्ट्रक्चर के बीच अहम अंतर
नया इंफ़्रास्ट्रक्चर, Crashlytics डेटासेट की जगहों के लिए काम करता है, जो अमेरिका से बाहर हैं.
डेटा एक्सपोर्ट करने की सुविधा, अक्टूबर 2024 के मध्य से पहले चालू की गई हो और डेटा एक्सपोर्ट करने के नए इन्फ़्रास्ट्रक्चर पर अपग्रेड किया गया हो — अब आपके पास डेटा एक्सपोर्ट करने की जगह बदलने का विकल्प है.
डेटा एक्सपोर्ट करने की सुविधा अक्टूबर 2024 के मध्य या उसके बाद चालू की गई — सेटअप के दौरान, आपसे डेटा एक्सपोर्ट करने के लिए कोई जगह चुनने के लिए कहा गया था.
नया इन्फ़्रास्ट्रक्चर, एक्सपोर्ट की सुविधा चालू करने से पहले के डेटा के बैकफ़िल के साथ काम नहीं करता.
पुराने इंफ़्रास्ट्रक्चर में, एक्सपोर्ट की सुविधा चालू करने की तारीख से 30 दिन पहले तक बैकफ़िल किया जा सकता था.
नया इन्फ़्रास्ट्रक्चर, पिछले 30 दिनों तक के बैकफ़िल या BigQuery में एक्सपोर्ट करने की सुविधा चालू करने की तारीख तक के बैकफ़िल के साथ काम करता है. हालांकि, इनमें से जो भी तारीख सबसे हाल की होगी वह ही लागू होगी.
नए इंफ़्रास्ट्रक्चर में, BigQuery बैच टेबल के नाम, आपके Firebase प्रोजेक्ट में मौजूद Firebase ऐप्लिकेशन के लिए सेट किए गए आइडेंटिफ़ायर का इस्तेमाल करते हैं.
पुराने इन्फ़्रास्ट्रक्चर ने, बंडल आईडी या पैकेज के नाम के आधार पर, नाम वाली बैच टेबल में डेटा डाला था. ये नाम, आपके ऐप्लिकेशन के कोडबेस में Firebase कॉन्फ़िगरेशन में मौजूद थे.
नया इन्फ़्रास्ट्रक्चर, बंडल आईडी या पैकेज के नाम के आधार पर, नाम वाली बैच टेबल में डेटा लिखता है. ये नाम, आपके Firebase प्रोजेक्ट में रजिस्टर किए गए Firebase ऐप्लिकेशन के लिए सेट किए जाते हैं.
पहला चरण: अपग्रेड करने से जुड़ी ज़रूरी शर्तें
देखें कि आपकी मौजूदा BigQuery बैच टेबल, बंडल आईडी या पैकेज के नाम से मैच करने वाले आइडेंटिफ़ायर का इस्तेमाल करती हैं या नहीं. ये आइडेंटिफ़ायर, आपके Firebase प्रोजेक्ट में रजिस्टर किए गए Firebase ऐप्लिकेशन के लिए सेट किए गए हैं. अगर ये आपस में मेल नहीं खाते हैं, तो हो सकता है कि एक्सपोर्ट किए गए डेटा में रुकावटें आएं. ज़्यादातर प्रोजेक्ट सही और काम करने की स्थिति में होंगे. हालांकि, अपग्रेड करने से पहले यह देखना ज़रूरी है.
Firebase कंसोल में, अपने Firebase प्रोजेक्ट में रजिस्टर किए गए सभी Firebase ऐप्लिकेशन देखे जा सकते हैं: अपने प्रोजेक्ट सेटिंग पर जाएं. इसके बाद, अपने सभी Firebase ऐप्लिकेशन और उनकी जानकारी देखने के लिए, आपके ऐप्लिकेशन कार्ड पर स्क्रोल करें.
आपको Google Cloud कंसोल के BigQuery पेज पर, अपनी सभी BigQuery बैच टेबल मिल सकती हैं.
उदाहरण के लिए, यहां कुछ ऐसे आदर्श स्टेटस दिए गए हैं जिनमें आपको अपग्रेड करने में कोई समस्या नहीं होगी:
आपके पास
com_yourcompany_yourproject_IOSनाम की एक बैच टेबल है और आपके Firebase प्रोजेक्ट में रजिस्टर किया गया, बंडल आईडीcom.yourcompany.yourprojectवाला Firebase iOS+ ऐप्लिकेशन है.आपके पास
com_yourcompany_yourproject_ANDROIDनाम की एक बैच टेबल है और आपके Firebase प्रोजेक्ट में, पैकेज के नाम के तौर परcom.yourcompany.yourprojectवाला Firebase Android ऐप्लिकेशन रजिस्टर है.
अगर आपकी बैच टेबल के नाम, रजिस्टर किए गए Firebase ऐप्लिकेशन के लिए सेट किए गए आइडेंटिफ़ायर से मेल नहीं खाते, तो अपने बैच एक्सपोर्ट में रुकावट से बचने के लिए, मैन्युअल तरीके से अपग्रेड करने से पहले या 15 सितंबर, 2025 से पहले, इस पेज पर दिए गए निर्देशों का पालन करें.
दूसरा चरण: नए इन्फ़्रास्ट्रक्चर पर मैन्युअल तरीके से अपग्रेड करना
अगर आपने अक्टूबर 2024 के मध्य से पहले, एक साथ कई आइटम एक्सपोर्ट करने की सुविधा चालू की है, तो नए इन्फ़्रास्ट्रक्चर पर मैन्युअल तरीके से अपग्रेड किया जा सकता है. इसके लिए, Firebase कंसोल में जाकर, Crashlytics डेटा एक्सपोर्ट को टॉगल करके बंद करें और फिर से चालू करें.
यहां इस बारे में ज़्यादा जानकारी दी गई है:
Firebase कंसोल में, इंटिग्रेशन पेज पर जाएं.
BigQuery कार्ड में, मैनेज करें पर क्लिक करें.
एक्सपोर्ट की सुविधा बंद करने के लिए, Crashlytics स्लाइडर को टॉगल करें. जब कहा जाए, तब पुष्टि करें कि आपको डेटा एक्सपोर्ट की सुविधा बंद करनी है.
एक्सपोर्ट की सुविधा को फिर से चालू करने के लिए, Crashlytics स्लाइडर को तुरंत फिर से टॉगल करें. जब आपसे कहा जाए, तब पुष्टि करें कि आपको डेटा एक्सपोर्ट करना है.
Crashlytics से BigQuery में डेटा एक्सपोर्ट करने के लिए, अब एक्सपोर्ट के नए इन्फ़्रास्ट्रक्चर का इस्तेमाल किया जा रहा है.