פיתוח Custom Metrics Exporter עבור Prometheus

אקספורטר Prometheus מותאם אישית: היכן נשבר איסוף המדדים

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

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

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

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

מה נותן אוסף מדדים משל עצמך: אפקט בגדלים מדידים

זמן אבחון אירוע

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

גילוי מוקדם של כשלים

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

שלמות תמונת הניטור

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

שיעור הכשלים לפני פניית משתמשים

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

נקודת אמת משותפת

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

אפשרויות מימוש האקספורטר: השוואת גישות

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

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

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

כיצד אנו מיישמים איסוף מדדים: שלבי העבודה

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

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

מה נשאר בתשתית לאחר היישום

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

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

מקרה בוחן: מדדי חיוב בלי בדיקה ידנית

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

מה עשינו

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

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

תוצאה

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

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

במה שונה אקספורטר משלך מאוספים מוכנים

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

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

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

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

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

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

ספקות טכניים לגבי איסוף מדדים ותשובות

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

איך תקבלו גישה למערכת סגורה?

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

אפשר להוסיף מדד בלי לעצור את השירות?

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

מה כלול בתמיכה באיסוף מדדים?

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

נדון במשימת איסוף המדדים שלכם

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

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

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

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