एक सिस्टम के लिए स्वास्थ्य जांच का दायरा क्या होना चाहिए जो एक वेबलॉपी को तैनात करता है?

Question

आज मेरे पास एक लंबे समय से चल रही सेवा के लिए "स्वास्थ्य जांच लिखने" का एक कार्य था जो एक वेब-ऐप को तैनात करने के लिए एक आर्केस्ट्रा सिस्टम है।

मैं यह निर्धारित करने की कोशिश कर रहा हूं कि इस तरह की स्वास्थ्य जांच की गुंजाइश क्या होगी, और स्वास्थ्य जांच के दायरे से संबंधित इन सवालों के साथ आया था:

1. क्या यह सेवा को स्वस्थ मानने के लिए पर्याप्त है अगर ऑर्केस्ट्रेशन सिस्टम रिपोर्ट करता है कि कार्य चल रहा है?
2. या क्या हमें प्रत्येक सेवा को मैन्युअल रूप से पिंग करना चाहिए?
3. या इसे और आगे जाना चाहिए और यह सुनिश्चित करने का प्रयास करना चाहिए कि वेब-ऐप वही करता है जो उसे करना चाहिए, जैसे वेब पेज दिखाना?
4. क्या हेल्थकेयर को यह भी जांचना होगा कि कुछ निर्भर सेवाएं भी चल रही हैं? डेटाबेस या ऑर्केस्ट्रेशन सिस्टम की ही तरह। या कि एक और स्वास्थ्य जांच की जिम्मेदारी है?
5. और सबसे आखिर में, यदि आश्रित सेवाओं में से कोई एक मृत है, और वेब-ऐप बाद में विफल हो जाता है, तो क्या वेब-ऐप को खराब स्वास्थ्य की रिपोर्ट करनी चाहिए, या क्या यह अच्छा स्वास्थ्य है, क्योंकि यह वेब-ऐप की गलती नहीं है?

मुझे पता है कि ये 5 अलग-अलग प्रश्न हैं, लेकिन ये सभी लंबे समय तक चलने वाली सेवा के लिए स्वास्थ्य जांच के दायरे से संबंधित हैं, जो एक वेब ऐप को प्रदर्शित करता है, इसलिए मैंने सोचा कि उन्हें एक ही प्रश्न में बांधे रखने के लिए अधिक समझदारी होगी।

यह मेरे लिए लागू करना कठिन है क्योंकि मुझे यकीन नहीं है कि स्वस्थ क्या है, या इस तरह की चीज के लिए एक मानक स्वास्थ्य जांच की परिभाषा क्या दिखनी चाहिए।

इस विशिष्ट सेवा के लिए स्वास्थ्य जांच क्या होनी चाहिए?

Comments

स्वचालित स्थिति रिपोर्ट पर कभी विश्वास न करें। हमेशा स्टेटस खुद चेक करें। ट्रिविया: ट्री माइल द्वीप की घटना के कारणों में से एक "वाल्व बंद" संकेतक था जो वास्तव में केवल संकेत देता था कि "क्लोज वाल्व" कमांड जारी किया गया था , न कि यह कि वाल्व वास्तव में बंद था ।

— किलियन फोथ

@KilianFoth: एक समान नोट पर: मैं एक कंपनी को जानता हूं जिसने धार्मिक और अच्छी तरह से परीक्षण किया कि उनके बैकअप ने काम किया। फिर, एक दिन, उनके पास एक भयावह डिस्क विफलता थी और पता चला: उनकी पुनर्स्थापना नहीं थी।

— Jörg W Mittag

मैं सोच रहा हूं कि यह उस व्यक्ति का काम है जिसने आपको "स्वास्थ्य" द्वारा परिभाषित करने के लिए "स्वास्थ्य जांच लिखने" के लिए कहा है। अन्यथा, यह सिर्फ अनुमान है।

— जोर्ग डब्ल्यू मित्तग

मैं @ JörgWMittag टिप्पणी से सहमत हूं, लेकिन मैं इसे एक कदम आगे भी ले जाऊंगा। आपको अपनी आवश्यकताओं को न केवल उस व्यक्ति से प्राप्त करना चाहिए जिसने आपको बताया था कि आपको "स्वास्थ्य जांच" डिजाइन करने की आवश्यकता है, बल्कि यह भी पता करें कि वे लोग या सिस्टम कौन हैं जो डेटा का उपयोग करते हैं जो स्वास्थ्य जांच का हिस्सा है और वे क्या जानते हैं जरूरत है या उन्हें इसकी जरूरत कैसे है। ये आपकी आवश्यकताएं हैं जो आपके डिज़ाइन को चलाएंगी।

