4,000 Discord सर्वरों पर नज़र: Grafana, PostHog और उन्होंने हमें क्या दिखाया

AlphaCloud 4,000 से कुछ ज़्यादा Discord सर्वरों पर चलता है, जो चार शार्ड में बँटे हैं। ये चार प्रोसेस हैं, हर एक सर्वरों के एक हिस्से को संभालता है, और सब एक ही API से बात करते हैं।

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

दो टूल, दो सवाल

Grafana इस सवाल का जवाब देता है: बॉट क्या कर रहा है? बॉट और API, Prometheus को मेट्रिक्स भेजते हैं (रिक्वेस्ट, रिस्पॉन्स टाइम, एरर रेट, Discord के जवाब, AI का इस्तेमाल), और लॉग Loki में जाते हैं। हर सर्वर नोड का अपना स्टैक है, और Grafana सिर्फ़ एक प्राइवेट नेटवर्क से पहुँचा जा सकता है, इंटरनेट से नहीं।

PostHog इस सवाल का जवाब देता है: लोग हमारी वेबसाइटों पर क्या अनुभव करते हैं? पेज व्यू, ब्राउज़र एरर, लोड टाइम और, सहमति के साथ, रिकॉर्ड किए गए सेशन। PostHog तभी शुरू होता है जब आप कुकी बैनर में सहमति देते हैं।

यह बँटवारा जानबूझकर है। Grafana मशीनों को देखता है, PostHog इंटरफ़ेस को। दोनों को एक टूल में ठूँसने पर या तो सर्वर लॉग में यूज़र डेटा आ जाता है या प्रोडक्ट एनालिटिक्स में सर्वर लोड।

उसे क्या मिला

एक लूप जो आधा ट्रैफ़िक पैदा कर रहा था

जिन पोल का एक खत्म होने का समय होता है, उन्हें एक बैकग्राउंड टास्क बंद करता है, जो हर मिनट जांचता है कि कुछ खत्म हुआ है या नहीं। वह ऐसा हर सर्वर के लिए अलग-अलग करता था। हर शार्ड पर लगभग 1,000 सर्वर और चार शार्ड के साथ, यह लगभग 70 रिक्वेस्ट प्रति सेकंड बनता था, और लगभग हर एक का जवाब "कुछ खत्म नहीं हुआ" होता था।

हमें यह Grafana में तभी दिखा, जब हमने API को भेजी गई बॉट की रिक्वेस्ट को पाथ के हिसाब से बाँटा: अकेला यह एंडपॉइंट पूरे ट्रैफ़िक के आधे से ज़्यादा था। सब कुछ चल रहा था। बस वह एक ऐसा बोझ उठा रहा था जो किसी ने मांगा ही नहीं था।

अब हर शार्ड मिनट में एक बार पूछता है: "किन सर्वरों पर कोई खत्म हुआ पोल है भी?" और सिर्फ़ उन्हीं का विवरण लाता है। प्रति मिनट लगभग 4,200 रिक्वेस्ट घटकर लगभग चार रह गईं।

तीस लाख बार "सेट अप नहीं है"

वही पैटर्न, दूसरी जगह: कई मॉड्यूल (सपोर्ट एंट्री, अनुपस्थिति, टीम सूची, बॉट आंकड़े, न्यूज़लेटर) अपने लूप में नियमित रूप से हर सर्वर की सेटिंग्स पढ़ते थे। ज़्यादातर सर्वरों पर कोई खास मॉड्यूल सेट अप ही नहीं होता, इसलिए जवाब "नहीं मिला" होता था। रोज़ लगभग 30 लाख बार।

फ़िक्स मामूली है: "सेट अप नहीं है" को अब 30 मिनट तक याद रखा जाता है। यह सिर्फ़ इसलिए सुरक्षित है क्योंकि इनमें से हर मॉड्यूल, वेब पैनल में सेव होते ही बॉट को एक अपडेट भेजता है, इसलिए किसी मॉड्यूल को सेट अप करने का मतलब कभी 30 मिनट इंतज़ार नहीं होता।

Discord के आउटेज हमारे बग नहीं हैं

