ניטור הוא אמצעי, לא מטרה

האם זה באמת חייב להיות מושלם?

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

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

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

אותם שיקולי הנדסה חלים על הניטור וצריך להסתכל עליהם בהקשר הרחב של השירות. האם כדאי שאדם יקפוץ מיידית על כל שורת לוג שכל אפליקציה שלך מייצרת? ומה אם שיעור השגיאות יעלה מ-0.01% ל-0.02%? ומה אם יקח 30 שניות נוספות לפעמים עד שיגיע עדכון התראה – זה בסדר? האם עדיף שהצוות ישקיע שנה בפיתוח אלגוריתם למידת מכונה שייקבע אוטומטית את הסף להודעת התראה אחת, או שעדיף להשקיע את הזמן הזה בפיצ’רים לשירות עצמו? האם כדאי להשקיע כמה שעות בשנה בתחזוקת כלל התראה מורכב שמונע פלט חיובי שגוי אחד בשנה, במקום להשתמש בסף פשוט וברור?

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

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