האם הניטור מת? - יחי ניטור

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

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

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

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

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

אז מה השתנה? - הכל השתנה!

2008 הכל בסדר

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

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

2010 העומס הולך וגדל

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

יתרה מכך, הישות הקשורה לתשתית עדיין נותרה הגדולה ביותר בראשו של המנהל. עדיין יש לי רעיון בראש שמי שעושה את הניטור הוא מי שיתקין את zabbix ויוכל להגדיר אותו.

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

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

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

אבל לעתים רחוקות מישהו מלווה פרויקט במשך 10 שנים.

קורות חיים של ניטור

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

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

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

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

• עליו להבין את הניטור והפרטים של תפעול תשתית הברזל.
• הוא חייב להבין את הפרטים של ניטור Kubernetes (וכולם רוצים ללכת ל"קוביה", כי אתה יכול להסתיר מהכל, להסתיר, כי המנהל יעסוק בכל השאר) - עצמו, התשתית שלו, ולהבין איך לנטר אפליקציות בְּתוֹך.
• עליו להבין ששירותים מתקשרים זה עם זה בדרכים מיוחדות, ולדעת את הפרטים של האופן שבו שירותים מתקשרים זה עם זה. זה בהחלט אפשרי לראות פרויקט שבו שירותים מסוימים מתקשרים באופן סינכרוני, כי אין דרך אחרת. לדוגמה, ה-backend עובר דרך REST, דרך gRPC לשירות הקטלוג, מקבל רשימת מוצרים ומחזיר אותה בחזרה. אתה לא יכול לחכות כאן. ועם שירותים אחרים זה עובד באופן אסינכרוני. להעביר את ההזמנה לשירות המשלוחים, לשלוח מכתב וכו'.
  בטח כבר שחית מכל זה? והמנהל, שצריך לפקח על זה, התבלבל עוד יותר.
• עליו להיות מסוגל לתכנן ולתכנן נכון – ככל שהעבודה הולכת ומתרחבת.
• לכן עליו ליצור אסטרטגיה מהשירות שנוצר על מנת להבין כיצד לנטר אותו באופן ספציפי. הוא זקוק להבנה של ארכיטקטורת הפרויקט ופיתוחו + הבנה של הטכנולוגיות המשמשות בפיתוח.

בואו נזכור מקרה רגיל לחלוטין: חלק מהשירותים נמצאים ב-PHP, חלק מהשירותים נמצאים ב-Go, חלק מהשירותים נמצאים ב-JS. הם איכשהו עובדים אחד עם השני. מכאן מגיע המונח "מיקרו-שירות": יש כל כך הרבה מערכות בודדות שמפתחים לא יכולים להבין את הפרויקט בכללותו. חלק אחד מהצוות כותב שירותים ב-JS שעובדים לבד ולא יודעים איך שאר המערכת עובדת. החלק השני כותב שירותים ב-Python ואינו מפריע לאופן שבו שירותים אחרים עובדים; הם מבודדים באזור שלהם. השלישי הוא שירותי כתיבה ב-PHP או משהו אחר.
כל 20 האנשים האלה מחולקים ל-15 שירותים, ויש רק מנהל אחד שחייב להבין את כל זה. תפסיק! פשוט חילקנו את המערכת ל-15 שירותי מיקרו כי 20 אנשים לא יכולים להבין את המערכת כולה.

אבל צריך לפקח איכשהו...

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

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

ניטור פרויקט תוכנה מודרני הוא פרויקט תוכנה בפני עצמו

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

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

ואם תתנו את זה גם למנהל ולמפתחים בשלב שנותר זמן קצר לפני השחרור, האדם יצטרך להבין את כל הפרוטוקול הזה. הָהֵן. פרויקט בסדר גודל כזה לוקח זמן משמעותי, ויש לקחת זאת בחשבון בפיתוח המערכת.
אבל לעתים קרובות מאוד, במיוחד בסטארט-אפים, אנו רואים כיצד הניטור נדחה למועד מאוחר יותר. "עכשיו נעשה Proof of Concept, נשיק איתה, נניח לזה - אנחנו מוכנים להקריב. ואז נעקוב אחר הכל". כאשר (או אם) הפרויקט מתחיל להרוויח כסף, העסק רוצה להוסיף עוד יותר פיצ'רים - כי הוא התחיל לעבוד, אז צריך לפרוס אותו הלאה! ואתה בנקודה שבה אתה צריך קודם כל לפקח על כל מה שהיה קודם, מה שלוקח לא 1% מהזמן, אלא הרבה יותר. ודרך אגב, יידרשו מפתחים לניטור, וקל יותר לתת להם לעבוד על תכונות חדשות. כתוצאה מכך נכתבים פיצ'רים חדשים, הכל מתקלקל ואתם במבוי סתום אינסופי.

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

ראשית, אתה צריך לתכנן.

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

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

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

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

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

הכל לפי רמות

כך אני רואה ארגון של מערכת ניטור.

1) רמת יישום:

• ניטור היגיון עסקי של יישומים;
• ניטור מדדי בריאות של שירותים;
• ניטור אינטגרציה.

2) רמת תשתית:

• ניטור רמת התזמור;
• ניטור תוכנת מערכת;
• ניטור רמת הברזל.

3) שוב רמת היישום - אבל כמוצר הנדסי:

• איסוף וניטור יומני יישומים;
• APM;
• מַעֲקָב.

4) התראה:

• ארגון מערכת אזהרה;
• ארגון מערכת חובה;
• ארגון "בסיס ידע" וזרימת עבודה לעיבוד אירועים.

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

שכבת אפליקציה - ניטור לוגיקה עסקית

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

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

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

