सीडीएन का उपयोग कर रहे एक उच्च उपलब्धता ऐप को मापने के लिए एक सिफारिश की तलाश है

Question

मैं एक फॉर्च्यून 500 कंपनी के लिए काम करता हूं जो उच्च उपलब्धता अनुप्रयोगों (यानी, ऐसे ऐप्स हैं जो 5 सेकंड के पेज से पेज नेविगेशन पर 99.5% तक हैं) के लिए सटीक माप प्रदर्शन और उपलब्धता के साथ संघर्ष करता है। हम इस उपलब्धता संख्या को निर्धारित करने के लिए अनुसूचित और अनिर्धारित डाउनटाइम दोनों में कारक हैं। हालाँकि, हमने हाल ही में इस मिश्रण में एक CDN जोड़ा है, जो हमारे मेट्रिक्स को थोड़ा जटिल करता है। CDN अब हमारे ट्रैफ़िक का लगभग 75% संभालती है, जबकि शेष हमारे अपने सर्वर को भेजती है।

हम यह मापने का प्रयास करते हैं कि हम एक "सच्चे उपयोगकर्ता अनुभव" को क्या कहते हैं (यानी, हमारी परीक्षण स्क्रिप्ट एक विशिष्ट उपयोगकर्ता को एप्लिकेशन के माध्यम से क्लिक करने का अनुकरण करती है।) ये निगरानी स्क्रिप्ट हमारे नेटवर्क के बाहर बैठती हैं, जिसका अर्थ है कि हम सीडीएन को लगभग 75% मार रहे हैं। समय।

प्रबंधन ने फैसला किया है कि हम उपलब्धता को मापने के लिए सबसे खराब स्थिति में हैं। इसलिए यदि हमारे मूल सर्वर में समस्याएँ हैं, लेकिन अभी तक सीडीएन ठीक सामग्री परोस रहा है, तो हम अभी भी उपलब्धता पर जोर दे रहे हैं। यही सच दूसरे तरीके से भी है। मेरा विचार है कि जब तक "उपयोगकर्ता अनुभव" सफल होता है, हमें अनावश्यक रूप से खुद को दंडित नहीं करना चाहिए। आखिरकार, प्रदर्शन और उपलब्धता में सुधार के लिए एक सीडीएन है!

मैं सोच रहा हूं कि क्या किसी को इस बात का ज्ञान है कि अन्य फॉर्च्यून 500 कंपनियां अपनी उपलब्धता संख्या की गणना कैसे करती हैं? उदाहरण के लिए, मैं Apple.com को देखता हूं, एक स्टोर के सामने जो एक CDN का उपयोग करता है जो कभी भी डाउन नहीं लगता है (जब तक कि कोई बड़ी उत्पाद घोषणा नहीं होती है।) कुछ कठिन, तथ्यात्मक डेटा होना बहुत अच्छा होगा क्योंकि मैं डॉन हूं। 'यह विश्वास नहीं है कि हमें इन मैट्रिक्स पर अनावश्यक रूप से चोट पहुँचाने की आवश्यकता है। हम इन नंबरों के आधार पर व्यावसायिक निर्णय ले रहे हैं ।

हालाँकि, मैं कह सकता हूँ कि ये मैट्रिक्स प्रबंधन के लिए दृश्यमान हैं, मुद्दों को संबोधित किया जाता है और बहुत तेजी से हल किया जाता है (पढ़ें: हम लाल-टेप के माध्यम से बहुत तेज कटौती करते हैं।) दुर्भाग्य से, एक डेवलपर के रूप में, मुझे लगता है कि प्रबंधन नहीं चाहिए। यह कि आवेदन ऊपर या नीचे है क्योंकि कुछ बाहरी कारक (यानी, CDN) संख्या को प्रभावित कर रहे हैं।

विचार?

(मैंने गलती से StackOverflow पर यह प्रश्न पोस्ट कर दिया, क्रॉस-पोस्ट के लिए अग्रिम रूप से खेद है)

Answer 1

अमूर्त में, मैं कहूंगा कि आपको "उपलब्ध" बनाम "अनुपलब्ध" के रूप में तेजी से परिभाषित करना चाहिए और इसके खिलाफ खुद को मापना चाहिए। उदाहरण के लिए, आप 1 सेकंड की साइट के लिए "गुना" और पूरी तरह से प्रदान किए गए पृष्ठ के लिए 3 सेकंड के लिए क्लाइंट-साइड प्रदर्शन SLA हो सकते हैं। जब आप प्रदर्शन SLA को पूरा नहीं करते हैं, तो आपको उस समय अवधि के लिए उपलब्धता विफलता के रूप में गिनना चाहिए। इससे कोई फर्क नहीं पड़ता कि आप सीडीएन को मार रहे हैं या नहीं - उपयोगकर्ता अनुभव यही मायने रखता है।

