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

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

מקור התמונה:pixabay.com

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

מדוע לנטר? זה די ברור... ובכל זאת, ננסה להסתכל מהזוויות של מאפייני  big-data:

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

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

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

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

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

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

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

הנה תיאור של מבנה קובץ לוג למסלול מסוים שכולל מספר תחנות שאותן נרצה לנטר:

• Timestamp - תאריך יצירת הלוג 
• EntityId – מזהה חד חד ערכי לכל תחנה (מזהה ללוג)
• Status – מצב מתוך רשימת מצבים אפשרית (למשל success או failure)
• Event – אירוע שגרם ללוג להיווצר (או exception אם הלוג נוצר מתוך כשל בתהליך)
• Data – אובייקט או מערך שיכול להכיל ערכים רבים שאותם לצרף ב"משלוח" ויכולים להשתנות מתחנה לתחנה

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

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

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

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

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

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

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

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

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

זיו כהן בוגר ממר"ם, יזם וארכיטקט data במשרד הבריאות