איך לקרוא אובדן מנות לפני שמאשימים את הכבל

אובדן של שני אחוזים לאורך ריצת ping ארוכה מרגיש כמו מספר שאפשר לפעול לפיו, ולעיתים רחוקות זה כך. הוא אינו אומר היכן נעלמו התגובות, אם הן נעלמו יחד, או כיצד יישום מסוים חווה את המרווח הזה. אובדן שמפוזר באופן אחיד על פני דקה ואובדן שמצטבר בתוך חילוף אחד מניבים תוצאות שונות מאוד עבור אותו אחוז.

השוו שלוש מדידות במקום לסמוך על אחת: מה ראה הגשש, מה עשו מוני הממשק ומה היישום באמת חיכה לו.

מה אחוז ping באמת מודד

גשש הד מעביר כיוון אחד של פרוטוקול אחד בגודל מנה אחד, בקצב שתבחרו. מנהרה שנושאת העלאה גדולה עושה משהו אחר לגמרי, וקישור שמפיל גששים קטנים אינו בהכרח הקישור שמזיק להעברה. האחוז גם מרסק את מידע התזמון החשוב ביותר, כי עשר תגובות שאבדו בהתפרצות אחד אינן זהות לעשר תגובות שאבדו בהפרש של שעה. הוא גם אינו יכול לומר לכם איזה צד של המנהרה הפיל משהו.

שמרו את תוצאת הגשש כרמז לגבי הנתיב. לאחר מכן חפשו את התזמון ואת הגבול שיצרו אותה.

השוו הפרשי מונים, לא סכומים לכל החיים

קחו קריאות עם חותמת זמן לפני ואחרי החלון שבו הופיע התסמין, בשני הקצוות ובכל פורט מתג שאתם שולטים בו. רשמו את נפח התעבורה לצד שגיאות, השלכות ושינויי מצב קישור, כי סכום שאינו אפס שנצבר במשך חודשים מתאר היסטוריה ולא את האירוע הזה. מונה שזז בשלוש במהלך העצירה הוא תצפית שונה ממונה שמראה שלושת אלפים ומעולם לא השתנה.

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

מנות שנזרקו בגלל שגיאות קליטה ומנות שנזרקו מסיבות אחרות חיות במונים נפרדים, וההבחנה הזו משנה את המשך הבדיקה. מוני שגיאות מצביעים על השכבה הפיזית או על שכבת הכונן, בעוד שלחץ תורים והשלכות מדיניות מצביעים על מקום גבוה יותר. שמרו גם את הכיוון ואת שם הממשק, כי עלייה בשגיאות קליטה בקישור עולה ומונה מנות מנהרה אינם ניתנים להחלפה.

אם כונן חושף מונים פיזיים מפורטים, קראו אותם דרך התיעוד של אותו מתאם. ייחוס משמעות אחת לכל שדה בשם “drop” אצל שני יצרנים הוא הדרך שבה מוזרות חשבונאית רגילה הופכת לאבחנת חומרה.

איך קטע שאבד הופך להמתנה ארוכה

יישום יכול להמתין הרבה יותר מהליכה וחזרה אחת לאחר שאיבד קטע. TCP מעריך את זמן ההליכה והחזרה, מחשב טיימר שידור חוזר מההערכה הזו ונרתע כאשר גם שידור חוזר נכשל, כך שקטע אחד שאבד ברגע הלא נכון יכול לעצור בקשה למרווח מורגש. המנגנון הזה מוגדר במסמך RFC 6298, והוא מסביר מדוע שיעור אובדן שנראה טריוויאלי עדיין יכול להיות מורגש.

עם זאת, לא כל הפסקה היא פסק זמן של שידור חוזר. אותה המתנה יכולה לבוא מפתרון שמות, משרת איטי או מיישום שמנסה שוב את בקשתו לאחר כשל. הפרידו בין המקרים על ידי יישור הפעולה שנכשלה עם תצפיות התעבורה ועם אירועי הסשן של המנהרה עצמה. קטיעה בנתיב הנתונים בלי התחברות מחדש היא אירוע שונה מלחיצת יד חדשה והחלפת אישורים.

היכן שלכידה מותרת, שמרו אותה צרה. מה שנחוץ הוא אם המנות או האישורים הצפויים נעצרים בגבול מסוים, לא העובדה שקיים שידור חוזר איפשהו בקובץ מעקב עמוס.

שנו גבול אחד בלי להזיז את האחרים

אם הראיות מצביעות על קישור מקומי, החליפו כבל או פורט מאושרים כהשוואה מבוקרת והניחו לכל השאר. שמרו על נקודת הקצה, על היישום ועל עומס העבודה כבני השוואה, ושנו בדיוק גבול אחד בכל ניסיון. השוואת מחשב נייד עם כבל לנייד אלחוטי תוך החלפת יציאות ופרוטוקולים גם יחד לא תגיד לכם דבר שאפשר לייחס.

מונים מקומיים נקיים אינם מאשרים את שאר הנתיב. הם תוחמים את החלק שאתם רואים, והדוח הכנה אומר אילו גבולות נצפו ואילו לא. מה שאתם רוצים בסוף הוא קביעה שתצפית אחת השתנתה כשהתרחשה התערבות אחת, לא אנקדוטה על כבל גרוע שהועלתה לדרגת כלל אוניברסלי.