ניטור עם Prometheus ו-Grafana מוסבר¶
יש רגע מוכר לכל מי שהפעיל אי פעם שירות בייצור: המערכת פתאום מתחילה להיות איטית, או נופלת לגמרי, ואתם יושבים מול טרמינל ומנסים לנחש מה קרה. בלי ניטור, אתם עיוורים - אתם יודעים שמשהו לא בסדר רק כשמשתמש מתלונן, וזה כבר מאוחר מדי. בדיוק בשביל זה קיים הצמד Prometheus ו-Grafana, שהפך ברבות השנים לסטנדרט הכמעט בלתי מעורער לניטור מערכות.
הבעיה - לא לדעת מה קורה בפנים¶
כל מערכת רצה מייצרת כל הזמן נתונים - כמה זיכרון היא צורכת, כמה בקשות היא מקבלת בשנייה, כמה מהן נכשלות, כמה זמן לוקח לכל בקשה לחזור. בלי לאסוף ולעקוב אחרי הנתונים האלה באופן שיטתי, אין לכם דרך לדעת אם המערכת בריאה, אם היא מתקרבת לגבול הקיבולת שלה, או אם משהו כבר התחיל להשתבש לפני שהוא הפך לתקלה מלאה. המטרה של ניטור היא לתפוס בעיות מוקדם, לפני שהמשתמשים בכלל מרגישים אותן.
איך Prometheus אוסף מטריקות¶
Prometheus הוא מערכת לאיסוף וניתוח מטריקות, ומה שמייחד אותה היא גישת ה-pull. במקום שהאפליקציות ישלחו נתונים אליו באופן יזום, Prometheus הוא זה שניגש - scrapes - לכל אחד מהיעדים שהוגדרו לו, בכתובת קבועה כמו /metrics, ואוסף משם את הנתונים העדכניים במרווחי זמן קבועים, נניח כל חמש עשרה שניות.
כל מה שהוא אוסף נשמר כ-time series - סדרה של ערכים לאורך זמן, כל אחד עם חותמת זמן. זה מאפשר לשאול שאלות כמו "כמה בקשות קיבל השירות בדקה האחרונה" או "מה אחוז השגיאות בשעה האחרונה". השאילתות האלה נכתבות בשפה ייעודית שנקראת PromQL, שמאפשרת לחשב ממוצעים, אחוזונים, שינויים לאורך זמן, ולשלב מטריקות שונות יחד.
מעבר לאיסוף וניתוח, ל-Prometheus יש גם מנגנון של alerting rules - כללים שמגדירים מתי מצב נחשב חריג, לדוגמה "אם אחוז השגיאות עולה מעל חמישה אחוזים למשך יותר מחמש דקות", ואז שולחים התראה לצוות במקום שמישהו יגלה את הבעיה מאוחר.
Grafana - הופכים מספרים לתמונה¶
Prometheus מצוין באיסוף וניתוח נתונים, אבל הוא לא בנוי כדי להציג אותם בצורה נוחה לעין אנושית. כאן נכנס Grafana - כלי שמתחבר למקורות נתונים כמו Prometheus, ומאפשר לבנות דשבורדים ויזואליים - גרפים, מדדים, מפות חום - שמראים בבת אחת את מצב המערכת.
הרעיון הוא שבמקום להריץ שאילתות PromQL ידנית כל פעם שרוצים לבדוק משהו, יש דשבורד קבוע שמראה את המדדים החשובים ביותר בזמן אמת - עומס על המערכת, זמני תגובה, אחוז שגיאות, שימוש במשאבים. כשמשהו נראה חריג בגרף, קל הרבה יותר לזהות את זה ולחקור לעומק.
Grafana לא מוגבל רק ל-Prometheus - הוא תומך בעשרות מקורות נתונים שונים, כולל מסדי נתונים רגילים ומערכות logs, מה שהופך אותו לשכבת התצוגה המרכזית לכל נתוני התפעול של הארגון, לא רק למטריקות.
למה זה הפך לסטנדרט בעולם הקלאוד-נייטיב¶
הצמד הזה הפך לבחירה הכמעט אוטומטית בעולם הקונטיינרים ו-Kubernetes, בין השאר כי שניהם open source, קלים להרצה כקונטיינרים בעצמם, ומתממשקים היטב עם סביבות דינמיות שבהן שירותים עולים ויורדים כל הזמן. Kubernetes עצמו חושף מטריקות בפורמט שמתאים ישירות ל-Prometheus, מה שהופך את האינטגרציה כמעט אוטומטית.
מלכודת נפוצה¶
טעות שכיחה היא להגדיר יותר מדי מטריקות ודשבורדים מההתחלה, עד שקשה להבין מה חשוב ומה רעש. עדיף להתחיל עם כמה מדדים מרכזיים באמת - זמן תגובה, אחוז שגיאות, שימוש במשאבים - ולהוסיף בהדרגה, במקום לנסות לעקוב אחרי הכל בבת אחת. עוד מלכודת נפוצה היא לשכוח להגדיר retention - כמה זמן Prometheus שומר נתונים היסטוריים - ולגלות שאין דרך לחקור תקלה שקרתה לפני חודש.
מי שרוצה להבין את התשתית שמאחורי כל זה - איך שרתים, שירותים ותהליכי תפעול עובדים יחד - מוזמן להעיף מבט על קורס צד שרת.
ברגע שיש לכם ניטור אמיתי, הפסקתם לחכות שמשתמשים יגידו לכם שמשהו נשבר. אתם רואים את זה בעצמכם, לרוב הרבה לפני שזה הופך לבעיה אמיתית.