اختيار الإشارة المناسبة للسؤال
يميز 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 وwebhooks ونطاقات ملفات الارتباط. إن كان المورد قد تحرر، صحح 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
فحوص قبل الاستنتاج
- 1000 + 700 = 1700 تتجاوز مهلة 1500 ملي ثانية.
- مرّر المهلة العامة وامنع تكرار الأثر؛ انتهاء المهلة لا يثبت إلغاء المعالجة البعيدة.
جرّب ميزانية الإعادات
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