ניטור כשירות: מערכת מודולרית לארכיטקטורת מיקרו-שירותים

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

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

העבר: תוכניות ותוכניות

איך הגענו למערכת הניטור הנוכחית? כדי לענות על שאלה זו, אתה צריך ללכת לשנת 2015. כך זה נראה אז:

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

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

תקן: ניטור 2.0

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

• זמינות מתמדת;
• מרווח אחסון מדדים = 10 שניות;
• אחסון מובנה של מדדים ודשבורדים;
• SLA > 99,99%
• אוסף מדדי אירועים באמצעות UDP (!).

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

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

הווה: תרשים של אינטראקציה של רכיבי ניטור

קודם כל, אנחנו עוקבים אחר אפליקציות: קוד ה-PHP שלנו, אפליקציות ומיקרו-שירותים - בקיצור, כל מה שהמפתחים שלנו כותבים. כל היישומים שולחים מדדים דרך UDP לצבר של רובק (statsd, משוכתב ב-C). התברר שהוא המהיר ביותר במבחנים סינתטיים. והוא שולח את המדדים שכבר מצטברים ל-Graphite דרך TCP.

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

יש לנו גם אגרגציה למדדים על חומרה, תוכנה, מדדי מערכת ומערכת הניטור הישנה שלנו מונין (זה עבד עבורנו עד 2015). אנחנו אוספים את כל זה דרך ה-C daemon CollectD (יש בו חבורה שלמה של תוספים שונים, הוא יכול לסקור את כל המשאבים של המערכת המארחת עליה הוא מותקן, רק ציין בתצורה היכן לכתוב את הנתונים) ו כתוב את הנתונים ל-Graphite דרכו. זה גם תומך בפלאגינים של python ובסקריפטים של מעטפת, כך שתוכל לכתוב פתרונות מותאמים אישית משלך: CollectD יאסוף את הנתונים האלה ממארח ​​מקומי או מרוחק (בהנחה של Curl) וישלח אותם ל-Graphite.

לאחר מכן אנו שולחים את כל המדדים שאספנו ל-Carbon-c-relay. זהו פתרון ה-Carbon Relay מבית Graphite, שונה ב-C. זהו נתב שאוסף את כל המדדים שאנו שולחים מהאגרגטורים שלנו ומנתב אותם לצמתים. גם בשלב הניתוב הוא בודק את תקפות המדדים. ראשית, הם חייבים להתאים לערכת הקידומת שהראיתי קודם, ושנית, הם תקפים עבור גרפיט. אחרת הם יירדו.

לאחר מכן, ממסר פחמן-c שולח את המדדים לאשכול הגרפיט. אנו משתמשים ב-Carbon-cache, שנכתב מחדש ב-Go, כאחסון העיקרי של מדדים. Go-carbon, בשל ריבוי ההליכים שלו, עולה בהרבה על Carbon-cache. הוא מקבל נתונים וכותב אותם לדיסקים באמצעות חבילת whisper (סטנדרטית, כתובה ב-python). על מנת לקרוא נתונים מהאחסון שלנו, אנו משתמשים ב-Graphite API. זה הרבה יותר מהיר מ-Graphite WEB סטנדרטי. מה קורה לאחר מכן לנתונים?

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

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

פרסנו את Moira ב-Kubernetes; היא משתמשת באשכול של שרתי Redis כמסד הנתונים הראשי. התוצאה הייתה מערכת סובלנית לתקלות. הוא משווה את זרם המדדים עם רשימת הטריגרים: אם אין בו אזכורים, הוא מוריד את המדד. אז הוא מסוגל לעכל ג'יגה-בייט של מדדים לדקה.

צירפנו אליו גם LDAP ארגוני, שבעזרתו כל משתמש במערכת הארגונית יכול ליצור לעצמו התראות על סמך טריגרים קיימים (או חדשים). מכיוון ש-Moira מכיל גרפיט, הוא תומך בכל התכונות שלו. אז תחילה אתה לוקח את הקו ומעתיק אותו לגרפאנה. ראה כיצד הנתונים מוצגים בגרפים. ואז אתה לוקח את אותו קו ומעתיק אותו למוירה. אתה תולה אותו עם מגבלות ומקבל התראה בפלט. כדי לעשות את כל זה, אתה לא צריך שום ידע ספציפי. Moira יכולה להתריע באמצעות SMS, דואר אלקטרוני, Jira, Slack... זה גם תומך בביצוע של סקריפטים מותאמים אישית. כאשר קורה לה טריגר, והיא רשומה לסקריפט מותאם אישית או בינארי, היא מפעילה אותו ושולחת את JSON ל-stdin עבור הבינארי הזה. בהתאם לכך, התוכנית שלך חייבת לנתח אותה. מה תעשה עם ה-JSON הזה תלוי בך. אם אתה רוצה, שלח את זה לטלגרם, אם אתה רוצה, פתח משימות בג'ירה, תעשה מה שלא יהיה.

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

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

