ניטור מדדים עסקיים: אינטגרציה של Prometheus ו-Grafana

ניטור מדדים עסקיים: היכן זה נשבר בפרודקשן

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

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

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

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

מה משתנה לאחר ההטמעה: השפעה על זמנים וכשלים

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

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

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

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

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

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

דרכי איסוף נתונים: סוכנים, אינטגרציות, זרם אירועים

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

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

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

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

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

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

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

כללי התראות, לוחות ותיעוד תורנויות

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

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

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

מקרה בוחן: כיצד קיצרנו את זמן התגובה לתקלה במוצר

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

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

מה שינינו

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

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

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

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

במה שונה ניטור מדדים עסקיים מניטור שרתים?

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

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

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

ספקות טכניים נפוצים לפני ההתחלה

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

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

כמה זמן לשמור היסטוריית מדדים?

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

האם יהיה צריך לשנות קוד באפליקציה?

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

איך מחפשים מדדים ומי אחראי על הדשבורדים?

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

נדבר על המשימה: מה לשלוח להערכת היקף העבודה

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

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

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