מושגים בניטור שירותים

המעקב אחר השירותים וממשק ה-API של SLO עוזרים לכם לנהל את השירותים שלכם כמו ש-Google מנהלת את השירותים שלה. המושגים העיקריים של ניטור שירותים כוללים את הדברים הבאים:

• בחירת מדדים שמשמשים כמדדי רמת שירות (SLI).
• שימוש ב-SLI להגדרת יעדים למדידת רמת השירות (SLO) עבור ערכי ה-SLI.
• שימוש בתקציב השגיאות שמשתמע מ-SLO כדי לצמצם את הסיכון בשירות.

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

הסברים על המונחים

יש כמה מושגי ליבה שקשורים למעקב אחרי שירותים, והם מוסברים כאן:

• מדד רמת שירות (SLI): מדד של ביצועים.
• יעד למדידת רמת השירות (SLO): הצהרה על הביצועים הרצויים.
• תקציב השגיאות: מתחיל ב-1 – SLO ויורד כשהביצועים בפועל לא עומדים ב-SLO.

מדדים לרמת השירות (SLI)

‫Cloud Monitoring אוסף מדדים שמודדים את הביצועים של תשתית השירות. דוגמאות למדדי ביצועים:

• מספר הבקשות: לדוגמה, מספר בקשות ה-HTTP לדקה שמניבות תגובות 2xx או 5xx.
• זמני האחזור של התגובות: לדוגמה, זמן האחזור של תגובות HTTP 2xx.

מדדי הביצועים מזוהים באופן אוטומטי על סמך קבוצה של סוגי שירותים מוכרים: Cloud Service Mesh,‏ Istio ב-Google Kubernetes Engine ו-App Engine. אפשר גם להגדיר סוג שירות משלכם ולבחור מדדי ביצועים עבורו.

מדדי הביצועים הם הבסיס של מדדי רמת השירות (SLI) של השירות שלכם. מחוון SLI מתאר את הביצועים של היבט מסוים בשירות שלכם. לשירותים ב-Cloud Service Mesh,‏ Istio ב-Google Kubernetes Engine ו-App Engine, כבר ידועים מדדי SLI שימושיים. לדוגמה, אם בשירות שלכם יש מדדים של מספר הבקשות או של זמן האחזור של התגובות, אפשר לגזור מהמדדים האלה אינדיקטורים סטנדרטיים לרמת השירות (SLI) על ידי יצירת יחסים באופן הבא:

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

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

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

פירוט נוסף על מדדי ה-SLI האלה מופיע במאמר תאימות ל-SLO מבוסס-בקשות וחלונות.

דוגמאות ליצירת SLI לשירותים נבחרים מופיעות במאמר יצירת SLI מתוך מדדים.

יעדים למדידת רמת השירות (SLO)

יעד רמת השירות (SLO) הוא ערך יעד של מדד רמת השירות (SLI), שנמדד לאורך תקופה. השירות קובע את מדדי ה-SLI הזמינים, ואתם מציינים את מדדי ה-SLO על סמך מדדי ה-SLI. ה-SLO מגדיר מה נחשב לשירות טוב. אפשר ליצור עד 500 יעדי SLO לכל שירות ב-Cloud Monitoring.

ה-SLO מבוסס על סוגי המידע הבאים:

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

לדוגמה, יכול להיות שיהיו לכם דרישות כאלה:

• זמן האחזור יכול לחרוג מ-300 אלפיות השנייה רק ב-5% מהבקשות במהלך תקופה מתגלגלת של 30 יום.
• זמינות המערכת צריכה להיות 99% לפחות, שנמדדת במהלך שבוע קלנדרי.

דרישות כאלה יכולות לשמש כבסיס ל-SLO. במאמר תכנון של SLO ושימוש בו מוסבר איך להגדיר SLO טוב.

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

יעד SLO שימושי הוא פחות מ-100%, כי ה-SLO קובע את תקציב השגיאות שלכם. בדרך כלל מתארים את יעדי ה-SLO כמספר של 'תשעיות': 99% (שתי תשעיות), 99.9% (שלוש תשעיות) וכן הלאה. הערך הכי גבוה שאפשר להגדיר הוא 99.9%, אבל אפשר להשתמש בכל ערך נמוך יותר שמתאים לשירות שלכם.

תקציבי שגיאות

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

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

תקציב השגיאות לתקופת התאימות הוא (1 − יעד ה-SLO) × (אירועים שעומדים בדרישות בתקופת התאימות). לדוגמה, אם ה-SLO שלכם הוא ש-85% מהבקשות יהיו טובות במהלך תקופה של 7 ימים, תקציב השגיאות מאפשר ש-15% מהבקשות האלה יהיו רעות. אם קיבלתם, למשל, 60,480 בקשות בשבוע האחרון, תקציב השגיאות שלכם הוא 15% מהסכום הכולל הזה, כלומר 9,072 בקשות שניתן להגדיר כבקשות שגויות. אם הופיעו יותר שגיאות מהמספר הזה, השירות לא עמד בדרישות ה-SLO במהלך תקופת התאימות של 7 ימים.