हालाँकि, चूंकि आप केवल हर 5 मिनट में माप ले रहे हैं, इसलिए सीडीएन बनाम मास्टर साइट पर हिट को मापना उचित है, और गणना करें कि उपलब्धता का 75% सीडीएन और मास्टर से 25% से आ रहा है। यहां मुश्किल यह है कि 75% सिर्फ एक औसत है। एक निश्चित समयावधि के लिए सटीक रूप से दोष लगाने के लिए, आपको यह जानना होगा कि जब एक या दूसरी साइट वास्तव में ग्राहक-सामना नहीं कर रही है, उदाहरण के लिए, एक नियोजित परिवर्तन के दौरान या किसी समस्या का पता चलने पर मैन्युअल कार्रवाई के बाद। मास्टर साइट या सीडीएन में से किसी एक के डाउन होने पर आपको भी क्या करना चाहिए। क्या ग्राहक को HTTP 500 मिलता है, या क्या वे कार्य स्थल पर पारदर्शी रूप से विफल हो जाते हैं? आपके लोड संतुलन समाधान पर बहुत कुछ निर्भर करता है। आपके द्वारा वर्णित "सबसे खराब स्थिति" वाली मीट्रिक बहुत सरल लगती है। अपने आप से पूछो, "

जब तक कि सीडीएन डाउन होने पर आपको "दोष" लेना चाहिए: बिल्कुल। यदि आपका 75% हिट सीडीएन में जा रहा है, तो आपके ग्राहक अनुभव का 75% उन पर निर्भर है। आप अपने ग्राहकों को एक अच्छा अनुभव प्रदान करने के लिए जिम्मेदार हैं, इसलिए यदि CDN में समस्याएँ हैं, तो आपको इसे साबित करने और प्रदाता के साथ अनुसरण करने के लिए अपने इंजीनियरिंग संसाधनों का उपयोग करने की आवश्यकता है।

एक अन्य बात यह सोचने की है कि जब मास्टर साइट समय की विस्तारित अवधि के लिए अनुपलब्ध होती है, तो क्या होता है। जैसा कि आपने इसे वर्णित किया है, ऐसा लगता है कि सीडीएन मास्टर साइट पर सामग्री की एक स्थिर प्रतिलिपि है। यदि मास्टर साइट लंबे समय तक डाउन रहती है, तो सीडीएन को बासी होना शुरू हो सकता है। तो शायद आपके SLA का हिस्सा नयापन होना चाहिए: 1 सेकंड "गुना" और पूरी तरह से रेंडर किए गए पेज के लिए 3 सेकंड, सामग्री 15 मिनट से अधिक पुरानी न हो।

Comments

@ user44700: यहाँ चाल दुगुनी है - सीडीएन आपके द्वारा वर्णित के समान एक टन मैट्रिक्स प्रदान करता है ... और मूल सर्वर पर हर 5 मिनट में हमारे अपने आंतरिक परीक्षण होते हैं। सीडीएन बनाम आंतरिक से डेटा बिंदुओं की परिमाण पूरी तरह असंतुलित है, फिर भी वे बहुत इलाज कर रहे हैं जैसे कि वे संतुलित थे (यानी, (सीडीएन + आंतरिक) / 2 = अपटाइम) ... मुझे विश्वास नहीं है कि प्रबंधन बुनियादी आंकड़ों को समझता है ... :)

— टिम रेड्डी 19

Answer 2

मैं उपयोगकर्ता44700 से सहमत हूं, अपने सर्वर बनाम सीडीएन के लिए उपलब्धता परीक्षण को अलग करना और दो स्वतंत्र रूप से ट्रैक करना बेहतर है। आपकी सच्ची उपलब्धता सर्वर Avail * CDN Avail होगी, यदि या तो नीचे जाती है - आप इस पर विचार कर रहे हैं कि आपका पृष्ठ / साइट नीचे है। यह आपको किसी भी निगरानी विक्रेताओं के साथ कम खर्च होगा।

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

आप इस ब्लॉग पोस्ट को कुछ और विचारों के लिए पढ़ सकते हैं: http://blog.catchpoint.com/2010/07/21/true-avavour-of-a-webpage/

Comments

लिंक के लिए धन्यवाद ... हम उस लेख के अनुरूप एक तरीके से बहुत अधिक / उपाय करते हैं।

— टिम रेड्डी

Answer 3