— थॉमस ओवेन्स

मैंने इसे थोड़ा स्पष्ट किया और फिर से मतदान किया क्योंकि मुझे लगता है कि मूल प्रश्न विषय पर है। यह समझना कि कैसे एक हेल्थकेयर में शामिल किया जाना चाहिए, सॉफ्टवेयर डिजाइन के लिए एक पूरी तरह से सामान्य बात है, भले ही असली जवाब "आवश्यकताओं के लिए पूछें" (या उस पर एक भिन्नता) हो।

— एंडरलैंड

Answer 1

स्वस्थ होने की परिभाषा के कारण इसे लागू करना कठिन है

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

अपने आप से पूछने के लिए एक अच्छा सवाल है, "पूछने वाले के दृष्टिकोण से, क्या चेक की गई सेवा उम्मीद के मुताबिक काम कर रही है?" यदि यह आप हैं, तो आप इसे परिभाषित करते हैं। यदि यह एक और टीम / सेवा है, तो आपको यह पहचानने की आवश्यकता है कि हेल्थचेक के मानक / विनिर्देश क्या हैं।

एक बड़े संगठन में संभवत: आपके पास कुछ प्रकार के मानक होंगे जो एक स्वास्थ्य परीक्षण करना चाहिए। उसका पता लगाओ।

विशेष रूप से यहाँ, आपके वेबएप्प उदाहरण का अर्थ है कि यह स्वस्थ नहीं लौटना चाहिए क्योंकि वेबप स्वस्थ नहीं है। लेकिन शायद "स्वस्थ" की आपकी परिभाषा में इसे "ठीक" के रूप में शामिल किया जाएगा। यह ऊपर चर्चा आवश्यकताओं का हिस्सा है (फिर, भले ही यह सिर्फ आपका अपना कोड हो)।

मेरी सिफारिश यह मानते हुए कि यह कहीं और निर्दिष्ट नहीं है, किसी न किसी तरह का स्थिति कोड अलग-अलग विफलताओं से जुड़ा होगा। जब आप वेबएप को क्वेरी करते हैं, तो यह एक त्रुटि लौटा सकता है जो कहता है कि "निर्भर सेवा मर चुकी है" और इसलिए आपका क्लाइंट (या जो कुछ भी स्वास्थ्य जांच कर रहा है) ग्राहक के मृत होने का कारण जान सकता है।

संपादित सवालों के लिए:

क्या यह सेवा को स्वस्थ मानने के लिए पर्याप्त है अगर ऑर्केस्ट्रेशन सिस्टम रिपोर्ट करता है कि कार्य चल रहा है?

नहीं, सिर्फ इसलिए कि एक प्रक्रिया चल रही है इसका मतलब यह नहीं है कि यह लटका हुआ नहीं है, पूरी तरह से गैर-कानूनी है, या अन्य संभावनाओं की एक बड़ी विविधता है।

या क्या हमें प्रत्येक सेवा को मैन्युअल रूप से पिंग करना चाहिए?

यह आपके एप्लिकेशन की कार्यक्षमता के दायरे के आधार पर काम कर सकता है। यदि सेवा का सत्यापन करने पर "क्या आप जीवित हैं?" पिंग तब यह सब आवश्यक हो सकता है। लेकिन अगर सेवा आसानी से "जीवित और उत्तरदायी हो सकती है लेकिन वास्तव में काम नहीं कर रही है" तो शायद आपको अन्य चीजों को भी जांचना होगा।

या इसे और आगे जाना चाहिए और यह सुनिश्चित करने का प्रयास करना चाहिए कि वेब-ऐप वही करता है जो उसे करना चाहिए, जैसे वेब पेज दिखाना?

आपकी स्वास्थ्य सेवा को यह सुनिश्चित करने की आवश्यकता है कि अपेक्षित कार्यक्षमता अपेक्षित कार्य है।

आप साथ ही सम्पूर्ण healthcheck से छुटकारा मिल सकता अपने अनुप्रयोग रिटर्न "स्वस्थ" और यह क्या करने की जरूरत नहीं कर सकते, तो के रूप में यह झूठे सकारात्मक दे देंगे (भ्रमित उल्लेख बिल्ली समस्या डिबग करने के लिए कोशिश कर रहा है लोगों में से - 'हे हमारा वेबसर्वर स्वस्थ दिखाता है, हम पृष्ठ क्यों नहीं देख सकते? ')।

क्या हेल्थकेयर को यह भी जांचना होगा कि कुछ निर्भर सेवाएं भी चल रही हैं? डेटाबेस या ऑर्केस्ट्रेशन सिस्टम की ही तरह। या कि एक और स्वास्थ्य जांच की जिम्मेदारी है?

