Graphite היא מערכת Open Source פופולארית למדי לניטור (Monitoring).
בצורה המקוצרת ביותר, היא מבצעת 2 פעולות בסיסיות:
מכיוון ש Graphite היא מערכת המורכבת ממודולים נפרדים עם APIs מוגדרים היטב - הצרכנים שהתלוננו פשוט החליפו חלקים שונים במערכת. בלי לשם לב, נוצרה אסופה גדולה של מודולים להחלפה, כאשר ה APIs שהגדירה Graphite - הפכו לסוג של "סטנדרט" בתעשייה, אליו מתממשקים כלים רבים.
כיום כבר ניתן לראות הרבה תצורות בהן החליפו חלק מהרכיבים של ה "Graphite Stack", ואפילו תצורות ללא אף אחד מהרכיבים המקוריים. Graphite הוא עדיין אחד כלי ה Monitoring הנפוצים ביותר שקיימים.
אם אתם קוראים אדוקים של הבלוג, אתם בוודאי יודעים שאני מאוד אוהב כלי Monitoring בשם New Relic- בעבר כתבתי עליו פוסט.
מה הטעם להשתמש ב Graphite כאשר יש לנו כלי monitoring נהדר כמו New Relic?
בצורה פשטנית משהו, ניתן לתאר את הארכיטקטורה של Graphite בצורה הבאה:
בשלב זה, ולפני שאנו צוללים לתמונת-מבט עמוקה יותר על הארכיטקטורה של Graphite, כדאי להבין מהם time-series - מכיוון שהם נמצאים בבסיסה של הארכיטקטורה של Graphite.
סדרה עתית (Time Series) היא סדרת נתונים, לרוב שנדגמו אחד לאחר השני, לרוב באינטרוולים קבועים, המסודרים לאורך ציר הזמן.
עצם הידיעה שמדובר בנתונים ששייכים לסדרה העתית, והם לא נתונים אקראיים מאפשרת לנו:
סדרות עתיות הן טובות לתאר מדדים של מזג אוויר, ונתונים כלכליים - מצד אחד, אך גם metrics של סביבת הפרודקשיין שלנו, וביצועים של מדדים עסקיים - מצד שני. ישנן טכניקות מתמטיות משמעותיות לניתוח נתונים של סדרות עתיות.
בסיסי נתונים רלציוניים (או KV/Document) מסוגלים בהחלט לנהל סדרות עתיות, במיוחד כאשר הם רצים על חומרה עם SSD (שמספקת ביצועים טובים בהרבה מדיסק מכאני לגישות אקראיות רבות).
נניח שאנו רוצים לאכסן סדרה עתית ב MySQL. באופן טבעי נרצה לצמצם את מספר הגישות לדיסק, ואת מספר הסריקות הארוכות של טבלאות בבסיס הנתונים (נקודות חולשה בביצועים של בסיס נתונים רלציוני). מימוש אפשרי הוא כזה:
כאשר יש לנו *הרבה* נתונים (מה שקורה לעתים קרובות ב Monitoring), ניתן לבצע אחת מ-2 אופטימיזציות מקובלות:
כמובן שבמקום לנהל את הסדרה העתית בעצמנו - ניתן לבחור בבסיס נתונים שזו ההתמחות שלהם (ועושים בערך מה שתיארנו למעלה). בסיסי הנתונים העתיים המדוברים ביותר כיום הם:
TSDB כוללים לרוב עוד כמה פונקציות מסביב למודל של סדרות עתיות:
סה"כ TSDBs כוללים tradeoff מאוד ברור: מודל נתונים פשוט ובסיסי של סדרות עתיות, עבורן ה TSDB יעיל בצורה לא-רגילה.
הנתונים שלכם הם קצת יותר מורכבים מסדרה עתית פשוטה? או שתעשו קצת תרגילים בכדי למדל אותם כ time-series (למשל: תשמרו את הנתונים ככמה סדרות עתיות שונות), או שתמצאו פתרון אחר שהוא יותר גמיש - אך פחות יעיל.
סה"כ אנו רואים היום מגמה של קצת פחות אופטימיזציה, וקצת יותר גמישות: ב RRD לא ניתן היה להוסיף נתונים שלא ע"פ הסדר, או שלא במרווחים קבועים. InfluxDB ו OpenTSDB מראים גמישות גבוהה הרבה יותר מזה.
בפוסט זה הכרנו את Graphite, כלי (או אולי Stack) טכנולוגיות פופולארי מאוד, בקוד פתוח - לניטור מערכות. הכח שלו - הוא ביכולת ה customization: ניתן להשתמש בו ל System Monitoring, ל Application Monitoring ואף ל Business Performance Monitoring. הבסיס שלו הוא דיי פשוט ויעיל - מה שתרם לפופולאריות הרבה שלו.
תמונת הארכיטקטורה שהצגתי היא פשטנית, ואנסה לכתוב פוסט המשך בו אסביר קצת יותר על Graphite, כיצד הוא עובד, ועם אילו בעיות / trade-offs יש להתמודד עם סוג כזה של מערכת.
בינתיים, אתם יכולים לגשת ל-2 הלינקים העוסקים בארכיטקטורה למטה - הם לא-רעים.
שיהיה בהצלחה!
----
[א] ע"פ מקורות זרים: כ 100$ לחודש לשרת. ע"פ מקורות זרים: ניתן להוריד את המחיר הנ"ל לבערך חצי - אם אתם צרכנים כבדים (יש לכם מאות שרתים מנוטרים). מה המחיר לאלפים? לרוב אם יש לכם יותר מכמה מאות שרתים - אתם לא תשלמו כבר ל NR, אלא תשתמשו ב open source כמו nagios עם הרחבות שלכם...
[ב] RRD הוא קיצור של Round Robin Database - על שם כך ששמר על קבצים בגודל קבוע בדיסק, ועשה שימוש חוזר בשטח שלהם.
----
לינקים רלוונטיים
רשימת כלי 3rd-party שעובדים עם Graphite:
http://graphite.readthedocs.org/en/latest/tools.html
הארכיטקטורה של Graphite, כפי שמתוארת ע"י היוצר שלה, כריס דיוויס:
http://aosabook.org/en/graphite.html
תיאור טוב ממקור אחר:
https://grey-boundary.io/the-architecture-of-clustering-graphite/
דרכים למימוש סדרות עתיות על גבי בסיס נתונים רלציוני:
https://academy.datastax.com/demos/getting-started-time-series-data-modeling
http://dba.stackexchange.com/questions/7634/timeseries-sql-or-nosql
ספר מבית O'Reilly על TSDB, ו openTSDB בעיקר. ניתן לקבל בחינם במימון MapR (שמשקיעה ב OpenTSDB):
https://www.mapr.com/time-series-databases-new-ways-store-and-access-data
השוואה של 10 TSDBs:
https://blog.outlyer.com/top10-open-source-time-series-databases
Splunk vs. ELK
https://riskfocus.com/splunk-vs-elk-part-1-cost/ (והמשכים...)
Elastic Search as a Time-Series datastore:
https://www.elastic.co/blog/elasticsearch-as-a-time-series-data-store
בצורה המקוצרת ביותר, היא מבצעת 2 פעולות בסיסיות:
- אוספת מספרים שמשתנים לאורך זמן (להלן "time-series").
- מציגה אותם כגרף.
המערכת מבוססת על עקרונות פשוטים למדי, ומסוגלת לטפל במליוני data points בשנייה.
Graphite זכתה לאימוץ נרחב בתעשייה, ככלי Monitoring חשוב. רבים משתמשים בה (ומספרים על זה): Github, Etsy, אובר, Electronic Arts, ועוד.
הקהילה הגדולה הרחיבה את Graphite עם מרחב של פונקציות סטטיסטיות בעזרתן ניתן להגדיר את הגרפים: החל מממוצע או median, דרך ניתוח אחוזונים או סטיית תקן, ועד אלגוריתמים לחיזוי מסוג Holt-Winters.
מצד שני - צצו גם תלונות שונות על המערכת:
הקהילה הגדולה הרחיבה את Graphite עם מרחב של פונקציות סטטיסטיות בעזרתן ניתן להגדיר את הגרפים: החל מממוצע או median, דרך ניתוח אחוזונים או סטיית תקן, ועד אלגוריתמים לחיזוי מסוג Holt-Winters.
מצד שני - צצו גם תלונות שונות על המערכת:
- ניהול הנתונים כקבצים אינו יעיל כאשר מתשאלים הרבה מטריקות (metrics) במקביל. בהמשך נראה שזה מצב כמעט ובלתי נמנע...
- ה UI הוא לא כ"כ יפה...
- יש פונקציונליות חסרה, למשל: aggregation של נתונים, alerts, וגילוי אנומליות...
- ההתקנה של Graphite היא לא פשוטה (הרבה תלויות), והתפעול השוטף שלה - גם עשוי להיות לא כ"כ פשוט.
מכיוון ש Graphite היא מערכת המורכבת ממודולים נפרדים עם APIs מוגדרים היטב - הצרכנים שהתלוננו פשוט החליפו חלקים שונים במערכת. בלי לשם לב, נוצרה אסופה גדולה של מודולים להחלפה, כאשר ה APIs שהגדירה Graphite - הפכו לסוג של "סטנדרט" בתעשייה, אליו מתממשקים כלים רבים.
כיום כבר ניתן לראות הרבה תצורות בהן החליפו חלק מהרכיבים של ה "Graphite Stack", ואפילו תצורות ללא אף אחד מהרכיבים המקוריים. Graphite הוא עדיין אחד כלי ה Monitoring הנפוצים ביותר שקיימים.
אם אתם קוראים אדוקים של הבלוג, אתם בוודאי יודעים שאני מאוד אוהב כלי Monitoring בשם New Relic- בעבר כתבתי עליו פוסט.
מה הטעם להשתמש ב Graphite כאשר יש לנו כלי monitoring נהדר כמו New Relic?
- New Relic הוא כלי יקר [א], וייתכן שיש מערכות שלא משתלם לשלם עבורן את ה premium של New Relic.
- New Relic מגיש סט מאוד שימושי של מדדים וניתוחים, אבל לעתים אנו רוצים מדדים ש New Relic לא מספק.
- דוגמה קלאסית: מדדים עסקיים.
בעולם של Gett: כמה הזמנות יש, כמה נהגים פנויים, כמה נוסעים שממתינים למונית כבר רבע שעה? - ב New Relic קיימת פונקציונליות שדומה ל Graphite (עבור מערכות שמנוטרות ברישיון).
New Relic מקשר את הנתונים בצורה קשיחה לאפליקציה, מה שעלול להקשות. אנחנו במקרה מסוים עזבנו אותו בנקודה זו לטובת Graphite, אם כי לא התאמצנו יותר מדי להשתמש בו. ייתכן ויש לזה פתרון.
 |
