DownDetector के लिए डाउन मॉनिटरिंग सेवा

• DownDetector साइट की परिचालन स्थिति को कई क्षेत्रों से रीयल-टाइम में जांचने वाली वेब सेवा
• लंदन, ऑकलैंड, न्यूयॉर्क सहित 3 क्षेत्रीय सर्वरों से HTTP response code और latency मापी जाती है
• सभी क्षेत्रों में HTTP code 200 (सामान्य response) लौट रहा है, और साइट सामान्य रूप से काम कर रही है
• क्षेत्रवार औसत latency 478~586ms की सीमा में दिखाई गई है
• प्रमुख outage monitoring platforms की reliability verification tool के रूप में उपयोग की संभावना

---

क्षेत्रवार जांच परिणाम

• London, UK क्षेत्र में स्थिति Up, HTTP code 200, latency 547ms
• Auckland, NZ क्षेत्र में स्थिति Up, HTTP code 200, latency 478ms
• New York, US क्षेत्र में स्थिति Up, HTTP code 200, latency 586ms
• सभी क्षेत्रों में एक ही परिणाम दोहराया गया, जिससे पुष्टि होती है कि DownDetector सेवा सामान्य रूप से संचालित हो रही है

सेवा का अवलोकन

• यह साइट DownDetector की स्थिति की निगरानी करने वाला एक समर्पित monitoring page है
• प्रत्येक क्षेत्र के लिए HTTP response code और latency को समय-समय पर मापकर दिखाया जाता है
• outage monitoring platform की availability verification के लिए संदर्भ संकेतक प्रदान करती है
• मूल पाठ में अतिरिक्त जानकारी नहीं है

[GN⁺]

Hacker News टिप्पणियाँ

• यूरोप-आधारित solo developer के तौर पर, मैंने इस साल की शुरुआत से पूरा infrastructure यूरोपीय services पर शिफ्ट कर दिया है
  Cloudflare की जगह Bunny.net, AWS की जगह Hetzner, और business email के लिए Infomaniak इस्तेमाल कर रहा हूँ
  अब तक एक भी downtime नहीं हुआ, और अमेरिकी services से पूरी तरह अलग होने का एहसास वाकई बहुत अच्छा लगता है

  • ये services आकार में छोटी हैं, लेकिन शायद इसी वजह से reliability सुनिश्चित करने को लेकर कहीं ज़्यादा गंभीर हैं
    बड़ी कंपनियों के माहौल में अक्सर यह सुनने को मिलता है, “अगर AWS इस्तेमाल किया होता तो ऐसा नहीं होता।” कुछ वैसा ही जैसे पहले IBM के बारे में कहा जाता था
    Hetzner, AWS की तुलना में कहीं ज़्यादा सरल service set देता है, इसलिए complexity भी कम है
    हालांकि brand recognition या “क्या यह professional दिखता है” जैसे सांस्कृतिक पहलू अब भी बड़े कारक हैं
  • यह ज़रूरी नहीं कि AWS या Cloudflare वास्तव में ज़्यादा बार down होते हों। बस उनके users बहुत ज़्यादा हैं, इसलिए issues की reporting ज़्यादा बड़ी हो जाती है
    infrastructure चुनना आपकी मर्ज़ी है, लेकिन availability को लेकर धारणा वास्तविकता से अलग हो सकती है
  • इस साल की शुरुआत में मेरे द्वारा managed एक Hetzner server बिना किसी वजह के reboot हो गया था
    maintenance notice था, लेकिन वह server प्रभावित systems की सूची में नहीं था
    मेरा मतलब यह नहीं कि Hetzner खराब है, बस यूरोप में भी ऐसे छोटे incidents होते हैं
  • मैं Bunny.net का fan हूँ, लेकिन Cloudflare की AI scrapers या malicious traffic filtering जैसी ‘smart defense’ capabilities काफ़ी मज़बूत हैं
    Bunny.net उस भूमिका को भी बदल सकता है या नहीं, इस पर मुझे संदेह है
  • मैं Infomaniak और Proton की तुलना देखना चाहूँगा। Infomaniak में office productivity tools ज़्यादा लगते हैं, लेकिन mail और drive की quality कैसी है, यह जानना चाहूँगा