רכיבי ניטור

להלן רשימה של קישורים לרכיבים בהם השתמשנו למשימה זו. כולם בקוד פתוח.

גרָפִיט:

• go-carbon: github.com/lomik/go-carbon
• לַחַשׁ: github.com/graphite-project/whisper
• graphite-api: github.com/brutasse/graphite-api

פחמן-c-ממסר:

github.com/grobian/carbon-c-relay

רובק:

github.com/github/brubeck

נאסף:

collectd.org

מוירה:

github.com/moira-alert

גרפאנה:

grafana.com

ערמה:

github.com/kubernetes/heapster

סטטיסטיקה

והנה כמה מספרים על איך המערכת עובדת עבורנו.

אגרגטור (ברובק)

מספר מדדים: ~300/שנייה
מרווח לשליחת מדדים ל-Graphite: 30 שניות
שימוש במשאבי שרת: ~ 6% CPU (אנחנו מדברים על שרתים מן המניין); ~ 1Gb RAM; ~3 Mbps LAN

גרפיט (גו-פחמן)

מספר מדדים: ~ 1/דקה
מרווח עדכון מדדים: 30 שניות
ערכת אחסון מדדים: 30 שניות 35 ד', 5 דקות 90 ד', 10 דקות 365 ד' (נותנת לך הבנה של מה קורה לשירות לאורך תקופה ארוכה)
שימוש במשאבי שרת: ~10% מעבד; ~ 20Gb RAM; ~30 Mbps LAN

גמישות

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

הנה דוגמה לבעיה אמיתית. מדד בגרפיט הוא קובץ. יש לזה שם. שם הקובץ = שם המדד. ויש דרך להגיע לשם. שמות קבצים בלינוקס מוגבלים ל-255 תווים. ויש לנו (כ"לקוחות פנימיים") חבר'ה ממחלקת הנתונים. הם אומרים לנו: "אנחנו רוצים לפקח על שאילתות ה-SQL שלנו. והם לא 255 תווים, אלא 8 מגה-בייט כל אחד. אנחנו רוצים להציג אותם בגרפאנה, לראות את הפרמטרים לבקשה הזו, ואפילו יותר טוב, אנחנו רוצים לראות את החלק העליון של בקשות כאלה. זה יהיה נהדר אם זה יוצג בזמן אמת. זה יהיה ממש מגניב להכניס אותם לכוננות".

שאילתת SQL לדוגמה נלקחת כדוגמה מ אתר postgrespro.ru

אנחנו מקימים שרת Redis ומשתמשים בתוספי Collectd שלנו, אשר עוברים ל-Postgres ולוקחים את כל הנתונים משם, שולחים מדדים ל-Graphite. אבל אנחנו מחליפים את השם המטרי ב-hashs. אנו שולחים בו-זמנית את אותו hash אל Redis כמפתח, ואת כל שאילתת ה-SQL כערך. כל שעלינו לעשות הוא לוודא שגראפנה יוכל ללכת לרדיס ולקחת את המידע הזה. אנחנו פותחים את גרפיט API כי... זה הממשק הראשי לאינטראקציה של כל רכיבי הניטור עם גרפיט, ואנחנו מכניסים שם פונקציה חדשה בשם aliasByHash() - מ-Grafana אנחנו מקבלים את שם המדד, ומשתמשים בו בבקשה ל-Redis כמפתח, ב בתגובה אנו מקבלים את הערך של המפתח, שהוא "שאילתת SQL" שלנו כך, הצגנו בגראפאנה תצוגה של שאילתת SQL, שבתיאוריה אי אפשר היה להציג אותה שם, יחד עם סטטיסטיקות עליה (שיחות, שורות, total_time,...).

תוצאות של

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

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

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

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

למה אנחנו מכוונים?

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

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

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

מקור: www.habr.com