איך בנינו ניטור על פרומתאוס, קליקהאוס ו-ELK

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

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

О проекте

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

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

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

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

פרומתאוס

בחרנו בפרומתאוס על סמך שלושה אינדיקטורים עיקריים:

1. מספר עצום של מדדים זמינים. במקרה שלנו יש 60 אלף כאלה. כמובן, ראוי לציין שאנו לא משתמשים ברובם המכריע (כנראה כ-95%). מצד שני, כולם זולים יחסית. עבורנו, זו הקיצוניות השנייה בהשוואה לאיצ'ינגה שהשתמשו בה בעבר. בו, הוספת מדדים הייתה כאב מיוחד: הקיימים היו יקרים (פשוט תסתכל על קוד המקור של כל תוסף). כל תוסף היה סקריפט ב-Bash או Python, שהשקתו יקרה במונחים של משאבים שנצרכו.
2. מערכת זו צורכת כמות קטנה יחסית של משאבים. 600 MB של זיכרון RAM, 15% של ליבה אחת וכמה עשרות IOPS מספיקים לכל המדדים שלנו. כמובן שצריך להפעיל יצואנים של מדדים, אבל כולם כתובים ב-Go וגם לא מאוד צריכות חשמל. אני לא חושב שבמציאות המודרנית זו בעיה.
3. מספק את היכולת לעבור אל Kubernetes. בהתחשב בתוכניות של הלקוח, הבחירה ברורה.

דִישׁוֹן

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

קליקהאוס

בתחילה, הבחירה נפלה על InfluxDB. הבנו את הצורך לאסוף יומני Nginx, סטטיסטיקות מ-pg_stat_statements, ולאחסן נתונים היסטוריים של Prometheus. לא אהבנו את Influx כי הוא החל לצרוך כמות גדולה של זיכרון מעת לעת וקרס. בנוסף, רציתי לקבץ שאילתות לפי remote_addr, אבל הקיבוץ ב-DBMS הזה הוא רק לפי תגים. התגים יקרים (זיכרון), מספרם מוגבל על תנאי.

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

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

NewRelic

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

זאביקס

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

הגדרת גישת ניטור

רצינו לפרק את המשימה ובכך לסדר את הגישה לניטור.

לשם כך חילקתי את המערכת שלנו לרמות הבאות:

• חומרה ו-VMS;
• מערכת הפעלה;
• שירותי מערכת, ערימת תוכנה;
• יישום;
• היגיון עסקי.

מדוע גישה זו נוחה:

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

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

מכונות וירטואליות

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

זמן גניבת מעבד – כשאתה קונה מכונה וירטואלית באמזון (t2.micro, למשל), אתה צריך להבין שלא מוקצית לך ליבת מעבד שלמה, אלא רק מכסה מהזמן שלה. וכשתמצה אותו, המעבד יילקח ממך.

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

זמן המתנה של IOPS + CPU - מסיבה כלשהי, מארחי ענן רבים חוטאים בכך שאינם מספקים מספיק IOPS. יתר על כן, לוח זמנים עם IOPS נמוך אינו ויכוח עבורם. לכן, כדאי לאסוף CPU iowait. עם צמד הגרפים הזה - עם IOPS נמוך והמתנה I/O גבוהה - אתה כבר יכול לדבר עם האירוח ולפתור את הבעיה.

מערכת הפעלה

מדדי מערכת הפעלה:

• כמות הזיכרון הפנוי ב-%;
• החלפת פעילות שימוש: vmstat swapin, swapout;
• מספר האינודים הזמינים ושטח פנוי במערכת הקבצים ב-%
• עומס ממוצע;
• מספר חיבורים במצב שני;
• חיבור שולחן מלא;
• ניתן לנטר את איכות הרשת באמצעות כלי השירות ss, חבילת iproute2 - קבלו אינדיקטור של חיבורי RTT מהפלט שלה וקבצו אותו לפי יציאת dest.

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

קבוצת המדדים היא כדלקמן:

• מעבד;
• הזיכרון הוא בעיקר תושב;
• IO - רצוי ב-IOPS;
• FileFd - פתח והגבלת;
• כשלים משמעותיים בעמוד - כך תוכלו להבין באיזה תהליך מחליפים.

אנו פורסים את כל הניטור ב-Docker, ואנחנו משתמשים ב-Advisor כדי לאסוף נתוני מדדים. במכונות אחרות אנו משתמשים ב-proces-exporter.

שירותי מערכת, ערימת תוכנה

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

הסט האוניברסלי הוא:

• שיעור בקשה;
• מספר טעויות;
• חֶבִיוֹן;
• רִוּוּי.

הדוגמאות הבולטות ביותר שלנו לניטור ברמה זו הן Nginx ו-PostgreSQL.

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

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

זה כל מה שהמנהל צריך.

אנו בונים גרפים של הפעילות של בקשות קריאה וכתיבה:

הכל פשוט וברור, לכל בקשה יש את הצבע שלה.

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

באופן אישי, הוספתי request_time, upstream_response_time, body_bytes_sent, request_length, request_id. אנו מתווים את זמן התגובה ומספר השגיאות:

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

אך נותרה בעיה אחת נוספת - להבטיח חיסול מהיר של הגורמים לאירוע.

פתרון אירוע

ניתן לחלק את כל התהליך מזיהוי ועד פתרון בעיה למספר שלבים:

• זיהוי הבעיה;
• הודעה למנהל התורן;
• תגובה לאירוע;
• ביטול הסיבות.

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

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

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

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

כמה נקודות.

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

שנית, השתמש נכון ברמות החומרה. לכל שפה יש תקן משלה. באופן אישי, אני מבחין בארבע רמות:

1. אין שגיאה;
2. שגיאה בצד הלקוח;
3. הטעות היא בצד שלנו, אנחנו לא מפסידים כסף, אנחנו לא נושאים בסיכונים;
4. הטעות היא בצד שלנו, אנחנו מפסידים כסף.

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

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

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

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

מקור: www.habr.com