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

רווחים:

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

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

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

הכלים הנפוצים ביותר: Prometheus למדדים, Grafana להדמיה, Loki/ELK ללוג, Jaeger/OpenTelemetry למעקב. בינה מלאכותית מיומנת מאוד בכתיבת שפות השאילתה (במיוחד PromQL של ​​Prometheus), כללי אזעקה ותצורות לוח המחוונים עבור כלים אלה. זה גם המקום שבו הבינה המלאכותית היא הכי חזקה שלה: סיכום נתחים גדולים של יומנים ומדדים וסימון חריגות.

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

שלב אחר שלב: מה ואיך לנטר?

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

טיפ: אזעקה טובה פוגשת שני דברים: היא ניתנת לפעולה ובעלת הדחיפות הנכונה. אזעקה שמעיר מישהו ב-3 לפנות בוקר חייבת להיות משהו שבעצם דורש התערבות לילית. אל תעיר אף אחד למשהו שאינו דורש פעולה בפני עצמו, כמו "מעבד 70%"; להציג אותו על הלוח.

איך כותבים כלל אזעקה?

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

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

פרטיות יומן: אזהרה קריטית

יומנים הם המקור הנפוץ ביותר לדליפות. שורת יומן עשויה להכיל בטעות סיסמה, מספר כרטיס אשראי או נתונים אישיים (תחת KVKK/GDPR). בעת הדבקת יומנים ב-AI לצורך ניתוח:

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

ארבעה אותות זהב וטבלאות אזעקה

אות

נמדד לפי

סף אזעקה לדוגמה

דחיפות

חביון

זמן תגובה

p95 > 800 אלפיות השנייה, 5 דקות

גבוה

תנועה

בקשה/שנייה

עלייה/ירידה פתאומית של 300%.

בינוני

שגיאה

שיעור הבקשות נכשל

> 5%, 5 דקות

קריטי

רוויה

תפוסת משאבים

דיסק > 85%

גבוה

שלושה מיני תיקים

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

מקרה 2 - עייפות אזעקה נפתרה. צוות אחד קיבל 200 אזעקות ביום והתעלם מכולן - עד שגם אזעקת הפסקה אמיתית התעלמה. תן ל-AI את כל כללי ההתראה ושאל "אילו לא ניתנים לפעולה ואיזה ניתן לשלב?" שאלו. מספר האזעקות ירד ל-12 ביום; כל אזעקה נלקחה כעת ברצינות.

מקרה 3 - סף שגוי נתפס מוקדם. YZ הציע "הזהיר כאשר 95% מלא" עבור הדיסק. המהנדס בחן נתונים היסטוריים: ברגע שהדיסק הגיע ל-95%, היה מעט זמן להתערבות. הוא הוריד את הסף ל-80% והוסיף אזעקה שנייה המבוססת על "קצב צמיחה". האימות מנע הפסקת חצות בפועל.

ארבע תבניות הניתנות להעתקה

1) סיכום יומן (מסווה):

נתח את דוגמה ביומן למטה (הסתרתי ערכים רגישים עם <REDACTED>). תן לי: (1) דפוסי שגיאה חוזרים, (2) ריכוז לאורך זמן, (3) ככל הנראה סיבת השורש ו- (4) 3 מדדים שאסתכל עליהם כדי לאמת. יומן: [LINES]

2) יצירת כלל אזעקה:

כתוב כלל אזעקה עבור Prometheus/Alertmanager: צור אזעקת [SEVERITY] אם [THRESHOLD] חורג מ-[METRIC][DURATION]. הכלל צריך להיות מכוון פעולה ולכלול שדה הערה ו-Runbook קישור. הסבר את PromQL וכתוב מדוע סף זה סביר.

3) כתיבה/הצהרה של שאילתת PromQL:

כתוב שאילתת PromQL שמודדת: [EX. אחוז שיעור שגיאות 5xx ב-5 הדקות האחרונות]. הסבר את השאילתה צעד אחר צעד. אז אמור לי מה הטווח הבריא עבור הערך הזה צריך להיות.

4) עיצוב לוח המחוונים:

עצב לוח מחוונים של Grafana עבור [SERVICE]: עם אילו פאנלים עלי להציג את ארבעת אותות הזהב (השהייה, תעבורה, שגיאה, רוויה)? הצע מדד, סוג הדמיה וסף סביר עבור כל פאנל. מטרה: לראות את המצב הבריאותי של שומר תוך 10 שניות.

הנחיה חלשה / הנחיה חזקה

חלש: "מה יש ביומן הזה?" (אחריהם 5000 שורות של יומן גולמי, אסימונים בתוכו)

תוצאה: אתה מדליף סודות וה-AI נותן סיכום לא ממוקד ושטחי.

חזק: "מצא דפוסי שגיאה חוזרים ועוצמת זמן בדוגמה של יומן המסכה של 300 שורות למטה; ספר לי את סיבת השורש הסבירה ביותר ואת המדדים שאסתכל עליהם כדי לאמת. עשיתי את האסימונים <REDACTED>."

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

טעויות נפוצות

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

לסיכום

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

משימת יישום

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

רשימת בדיקה

• [ ] בחרתי את המדדים למעקב על סמך ארבעה אותות זהב.
• [ ] הסתרתי את כל היומנים שנתתי ל-AI במונחים של אזורים רגישים.
• [ ] וידאתי שכל אזעקה הייתה מוכוונת פעולה ובעלת דחיפות נכונה.
• [ ] בדקתי את ספי האזעקה מול הנתונים ההיסטוריים של המערכת שלי.
• [ ] סיננתי תנודות מיידיות על ידי הוספה של (משך זמן) לאזעקות.
• [ ] השתמשתי ב-metric + log + trace יחד לסיבת השורש.