ניטור אשכול Kubernetes: סקירה והיכרות עם פרומתאוס

קחו בחשבון את הרעיון של ניטור Kubernetes, הכירו את הכלי Prometheus ודברו על התרעה.

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

החומר של המאמר הוא סחיטה מ הרצאה פתוחה של בית הספר "סלורם". אם אתה רוצה לעבור קורס מלא - הירשמו לקורס בנושא תשתית ניטור ורישום ב-Kubernetes.

מה מנוטר באשכול Kubernetes

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

בואו נעבור לניטור ברמת האשכול.

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

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

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

כניסה. יש צורך לשלוט בזמינות הכניסות (כולל ה-Ingress Controller) כנקודות כניסה לפרויקט.

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

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

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

פרומתאוס

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

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

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

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

Prometheus משולב היטב עם Kubernetes: הוא יכול לגשת לשרת ה-API ולקיים איתו אינטראקציה.

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

ארכיטקטורת פרומתאוס

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

המדדים מאוחסנים במסד הנתונים של סדרות הזמן (TSDB). TSDB אינו מסד נתונים נפרד, אלא חבילה בשפת Go המוטמעת ב-Prometheus. באופן גס, הכל בבינארי אחד.

אל תשמור נתונים ב-TSDB במשך זמן רב

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

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

Prometheus Server עובד על הדגם למשוך: הוא הולך על מדדים לנקודות הקצה האלו שנתנו לו. הם אמרו: "עבור לשרת ה-API", והוא הולך לשם כל מספר n' של שניות ולוקח את המדדים.

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

כדי להגדיר התראות ב-Prometheus יש רכיב נפרד - מנהל התראה. וכללי ההתראה. לדוגמה, עליך ליצור התראה אם ​​ממשק ה-API של השרת הוא 0. כאשר האירוע מופעל, ההתראה מועברת למנהל ההתראות להמשך שיגור. למנהל ההתראות יש הגדרות ניתוב גמישות למדי: ניתן לשלוח קבוצה אחת של התראות לצ'אט טלגרם של המנהלים, אחרת לצ'אט של המפתחים ושלישית לצ'אט של עובדי התשתית. ניתן לשלוח התראות ל-Slack, טלגרם, דואר אלקטרוני וערוצים אחרים.

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

הגישה הזו משתלבת היטב במבנה Kubernetes, שבו גם הכל צף: היום יש 10 שרתים, מחר 3. כדי לא לציין בכל פעם את כתובת ה-IP של השרת, כתבו פעם אחת איך למצוא אותה - ו-Discovering יעשה זאת. .

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

https://prometheus.io/docs/prometheus/latest/querying/basics/

Простой запрос

    container_memory_usage_bytes

Математические операции

    container_memory_usage_bytes / 1024 / 1024

Встроенные функции

    sum(container_memory_usage_bytes) / 1024 / 1024

Уточнение запроса

    100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

ממשק אינטרנט של פרומתאוס

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

בשורת Expression, אתה יכול לכתוב שאילתה בשפת PromQL.

הכרטיסייה התראות מכילה כללי התראה, ויש להם שלושה סטטוסים:

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

בתפריט סטטוס תמצא גישה למידע על מה זה פרומתאוס. יש גם מעבר למטרות (מטרות), עליהן דיברנו למעלה.

לסקירה מפורטת יותר של ממשק פרומתאוס, ראה בהרצאה של Slurm על ניטור אשכול Kubernetes.

אינטגרציה עם גרפאנה

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

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

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

מחבר: מרסל איברייב, מנהל קוברנטס מוסמך, מהנדס בפועל בחברה סאות'ברידג ', דובר ומפתח קורס Slurm.

מקור: www.habr.com