ניטור צומת בלוקצ'יין: מה נשבר בלי בדיקות חיצוניות
התמונה הנפוצה ביותר: הצומת פועל, השירות מגיב, מדדי התהליך תקינים — והשרשרת עליו נעצרה לפני כמה שעות. בדיקה מקומית "התהליך חי" מחזירה הצלחה, כי עונה שירות הצומת, לא הרשת. הפער של הצומת מהרשת גדל בשקט, והראשון שמבחין בו אינו מערכת הבקרה, אלא המשתמש.
כשל שקט נראה בדיוק כך. הצומת לא זמין לעמיתים, אך ממשיך לקבל בקשות מקומיות: מספר החיבורים ירד לאפס, בלוקים נכנסים לא מגיעים, ובמקביל התהליך עצמו לא נופל ולא רושם שגיאות ביומן. פורמלית הכל ירוק — בפועל הצומת נפל מהרשת.
אי-סנכרון מסוכן יותר מעצירה. הצומת מקבל ומוסר נתונים, אך נמצא על ענף אחר: עסקאות לא מאושרות, יתרות בארנק לא תואמות את המציאות, שליחות חוזרות יוצרות כפילויות. התקלה משוכפלת אצל חלק מהמשתמשים ונראית כמו פגם באפליקציה, לא בתשתית.
מכאן הספירה היא בשעות. כל עוד אין קו בדיקות חיצוני, האות היחיד נשאר פנייה לתמיכה — כלומר על הכשל נודע כאשר הלקוחות כבר ראו את התקלה. ניטור צומת בלוקצ'יין נדרש בדיוק כנקודת מבט צד שלישי: היא מסתכלת על הצומת מבחוץ ומשווה את מצבו לרשת. נפרט כיצד זה נסגר.
מה נותן בקרה רציפה של מצב הצמתים
הבקרה מתחילה בכך שהצומת עצמו מוסר נתונים על מצבו, ולא שותק עד הפנייה הראשונה. Prometheus קורא את גובה הבלוק המעובד, מספר השכנים הפעילים, עומק תור העסקאות, מקום פנוי בדיסק וזמן תגובה.
מעל סדרות אלו מוגדרים כללי סף: כל עוד הערכים תקינים — שקט, בסטייה, התורן מקבל התראה ממוקדת עם ציון הצומת והמדד.
זמן גילוי התקלה יורד משעות לדקות. בלי בקרה הצומת מפגר אחרי הרשת בשקט, ועל הבעיה נודע מהמשתמש או מעסקה שלא עברה. הכלל "גובה הבלוק לא עולה יותר משתי דקות" או "הפער מול צומת ייחוס עבר מספר בלוקים" מעלה את התורן לפני שהכשל נעשה מורגש מבחוץ.
זמן השחזור מתקצר הודות לפעולות שתוארו מראש. אתחול סביבת ההרצה, חזרה לתמונת מצב, מעבר לצומת גיבוי וסנכרון מחדש — כל פעולה נבדקה בסביבת בדיקה ומבוצעת לפי נוהל, ולא במצב של חיפוש סיבה. במקום ניתוח ידני של שעות — תרחיש טיפוסי של עשרות דקות.
בנפרד נעלם סוג שלם של כשלים: התמלאות הדיסק, אי-סנכרון בגובה הבלוק, אובדן שכנים, אי-התאמת גרסאות בצמתים. לכל אחד סף משלו ונוהל תגובה משלו, לכן הוא לא הופך לתקלה. זמן ההשבתה של התשתית נעשה צפוי, ועומס התורנות — מתוכנן: גרפים, ספים וסדר הסלמה ידועים מראש.
מצבי בדיקה: דגימות חיצוניות, סוכן מקומי, היברידי
המצבים נבדלים בשני דברים: מאיפה נאספים הנתונים ומה הם מסוגלים לראות. בדיקות זמינות חיצוניות מגיעות מכמה נקודות מפוזרות ומתארות את הצומת בעיני הלקוח: האם כתובת המצב השירותית מגיבה, האם התשובה עומדת בזמן הצפוי, האם הצומת מוסר גובה בלוק עדכני.
סוכן מקומי פועל על אותו מארח, קורא את מדדי התהליך עצמו ורואה את מה שמבחוץ לא נראה — פיגור בסנכרון, מספר עמיתים, גידול ביומנים, התמלאות הדיסק.
בנפרד, אף מצב לא מכסה את שני סוגי הכשלים, לכן בצמתי פרודקשן נוטים יותר לסכימה היברידית: הסוכן נותן פירוט, דגימות חיצוניות מאשרות זמינות ומבטחות למקרה שבו המארח נפל יחד עם הסוכן. הבחירה מצטמצמת להתאמה ולמגבלות:
| סכימת בקרה | מתי מתאימה | מגבלות |
|---|---|---|
| דגימות זמינות חיצוניות | צומת אצל ספק או מאחורי מאזן עומסים, אין גישה פנימה למארח | נראית רק התגובה החיצונית — עומס יתר, פיגור בסנכרון והתמלאות הדיסק מחוץ לתמונה |
| סוכן מקומי | שרת משלכם או מכונה וירטואלית עם גישה מלאה | בנפילת המארח הוא שותק יחד איתו, נדרש שומר בלתי תלוי מבחוץ |
| סכימת בקרה היברידית | צומת פרודקשן שבו השבתה קריטית | שני מקורות ומצבי דגימה שונים: יש לתאם ספים וחלונות שקט, אחרת כפילויות התראות |
כלל מעשי: מתחילים מדגימות חיצוניות — מינימום גישה והבטחה בסיסית; כאשר הצומת נעשה חלק מקו הפרודקשן, מוסיפים סוכן ומאחדים את שני הזרמים לכלל התראה אחד עם חלון שקט משותף.
שלבי הטמעה: ביקורת, סכימה, הגדרה, קבלה
סדר העבודות קבוע: כל עוד הקו לא מתואר, כל סף הוא ניחוש, ולוח בקרה בלי קבלה חי עד התורנות הראשונה. הולכים מהסקר להעברת הנהלים, בכל שלב — חפץ שאפשר לבדוק.
- ביקורת תשתית. אוספים טופולוגיה: היכן ממוקמים הצמתים, כיצד מופרדים פרודקשן וטסט, אילו מדדים כבר נמסרים, מה נראה מחוץ לקו. בנפרד מתעדים מקומות שבהם ייתכן כשל "אילם" — התהליך חי, והפיגור אחרי הרשת גדל.
- מפת כשלים. מסמנים תרחישים: עצירת סנכרון, חוסר מקום, ירידה במספר החיבורים עם שכנים ברשת, אי-סנכרון שעונים. לכל אחד — סימן שלפיו רואים את התקלה, וזמן תגובה מותר.
- סכימת התראות. קובעים לאן ולמי הולך האות — לתורן, לערוץ משותף, בשיחה. קריטי מפרידים מרעש: חלון עם הודעות מאותו סוג מפחית מערך התגובה יותר מהיעדר חלק מהבדיקות.
- הגדרת ספים. ספים מחשבים מהתנהגות הרשת, לא ממספרים עגולים: פיגור בגובה הבלוק, השהיית כתיבה, מרווח מקום לשרשרת. מכניסים שני רמות — אזהרה ותקלה — עם זמן אישור שונה.
- לוחות בקרה. אוספים תצוגה שלפיה התורן תוך 15 שניות מבין את מצב הצומת: סנכרון, חיבורים, משאבים, שגיאות בעיבוד בקשות. לצד — היסטוריה, כדי להבדיל בין פרץ חד-פעמי לירידת ביצועים.
- בדיקות חיצוניות. דגימות בלתי תלויות מחוץ לקו מתשאלות את הצומת מבחוץ: כך נתפס כשל רשת או מאזן עומסים שהניטור הפנימי לא יראה.
- קבלת בקרה. מפילים תהליכים באופן מבוקר ומנתקים ערוצים — בודקים שהאות הגיע לאדם הנכון בזמן המוסכם. נהלים וספים מעבירים למשמרת התורנות.
סכימות, לוחות בקרה ונהלים שנשארים אצלכם
ניטור צומת בלוקצ'יין עובד בדיוק עד המשמרת הראשונה של תורן שלא מבין מה לעשות עם האות. לכן יחד עם הבדיקות המוגדרות מוסרים סט חפצים — הם נשארים במאגר שלכם ומתעדכנים יחד עם התשתית.
- לוחות בקרה למצב הצמתים — גובה השרשרת, פיגור אחרי הרשת, מספר חיבורים פעילים, מקום פנוי, היענות לבקשות; פאנל נפרד לכל קו, כדי שתקלה לא תאבד בין התקין.
- כרטיסי התראות — לכל אות: מה הוא אומר, סף וחלון הפעלה, כיצד תוך שתי דקות לאשר את הבעיה, איזו פעולה לבצע לפני הסלמה.
- סכימת תשתית — צמתים, תפקידיהם, רשתות, נקודות בדיקה חיצוניות ומקומות שבהם התעבורה מתחלפת בעת כשל.
- סכימת ניתוב התראות — איזו התראה הולכת לאיזה ערוץ, מי ברוטציה, מה משוכפל לצ'אט חירום ובאיזו השהיה.
- נוהל תורנות — חלונות משמרות, סדר העברת משמרת, קריטריונים להכרה באירוע ותיעוד ביומן.
- הוראות הסלמה — רמות, זמני העלאה, תחום אחריות התורן והמפתחים, למי לכתוב בעת אובדן קונצנזוס ברשת.
- קונפיגורציות בדיקות וייצואני מדדים — במערכת בקרת גרסאות, שינויים עוברים סקירה, ולא נערכים ידנית בשרת.
- רשימת בדיקה לקבלה — אילו בדיקות חייבות להיות ירוקות, כיצד לגרום באופן מלאכותי להפעלת התראה ולוודא שההתראה הגיעה.
סט כזה מאפשר להפעיל את הקו בכוחות עצמכם: מהנדס חדש נכנס לתורנות לפי הוראות, ולא לפי סיפורי קולגות. אם תחליטו להעביר את הליווי אלינו — נתחיל בלי הנדסה הפוכה.
מקרה בוחן: כיצד החזרנו שליטה על הרשת וצמצמנו השבתה
אצל הלקוח — מפעיל רשת עם כמה עשרות צמתים: חלקם מאמתים בלוקים, חלקם משרתים בקשות ציבוריות. הניטור אז בדק רק את חיוניות התהליך: הדמון ענה לבקשה מקומית — סימן שהכל תקין. הפער בין אובדן הסנכרון בפועל לתגובת התורן הגיע עד 40 דקות, וחתימה שהוחמצה — זה קנס על ההחזקה ושאלות מהמאצילים.
במשך רבעון הצטברו 3.5 שעות השבתה, וכמעט כל האירועים התפתחו לפי תרחיש אחד: הצומת פיגר אחרי הרשת, אך נשאר "ירוק" בגרף. לכן שינינו לא את הספים, אלא את עצם לוגיקת הבדיקות.
מה שינינו
בדיקות חיצוניות הוצאו מחוץ להיקף הצומת עצמו — ל-Prometheus עם סוכנים בלתי תלויים.
- דגימות בלתי תלויות של הממשק הציבורי כל 15 שניות: הנפילה נראית גם אם הצומת לא יכול למסור את המדד של עצמו;
- התראה על פיגור בגובה השרשרת ואי-התאמה עם רוב העמיתים — מופעלת דקות לפני החמצת חתימה, ולא אחריה;
- לוח בקרה לפי תפקידים: חתימה, הפצת בלוקים, מספר עמיתים, מקום בדיסק, פיגור ביישום המצב;
- הסלמת התראות עם היסטוריה: תורן, ואחר כך מהנדס בכיר, עם תיעוד זמן התגובה.
מדדים לפני ואחרי
זמן גילוי התקלה הממוצע הצטמצם מ-40 דקות ל-90 שניות. השבתה של 3.5 שעות ברבעון הוחלפה באפס חתימות שהוחמצו בתקופה דומה. התראות שווא פחתו פי שלושה לאחר הגדרת ספים לפי ההיסטוריה המצטברת — התורן הפסיק להתעלם מהתראות.
התוצאה העיקרית — סוג הכשלים "אי-סנכרון שקט" חוסל: כעת כל פיגור מתועד לפני שהוא הופך לקנס. לפי אותה סכימה אנו בונים ניטור צומת בלוקצ'יין גם ברשתות חדשות של הלקוח.
במה ניטור חיצוני שונה מפנימי?
ניטור פנימי — זה סוכן על מארח הצומת עצמו. הוא קורא מדדי תהליך: גובה הבלוק הנוכחי ביחס לרשת, מספר עמיתים פעילים, פיגור עיבוד, מצב קונצנזוס, מקום פנוי ושגיאות ביומן.
קו כזה עונה על השאלה "מה קורה בפנים": הצומת פיגר לא "באופן כללי", אלא בגלל דיסק מלא או התפרקות קשרים עם שכנים.
נקודות העיוורון שלו מתחילות במקום שבו נכשל הערוץ עצמו. כאשר הצומת נופל לחלוטין, הסוכן עליו גם מפסיק למסור נתונים, וגרף ריק נראה כמעט כמו שלום. הקו הפנימי לא יודע אם RPC זמין ללקוח מבחוץ, אם הצומת מגיב מאזור אחר ואם מצבו תואם את הרשת.
ניטור חיצוני — דגימות בלתי תלויות מכמה נקודות. הן מתשאלות את הצומת כמו צרכן: האם הממשק מגיב, האם התגובה עומדת בסף, האם הגובה לא מפגר אחרי מקורות ייחוס, האם הפלט תואם צמתים שכנים. כאן נתפסים אי-זמינות, אי-התאמה עם הרשת וירידת ביצועים בנתיב — מה שמבפנים פשוט לא נראה.
האסימטריה הפוכה: הקו החיצוני לא יודע סיבות. הוא יתעד פיגור של עשרות בלוקים, אך לא יגיד שהאשם הוא הדיסק או אובדן עמיתים. מנגד, הוא לא תלוי בסוכן על המארח ושורד את נפילתו — זה גם смысл הקו השני.
ההבדלים בין הגישות מצטמצמים לשלושה דברים: היכן מקור האמת, היכן עובר גבול הכשל וכמה זמן לוקח האות. לכן מאחדים את הקווים — דגימות חיצוניות נותנות את העובדה של אי-זמינות ואי-התאמה, הפנימיות מסבירות את הסיבה. התראה שמים על שילוב תנאים, אחרת התורן מקבל או רעש, או מחמיץ כשל שקט.
מגבלות וספקות טכניים לפני התחלה
ניטור צומת מעורר בדרך כלל שלושה ספקות: כמה משאבים צורך איסוף המדדים, עד כמה רועשות יהיו ההתראות ומי אחראי לתגובה. להלן תשובות ישירות, בלי מילים כלליות.
האם איסוף מדדים יוצר עומס על הצומת?
קוראים מדדים ממה שהצומת מוסר בעצמו: יומן, מונים שירותיים, מצב סנכרון, גובה השרשרת. סריקה כבדה נפרדת לא מופעלת, לכן התוספת נשארת בגבולות התנודה הרגילה של התעבורה. אם הצומת עובד על הקצה, מורידים את תדירות הדגימה ומשאירים רק מדדים קריטיים.
כיצד מתמודדים עם התראות שווא?
סף שמים לא על ערך חד-פעמי, אלא על החזקה: האות יוצא כשהסטייה נמשכת כמה מחזורים ברצף. רמות מפרידים — אזהרה הולכת לערוץ העבודה, קריטי מעלה את התורן. ספי התראות בודקים מחדש לאחר השבועות הראשונים: חלק מההפעלות מוסרות בהתאמה לפרופיל העומס האמיתי של הצומת.
צומת בלי כתובת ציבורית — אפשר יהיה לנטר?
כן. סוכן האיסוף עובד בתוך הרשת ומעביר נתונים בחיבור יוצא, אין צורך לפתוח פורטים נכנסים. כתובת ציבורית נדרשת רק לבדיקות זמינות חיצוניות — אותן עושה דגימה נפרדת מבחוץ. מדדים פנימיים וזמינות חיצונית נבדקים בנפרד, כדי לא לבלבל בין כשל צומת לבעיית רשת.
היכן מסתיים תחום האחריות שלכם?
התחום שלנו — איסוף מדדים, אחסון, הגדרת ספי התראות, לוחות בקרה והעברת האות עד התורן. התגובה אליו, אתחול שירותים ושחזור נשארים בצד שלכם או על צוות הליווי. את הגבול מתעדים בכתב לפני ההתחלה, כדי שבניתוח אירוע לא יתעורר ויכוח של מי האות הזה.
נדון במשימה ונחזור עם תוכנית הטמעה
כדי לחזור לא עם מילים כלליות, אלא עם הערכת עבודה ותוכנית הטמעה, נדרש מאיתנו מינימום נתונים על הקו — את השאר נברר בשיחה.
- אילו רשתות ולקוחות צמתים בעבודה: כמה שרשראות, כמה מופעים, האם יש צמתי ארכיון וצמתי ולידציה.
- כיצד הצומת פרוס: מכונות פיזיות, קונטיינרים או ענן, האם יש אורקסטרטור וכיצד מתעדכנים אימג'ים.
- מה כבר נאסף: מדדים, לוגים, יומנים מערכתיים, לאן הם הולכים וכמה זמן נשמרים.
- רמת גישה: מפתח לקריאה בלבד למערכת האיסוף, גישה למכונות או ייצוא לפי לוח זמנים — מזה תלויה סכימת הבדיקות החיצוניות.
- תרחישים קריטיים: איזה פיגור אחרי הרשת נחשב לאירוע, עד איזה בלוק מותר סנכרון לאחר אתחול.
- ערוצי התראות ותורנות: לאן לשלוח התראות, האם יש הסלמת לילה ומי מקבל אותה.
- מגבלות הקו: חלונות תחזוקה, דרישות לאחסון היסטוריה, בידוד הרשת מבדיקות חיצוניות.
בשיחה נברר את ספי ההתראות, את תדירות בדיקות הזמינות החיצוניות ואילו לוחות בקרה באמת נצפים על ידי מהנדסי התורנות. לאחר מכן נחזור עם היקף העבודות, לוחות זמנים לפי שלבים וסכימת פריסה — עם גבול אחריות קבוע. תארו את המשימה, ונחזור עם הערכה ותוכנית הטמעה.