• יצירת בדיקות כאלה היא בעצם המשימה של המפתחים. מבחני יחידה צריכים להיכתב על ידי המתכנתים שכותבים את הקוד. כי אם אתה מדליף את זה למנהל, "אחי, הנה רשימה של פרוטוקולי API עבור כל 25 הפונקציות, נא לפקח על הכל!" - שום דבר לא יסתדר.
• אם תדפיס "שלום עולם", אף אחד לעולם לא יידע שה-API צריך ועובד. כל שינוי ב-API חייב להוביל לשינוי בבדיקות.
• אם כבר יש לך בעיה כזו, עצור את הפיצ'רים והקצה מפתחים שיכתבו את הצ'קים האלה, או יקבלו את ההפסדים, קבל ששום דבר לא נבדק ויכשל.

טיפים טכניים:

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

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

עכשיו אנחנו מדברים על מדדי בריאות חיצוניים של שירותים.

החלטנו שאנו מפקחים על כל "הטיפולים" של האפליקציה באמצעות בדיקות חיצוניות, שאנו קוראים להן ממערכת ניטור חיצונית. אבל אלו הן ה"ידיות" שהמשתמש "רואה". אנחנו רוצים להיות בטוחים שהשירותים שלנו עצמם עובדים. יש כאן סיפור טוב יותר: ל-K8s יש בדיקות בריאות, כך שלפחות את ה"קוביה" עצמה ניתן לשכנע שהשירות עובד. אבל חצי מהצ'קים שראיתי הם אותו הדפס "שלום עולם". הָהֵן. אז הוא מושך פעם אחת לאחר הפריסה, הוא ענה שהכל בסדר - זה הכל. ולשירות, אם הוא מספק API משלו, יש מספר עצום של נקודות כניסה לאותו API, שגם אותו צריך לנטר, כי אנחנו רוצים לדעת שהוא עובד. ואנחנו כבר עוקבים אחרי זה בפנים.

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

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

שכבת אפליקציה - ניטור אינטגרציה

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

לדוגמה, ישנם 15 שירותים המתקשרים זה עם זה. אלה כבר לא אתרים נפרדים. הָהֵן. אנחנו לא יכולים למשוך את השירות לבד, לקבל את /helloworld ולהבין שהשירות פועל. מכיוון ששירות האינטרנט המזמין חייב לשלוח מידע על ההזמנה לאוטובוס - מהאוטובוס, על שירות המחסן לקבל הודעה זו ולעבוד איתה הלאה. ושירות הפצת הדוא"ל חייב לעבד את זה איכשהו הלאה, וכו'.

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

מה אני ממליץ לעשות:

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

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

לעתים קרובות מאוד אנו שומעים את השאלה "איך אנחנו יכולים לבדוק את זה על נתוני לחימה?" לדוגמה, אנחנו מדברים על אותו שירות הזמנות. ההזמנה שולחת הודעות למחסן שבו הסחורה נמחקת: אנחנו לא יכולים לבדוק זאת על נתוני לחימה, כי "הסחורה שלי תימחק!" פתרון: תכננו את כל המבחן הזה בהתחלה. יש לך גם מבחני יחידה שעושים לעג. לכן, עשו זאת ברמה עמוקה יותר שבה יש לכם ערוץ תקשורת שאינו פוגע בתפעול העסק.

שכבת תשתית

ניטור תשתיות הוא דבר שנחשב מזמן לניטור עצמו.

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

רמת יישום כיחידה עסקית

נקודות עיקריות:

• דִישׁוֹן. זהו תקן התעשייה. אם מסיבה כלשהי אינך אוסף יומנים, התחל לעשות זאת מיד.
• APM. APMs חיצוניים כדרך לסגירה מהירה של ניטור יישומים (NewRelic, BlackFire, Datadog). אתה יכול להתקין את הדבר הזה באופן זמני כדי לפחות איכשהו להבין מה קורה איתך.
• מַעֲקָב. בעשרות מיקרו-שירותים צריך להתחקות אחר הכל, כי הבקשה כבר לא חיה בפני עצמה. קשה מאוד להוסיף מאוחר יותר, ולכן עדיף לתזמן מיד מעקב בפיתוח - זו העבודה והתועלת של המפתחים. אם עדיין לא יישמת את זה, יישם את זה! ראה יגר/זיפקין

מתריע

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

ערימת טכנולוגיה

בואו נדמיין שהמחסנית שלנו היא כדלקמן:

• איסוף נתונים - פרומתאוס + גרפנה;
• ניתוח יומן - ELK;
• עבור APM או Tracing - Jaeger (Zipkin).

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

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

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

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

ממצאים

• ניטור פיתוח אינו התקנה של כלי עזר, אלא פיתוח של מוצר תוכנה. 98% מהניטור של היום הוא קידוד. קידוד בשירותים, קידוד שיקים חיצוניים, בדיקת שירותים חיצוניים, וזה הכל.
• אל תבזבז את זמנם של המפתחים שלך על ניטור: זה יכול לקחת עד 30% מהעבודה שלהם, אבל זה שווה את זה.
• Devops, אל תדאג שאתה לא יכול לפקח על משהו, כי יש דברים שהם דרך חשיבה אחרת לגמרי. לא היית מתכנת, ועבודת ניטור היא בדיוק העבודה שלהם.
• אם הפרויקט כבר פועל ואינו בפיקוח (ואתם מנהלים), הקצו משאבים לניטור.
• אם המוצר כבר בייצור, ואתם דבוקים שאמרו לכם "להגדיר ניטור" - נסו להסביר להנהלה על מה כתבתי את כל זה.

זוהי גרסה מורחבת של הדו"ח בכנס Saint Highload++.

אם אתה מעוניין ברעיונות ובמחשבות שלי בנושא ובנושאים קשורים, אז כאן אתה יכול לקרוא את הערוץ ???

מקור: www.habr.com