यह कुछ हद तक निर्भर करता है। यदि आपकी सेवा किसी अन्य सेवा पर निर्भर करती है, तो उस इंटरैक्शन की प्रकृति को आपके ऐप में भेजे गए एपीआई / नेटवर्क कॉल में परिलक्षित होना चाहिए और हेल्थचेक में शामिल किया जाना चाहिए।

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

हालांकि, यदि आपकी सेवा उन उपभोक्ताओं को ईवेंट भेज रही है जो बिना किसी मान्यता के सुनते हैं, तो यह आपके ऐप की कार्यक्षमता के लिए कम महत्वपूर्ण है कि उपभोक्ता जीवित हैं। आपके एप्लिकेशन को "स्वस्थ" संदेश भेज रहा है, वास्तव में उन्हें प्राप्त नहीं कर रहा है।

मूल रूप से, यदि आपकी सेवा को अन्य सेवाओं के साथ बात करने और अपने स्वास्थ्य को सत्यापित करने की आवश्यकता है, तो इससे कम से कम आपकी सेवा के स्वास्थ्य परीक्षण के लिए एक बुनियादी स्तर की जाँच हो सकती है। यह वैचारिक रूप से दिया जाना चाहिए जो मैंने अभी कहा है क्योंकि आपका आवेदन पहले से ही इसे संभाल रहा होगा (या बेतरतीब ढंग से दुर्घटनाग्रस्त हो रहा है, मुझे लगता है)।

और सबसे आखिर में, यदि आश्रित सेवाओं में से कोई एक मृत है, और वेब-ऐप बाद में विफल हो जाता है, तो क्या वेब-ऐप को खराब स्वास्थ्य की रिपोर्ट करनी चाहिए, या क्या यह अच्छा स्वास्थ्य है, क्योंकि यह वेब-ऐप की गलती नहीं है?

यह मूल रूप से ऊपर उत्तर दिया गया है। मेरी सिफारिश होगी कि आपका स्वास्थ्य परीक्षण एक कोड / संदेश / जो कुछ भी यह जानकारी देता है, उसे लौटा दें। जानकारी के दोनों टुकड़े महत्वपूर्ण हैं: यह कि आपकी सेवा के लिए आश्रित सेवा मृत है और परिणामस्वरूप आपकी सेवा अपेक्षित रूप से काम नहीं करेगी।

Answer 2

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

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

आश्रित प्रणालियों की जांच करना स्वास्थ्य जांच का हिस्सा नहीं है, आपको इसे सरल और स्व-निहित रखने की आवश्यकता है। बदले में प्रत्येक आश्रित सेवा के लिए एक स्वास्थ्य जांच जोड़ें। इस तरह से आप चलने की एक सूची प्राप्त कर सकते हैं, स्वस्थ प्रणाली और आसानी से बता सकते हैं कि जब कोई खराब होता है, तो वह कौन सा है!

Comments

सिस्टम में मैं लिख रहा हूं, मैं बस इसके संस्करण की जानकारी के लिए प्रत्येक निर्भर सेवा को क्वेरी करता हूं। यदि यह समय पर तरीके से प्रतिक्रिया करता है (मेरे मामले में 2500ms) तो इसे "ऊपर" माना जाता है। मैं उन सभी को समानांतर रूप से क्वेरी करता हूं, इसलिए मेरी सबसे खराब स्थिति प्रतिक्रिया समय है।

— TM32

Answer 3

मेरे अनुभव में, महत्वपूर्ण सेवाओं में निम्नलिखित विशेषताएं हैं:

दिल की धड़कन

यदि सेवा नियमित रूप से चलती है, तो यह बस लॉग फ़ाइल के लिए एक पंक्ति या टाइमस्टैम्प के साथ इसी तरह लिखती है कि यह इंगित करने के लिए कि सेवा निकाय एक निश्चित समय पर किक करता है।

ब्रेडक्रम्ब्स

उपर्युक्त के समान, ब्रेडक्रंब आमतौर पर यह दिखाने के लिए विधि नाम (और कभी-कभी मापदंडों) का एक डंप है कि सेवा सेवा निकाय को अपेक्षित रूप से संसाधित कर रही है और प्रवाह में ठिकाना है। चूंकि ये अधिक आउटपुट उत्पन्न कर सकते हैं, ये आमतौर पर कॉन्फिग फाइलों या इसी तरह से नियंत्रित होते हैं ताकि सर्विस बंद होने के बाद इन्हें बंद कर दिया जा सके।

---

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