עיצוב של SLO ושימוש בו

מה הופך יעד SLO לטוב? מה כדאי לקחת בחשבון כשבוחרים את האפשרויות? בקטע הזה מובאת סקירה כללית של כמה מהמושגים הכלליים שקשורים לתכנון ולשימוש ביעדי SLO. הנושא הזה מוסבר בפירוט רב יותר בSite Reliability Engineering: How Google Runs Production Systems, בפרק על SLO.

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

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

תקופות תאימות

יש שני סוגים של תקופות תאימות ל-SLO:

• תקופות שמבוססות על היומן (מתאריך מסוים עד תאריך מסוים)
• תקופות מתגלגלות (מ-n ימים לפני היום ועד היום, כאשר n הוא מספר בין 1 ל-30)

תקופות תאימות שמבוססות על היומן

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

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

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

תקופות תאימות מבוססות חלון נע

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

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

עמידה בדרישות ב-SLO מבוססי-בקשות וב-SLO מבוססי-חלונות

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

• איך נקבעת תקופת התאימות. ההחלטה הזו מוסברת במאמר בנושא תקופות תאימות.
• סוג ה-SLO. יש שני סוגים של SLO:
  • הסכמי רמת שירות (SLO) מבוססי-בקשות
  • יעדי זמינות (SLO) מבוססי-Windows

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

אם יעד ה-SLO שלכם הוא 99.9%, אתם עומדים בו אם רמת התאימות שלכם היא לפחות 99.9%. הערך המקסימלי הוא 100%.

הסכמי רמת שירות (SLO) מבוססי-בקשות

יעד SLO מבוסס-בקשות מבוסס על SLI שמוגדר כיחס בין מספר הבקשות הטובות לבין המספר הכולל של הבקשות. היעד של הסכם רמת שירות (SLO) מבוסס-בקשות מושג כשהיחס הזה שווה ליעד או גבוה ממנו בתקופת התאימות.

לדוגמה, נניח שיש לנו SLO שמבוסס על בקשות: 'החביון נמוך מ-100 אלפיות השנייה לפחות ב-95% מהבקשות'. בקשה טובה היא בקשה עם זמן תגובה של פחות מ-100 אלפיות השנייה, ולכן מדד התאימות הוא החלק של הבקשות עם זמני תגובה של פחות מ-100 אלפיות השנייה. השירות עומד בדרישות אם החלק הזה הוא לפחות 0.95.

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

יעדי זמינות (SLO) מבוססי-Windows

יעד רמת שירות (SLO) שמבוסס על חלון זמן מבוסס על מדד רמת שירות (SLI) שמוגדר כיחס בין מספר מרווחי המדידה שעומדים בקריטריון מסוים של איכות לבין המספר הכולל של המרווחים. היעד של SLO מבוסס-חלון מושג אם היחס הזה מגיע ליעד או עולה עליו במהלך תקופת התאימות.

לדוגמה, נניח שיש לנו יעד SLO כזה: "מדד זמן האחזור באחוזון ה-95 נמוך מ-100 אלפיות השנייה לפחות ב-99% מהחלונות של 10 דקות". תקופה טובה למדידה היא פרק זמן של 10 דקות שבו זמן האחזור של 95% מהבקשות נמוך מ-100 אלפיות השנייה. מדד התאימות הוא החלק היחסי של תקופות טובות כאלה. השירות עומד בדרישות אם השבר הזה הוא לפחות 0.99.

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

דוגמה נוספת: נניח שהגדרתם את תקופת התאימות ל-30 ימים, את מרווח המדידה לדקה ואת יעד ה-SLO ל-99%. כדי לעמוד ב-SLO הזה, בשירות שלכם צריכים להיות 42,768 מרווחי זמן 'טובים' מתוך 43,200 דקות (99% ממספר הדקות ב-30 ימים).

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

המסלול של תקציבי השגיאות

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

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

יש כמה חריגים בולטים לדפוס הזה:

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

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

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

• אם אתם מודדים את ה-SLO במהלך תקופת תאימות מתמשכת, אתם תמיד בסוף תקופת התאימות. במקום להתחיל מאפס, נקודות נתונים ישנות מוסרות באופן רציף ונקודות נתונים חדשות מתווספות באופן רציף.

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

מעקב אחר תקציב השגיאות

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

המאמרים הבאים

• במאמר מיקרו-שירותים מוסבר מהם מיקרו-שירותים ואיך משתמשים במסוף Google Cloud כדי להגדיר, לראות ולנהל את המיקרו-שירותים.
• במאמר התראות על קצב שריפת המזומנים מוסבר איך לעקוב אחרי מדדי רמת השירות (SLI) כדי לקבל התראות על בעיות אפשריות.
• במאמר עבודה עם SLO API מוסבר איך להשתמש ב-SLO API, שהוא קבוצת משנה של Cloud Monitoring API, כדי ליצור שירותים, יעדי SLO ומבנים קשורים.