הגדרת ניטור לבוט קריפטו: Prometheus, Grafana, התראות

ניטור בוט קריפטו: מה נשבר בלי תצפית

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

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

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

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

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

מה נותנת יכולת תצפית: אפקט בגדלים מדידים

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

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

זמן עד גילוי: דקות במקום שעות

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

דשבורדים: הסיבה נראית בתרשים, לא בלוגים

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

שחזור ושיעור אירועים בלי השלכות

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

דרכים לארגון ניטור בוט קריפטו: מה לבחור

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

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

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

סדר הטמעה: מביקורת ועד מסירת נהלים

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

1. ספירת מלאי צמתים. מרכיבים מפת מערכת: צמתי RPC, שירות חתימה, תורי משימות, וורקרים של אסטרטגיות, מאגרי נתונים. עבור כל צומת מתעדים בעלים, מצב פעולה ותלויות — על המפה הזו נבנית כל סכמת התצפית.
2. סכמת תצפית. מפרידים מה נלקח מהאפליקציה ומה מהתשתית: השהיית תגובת הצומת, מספר העסקאות המאושרות, הפער בין האות לביצוע, מצב המפתחות והמגבלות.
3. הגדרת המלקט. פורסים איסוף ואחסון מדדים על Prometheus ו-Grafana, קובעים מרווחי דגימה ותקופת אחסון, כדי שנפח הנתונים לא יגדל ללא בקרה. דשבורדים מרכיבים לפי תפקידים: תורן, מפתח, מנהל.
4. ספי הפעלה. ספים מחשבים מהסטטיסטיקה של הבוט עצמו, לא "בעין": רמת אזהרה ורמה קריטית. כך פרץ רגיל של פעילות רשת לא מעיר את התורן.
5. בדיקת התראות. מריצים על תקלות חיות: מכבים צומת, מאטים תור, מבטלים גישה. בודקים מי קיבל את האות, תוך כמה זמן והאם הוא לא אבד ברעש.
6. מסירת תצפית. נהלי תורנויות, ערוצי התראות, הוראות לתקלות טיפוסיות, תפקידים והרשאות, הדרכת הצוות.

ערכת מסירה: תצורות, תרשימים, נהלי תורנות

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

• קובצי תצורה — יצואנים, תיאורי job, דשבורדים וכללי התראות נמצאים במערכת בקרת גרסאות עם היסטוריית שינויים בעלת משמעות. פריסת מתקן הניטור חוזרת מהמאגר, בלי עריכות ידניות בשרת.
• תרשים צמתי הבוט — אילו תהליכים, על אילו צמתים, מה מחליף נתונים עם מה, והיכן נקודות הכשל: ניתוק החיבור לבורסה, פיגור תור ההזמנות, אי-זמינות מסד היסטוריית העסקאות.
• כללי התראות — לכל אות מתועדים סף, חלון מיצוע, עדיפות ויעד. מופרדים "בוער עכשיו" מ"לבדוק בבוקר" — אחרת התורן מפסיק להגיב להתראות.
• הוראות לתורן — סדר פעולות מהפעלה ועד הסלמה: מה לבדוק, אילו פקודות בטוחות, מתי לעצור את לוגיקת המסחר, את מי להעיר ובאיזה ערוץ.
• נוהל ניתוח אירוע — מועדי תיעוד, שדות חובה בניתוח (סימפטום, סיבת שורש, פעולה), קריטריון שלפיו כותבים מחדש כלל התראה במקום להשתיק אותו.
• הרשאות ותפקידים — חשבונות נפרדים לתורן ולמנהל, סדר הענקה וביטול, כדי שעזיבת אדם לא תשאיר את המערכת בלי השגחה.

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

מקרה בוחן: תקלות בבוט נמצאו לפי תלונות, עכשיו — בדקות

המערכת לפני: לוגים יש, תצפית אין

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

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

מה שינו

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

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

מדדים לפני ואחרי

• זמן גילוי תקלה: היה 3-6 שעות (לפי תלונת לקוח), הפך ל-30-90 שניות — לפי התראה על מדד;
• ניתוח אירוע: היה 2-4 שעות של הצלבה ידנית של לוגים, הפך ל-10-20 דקות: הדשבורד מציג את מצב החשבון וההזמנות ברגע התקלה;
• פוזיציות תקועות: נסגרות אוטומטית לפי כלל, והתורן בודק רק את עובדת הסגירה;
• שיעור התקלות שנמצאו לפני פניית הלקוח: תשע מתוך עשר.

כל אירוע נשמר עכשיו עם תמונת מדדים לשעה לפני ואחרי — הניתוח הבא מתחיל מתמונה מוכנה, לא מאפס.

במה בדיקת זמינות חיצונית שונה מאיסוף מדדים?

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

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

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

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

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

ספקות טכניים: עומס יתר, הרשאות, התראות שווא

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

האם נצטרך למסור מפתחות פרטיים או גישה לבורסה?

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

איך להגדיר ספים כדי לא לטבוע בהתראות שווא?

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

מה עם תורנות בשעות לא עבודה?

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

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

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

מה צריך מכם כדי שההערכה תהיה מדויקת:

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית.