सवाल के अनुसार संकेत चुनें
OpenTelemetry में मेट्रिक्स, लॉग और ट्रेस जैसे संकेत अलग हैं। वे एक-दूसरे के पूरक हैं, पूर्ण दृश्यता की गारंटी नहीं। अवधि, मापन बिंदु और अपवाद लिखें; औसत धीमे अनुरोध छिपा सकता है।
| सवाल | उपयोगी संकेत | सीमा |
|---|---|---|
| कितने अनुरोध विफल हैं? | समेकित मेट्रिक्स | विफलता, दायरा और अवधि तय करें। |
| समय कहाँ लगा? | ट्रेस और चरणों का समय | सैंपलिंग और बिना मापन की निर्भरताएँ। |
| क्या घटना हुई? | संरचित लॉग | रहस्य या अतिरिक्त डेटा नहीं। |
| क्या पूरा पथ चलता है? | कार्यात्मक जाँच | एक उदाहरण सभी उपयोग नहीं जाँचता। |
निदान को उपयोगी बनाएँ
- सामान्यीकृत ऑपरेशन के अनुसार ट्रैफ़िक, त्रुटियाँ और अवधि का वितरण मापें। उपयोगकर्ता पहचान और बदलते URL को मेट्रिक लेबल न बनाएँ।
- घटनाओं को सहसंबंध पहचान और सेवा संस्करण से जोड़ें। गायब ट्रेस खोजने से पहले संदर्भ प्रसार और सैंपलिंग नीति जाँचें।
- हर चेतावनी के साथ प्रभाव, ज़िम्मेदार व्यक्ति और पहला कदम रखें। जाँच के लिए अलग खाते लें और अपरिवर्तनीय काम से बचें।
डेटा बचाएँ और परिणाम जाँचें
पासवर्ड, टोकन और संवेदनशील सामग्री लॉग में न रखें; पहुँच और संग्रह अवधि सीमित करें। सफल HTTP उत्तर में भी गलत व्यावसायिक परिणाम हो सकता है। नियंत्रित वातावरण में अपेक्षित नियम और अधिकार भी जाँचें।
प्राथमिक स्रोत
टेलीमेट्री को यूज़र टास्क से कनेक्ट करें
मेट्रिक्स, लॉग और ट्रेस अलग-अलग सवालों के जवाब देते हैं। ज़्यादा अपटाइम से चेकआउट या साइन-इन जर्नी फेल हो सकती है। यूज़र जो नतीजा चाहते हैं, उसे तय करें, फिर उन कॉल्स को इंस्ट्रूमेंट करें जो उसे डिलीवर करें।
- सफलता, लेटेंसी और यूज़र को दिखने वाली फेलियर के लिए एक जर्नी इंडिकेटर चुनें।
- ट्रेस में सेंसिटिव डेटा को लिमिट करते हुए सर्विसेज़ में कोरिलेशन को प्रोपेगेट करें।
- डिपेंडेंसी फेलियर की रिहर्सल करके देखें कि क्या अलर्ट एक्शन और समझने लायक डिग्रेडेड मोड की ओर ले जाते हैं।
प्राथमिक स्रोत: OpenTelemetry — Observability primer. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
संग्रह बाधा: लॉग और गायब घटनाएँ मिलाएँ
बनी, मिली और उपयोगी घटनाएँ अलग करें; मौन को घटना न होने का प्रमाण न मानें।
- एप्लिकेशन, कलेक्टर और भंडारण के जिम्मेदार लिखें। स्थिर पहचानकर्ताओं वाली सीमित काल्पनिक घटना-श्रृंखला तैयार करें, बिना रहस्य या ग्राहक डेटा। घटना और निरीक्षण का समय रखें; संग्रह में देरी स्वतः हानि नहीं है।
- परीक्षण में गंतव्य रोकें और फिर बहाल करें। कतार, प्रयास, अस्वीकृति और पुनः शुरू होना देखें। स्थायी कतार कुछ हानि सीमित कर सकती है, पर क्षमता सीमित और भंडारण पर निर्भर है; पूरी कतार का व्यवहार तय करें। जाँचें कि संग्रह सेवा चुपचाप न रोकता हो।
- एक ही निरीक्षण कटऑफ पर संदर्भ और वास्तव में पढ़ी जाने वाली घटनाएँ मिलाएँ। दोहराव, देरी और गायब घटनाएँ अलग गिनें; नेटवर्क पुष्टि अंतिम उपयोग साबित नहीं करती। विश्वसनीय संदर्भ न हो तो कवरेज अज्ञात है, शून्य हानि या शून्य घटना नहीं।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"expected_ids": [
"E1",
"E2",
"E3"
],
"received_ids": [
"E1",
"E1",
"E3"
],
"received_rows": 3,
"unique_received": 2,
"missing_ids": [
"E2"
],
"observation_cutoff": "same_for_both_sets"
}अपेक्षित निर्णय
काल्पनिक उदाहरण: E1, E2 और E3 अपेक्षित हैं, लेकिन E1, E1 और E3 मिलते हैं। तीन पंक्तियाँ पूर्णता साबित नहीं करतीं: E1 दोहराता है और कटऑफ पर E2 गायब है।
क्या तीन मिली पंक्तियाँ तीन घटनाएँ सुरक्षित होने का प्रमाण हैं?
नहीं। दो पंक्तियाँ वही पहचानकर्ता दोहरा कर गायब घटना छिपा सकती हैं। पहचानकर्ता, निरीक्षण अवधि और श्रृंखला के चरण तुलना करें।
प्राथमिक स्रोत: OpenTelemetry — Collector resiliency. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
छोड़े गए उपडोमेन: नियंत्रण के साथ CNAME हटाएँ
DNS नाम को नियंत्रित संसाधन से जोड़ें और सेवा छोड़ने से पहले निर्भरताएँ बंद करें।
- नाम, CNAME शृंखला, प्रदाता संसाधन और जिम्मेदार व्यक्ति दर्ज करें। DNS को अधिकृत खाते की सूची से मिलाएँ। HTTP त्रुटि, NXDOMAIN या गायब संसाधन जाँच का संकेत है, कब्जे की संभावना का प्रमाण नहीं; प्रदाता सुरक्षा अलग होती है।
- संदर्भ हटाएँ या नियंत्रित लक्ष्य चुनें, फिर संसाधन छोड़ें। पुराने TTL और कैश देखें; प्रामाणिक DNS और कई रिज़ॉल्वर जाँचें। जरूरी स्वामित्व सत्यापन रखें, सभी TXT रिकॉर्ड न हटाएँ।
- लिंक, रीडायरेक्ट, OAuth कॉलबैक, webhook और कुकी डोमेन देखें। संसाधन पहले ही छोड़ा गया हो तो DNS सुधारें और घटना प्रक्रिया से संभावित खुलासे की जाँच करें। हर हटाने के बाद DNS और संसाधन मिलाएँ।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"name": "portal.example",
"cname_present": true,
"resource_deleted": true,
"provider_claimability": "not_verified",
"takeover_observed": false,
"expected": "remove_or_replace_mapping_and_review_exposure"
}अपेक्षित निर्णय
काल्पनिक उदाहरण: portal.example हटाए संसाधन को दिखाता है। CNAME हटाएँ या नियंत्रित लक्ष्य चुनें; गायब संसाधन अकेले तीसरे पक्ष का कब्जा साबित नहीं करता।
प्राथमिक स्रोत: Microsoft — Prevent dangling DNS entries. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
API दोहराव: पूरे समय का बजट गिनें
कॉल, प्रतीक्षा और पूरा प्रवाह अलग रखें।
काल्पनिक शैक्षिक मामला: आँकड़े CIE या ग्राहकों के परिणाम नहीं हैं।
काल्पनिक मॉडल: चार कॉल, हर एक अधिकतम 250 मिलीसेकंड; प्रतीक्षा 100, 200, 400। जिटर, कनेक्शन, कतार और स्थानीय जाँच बाहर हैं।
- कुल प्रयास
- 41 + 3
- कुल प्रतीक्षा (ms)
- 700100 + 200 + 400
- मॉडल बजट (ms)
- 17004 × 250 + 700
| चरण | अधिकतम कॉल (ms) | अगली प्रतीक्षा (ms) |
|---|---|---|
| प्रयास 1 | 250 | 100 |
| प्रयास 2 | 250 | 200 |
| प्रयास 3 | 250 | 400 |
| प्रयास 4 | 250 | 0 |
| कुल | 1000 | 700 |
- कॉल समय1,000
- कुल प्रतीक्षा700
- कुल समय सीमा (ms)1,500
निष्कर्ष से पहले जाँच
- 1,000 + 700 = 1,700 समय सीमा 1,500 मिलीसेकंड से अधिक है।
- कुल समय सीमा आगे दें और दोहरे प्रभाव रोकें; टाइमआउट दूरस्थ रद्द होना सिद्ध नहीं करता।
पुनः प्रयास का बजट आज़माएँ
n × T + W × (2^(n−1) − 1)
संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
संदर्भ: डेटा, उपयोग और सीमाएँ
दस्तावेज़ जाँच की तारीख .
इस संस्करण में विस्तृत संदर्भ टिप्पणियाँ अंग्रेज़ी में उपलब्ध हैं।
| स्रोत और उद्देश्य | सत्यापित डेटा या मानक | उपयोग कैसे करें | ध्यान में रखने योग्य सीमा |
|---|---|---|---|
| NIST · SP 800-61 Rev. 3 Prepare incident response within cybersecurity risk management. |
Revision 3 was published in April 2025 and supersedes Revision 2. It is a CSF 2.0 Community Profile. | Rehearse containment decisions, evidence preservation, communication and recovery. Compare planned actions with evidence produced during the exercise. | Reading the guide does not validate a local plan. Contacts, emergency access and dependencies need local testing. |
| Google · Core Web Vitals Distinguish loading, responsiveness and visual stability. |
Good thresholds are LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1 at the 75th percentile, segmented by mobile and desktop. | Separate field measurement from laboratory tests. Record period, URL, device, population and sample size before comparing changes. | These thresholds are not measured results for this site. A good lab score alone does not establish visitor experience. |
API अप्रचलन और समाप्ति
इस संस्करण में विस्तृत संदर्भ टिप्पणियाँ अंग्रेज़ी में उपलब्ध हैं।
Announced retirement and continuity to verify
A Sunset field signals intent; it establishes neither actual shutdown nor guaranteed continuity until then. Prepare dependencies, data and access to move.
- Identify the announcement’s exact scope and owner.
- Keep dates and updates with receipt evidence.
- Test exit, in-flight operations and removal of obsolete access.
Compare deprecation and retirement announcements →
IETF · RFC 9745 · Deprecation · Standards Track · March 2025 · §2–5 · consulted 2026-10-23
IETF · RFC 8594 · Sunset · Informational · May 2019 · §3–5, §8 · consulted 2026-10-23