| Graphana - ה Dashboard ה"חם" בעולם ה Graphite כיום. |
הארכיטקטורה של Graphite
בצורה פשטנית משהו, ניתן לתאר את הארכיטקטורה של Graphite בצורה הבאה:
- ניתן לזהות ב Graphite שלושה רכיבי-על מרכזיים: whisper, carbon ו graphite-web.
- המערכת (Application) שולחת נתונים של מטריקות (metrics) שונות ל carbon מעל tcp (פורט ברירת-מחדל: 2003).
- הפורמט בו מועברים הנתונים הוא מאוד פשוט: some metric name : some value : timestamp.
- קרבון שומר את הנתונים בבסיס הנתונים whisper, בסיס נתונים שמבוסס על קבצים ודומה לכלי ישן, יחסית, שנקרא RRD [ב].
- whisper מנהל קובץ נפרד לכל מטריקה, הוא למעשה סוג של Time Series Database (פרטים בהמשך).
- Graphite-web יודע לקבל קריאת GET (בעזרת endpoint בשם render/) כשהפרמטרים על ה URL מתארים query על מטריקה או מספר מטריקות.
- למשל: הפרמטר הבא סוכם את כמות ה logins היומית:
target=summarize(my.metric.logins, "1d")
- Graphite-web מרנדר PNG אותו הוא מגיש לדפדפן.
הערה: זהו אלמנט של חוסר יעילות: היום קל יותר לקבל נתונים ולרנדר אותם ב javaScript - כך גם העבודה מתפזרת בין ה clients השונים.
Graphite כתובה ב Python, כאשר carbon ממומש ע"ג twisted (שהוא framework ל event-driven I/O) ו graphite-web כתוב ב django - ספריית MVC מפורסמת שדומה באופייה ל Rails.
Time Series Databases (להלן TSDB)
בשלב זה, ולפני שאנו צוללים לתמונת-מבט עמוקה יותר על הארכיטקטורה של Graphite, כדאי להבין מהם time-series - מכיוון שהם נמצאים בבסיסה של הארכיטקטורה של Graphite.
סדרה עתית (Time Series) היא סדרת נתונים, לרוב שנדגמו אחד לאחר השני, לרוב באינטרוולים קבועים, המסודרים לאורך ציר הזמן.
עצם הידיעה שמדובר בנתונים ששייכים לסדרה העתית, והם לא נתונים אקראיים מאפשרת לנו:
- לדחוס את הנתונים בצורה יעילה יותר.
- איתור מגמות (trends), מחזורים (cyclical fluctuation), ועונתיות (seasonal fluctuation) בנתונים.
- לנתח חריגות בנתונים (אנומליות).
- לנסות לחזות את המשך הסדרה.
- להיות מסוגלים לחשב (בדיוק כזה או אחר) את ההסתברות להתנהגויות עתידיות של הסדרה. למשל: הסבירות לקטסטרופה עתידית.
סדרות עתיות הן טובות לתאר מדדים של מזג אוויר, ונתונים כלכליים - מצד אחד, אך גם metrics של סביבת הפרודקשיין שלנו, וביצועים של מדדים עסקיים - מצד שני. ישנן טכניקות מתמטיות משמעותיות לניתוח נתונים של סדרות עתיות.
 |
