הגדרת CloudWatch: מה נשבר ללא ניטור מקצה לקצה
כשל обычно נראה כך: השירות מחזיר שגיאות 500, ובקונסולה — שקט. מדדי עומס על האינסטנסים נכתבים לכלי אחד, לוגים של האפליקציה נשמרים בקבצים על הדיסק, והתראות מוגדרות על כמה ספים ברורים מאליהם. המהנדס מבזבז שעות על תיאום חותמות זמן משלושה מקורות, במקום לאתר את הסיבה תוך דקות.
המחיר של נקודה עיוורת כזו הוא לא רק השבתה: ללא נראות מקצה לקצה אי אפשר להוכיח שהבעיה הייתה בדיוק בצומת הזה, והיא חוזרת.
הגדרת CloudWatch מתחילה לא בהפעלת הסוכן, אלא במפה של אילו אותות בכלל נדרשים כדי לענות על השאלה "מה נשבר ואיפה". מדדים ללא ממדים לפי שירות וסביבה חסרי תועלת — הם לא מאפשרים לחתוך את הרעש ולראות את ההידרדרות של נתיב בקשה מסוים.
לוגים ללא פורמט מובנה ומזהה בקשה אחיד לא מתחברים לשרשרת בין שירותים, ולכן תיעוד לוגים בענן הופך למזבלה, ולא לכלי לניתוח.
נקודה עיוורת נפרדת היא הפער בין השכבה התשתיתית לשכבת האפליקציה. העומס על הצמתים תקין, אבל המשתמשים מקבלים שגיאות: ללא חיבור בין מדדים ללוגים ולטרייסינג תרחיש כזה לא מאובחן. נראות מקצה לקצה נבנית על נקודת איסוף אחידה, שבה מדדים, לוגים והתראות חיים זה לצד זה ומפנים זה לזה.
מפרקים כיצד זה נסגר: כיצד לבנות איסוף מדדים ולוגים, להגדיר התראות על סימפטומים ולא על רעש, ולהסיר נקודות עיוורות בתשתית לפני שהן מתגלות בפרודקשן.
מה נותן מעגל ניטור ולוגים אחיד
מעגל אחיד אוסף מדדים, לוגים וטראסות במקום אחד, ולכן תקלה נראית בשלמותה ולא כשברים בכלים שונים. כאשר האות מהאפליקציה, מהמאזן ומהמסד נמצאים זה לצד זה, סיבת התקלה נמצאת תוך דקות ולא תוך שעות של התכתבות בצ'אט. נפרק כיצד זה בנוי ומה זה נותן במונחים מדידים.
זמן זיהוי ושחזור
התראות סף על מדדי מפתח — שיעור שגיאות, השהיית תגובה, רוויה של תור — מופעלות לפני שהלקוח מספיק לכתוב לתמיכה. בפועל זמן זיהוי התקלה יורד משעות לדקות: התורן מקבל התראה ברגע הסטייה מהנורמה, ולא לפי עובדת התלונה.
לאחר מכן השחזור מהיר יותר, כי ההקשר כבר נאסף: רואים איזה ריליס עלה, איזה צומת הידרדר, מה כתבו הלוגים ברגע התקלה.
הפחתת רעש ההתראות
הסיבה העיקרית לשחיקה של תורנים — מפולת התראות, שבה תקלה אמיתית טובעת בהתראות שווא. אנו מגדירים תנאים מורכבים וחלונות דיכוי: התראה נשלחת רק כאשר המדד נשאר מחוץ לנורמה לזמן מוגדר, והאותות הקשורים מקובצים להתראה אחת. שיעור הרעש יורד פי כמה, והתורן מגיב למה שבאמת דורש התערבות.
עלות אחסון לוגים
לוגים לעתים רחוקות נחוצים בשלמותם ולנצח. מדיניות אחסון מפרידה נתונים לפי תקופות: טריים — בגישה מהירה לניתוח, ישנים — בשכבה זולה או למחיקה לפי לוח זמנים. נפח האחסון מפסיק לגדול באופן ליניארי, והוצאות האחסון מתייצבות בלי לאבד את היכולת להעלות היסטוריה לתקופה הנדרשת.
סוג הכשל שנעלם
אפקט נפרד — צפיות. התראות על שטח דיסק, תוקף תעודות ומגבלות תורים סוגרות סוג שלם של כשלים שקרו בעבר בפתאומיות. אנו עובדים על Amazon Web Services ומגדירים CloudWatch כך שיהיה מקור האמת למצב התשתית, ולא עוד פאנל שאף אחד לא מסתכל עליו.
איסוף מדדים ולוגים: סוכנים, זרמים ויומני גישה
ההגדרה של CloudWatch אינה מתחילה מהקונסולה, אלא ממלאי מקורות: מה בדיוק אנחנו חייבים לראות ובאיזו תדירות. מדדי מערכת (עומס, זיכרון, פעולות דיסק) מגיעים מהמופעים דרך סוכן איסוף הלוגים והמדדים — הוא גם אוסף את יומני האפליקציות ואת קובצי ביקורת הגישה.
מדדי היישום מועברים על ידי השירות עצמו: מוני בקשות, שיעור שגיאות, זמן תגובה בפעולות. אם המקור לא הוגדר מראש, בלוח המחוונים מופיעים גרפים שלפיהם אי אפשר לקבל החלטה.
השלב הבא — ניתוב. זרמי אירועים מהשירותים, יומני הגישה של מאזן העומסים וביקורת הפניות ל-API עוברים לקבוצות לוגים נפרדות: אסור לערבב אותם בקבוצה אחת, כי תקופת השמירה שלהם שונה ומעגל הקוראים שלהם שונה.
עבור כל קבוצה מגדירים מדיניות שמירה ומסננים — לפי קוד שגיאה, לפי נתיב מסוים, לפי חשבון משתמש. המסנן הופך את הזרם הגולמי למדד, והוא בדיוק מה שנכנס לכלל ההתראה.
Amazon Web Services מספקת כאן חבילה מוכנה: מדדים, לוגים וכללי התראה חיים במעגל אחד, ולכן אין צורך לבנות אוסף ומאגר נפרדים. המהנדסים שלנו מגדירים את סוכן איסוף הלוגים עם פרופילים לכל סוג עומס, כדי לא לשלם על זרמים מיותרים ולא לאבד את הנדרשים.
נושא נפרד — ביקורת גישה. יומני הפניות ל-API ולשינויים בהרשאות נכתבים בנפרד מהיישום ונשמרים לזמן ארוך יותר: זהו בסיס הראיות בעת חקירת אירוע. אנחנו מאחדים אותם לסכימה אחת עם מדדי השירותים, כדי לשחזר לפי זמן האירוע תמונה מלאה — מי, מה ומתי שינה.
השוואת גישות לארגון נראות
ישנן שלוש סכמות עבודה, והבחירה ביניהן נקבעת לא לפי טעם, אלא לפי מידת העומק הנדרשת ומהירות התגובה הנדרשת. ניטור מובנה של הענן מכסה את השכבה הבסיסית: מדדי שירותים, יומני אפליקציות, ספים והתראות — הכל בקונסולה אחת, ללא מעגל אחסון נפרד.
פלטפורמות צד שלישי לוקחות על עצמן את המתאם בין שירותים, אחסון ארוך טווח וניתוח תקלות בדיעבד. הגישה ההיברידית משאירה את האיסוף והסינון הראשוני בענן, ואת הניתוח וההתראות מוציאה החוצה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| ניטור מובנה של הענן | מעגל קטן, מדדים ספירים, נדרש התחלה מהירה ללא מערכות חדשות | מתאם חלש בין שירותים, חלון אחסון קצר כברירת מחדל, ניתוח תקלות ידני |
| פלטפורמת צד שלישי | שירותים וצוותים רבים, נדרשים מעקבים מקצה לקצה, היסטוריה ארוכה, לוח בקרה אחיד | דורשת סוכנים וגישה לרשת, נפח הנתונים גדל באופן ליניארי, נדרש מעגל תפעול עצמאי |
| סכמה היברידית | מעגל גדול עם נתונים רגישים: חומר הגלם נשאר בפנים, החוצה יוצאים אגרגטים | תצורה מורכבת יותר, נדרשת משמעת בכללי הסינון ובסכמת התגיות |
המגבלה המרכזית של הגישה המובנית אינה הנפח, אלא עלות אחסון יומני הגלם: ככל שהתקופה ארוכה יותר, כך הגידול מורגש יותר. הגישה ההיברידית מסירה מגבלה זו באמצעות סינון בכניסה — החוצה יוצא רק מה שנדרש בפועל לניתוח.
לכן בחירת הכלי מתחילה לא בהשוואת לוחות בקרה, אלא בשאלה: אילו אותות צריכים לחיות חודשים, ואילו די לשמור יממה.
ננתח את הסכמה שלכם — נחזור עם הערכה ותוכנית.
שלבי יישום ניטור ולוגים
הגדרת CloudWatch מתחילה לא מהקונסולה, אלא ממלאי מלאי: אילו שירותים כבר מספקים מדדים, היכן הלוגים נשמרים מקומית והולכים לאיבוד בעת הפעלה מחדש, אילו התראות הוגדרו "לפי הערכה" ומופעלות לשווא.
ללא שלב זה קל לקבל מאות מדדים שאף אחד לא מסתכל על אף אחד מהם — ולשלם על נפח אחסון שלא עוזר בניתוח תקלה.
-
ביקורת תשתית. אוספים מפת משאבים: מופעים, מכולות, מאזני עומסים, בסיסי נתונים, תורים. מתעדים מה כבר מנוטר, היכן לוגים נכתבים לקבצים ומסתובבים ידנית, והיכן אין לא מדדים ולא לוגים. בפלט — רשימת פערים וסדרי עדיפויות: מה סוגרים ראשון, כי בלעדיו לא נראה את התקלה.
-
תרשים נראות. מגדירים אילו מדדים ואירועים קריטיים לתהליך העסקי, ואילו הם רעש. מסכמים על ספים: מה נחשב לירידה בביצועים, מה לתקלה, למי ואיך נשלח האות. התרשים מתעד את הקשר "תסמין → מדד → התראה → פעולה", כדי שהתורן לא יתלבט מה לעשות בלילה.
-
הגדרת איסוף. מחברים סוכן על המופעים, מגדירים קבוצות לוגים, תקופות שמירה ומסננים. מביאים את המדדים למרחבי שמות אחידים, כדי שלוחות בקרה ייבנו ממקורות צפויים, ולא משמות מפוזרים.
-
בדיקת התראות. כל כלל מריצים בכוונה: מכבים שירות, שופכים שגיאות ללוג, בודקים — האם האות הופעל, האם הגיע לאדם הנכון, האם אין הפעלות שווא בעומס שגרתי. התראה שלא נבדקה — לא עובדת.
-
מסירת תיעוד. מוסרים נהלי תורנות, תיאור מדדים, הוראות לתקלות טיפוסיות והרשאות. צוות הלקוח ממשיך לנהל את המערכת בעצמו, ללא תלות בנו.
סדר זה סוגר את הסיכון העיקרי — ניטור שקיים, אבל לא עוזר. תארו את התשתית שלכם, ונחזור עם הערכה ותוכנית יישום.
מה הלקוח מקבל לידיו לאחר ההטמעה
לאחר הטמעת הניטור, לצוות נשארת לא "קבוצת סקריפטים", אלא מערכת עובדת: קונפיגורציות, תרשימים, מדיניות ונהלים שלפיהם התשתית מתוחזקת בהמשך ללא מעורבותנו. להלן — מה בדיוק מועבר ללקוח.
- קונפיגורציות ניטור — מטריקות, התראות, ספי הפעלה וכללי צבירה, המעוצבים כקוד. שינויים עוברים סקירה ומנוהלים בגרסאות, ולא נערכים ידנית בקונסולה.
- תרשימי זרימות לוגים ומטריקות — מהמקור ועד לאחסון וללוח המחוונים: אילו שירותים ואפליקציות שולחים מה, היכן נשמרים הנתונים, כמה זמן נשמרים ומתי עוברים לארכיון.
- מדיניות גישה — תפקידים והרשאות לפי עקרון המינימום ההכרחי: מי רואה לוגים, מי משנה התראות, מי רק קורא לוחות מחוונים. בנפרד — גישות לקבלנים חיצוניים ולבקרת ביקורת.
- לוחות מחוונים — פאנלים עובדים לפי שירותים וסביבות: מטריקות מרכזיות, השהיות, שגיאות, רוויה של משאבים. בנויים כך שהתורן יבין בתוך דקה את מצב המערכת.
- נהלי תגובה — מה לעשות בעת הפעלת התראה: למי ולאן מגיעה הודעה, מי מבצע הסלמה, אילו צעדי אבחון וחזרה לאחור. עם קישור לרמות קריטיות.
- תיעוד — תיאור ארכיטקטורת הניטור, הוראות להוספת שירותים והתראות חדשים, סדר רוטציית גישות ועדכון ספים.
- העברת ידע — פירוק המערכת עם הצוות שלכם: כיצד לקרוא לוחות מחוונים, כיצד להגדיר בדיקות חדשות, לאן להסתכל בעת תקרית.
כל ארטיפקט מקושר לסביבה ולשמות שלכם, ולא לתבנית מופשטת — הצוות יכול לפתח את המערכת באופן עצמאי. תארו את המשימה, ונחזור עם הערכה ותוכנית עבודה.
במה שונה ניטור מנראות ומה לבחור
ניטור עונה על השאלה "האם המערכת עובדת והאם אנחנו עומדים בספים": נאספות מטריקות — עומס, השהיה, תדירות שגיאות, מספר בקשות — והן מושוות לגבולות שהוגדרו מראש.
נראות עונה על השאלה "מדוע דווקא הבקשה הזו רצה לאט ולאן נעלם התוצאה": למטריקות מתווספים לוגים וטרייסינג של בקשות, שבאמצעותם ניתן לשחזר את המסלול של קריאה מסוימת דרך כל השירותים.
ההבדל אינו בכלים, אלא בשאלות שאתם יכולים לשאול את הנתונים: ניטור מראה שיש בעיה, נראות — היכן ומדוע היא נוצרה.
מטריקות מספיקות כאשר המערכת פשוטה: שירות אחד או שניים, עומס צפוי, כשלים משוחזרים. ברגע שמופיעים תורים, תלויות חיצוניות ושרשראות קריאות בין שירותים, המטריקה "ההשהיה גדלה" מפסיקה לעזור — לא ברור איזו חוליה אשמה. כאן נדרשים לוגים עם הקשר של הבקשה וטרייסינג שמקשר רשומות מפוזרות למסלול אחד.
קריטריון מעשי לבחירה הוא בגרות הפרקטיקות בצוות. אם אירועים מנותחים ידנית לפי לוגים וזה לוקח שעות, כדאי להתחיל ממטריקות והתראות: הן מספקות תוצאה מהירה ואינן דורשות שינוי בקוד.
כאשר קווי המתאר הבסיסיים עובדים וההתראות הפסיקו להיות רעש, מוסיפים לוגים מובנים, ולאחר מכן טרייסינג — הוא דורש מזהה בקשה מקצה לקצה ותמיכה בכל שירות.
חשוב לא להעמיד את הגישות זו מול זו: נראות נבנית מעל הניטור, ולא במקומו. מטריקות זולות באחסון וטובות להיסטוריה ארוכה ולמגמות, לוגים וטרייסינג יקרים יותר בנפח, ולכן מחזיקים אותם לתקופה מוגבלת ועם פירוט סלקטיבי.
הרצף הסביר — מטריקות והתראות, לאחר מכן לוגים בנתיבים קריטיים, ולאחר מכן טרייסינג במקומות שבהם שרשראות קריאות באמת מסבכות את איתור הסיבה.
עבור רוב המשימות מספיקה השילוב של מטריקות ולוגים, וטרייסינג מחזיר את ההשקעה במערכות מבוזרות עם מספר רב של שירותים. אנחנו מתחילים בבדיקת הנתונים הנוכחיים והאירועים: בוחנים אילו שאלות הצוות אינו יכול לסגור היום, ולפיכך קובעים מה חסר — מטריקות, לוגים או טרייסינג מקצה לקצה.
מקרה בוחן: כיצד קוצר זמן התגובה לאירועים
הלקוח הגיע עם כאב טיפוסי: שירות של עשרה קונטיינרים ב-AWS, לוגים מפוזרים בין אינסטנסים, התראות מגיעות מהמשתמשים לפני שהן מגיעות מהמערכת. אירועים נותחו בדיעבד — לפי צילומי מסך וקטעי לוגים, זמן התגובה הממוצע לתקלה הגיע עד לכמה שעות, והשבתה שולמה בתדמית ובהזמנות שהוחמצו.
אנחנו ריכזנו את הנראות למעגל אחיד על בסיס Amazon CloudWatch: מדדי אפליקציות ותשתית, לוגים מרוכזים דרך סוכן, דאשבורדים לפי תהליכים עסקיים מרכזיים והתראות עם הסלמה. לפני ההטמעה לצוות לא הייתה תמונה אחידה — כעת המהנדס רואה את הסיבה הראשונית בתוך דקות, במקום לאסוף אותה בחתיכות.
מה השתנה לאחר ההטמעה
| מדד | לפני | אחרי |
|---|---|---|
| זמן גילוי ממוצע של תקלה | שעות | יחידות דקות |
| זמן איתור הסיבה | איסוף לוגים ידני | מעבר מהתראה לדאשבורד המתאים |
| שיעור האירועים עם התראה אוטומטית | פחות ממחצית | כמעט כולם |
| השבתה בשירותים קריטיים | בלתי נשלטת | מוגבלת לחלון תגובה |
האפקט המרכזי — לא מהירות ההתראה עצמה, אלא העובדה שהאירוע הפסיק להיות הפתעה. מדדי סף וכללים לחריגות תופסים את ההידרדרות לפני שהמשתמש מבחין בה, ויומן אחיד מספק הקשר בלי לעבור בין כלים. תקלות חוזרות מנותחות לפי היסטוריה מצטברת, ולא מאפס.
התוצאה המעשית עבור הלקוח: צמצום השבתות הודות לגילוי מוקדם, זמן תגובה צפוי וניתוח אירועים לפי עובדות, ולא לפי השערות. מעגל כזה מתרחב יחד עם העומס — שירותים חדשים מתחברים לאותם כללים ודאשבורדים.
ספקות טכניים נפוצים בעת הגדרת CloudWatch
ניטור הוא תחום שבו ספקות לעיתים רחוקות מופשטים: המהנדס כבר ראה כיצד לוגים דולפים החוצה, כיצד עלות האחסון גדלה מהר יותר מהעומס, או כיצד מדדים אינם מתיישבים עם מה שמציג ה-APM. להלן ניתוח של ארבע התנגדויות שעולות לרוב לפני תחילת העבודה.
לוגים ומדדים יוצאים מחוץ להיקף — האם זה בטוח?
הנתונים נשארים בחשבון שלכם ובאזור שלכם — אנחנו לא מייצאים אותם לפלטפורמות חיצוניות. את הגישה אנחנו מפרידים באמצעות תפקידים: אפליקציות כותבות רק לקבוצות הלוגים שלהן, מהנדסים קוראים דרך פרופילים נפרדים, והרשאות לשינוי מדיניות שמירה — בידי מעגל מצומצם.
שדות רגישים אנחנו מסווים בכניסה, לפני הכתיבה לאחסון, ולא בדיעבד. בנפרד אנחנו מגדירים יומן גישה ללוגים עצמם — כך נראה מי ומתי קרא את הנתונים.
נפח הלוגים יגדל ויהפוך לבלתי נשלט?
את גידול הנפח אנחנו מביאים בחשבון מראש: מדיניות שמירה לפי קבוצות (נתונים חמים — תקופה קצרה, ארכיון — תקופה ארוכה), מסננים בכניסה חוסמים רעש מהודעות דיבאג, ומדדים אנחנו בונים מהלוגים במקום לשמור את כל חומר הגלם.
זה מפחית את נפח האחסון פי כמה ללא אובדן יכולת הניטור — בעת חקירת תקלה נדרשים אגרגטים והקשר, ולא גיגה-בייטים של שורות זהות.
איך זה משתלב עם מה שכבר יש לנו?
אנחנו לא שוברים את המערך הקיים: מדדים ולוגים נאספים מהשירותים הקיימים, התראות נשלחות לערוצים הרגילים של הצוות, ולוחות בקרה נבנים לפי תרחישי התורנות שלכם.
אם חלק מהניטור כבר מכוסה על ידי כלים אחרים — אנחנו משאירים אותם, ומשתמשים ב-CloudWatch במקומות שבהם הוא נותן את החיבור «מדד → לוג → התראה» בלי להדביק שלוש מערכות ידנית.
אחסון לוגים — האם החשבון לא יגדל בלי לשים לב?
את העלות אנחנו שומרים בשליטה באמצעות כללי מחזור חיים: נתונים ישנים עוברים אוטומטית למחלקת אחסון זולה או נמחקים, במקום להצטבר בשכבה החמה. בהתחלה אנחנו מחשבים את הנפח הצפוי לפי התעבורה הנוכחית, ומגדירים התראה בסטייה מהתחזית — כך הגידול נראה מראש, ולא בסוף החודש לפי החשבון.
אם נותרו שאלות לגבי המערכות שלכם — בנוגע להרשאות, נפחים או השתלבות עם הניטור הנוכחי — תארו את המשימה, ונחזור עם הערכה ותוכנית.
בואו נדון במשימת הניטור והלוגים שלכם
כדי לחזור עם הערכה ותוכנית להגדרת CloudWatch, אנחנו צריכים להבין את התמונה הנוכחית שלכם: אילו שירותים כבר מספקים מדדים ולוגים, היכן נמצאים כיום צווארי הבקבוק — התראות רועשות, אירועים שהוחמצו או עלויות גדלות לאחסון לוגים.
ככל שהנתונים הראשוניים מדויקים יותר, כך התוכנית מדויקת יותר: אנחנו לא מנחשים לפי תיאור "רוצים ניטור AWS", אלא מחשבים נפחים, ריטנשן ועלות אחסון לפי הנתונים שלכם.
מה לשלוח לניתוח ראשוני:
- רשימת השירותים והחשבונות ב-AWS שצריכים להיות מכוסים בניטור ובלוגים;
- דשבורדים, התראות וכללי ריטנשן קיימים, אם הם כבר מוגדרים;
- דוגמאות לאירועים שהמערכת לא תפסה או, להפך, הציפה בהתראות שווא;
- נפחי לוגים ביום לפי שירותים מרכזיים ותקופות האחסון שלהם לפי דרישות;
- כיצד בנויה הגישה: תפקידים, קשרים בין חשבונות, מי ומאיפה מקבל התראות;
- סדרי עדיפויות — מה קריטי לסגור ראשון ומה אפשר להעביר לגל שני.
לפי הנתונים האלה נחזור עם הערכה ותוכנית: אילו מדדים וקבוצות לוגים מחברים, כיצד מגדירים התראות וניתוב שלהן, איזה ריטנשן קובעים וכיצד זה ישפיע על האחסון. תארו את המשימה — נדון בפרטים ונציע אפשרות עבודה להגדרת CloudWatch עבור התשתית שלכם.