एसएलए रिपोर्टिंग वास्तव में वास्तविकता को प्रतिबिंबित करना चाहिए। यदि आप उपयोगकर्ता के दृष्टिकोण से उपलब्धता को माप रहे हैं और केवल मापने वाले सर्वर को समस्याओं का सामना करना पड़ रहा है, तो आपके SLA के भीतर उस समस्या की रिपोर्ट करना उपयोगकर्ता अनुभव को प्रतिबिंबित नहीं करेगा।

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

यदि आप समझौते पर नहीं आ सकते हैं, तो शायद मापने वाले सर्वर को कम गिरने योग्य बनाने के लिए एक तकनीकी समाधान है।

यदि सूचना को आउटेज के रूप में रिपोर्ट किया जाता है और यह नहीं था, तो रिपोर्टिंग किस मूल्य प्रदान करती है?

मेरे वातावरण में, हम कई स्रोतों से रिपोर्ट करते हैं। बाहरी निगरानी से उपलब्धता की रिपोर्ट करने के साथ-साथ हमारे आंतरिक आउटेज रिकॉर्डिंग सिस्टम की रिपोर्टिंग के लिए एक बाहरी निगरानी पद्धति, जो मानव में प्रवेश की है और कई कारकों पर विचार करती है जो स्थिति को सबसे सटीक रूप से दर्शाते हैं।

Comments

@Warner: दुर्भाग्य से, मैट्रिक्स को चलाने वाला सर्वर ठीक वही है जो प्रबंधन "उपयोगकर्ता अनुभव" पर विचार करता है। प्रत्येक परीक्षण 5 मिनट के अलावा है, इसलिए मूल रूप से हमारे सभी "आउटेज" वास्तविक आउटेज समय की परवाह किए बिना 5 मिनट की वृद्धि में हैं (यह 1 सेकंड हो सकता है।) हमारा सीडीएन इसे परिप्रेक्ष्य से मैट्रिक्स प्रदान करता है, और यह एक से अधिक दानेदार है। हर 5 मिनट में परीक्षण करें ... मैं इन्हें अलग से रिपोर्ट करना चाहूंगा। दुर्भाग्य से, प्रबंधन ने हर एक आवेदन को लेने का फैसला किया है, सबसे खराब स्थिति को चुनें, और रिपोर्ट करें कि ... जो एक वास्तविक एसएलए को प्रतिबिंबित नहीं करता है ...

— टिम रेड्डी

यह लगभग ऐसा लगता है जैसे वे तकनीकी विवरण को नहीं समझते हैं और स्थिति पर भरोसा नहीं करते हैं, इस प्रकार वे सटीकता का बीमा करने के लिए सबसे खराब स्थिति में चूक कर रहे हैं।

— वार्नर

आपने कुछ इस तरह की संभावना पर विचार किया है, लेकिन एक प्रमुख कार किराए पर लेने की कंपनी के लिए आरक्षण डेटाबेस का समर्थन करने वाले पूर्व नौकरी जीवन में, हमने वेबसाइट पर प्रवेश करने और किसी विशेष के लिए एक दर प्राप्त करने के लिए हमें "रीड्स" देने के लिए Gomez.com का उपयोग किया। किराये पर लेना। हमारी विशेष परिस्थितियों में इसने प्रबंधन को उस तरह के गेज की जरूरत दी। साइट के लिए सभी गोल पांच 9 के थे।

— जेएल

Answer 4

गोमेज़ और कीनोट आपके द्वारा उल्लिखित मीट्रिक के प्रकारों को इकट्ठा करने के लिए उद्यम-स्वीकृत समाधान हैं। गोमेज़ की एक सेवा भी है जो आपके एंड्यूज़र यूएक्स पर नज़र रखती है, जो एक गूगल-एनालिटिक्स-एस्क जावास्क्रिप्ट फाइल को सोर्स करता है।

Answer 5

Phatt अच्छा है: http://www.phatt.com/

Comments

सवाल यह नहीं था कि किस सेवा का उपयोग किया जाए। यह वर्णित मामले परिदृश्य से निपटने के लिए है।

— जॉर्जू

Answer 6

हम CDN- सक्षम साइट के साथ फॉर्च्यून 500 हैं, और हम कई चीजों का उपयोग करते हैं। आपने सही तरीके से निर्धारित किया है कि आपको अलग-अलग चीजों को मापने की आवश्यकता है यदि आप अलग-अलग चीजों का पता लगाना चाहते हैं। यह मेरे लिए स्पष्ट नहीं है कि आप विशेष रूप से क्या चाहते हैं - उपलब्धता संख्या यह निर्धारित करने में आपकी सहायता के लिए कि कोई ऐप वास्तव में डाउन है, या नंबर जो आपके बैक से प्रबंधन प्राप्त करते हैं। वैसे भी ...