हमारा टीम एरर चैनल हर फ़ेल हुए एक्शन को "Runtime Error" के रूप में पोस्ट करता था, एक यूनिक रेफ़रेंस और बाकी सब के साथ। इसमें वे पल भी शामिल थे जब Discord खुद सर्वर एरर से जवाब देता था। यह न तो हमारी तरफ़ का बग है और न ही कुछ ऐसा जिसे हम ठीक कर सकें, और यह चैनल में बिल्कुल असली खराबी जैसा दिखता था।

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

एक हमला जो एक मिनट चला

सितंबर के आखिर में एक दोपहर हमारे होम पेज पर एक मिनट के अंदर 5 लाख से कुछ ज़्यादा रिक्वेस्ट आईं, एक साथ कई देशों से। इसका ज़्यादातर हिस्सा हमारे सर्वरों तक पहुँचने से पहले ही रोक दिया गया, और एक मिनट बाद ट्रैफ़िक फिर सामान्य था।

हमें यह इसलिए नहीं दिखा कि कुछ बंद हो गया। हमें यह इसलिए दिखा कि वह संख्या चार्ट के बाकी हिस्से से मेल नहीं खाती थी। मॉनिटरिंग का असली काम यही है: जब सब कुछ जल रहा हो तब अलार्म बजाना नहीं, बल्कि यह दिखाना कि कहाँ कुछ सामान्य से मेल नहीं खाता।

हमारी मॉनिटरिंग जानबूझकर क्या नहीं देखती

यहाँ के नियम उतने ही अहम हैं जितने डैशबोर्ड:

• लॉग में विज़िटर के IP पते नहीं। हमारी गोपनीयता नीति इसका वादा करती है, इसलिए हम उन्हें दो जगह हटाते हैं: जब एक्सेस लॉग लिखा जाता है, और एक बार फिर सेव होने से पहले।
• मेट्रिक्स में सर्वर, यूज़र या मैसेज ID नहीं। हर मेट्रिक सिर्फ़ मोटी-मोटी विशेषताओं (मॉड्यूल, स्टेटस क्लास, शार्ड) के हिसाब से बँटा होता है। इससे डेटा सुरक्षित रहता है और मेट्रिक्स डेटाबेस छोटा रहता है।
• सेशन रिकॉर्डिंग हमारा इंटरफ़ेस दिखाती है, आपका कंटेंट नहीं। सिर्फ़ वही टेक्स्ट पढ़ने लायक रहता है जो शब्दशः हमारी अनुवाद फ़ाइलों से आता है। सर्वर, चैनल और यूज़र के नाम, इनपुट और प्रीव्यू छिपा दिए जाते हैं। अगर अनुमत टेक्स्ट की सूची लोड न हो सके, तो सब कुछ छिपा दिया जाता है।
• वेबसाइट पर सब कुछ सिर्फ़ सहमति के बाद। इसका मतलब यह भी है कि वहाँ की संख्याएँ न्यूनतम सीमा हैं। असली पेज संख्या के लिए हम अपने नेटवर्क प्रोवाइडर के अनाम कुल आँकड़े देखते हैं।

विवरण गोपनीयता नीति में है।

हम इससे क्या सीखते हैं

महंगी चीज़ शायद ही कभी टूटी हुई चीज़ होती है। ऊपर की किसी भी खोज से कोई एरर नहीं आया। उनसे लोड, खर्च और शोर पैदा हुआ, और मापे बिना आप इनमें से कुछ भी कभी नहीं देखते।

हर सर्वर से अलग-अलग पूछना स्केल नहीं करता। दोनों बड़ी खोजें एक ही पैटर्न थीं: हर सर्वर पर चलने वाला एक लूप, जो हर एक के बारे में अलग-अलग पूछता है। जवाब लगभग हमेशा वही सवाल है, जो सबके लिए एक बार पूछा जाए।

अलर्ट दुर्लभ होना चाहिए, वरना वह अलर्ट नहीं है। इसीलिए सिर्फ़ Grafana टीम को पिंग करता है, और सिर्फ़ उन चीज़ों के लिए जिनमें किसी के दखल की ज़रूरत हो। PostHog से आने वाले नए एरर प्रकार बिना पिंग के चैनल में आते हैं।

अगर आप खुद कोई Discord सर्वर चलाते हैं और यहाँ बताए गए मॉड्यूल देखना चाहते हैं: पोल, सपोर्ट एंट्री और अनुपस्थिति वेब पैनल में हैं, और उनका विवरण डॉक्यूमेंटेशन में है।