תרגום המאמר הוכן במיוחד עבור תלמידי הקורס .
הוא מפתח תוכנה, Go פנאט ופותר בעיות. הוא גם מתחזק פרומתאוס ומייסד שותף של מכשור SIG Kubernetes. בעבר, הוא היה מהנדס הפקה ב-SoundCloud והוביל את צוות הניטור ב-CoreOS. עובד כרגע בגוגל.
- מהנדס תשתית ב-Improbable. הוא מתעניין בטכנולוגיות חדשות ובבעיות של מערכות מבוזרות. יש לו ניסיון בתכנות ברמה נמוכה באינטל, ניסיון של תורמים ב-Mesos, וניסיון בייצור SRE ברמה עולמית ב-Improbable. מוקדש לשיפור עולם שירותי המיקרו. שלוש האהבות שלו: גולנג, קוד פתוח וכדורעף.
כשמסתכלים על מוצר הדגל שלנו SpatialOS, אתה יכול לנחש ש-Improbable דורשת תשתית ענן דינאמית מאוד בקנה מידה עולמי עם עשרות אשכולות Kubernetes. היינו מהראשונים שהשתמשו במערכת ניטור . פרומתאוס מסוגלת לעקוב אחר מיליוני מדדים בזמן אמת ומגיעה עם שפת שאילתות רבת עוצמה המאפשרת לך לחלץ את המידע שאתה צריך.
הפשטות והאמינות של פרומתאוס היא אחד היתרונות העיקריים שלו. עם זאת, ברגע שעברנו קנה מידה מסוים, נתקלנו בכמה חסרונות. כדי לפתור את הבעיות הללו פיתחנו הוא פרויקט קוד פתוח שנוצר על ידי Improbable כדי להפוך בצורה חלקה אשכולות פרומתאוס קיימים למערכת ניטור אחת עם אחסון נתונים היסטורי בלתי מוגבל. Thanos זמין ב-Github .
המטרות שלנו עם ת'אנוס
בקנה מידה מסוים מתעוררות בעיות שהן מעבר ליכולותיו של פרומתאוס וניל. כיצד לאחסן באופן אמין וחסכוני פטה-בייט של נתונים היסטוריים? האם ניתן לעשות זאת מבלי לפגוע בזמן התגובה? האם ניתן לגשת לכל המדדים הממוקמים בשרתי פרומתאוס שונים באמצעות בקשת API אחת? האם יש דרך לשלב נתונים משוכפלים שנאספו באמצעות Prometheus HA?
כדי לטפל בבעיות האלה, יצרנו את Thanos. הסעיפים הבאים מתארים כיצד ניגשנו לנושאים אלה ומסבירים את המטרות שלנו.
שאילתת נתונים ממופעי פרומתאוס מרובים (שאילתה גלובלית)
פרומתאוס מציע גישה פונקציונלית לרסיסים. אפילו שרת Prometheus בודד מספק מדרגיות מספקת כדי לשחרר את המשתמשים מהמורכבות של ריסוק אופקי כמעט בכל מקרי השימוש.
למרות שזהו מודל פריסה נהדר, לעתים קרובות יש צורך לגשת לנתונים בשרתי פרומתאוס שונים דרך ממשק API או ממשק משתמש בודד - תצוגה גלובלית. כמובן, ניתן להציג מספר שאילתות בפאנל אחד של Grafana, אך כל שאילתה יכולה להתבצע רק בשרת Prometheus אחד. מצד שני, עם Thanos אתה יכול לבצע שאילתות ולצבור נתונים ממספר שרתי Prometheus מכיוון שכולם נגישים מנקודת קצה אחת.
בעבר, כדי לקבל תצוגה גלובלית ב-Improbable, ארגנו את מופעי Prometheus שלנו לריבוי רמות . משמעות הדבר הייתה יצירת מטא שרת אחד של Prometheus שאוסף חלק מהמדדים מכל שרת עלים.
גישה זו התגלתה כבעייתית. זה הביא לתצורות מורכבות יותר, להוספת נקודת כשל פוטנציאלית נוספת ויישום כללים מורכבים כדי להבטיח שנקודת הקצה המאוחדת תקבל רק את הנתונים הדרושים לה. בנוסף, פדרציה מסוג זה אינה מאפשרת לך לקבל תצוגה גלובלית אמיתית, מכיוון שלא כל הנתונים זמינים מבקשת API אחת.
קשר הדוק לכך הוא תצוגה אחידה של הנתונים שנאספו בשרתי פרומתאוס בעלי זמינות גבוהה (HA). מודל ה-HA של פרומתאוס אוסף באופן עצמאי נתונים פעמיים, וזה כל כך פשוט שלא יכול להיות פשוט יותר. עם זאת, שימוש בתצוגה משולבת וחסרת כפילות של שני הזרמים יהיה הרבה יותר נוח.
כמובן, יש צורך בשרתי Prometheus זמינים במיוחד. ב-Improbable, אנחנו מתייחסים ברצינות לניטור נתונים מדקה אחר דקה, אבל קיום מופע אחד של Prometheus לכל אשכול הוא נקודת כשל בודדת. כל שגיאת תצורה או כשל חומרה עלולים להוביל לאובדן נתונים חשובים. אפילו פריסה פשוטה עלולה לגרום לשיבושים קלים באיסוף המדדים מכיוון שההפעלה מחדש יכולה להיות ארוכה משמעותית ממרווח הגרידה.
אחסון אמין של נתונים היסטוריים
אחסון מדדים זול, מהיר ולטווח ארוך הוא החלום שלנו (משותף לרוב משתמשי פרומתאוס). ב-Improbable, נאלצנו להגדיר את תקופת השמירה של המדדים לתשעה ימים (עבור Prometheus 1.8). זה מוסיף גבולות ברורים לכמה רחוק אנחנו יכולים להסתכל אחורה.
Prometheus 2.0 השתפר בהקשר זה, מכיוון שמספר סדרות הזמן אינו משפיע עוד על הביצועים הכוללים של השרת (ראה. ). עם זאת, פרומתאוס מאחסן נתונים בדיסק מקומי. למרות שדחיסת נתונים ביעילות גבוהה יכולה להפחית באופן משמעותי את השימוש ב-SSD המקומי, בסופו של דבר עדיין יש גבול לכמות הנתונים ההיסטוריים שניתן לאחסן.
בנוסף, ב-Improbable אכפת לנו מאמינות, פשטות ועלות. דיסקים מקומיים גדולים קשים יותר לתפעול ולגיבוי. הם עולים יותר ודורשים יותר כלי גיבוי, מה שגורם למורכבות מיותרת.
הורדת דגימה
ברגע שהתחלנו לעבוד עם נתונים היסטוריים, הבנו שיש קשיים מהותיים עם big-O שהופכים שאילתות לאט יותר ויותר ככל שאנו עובדים עם נתונים של שבועות, חודשים ושנים.
הפתרון הסטנדרטי לבעיה זו יהיה (הורדת דגימה) - הפחתת תדירות דגימת האות. עם דגימה מטה, אנו יכולים "להקטין" לטווח זמן גדול יותר ולשמור על אותו מספר של דגימות, תוך שמירה על תגובה של שאילתות.
הפחתת דגימת נתונים ישנים היא דרישה בלתי נמנעת של כל פתרון אחסון לטווח ארוך והיא מעבר לטווח של וניל פרומתאוס.
מטרות נוספות
אחת המטרות המקוריות של פרויקט Thanos הייתה להשתלב בצורה חלקה עם כל התקנות פרומתאוס קיימות. המטרה השנייה הייתה קלות תפעול עם חסמי כניסה מינימליים. כל תלות צריכה להיות מסופקת בקלות עבור משתמשים קטנים וגדולים כאחד, מה שאומר גם עלות בסיס נמוכה.
ארכיטקטורת ת'אנוס
לאחר פירוט המטרות שלנו בסעיף הקודם, הבה נעבוד דרכן ונראה כיצד Thanos פותר את הבעיות הללו.
תצוגה גלובלית
כדי לקבל תצוגה גלובלית על גבי מופעי Prometheus קיימים, עלינו לקשר נקודת כניסה אחת לבקשה לכל השרתים. זה בדיוק מה שעושה רכיב Thanos. . הוא נפרס ליד כל שרת Prometheus ופועל כפרוקסי, ומגיש נתוני Prometheus מקומיים דרך ה-API של חנות gRPC, ומאפשר לאחזר נתוני סדרות זמן לפי תג וטווח זמן.
בצד השני נמצא רכיב ה-Querier המורחיב וחסר מצב, שעושה מעט יותר מאשר רק לענות על שאילתות PromQL באמצעות ה-API הסטנדרטי של Prometheus HTTP. Querier, Sidecar ורכיבי Thanos אחרים מתקשרים באמצעות .
- Querier, עם קבלת בקשה, מתחבר לשרת ה-API המתאים של Store, כלומר ל-Sidecars שלנו ומקבל נתוני סדרות זמן משרתי Prometheus המתאימים.
- לאחר מכן, הוא משלב את התגובות ומבצע עליהן שאילתת PromQL. Querier יכול למזג גם נתונים לא משותפים וגם נתונים משוכפלים משרתי Prometheus HA.
זה פותר חלק מרכזי בפאזל שלנו - שילוב נתונים משרתי פרומתאוס מבודדים לתצוגה אחת. למעשה, ניתן להשתמש ב-Thanos רק עבור תכונה זו. אין צורך לבצע שינויים בשרתי פרומתאוס קיימים!
חיי מדף בלתי מוגבלים!
עם זאת, במוקדם או במאוחר נרצה לאחסן נתונים מעבר לזמן השמירה הרגיל של פרומתאוס. בחרנו באחסון אובייקטים לאחסון נתונים היסטוריים. זה זמין באופן נרחב בכל ענן כמו גם במרכזי נתונים מקומיים והוא מאוד חסכוני. בנוסף, כמעט כל אחסון אובייקטים זמין דרך ה-API הידוע של S3.
פרומתאוס כותב נתונים מ-RAM לדיסק בערך כל שעתיים. בלוק הנתונים המאוחסן מכיל את כל הנתונים לפרק זמן קבוע ואינו ניתן לשינוי. זה מאוד נוח מכיוון ש-Thanos Sidecar יכול פשוט להסתכל על ספריית הנתונים של Prometheus, וכאשר בלוקים חדשים הופכים זמינים, לטעון אותם לתוך דליים לאחסון אובייקטים.
טעינה לאחסון אובייקטים מיד לאחר הכתיבה לדיסק מאפשרת גם לשמור על הפשטות של המגרד (Prometheus ו-Thanos Sidecar). מה שמפשט את התמיכה, העלות ותכנון המערכת.
כפי שאתה יכול לראות, גיבוי נתונים הוא פשוט מאוד. אבל מה לגבי שאילתת נתונים באחסון אובייקטים?
רכיב Thanos Store פועל כפרוקסי לאחזור נתונים מאחסון אובייקטים. כמו Thanos Sidecar, היא משתתפת באשכול הרכילות ומיישמת את ה-API של Store. בדרך זו, Querier קיים יכול להתייחס אליו כמו Sidecar, כמקור נוסף לנתוני סדרות זמן - אין צורך בהגדרות מיוחדות.
בלוקי נתונים מסדרת זמן מורכבים ממספר קבצים גדולים. טעינתם לפי דרישה תהיה די לא יעילה, ושמירת המטמון המקומית תדרוש כמות עצומה של זיכרון ושטח דיסק.
במקום זאת, Store Gateway יודע להתמודד עם פורמט האחסון של Prometheus. הודות למתזמן שאילתות חכם ואחסון במטמון רק חלקי האינדקס הנחוצים של בלוקים, ניתן לצמצם שאילתות מורכבות למספר מינימלי של בקשות HTTP לאובייקט קבצי אחסון. בדרך זו, תוכלו לצמצם את מספר הבקשות בארבעה עד שש סדרי גודל ולהשיג זמני תגובה שבדרך כלל קשה להבדיל מבקשות לנתונים על SSD מקומי.
כפי שמוצג בתרשים למעלה, Thanos Querier מפחית משמעותית את העלות לשאילתה של נתוני אחסון אובייקטים על ידי מינוף פורמט האחסון של Prometheus והצבת נתונים קשורים זה לצד זה. באמצעות גישה זו, אנו יכולים לשלב בקשות בודדות רבות למספר מינימלי של פעולות בכמות גדולה.
דחיסה והורדת דגימה
ברגע שבלוק חדש של נתוני סדרות זמן נטען בהצלחה לאחסון אובייקטים, אנו מתייחסים אליו כאל נתונים "היסטוריים", הזמינים באופן מיידי דרך שער החנות.
עם זאת, לאחר זמן מה, בלוקים ממקור אחד (Prometheus עם Sidecar) מצטברים ואינם מנצלים עוד את מלוא פוטנציאל האינדקס. כדי לפתור בעיה זו, הצגנו רכיב נוסף בשם Compactor. הוא פשוט מיישם את מנוע הדחיסה המקומי של פרומתאוס על נתונים היסטוריים באחסון אובייקטים וניתן להפעיל אותו כעבודת אצווה תקופתית פשוטה.
הודות לדחיסה יעילה, שאילתת האחסון לאורך תקופה ארוכה אינה מהווה בעיה מבחינת גודל הנתונים. עם זאת, העלות הפוטנציאלית של פירוק מיליארד ערכים והרצתם באמצעות מעבד שאילתות תגרום בהכרח לעלייה דרמטית בזמן ביצוע השאילתה. מצד שני, מכיוון שיש מאות נקודות נתונים לכל פיקסל על המסך, זה הופך להיות בלתי אפשרי אפילו לדמיין את הנתונים ברזולוציה מלאה. לפיכך, הורדת דגימה לא רק אפשרית, אלא גם לא תוביל לאובדן דיוק ניכר.
כדי לצמצם את הדגימה של נתונים, קומפאקטור צובר נתונים ללא הרף ברזולוציה של חמש דקות ושעה. עבור כל נתח גולמי המקודד באמצעות דחיסת TSDB XOR, מאוחסנים סוגים שונים של נתונים מצטברים, כגון min, max או sum עבור בלוק אחד. זה מאפשר ל-Querier לבחור אוטומטית אגרגט שמתאים לשאילתת PromQL נתונה.
אין צורך בתצורה מיוחדת כדי שהמשתמש ישתמש בנתוני דיוק מופחתים. Querier עובר אוטומטית בין רזולוציות שונות ונתונים גולמיים כאשר המשתמש מתקרב ומתרחק. אם תרצה, המשתמש יכול לשלוט בכך ישירות דרך פרמטר "שלב" בבקשה.
מכיוון שעלות האחסון של GB אחד נמוכה, כברירת מחדל Thanos מאחסנת נתונים גולמיים, נתוני רזולוציה של חמש דקות ושעה אחת. אין צורך למחוק את הנתונים המקוריים.
כללי הקלטה
אפילו עם Thanos, כללי הקלטה הם חלק מהותי מערימת הניטור. הם מפחיתים את המורכבות, האחזור והעלות של שאילתות. הם גם נוחים למשתמשים להשיג נתונים מצטברים לפי מדדים. Thanos מבוסס על מופעי Prometheus של וניל, כך שמקובל לחלוטין לאחסן כללי הקלטה וכללי התראה בשרת Prometheus קיים. עם זאת, במקרים מסוימים זה לא יספיק:
- התראה וכלל גלובליים (לדוגמה, התראה כאשר שירות אינו פועל על יותר משניים מתוך שלושה אשכולות).
- כלל לנתונים מחוץ לאחסון מקומי.
- הרצון לאחסן את כל הכללים וההתראות במקום אחד.
עבור כל המקרים הללו, Thanos כולל רכיב נפרד בשם Ruler, אשר מחשב כלל והתראה באמצעות Thanos Queries. על ידי מתן StoreAPI ידוע, צומת השאילתה יכול לגשת למדדים מחושבים טריים. מאוחר יותר הם גם מאוחסנים באחסון אובייקטים ומוגשים דרך ה- Store Gateway.
הכוח של תאנוס
Thanos גמיש מספיק כדי להיות מותאם אישית כדי להתאים לצרכים שלך. זה שימושי במיוחד בעת הגירה מפרומתאוס רגיל. בואו נסכם במהירות את מה שלמדנו על רכיבי Thanos עם דוגמה מהירה. הנה איך לקחת את Prometheus הוניל שלך לעולם של "אחסון מדדים בלתי מוגבל":
- הוסף את Thanos Sidecar לשרתי Prometheus שלך - לדוגמה, מיכל צדדי בתרמיל Kubernetes.
- פרוס מספר העתקים של Thanos Querier כדי להיות מסוגל להציג נתונים. בשלב זה קל להגדיר רכילות בין Scraper ל-Querier. כדי לבדוק את האינטראקציה של רכיבים, השתמש במדד 'thanos_cluster_members'.
רק שני השלבים האלה מספיקים כדי לספק תצוגה גלובלית ומניעת כפילות חלקה של נתונים מהעתקים פוטנציאליים של Prometheus HA! פשוט חבר את לוחות המחוונים שלך לנקודת הקצה של Querier HTTP או השתמש ישירות בממשק המשתמש של Thanos.
עם זאת, אם אתה זקוק לגיבוי מדדים ואחסון לטווח ארוך, תצטרך להשלים שלושה שלבים נוספים:
- צור דלי AWS S3 או GCS. הגדר את Sidecar להעתיק נתונים לדליים אלה. כעת ניתן למזער את אחסון הנתונים המקומי.
- פרוס את Store Gateway וחבר אותו לאשכול הרכילות הקיים שלך. עכשיו אתה יכול לשאול את הנתונים המגובים!
- פרוס קומפאקטור כדי לשפר את יעילות השאילתות לאורך תקופות זמן ארוכות באמצעות דחיסה והורדת דגימה.
אם אתה רוצה לדעת יותר, אל תהסס להסתכל על שלנו и !
בחמישה שלבים בלבד הפכנו את Prometheus למערכת ניטור אמינה עם תצוגה גלובלית, זמן אחסון בלתי מוגבל וזמינות גבוהה פוטנציאלית של מדדים.
בקשה למשוך: אנחנו צריכים אותך!
היה פרויקט קוד פתוח מההתחלה. אינטגרציה חלקה עם Prometheus והיכולת להשתמש רק בחלק של Thanos הופכים אותו לבחירה מצוינת להגדלת מערכת הניטור שלך ללא מאמץ.
אנו תמיד מקבלים בברכה בקשות ובעיות של משיכה של GitHub. בינתיים, אל תהסס לפנות אלינו דרך Github Issues או slackאם יש לך שאלות או משוב, או רוצה לשתף את החוויה שלך בשימוש בו! אם אתה אוהב את מה שאנחנו עושים ב-Improbable, אל תהסס לפנות אלינו - !
מקור: www.habr.com