1. बाहरी सिंथेटिक निगरानी - कीनोट / गोमेज़ / वेबमेट्रिक्स। हम कीनोट का उपयोग करते थे, अब हम गोमेज़ का उपयोग करते हैं। बेशक, जैसा कि आप ध्यान दें कि इसमें सीडीएन और अन्य बाहरी घटक शामिल हैं - जो आपके समग्र एसएलए को मापने के लिए अच्छा है, लेकिन आपके अनुप्रयोगों के एसएलए को निर्धारित करने के लिए इतना अच्छा नहीं है।

"CDN इसे से बाहर" पाने के लिए यदि आप किसी अन्य मुख्य वक्ता के रूप / गोमेज़ पर नजर रखने के लिए ले सकें और अपने एप्लिकेशन में यह बात कर सकता है नहीं एक वैकल्पिक DNS नाम या whatnot का उपयोग कर CDN के माध्यम से। लेकिन चूंकि इसमें अभी भी स्थैतिक संपत्ति है, इसलिए यह उपलब्धता की तुलना में प्रदर्शन के लिए अधिक उपयोगी है। और यह लूप में इंटरनेट आउटेज, एजेंट आउटेज आदि को रखता है, जो कुछ उद्देश्यों के लिए उपयुक्त है और अन्य नहीं।

2. वास्तविक उपयोगकर्ता निगरानी। नेटवर्क-आधारित (Coradiant, Tealeaf) और टैग-आधारित (Jiffy, Gomez) है। हम एक नेटवर्क स्निफर के रूप में कोराडिएंट का उपयोग करते हैं और यह हमारे डेटा सेंटर में यहां होस्ट की गई परिसंपत्तियों के वास्तविक उपयोगकर्ता-देखा प्रदर्शन को निर्धारित करता है- दूसरे शब्दों में, वास्तविक एप्लिकेशन और सीडीएन पर सभी स्थिर कबाड़ नहीं। हमने तब एप्लिकेशन त्रुटि दर और प्रदर्शन को निर्धारित करने के लिए रिपोर्ट लिखी और एक व्युत्पन्न मीट्रिक के रूप में Apdex (apdex.org) का उपयोग किया। कुछ मामलों में आप नेटवर्क आधारित (बहुत अधिक ट्रैफ़िक का उपयोग नहीं कर सकते हैं, या आपकी परिसंपत्तियाँ होस्ट नहीं की जा सकती हैं जहाँ आप नेटवर्क पर पहुँच सकते हैं), और टैग-आधारित वह विश्वसनीय नहीं है। वास्तव में अंतिम उपयोगकर्ता प्रतिक्रिया समय और त्रुटियों को देखने का अत्यधिक लाभ है - एक सिंथेटिक मॉनिटर स्थापित करना आसान है जो सभी मामलों में त्रुटि नहीं करता है जो एक वास्तविक उपयोगकर्ता करता है।

3. स्थानीय सिंथेटिक निगरानी। नागियोस / ज़ैबिक्स / साइटस्कोप / सौ अन्य। स्थानीय रूप से अपने ऐप पर एक मॉनिटर इंगित करें (सीडीएन के माध्यम से न जाएं)। कार्रवाई करने योग्य (जैसा कि, किसी को जगाने के लिए एक पृष्ठ भेजें) उपलब्धता की निगरानी, ​​यह सोने का मानक है। नेटवर्क सामान को ध्यान में नहीं रखता है।

4. लॉग मॉनिटरिंग। एक मायने में, यह यहूदी बस्ती वास्तविक उपयोगकर्ता निगरानी है। लेकिन अगर आप वास्तव में देखना चाहते हैं कि कब क्या गड़बड़ है, तो यह बहुत आसान है। वास्तविक उपयोगकर्ता की निगरानी का "कोई वास्तव में ऐसा नहीं हुआ है" लाभ हुआ है। केवल तब तक उपलब्धता, जब तक आप वेब टियर पर लॉग-इन नहीं कर रहे हैं, उस स्थिति में यह दिखाता है कि आपका सर्वर अंत कितना समय ले चुका है - SLA का सामना करने वाले उपयोगकर्ता के लिए सहायक नहीं है, लेकिन "किस कोड के लिए हमें काम करने की आवश्यकता है" के लिए बहुत उपयोगी है । " स्प्लंक का प्रयोग करें।

यह या तो नहीं है या, हम इन सभी का उपयोग करते हैं, क्योंकि आप "अंत उपयोगकर्ता कहानी" के साथ-साथ "किस प्रोग्रामर पर हमें दुबला होने की आवश्यकता है" चाहते हैं।

Answer 7

BrowserMob बढ़िया है