בחירת האות לשאלה
OpenTelemetry מבחין בין היתר במדדים, יומנים ועקבות. הם משלימים זה את זה ללא הבטחת כיסוי מלא. תעדו חלון מדידה, מכשור והחרגות; ממוצע עלול להסתיר בקשות אטיות.
| שאלה | אות מועיל | מגבלה |
|---|---|---|
| כמה בקשות נכשלות? | מדדים מצטברים | להגדיר כשל, היקף ותקופה. |
| היכן הושקע הזמן? | עקבה ומשכי שלבים | דגימה ותלויות ללא מכשור. |
| איזה אירוע התרחש? | יומן מובנה | ללא סודות או נתונים מופרזים. |
| האם המסלול עובד? | בדיקה תפקודית | תרחיש אחד אינו מכסה הכול. |
אבחון שאפשר לפעול לפיו
- מדדו תעבורה, שגיאות והתפלגות משכים לפי פעולה מנורמלת. הימנעו ממזהי משתמשים וכתובות משתנות כתוויות מדדים.
- קשרו אירועים למזהה מתאם ולגרסת השירות. בדקו העברת הקשר ומדיניות דגימה לפני חיפוש עקבה חסרה.
- לכל התראה הגדירו השפעה, אחראי ופעולה ראשונה. השתמשו בחשבונות ייעודיים לבדיקות והימנעו מפעולות בלתי הפיכות.
הגנת נתונים ובדיקת תוצאות
אל תרשמו סיסמאות, אסימונים או תוכן רגיש ביומנים; הגבילו גישה ושמירה. הצלחת 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. אינו כולל jitter, חיבור, תורים ובדיקה מקומית.
- כל הניסיונות
- 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 מילישניות.
- העבירו מועד כולל ומנעו השפעות כפולות; timeout אינו מוכיח ביטול מרוחק.
נסו תקציב ניסיונות
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