| מקור: Sabbir Rehman |
בסיסי נתונים רלציוניים (או KV/Document) מסוגלים בהחלט לנהל סדרות עתיות, במיוחד כאשר הם רצים על חומרה עם SSD (שמספקת ביצועים טובים בהרבה מדיסק מכאני לגישות אקראיות רבות).
נניח שאנו רוצים לאכסן סדרה עתית ב MySQL. באופן טבעי נרצה לצמצם את מספר הגישות לדיסק, ואת מספר הסריקות הארוכות של טבלאות בבסיס הנתונים (נקודות חולשה בביצועים של בסיס נתונים רלציוני). מימוש אפשרי הוא כזה:
- ניצור טבלה לכל מדד (למשל: צריכת זכרון של שרת A, צריכת זכרון של שרת B, כמות פעולות IO של שרת A,... וכו')
- בכל טבלה יהיו שתי עמודות: זמן, וערך המדד.
כאשר יש לנו *הרבה* נתונים (מה שקורה לעתים קרובות ב Monitoring), ניתן לבצע אחת מ-2 אופטימיזציות מקובלות:
- ליצור טבלה לא רק לכל מדד, אלא גם לכל מדד וטווח זמן - למשל מדד + תאריך (יום מסוים). כל יום יהיה טבלה חדשה.
- אם הטבלה מייצגת תאריך - אז שדה הזמן יכול עתה להיות מצומצם לשעה ביום (ברזולוציה הנדרשת: שניות או מילי-שניות, למשל), וכך לחסוך מקום רב של אכסון, בעיקר באינדקסים.
- התוצאה כמובן יכולה להיות שבמערכת יהיו לנו מאות או אלפי טבלאות שונות.
- לרוב מקובל לשמור את הערכים לטווח מוגדר (נאמר: 30 יום), ולמחוק טבלאות ישנות יותר.
- לצמצם את מספר השורות ע"י אכסון של טווח ערכים בכל שורה. למשל: יש לנו הרבה מדידות בשנייה (או בדקה), ואנו הופכים את הסכמה של כל שורה להיות: זמן, כמות דגימות, ממוצע דגימות, פיזור דגימות, ערך מקסימום, ערך מינימום ו BLOB עם כל ערכי הדגימות הספציפיים ומרכיב הזמן המתאים (שניה או מילי-שניה).
- אם עבור הרוב הגדול של השאילתות הרזולוציה אליה צמצמנו את הנתונים (נאמר: דקה) היא מספיק טובה, אז רוב השאילתות יוכלו לרוץ על סיכמוי הביניים (למשל: "ממוצע דגימות" ו "כמות דגימות") - מה שירוץ הרבה יותר מהר.
- צמצום שמצדיק את הטרחה הוא לרוב צמצום של כמה עשרות או מאות ערכים שונים או יותר - לתוך שורה בודדת.
- אם נרצה לגשת לכל הערכים המדויקים (כנראה שנרצה לעשות זאת ברזולוציה קטנה, למשל - כמה דקות) - כל הנתונים עדיים שם. לא יצרנו איבוד מידע.
 |
| דוגמה לדחיסה של נתוני סדרה עתית לרשומה / אובייקט יחיד. מקור: O'Rielly, באדיבות MapR. |
כמובן שבמקום לנהל את הסדרה העתית בעצמנו - ניתן לבחור בבסיס נתונים שזו ההתמחות שלהם (ועושים בערך מה שתיארנו למעלה). בסיסי הנתונים העתיים המדוברים ביותר כיום הם:
- Splunk (מוצר proprietary)
- משמש בעיקר לאינדוקס וניתוח נתונים (לא ממש monitoring), יותר נכון להשוות אותו ל ELK Stack מאשר ל Graphite Stack (למרות שהוא נחשב מוצר TSDB).
- InfluxDB (כתוב ב Go, יכול לחבר אותו ל Storage Engines שונים כמו LevelDB או RockDB).
- ניתן לאפיין אותו בפשטות התקנה / תפעול. הוא מתיימר להחליף את כל ה Graphite Stack בעתיד, ובנוסף הוא תומך במודל של time-events, שהוא רחב יותר ממודל ה time-series הקלאסי (מה שבא קצת על חשבון יעילות אכסון וביצועים). אולי שווה להקדיש לו פוסט בעתיד...
- OpenTSDB (הממומש מעל Hadoop HBase)
- ניתן לאפיין אותו ביכולת לטפל בכמויות גדולות מאוד של נתונים, ובמהירות. הוא מהיר בסדר גודל מ InfluxDB - כאשר כמות הנתונים גדולה מאוד.
TSDB כוללים לרוב עוד כמה פונקציות מסביב למודל של סדרות עתיות:
- downsampling - היכולת לשלוף נתונים ביעילות ברזולוציה קטנה יותר מזו שנשמרה (למשל: אנו שומרים מדד כל שניה, אך רוצים לשלוף את הערכים של פעם בחמש דקות).
- ביצוע פעולות השוואה / חישוב בין סדרות עתיות שונות, או מקטעים שונים באותה סדרה עתית. למשל: מה ההבדל בין התנהגות המדד היום, להתנהגותו באותו היום - לפני שבוע?
- אינדוקס הערכים ושליפה מהירה שלהם. למשל: שלוף את כל מקטעי הזמן בחודש האחרון בהם ה CPU utilization היה גבוה מ 70% - בצורה יעילה (ובהנחה שזה אירוע דיי נדיר).
סה"כ TSDBs כוללים tradeoff מאוד ברור: מודל נתונים פשוט ובסיסי של סדרות עתיות, עבורן ה TSDB יעיל בצורה לא-רגילה.
הנתונים שלכם הם קצת יותר מורכבים מסדרה עתית פשוטה? או שתעשו קצת תרגילים בכדי למדל אותם כ time-series (למשל: תשמרו את הנתונים ככמה סדרות עתיות שונות), או שתמצאו פתרון אחר שהוא יותר גמיש - אך פחות יעיל.
סה"כ אנו רואים היום מגמה של קצת פחות אופטימיזציה, וקצת יותר גמישות: ב RRD לא ניתן היה להוסיף נתונים שלא ע"פ הסדר, או שלא במרווחים קבועים. InfluxDB ו OpenTSDB מראים גמישות גבוהה הרבה יותר מזה.
סיכום
בפוסט זה הכרנו את Graphite, כלי (או אולי Stack) טכנולוגיות פופולארי מאוד, בקוד פתוח - לניטור מערכות. הכח שלו - הוא ביכולת ה customization: ניתן להשתמש בו ל System Monitoring, ל Application Monitoring ואף ל Business Performance Monitoring. הבסיס שלו הוא דיי פשוט ויעיל - מה שתרם לפופולאריות הרבה שלו.
תמונת הארכיטקטורה שהצגתי היא פשטנית, ואנסה לכתוב פוסט המשך בו אסביר קצת יותר על Graphite, כיצד הוא עובד, ועם אילו בעיות / trade-offs יש להתמודד עם סוג כזה של מערכת.
בינתיים, אתם יכולים לגשת ל-2 הלינקים העוסקים בארכיטקטורה למטה - הם לא-רעים.
שיהיה בהצלחה!
[א] ע"פ מקורות זרים: כ 100$ לחודש לשרת. ע"פ מקורות זרים: ניתן להוריד את המחיר הנ"ל לבערך חצי - אם אתם צרכנים כבדים (יש לכם מאות שרתים מנוטרים). מה המחיר לאלפים? לרוב אם יש לכם יותר מכמה מאות שרתים - אתם לא תשלמו כבר ל NR, אלא תשתמשו ב open source כמו nagios עם הרחבות שלכם...
[ב] RRD הוא קיצור של Round Robin Database - על שם כך ששמר על קבצים בגודל קבוע בדיסק, ועשה שימוש חוזר בשטח שלהם.
----
לינקים רלוונטיים
רשימת כלי 3rd-party שעובדים עם Graphite:
http://graphite.readthedocs.org/en/latest/tools.html
הארכיטקטורה של Graphite, כפי שמתוארת ע"י היוצר שלה, כריס דיוויס:
http://aosabook.org/en/graphite.html
תיאור טוב ממקור אחר:
https://grey-boundary.io/the-architecture-of-clustering-graphite/
דרכים למימוש סדרות עתיות על גבי בסיס נתונים רלציוני:
https://academy.datastax.com/demos/getting-started-time-series-data-modeling
http://dba.stackexchange.com/questions/7634/timeseries-sql-or-nosql
ספר מבית O'Reilly על TSDB, ו openTSDB בעיקר. ניתן לקבל בחינם במימון MapR (שמשקיעה ב OpenTSDB):
https://www.mapr.com/time-series-databases-new-ways-store-and-access-data
השוואה של 10 TSDBs:
https://blog.outlyer.com/top10-open-source-time-series-databases
Splunk vs. ELK
https://riskfocus.com/splunk-vs-elk-part-1-cost/ (והמשכים...)
Elastic Search as a Time-Series datastore:
https://www.elastic.co/blog/elasticsearch-as-a-time-series-data-store
היי, רק עכשיו קראתי את המאמר, מעניין מאד! אשמח לעוד מאמרים בנושא :)
השבמחקתודה רבה!