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

שלום לכולם!

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

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

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

אסטרטגיית ניטור

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

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

המהות של אסטרטגיית הניטור שלנו:

חלק את היישום שלך לרכיבים.
צור בדיקות בקרה עבור כל רכיב.

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

לפיכך, כל מערכת יכולה להיות מיוצגת כעץ של רכיבים. רכיבים מורכבים מחולקים לפשוטים יותר. לרכיבים פשוטים יש צ'קים.

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

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

מערכת פיקוח

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

נצטרך מערכת ניטור. היא תבצע את המשימות הבאות:

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

תיאור קצר של מערכת ASMO

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

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

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

פירוק המערכת לרכיבים

ניתן להבחין בין הרכיבים הבאים במערכת ASMO:

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

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

3. שרת
בשרת אנו מתכוונים לחומרה שעליה רצות יישומים. יש צורך לבדוק את המצב של HDD, RAM, CPU.

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

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

6. נקודות בקרת דרכים (מיכל של כל ה-MPC)
ישנן נקודות בקרת דרכים רבות, אז בואו נשלב את כל ה-MPC ברכיב אחד. זה יעשה את זה נוח יותר לקרוא נתוני ניטור. בעת צפייה בסטטוס של רכיב "מערכת ASMO", יהיה ברור מיד היכן הבעיות: באפליקציות, בחומרה או במערכת הבקרה המקסימלית.

7. נקודת בקרת דרך (מגבלה מקסימלית אחת)
אנו נשקול את הרכיב הזה כשיר לשירות אם כל המכשירים ב-MPC זה ניתנים לשירות.

8. מכשיר
זוהי מצלמת וידאו או תחנת מזג אוויר המותקנת במגבלת הריכוז המקסימלית. יש צורך לבדוק שהמכשיר תקין.

במערכת הניטור, עץ הרכיבים ייראה כך:

ניטור יישומי אינטרנט

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

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

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

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

3. בדיקת תעודת SSL
כיום, כמעט כל האתרים משתמשים בפרוטוקול https לגישה. כדי שהפרוטוקול יפעל כהלכה, אתה צריך תעודת SSL תקפה.

להלן מרכיב "חשבון אישי" במערכת הניטור:

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

מה עוד אפשר לבדוק?

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

• מספר שגיאות JavaScript לכל תקופה
• מספר השגיאות בצד יישום האינטרנט (בקצה האחורי) עבור התקופה
• מספר תגובות יישומי אינטרנט לא מוצלחות (קוד תגובה 404, 500 וכו')
• זמן ביצוע שאילתה ממוצע

ניטור שירות Windows (סוכן)

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

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

אנו מפצלים את רכיב הסוכן לרכיבי צאצא (משימות):

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

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

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

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

בדוק אלגוריתם

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

בדיקה זו יכולה לזהות את הבעיות הבאות:

1. המשימה פועלת אך נכשלת עם שגיאה.
2. המשימה הפסיקה לפעול, למשל, היא קפאה.

הבה נבחן כיצד בעיות אלה נפתרות ביתר פירוט.

בעיה 1 - המשימה פועלת אך נכשלת עם שגיאה
להלן מקרה שבו המשימה פועלת אך נכשלת בין 14:00 ל-16:00.

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

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

בעיה 2 - המשימה הפסיקה לבצע (הוקפאה)
כיצד תבין מערכת הניטור שמשימה תקועה?

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

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

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

באיזה זמן בדיקת רלוונטיות עלי להשתמש?

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

בודק התקדמות

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

בדוק אלגוריתם

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

הצ'ק חייב להיות בעל מרווח רלוונטיות כך שבמהלך זמן זה מובטח לו התקדמות חדשה.

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

ניטור מסדי נתונים

כדי לשלוט במסד הנתונים במערכת ASMO, אנו מבצעים את הבדיקות הבאות:

1. אימות יצירת גיבוי
2. בודק מקום פנוי בדיסק

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

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

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

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

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

להלן תמונה של איך נראה רכיב "בסיס הנתונים" במערכת הניטור:

ניטור שרתים

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

1. שטח דיסק פנוי
אם שטח הדיסק אוזל, היישום לא יוכל לעבוד. אנו משתמשים ב-2 ערכי סף: הרמה הראשונה היא WARNING, הרמה השנייה היא ALARM.

2. ערך RAM ממוצע באחוזים לשעה
אנו משתמשים בממוצע לשעה כי... אנחנו לא מעוניינים במרוצים נדירים.

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

4. בדיקת פינג
בודק שהשרת מקוון. מערכת הניטור יכולה לבצע בדיקה זו; אין צורך לכתוב קוד.

להלן תמונה של איך נראה רכיב ה"שרת" במערכת הניטור:

ניטור ציוד

אני אגיד לך איך הנתונים מתקבלים. עבור כל נקודת בקרת כביש (MPC) ישנה משימה במתכנן המשימות, למשל, "סקר MPC M2 km 200". המשימה מקבלת נתונים מכל מכשירי MPC כל 30 דקות.

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

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

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

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

להלן תמונה של איך נראה הציוד במערכת הניטור:

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

ערכת ניטור סופית של ASMO

בואו נחבר הכל ונראה איזה סוג של ערכת ניטור יש לנו.

מסקנה

בואו נסכם.
מה נתן לנו ניטור הביצועים של ASMO?

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

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

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

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

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

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

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

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

המלצות:

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

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

מזל טוב.

מקור: www.habr.com