• कल Cloudflare outage के समय Downdetector भी साथ में down हो गया, तो सब लोग हँस पड़े। timing कमाल की थी

  • पहले जिस CDN कंपनी में मैं काम करता था, वहाँ एक बार state-page provider हमारा customer बन गया था, और हमें status page बदलना पड़ा था

• एक मज़ाक था: “तीन Down Detector एक bar में घुसे”
  पहले ने कहा “पता नहीं”, दूसरे ने भी कहा “पता नहीं”, और तीसरे ने जवाब दिया “हाँ”

  • इस पर किसी ने प्रतिक्रिया दी कि शायद वे ‘अंधे down detectors’ रहे होंगे
  • यह इतना मज़ेदार था कि यह joke मैं ज़रूर चुराकर इस्तेमाल करूँगा

• किसी ने कहा, “यह तो सच में सोना है (GOLD),” और फिर meta joke चला: “तो down detector को monitor करने वाले down detector को monitor करने वाले down detector को कौन monitor करेगा?”

  • सच में isitdownrightnow.com का Downdetector monitoring page शेयर किया गया
  • इस पर प्रतिक्रिया आई, “अभी उस site पर जाने वाला वही व्यक्ति तुम हो!”
  • गंभीर तौर पर देखें तो, अलग-अलग availability zones और codebases वाले down detectors अगर एक-दूसरे को monitor करें, तो यह काफ़ी practical approach है
  • किसी ने कहा कि इसे distributed down detector आइडिया में विकसित करके HN पर project के रूप में पोस्ट किया जा सकता है
  • एक और सुझाव आया कि “तीनों में से कौन-सा down है” यह देखने वाला meta down detector बनाया जाए

• दरअसल Downdetector खुद पूरी तरह down नहीं हुआ था, समस्या Cloudflare के human verification module में थी
  इसलिए तकनीकी रूप से वह “up” था, लेकिन व्यवहार में इस्तेमाल करने लायक नहीं था

• एक मज़ाक यह भी था कि “तुम्हारे down detector के ज़िंदा होने की निगरानी के लिए एक और down detector चाहिए”
  और किसी ने कहा, “Downdetectorsdown का सिलसिला अंतहीन चलता रहेगा”

  • downdetectorsdowndetectorsdowndetector.com लिंक भी शेयर किया गया
  • यह भी आइडिया आया कि अगर कई हों, तो कुछ न कुछ हमेशा down रहेगा, इसलिए उस अनुपात को track करने वाली site होनी चाहिए
  • आख़िरकार यह centralization vs decentralization vs distributed systems का सवाल है
    अगर down detectors एक-दूसरे को heartbeat भेजते हुए monitor करें, तो कुछ के बंद हो जाने पर भी पूरी व्यवस्था चल सकती है
    self-healing architecture जोड़ दी जाए, तो नेटवर्क और भी resilient बन सकता है
  • “down detector अनंत तक चलते जाते हैं” जैसी बात भी दोहराई गई
  • और “Nवें down detector” के रूप में इसे linked list structure बनाने का भी मज़ाक हुआ

• “Sup dawg, I heard you like down detectors” वाला meme-जैसा comment भी आया

• Downdetector का status page भी सीधे शेयर किया गया

• किसी ने कहा, “Cloudflare outage से Downdetector down हुआ, और उसके कारण CloudFront पर भी load आ गया,”
  और चुनौती दी कि ऐसा नया CDN बनाकर दिखाओ जो वह load भी झेल सके

  • लेकिन इस पर एक व्यावहारिक प्रतिक्रिया भी आई: “अगर यह images के बिना static HTML है, तो क्या CDN सच में ज़रूरी है?”

• एक सवाल उठा: “Downdetector ‘normal state’ को detect कैसे करता है?”
  Cloudflare outage के दौरान index page शायद 200 return कर रहा होगा
  अगर headless browser से screenshot लेकर verify करने की कोशिश की जाए, तो Cloudflare शायद उसे block कर देगा

  • असल में यह fake data generate करता है
    script.js का fetchStatus() generateMockStatus() को call करता है और random response times बनाता है
    यानी यह असली status check नहीं करता, बल्कि simulated status data दिखाता है