אם אתם יוצרים שירותים בהתאמה אישית, אתם צריכים גם ליצור יעדים ברמת השירות (SLO) עבורם. אין יעדי SLO מוגדרים מראש לשירותים מותאמים אישית.
אפשר גם ליצור יעדי SLO בהתאמה אישית לשירותים שמזוהים באופן אוטומטי, אבל זה פחות נפוץ.
הסכמי רמת שירות (SLO) מבוססים על מדדים למדידת ביצועים, ומשמשים כאינדיקטורים לרמת השירות (SLI). כדי להגדיר יעדי SLO מותאמים אישית, צריך לציין את המדדים שרוצים להשתמש בהם במדדי ה-SLI.
אם אתם לא יוצרים יעדי SLO בהתאמה אישית, אתם יכולים לדלג על הדף הזה.
מאפיינים של סוגי מדדים מתאימים
יש שני סוגים של יעדי רמת שירות (SLO) שאפשר ליצור לשירותים:
- הסכמי רמת שירות (SLO) מבוססי-בקשות.
- הסכמי רמת שירות (SLO) מבוססי-Windows.
ה-SLO מבוסס על סוגי המדדים שבוחרים כ-SLI. הערכים ב-metrics
types מסווגים לפי הקשר ביניהם. הסיווג הזה נקרא סוג המדד, ויש לו שלושה ערכים אפשריים: GAUGE, DELTA, ו-CUMULATIVE. מידע נוסף זמין במאמר MetricKind.
ב-SLO שמבוסס על בקשות, ה-SLI מייצג את היחס בין בקשות תקינות לבין סך הבקשות. סוג המדד של ה-SLI חייב להיות DELTA או CUMULATIVE. אי אפשר להשתמש במדדים GAUGE ב-SLI מבוססי-בקשות.
עבור SLOs מבוססי-חלונות, ה-SLI מייצג ספירה של תוצאות טובות בתקופה נתונה. סוגי המדדים הקבילים תלויים במבנה של מדדי רמת השירות. עם זאת, אם משתמשים ב-SLI מבוסס-בקשות, סוג המדד של ה-SLI צריך להיות DELTA או CUMULATIVE. אי אפשר להשתמש במדדים GAUGE ב-SLI מבוססי-בקשות.
מידע נוסף זמין במאמר בנושא מבנים של SLI מבוססי-Windows.
מידע נוסף על הסוגים של יעדי SLO זמין במאמר מושגים בניטור שירותים.
אתם יכולים להשתמש בסוגי מדדים שסופקו על ידי Cloud Monitoring, או להשתמש בסוגי מדדים מותאמים אישית שיצרתם. בשני המקרים, הערכים מתאימים ל-SLI שרוצים ליצור.
סוגי מדדים לא מתאימים
כשבוחרים סוג מדד לשימוש כמדד SLI, כדאי להימנע מסוגי מדדים בעלי עוצמה גבוהה. העוצמה (cardinality) מתארת את מספר סדרות הזמן האפשריות שאפשר לשייך לסוג המדד, והיא קשורה לגרנולריות של הערכים שתוויות המדדים יכולות לקבל. במאמר עוצמה (cardinality): סדרות זמנים ותוויות מפורטות דוגמאות לשימוש בעוצמה.
לסוגי מדדים עם תוויות שמקבלות ערכים כמו חותמות זמן יש כנראה עוצמה גבוהה מאוד, ולכן הם לא מתאימים לשימוש בתור SLI. מדדים בעלי עוצמה גבוהה הם לרוב מדדים שהוגדרו על ידי המשתמשים ולא תוכננו כך שלא יגרמו לבעיות שקשורות לעוצמה. הם יכולים לכלול מדדים מבוססי-יומן שהוגדרו על ידי המשתמש ומדדים מותאמים אישית.
איך מוצאים סוגי מדדים מתאימים
אפשר למצוא מידע על סוגי מדדים, כולל סוג המדד, בכמה מקומות:
בבורר המדדים שמשמש בכלים כמו Metrics Explorer מוצג כרטיס צף עבור סוג המדד שמודגש. הכלי הזה פועל עם מדדים מותאמים אישית ומדדים מובנים.
לדוגמה, בצילום המסך הבא מוצג כרטיס המידע של סוג המדד
loadbalancing.googleapis.com/https/request_countכפי שהוא מופיע ב-Metrics Explorer:
ב-Metrics Explorer אפשר גם להגדיר את המדד כך שידמה את הפעולה של SLO API, ולקבל ייצוג JSON של ההגדרה הזו. קובץ ה-JSON הזה שימושי ליצירת SLI באופן ידני.
בדפים ברשימת המדדים יש טבלאות לכל שירות, עם פירוט של סוגי המדדים שמשויכים לשירותים. הטבלאות האלה כוללות את כל סוגי המדדים המובנים, אבל לא מוצגים בהן סוגים של מדדים בהתאמה אישית.
לדוגמה, בצילום המסך הבא מוצגת הרשומה של סוג המדד
loadbalancing.googleapis.com/https/request_countכפי שהיא מופיעה ברשימת מדדי איזון העומסים. הערכים האלה לרוב מספקים פרטים נוספים בהשוואה לכרטיסים הצפים ב-Metrics Explorer.
יצירת ה-SLI
כשעוקבים אחרי שירותים, נתוני המדדים מעובדים בדרכים ספציפיות שאפשר לשכפל ב-Metrics Explorer. בדף הזה מניחים שאתם יודעים להשתמש ב-Metrics Explorer. מידע נוסף זמין במאמר בנושא Metrics Explorer.
כדי ליצור מדד SLI מבוסס-בקשות על סמך יחס של סדרת נתונים לפי זמן, צריך שתי סדרות נתונים לפי זמן: אחת שמייצגת את כל הבקשות, ואחת שמייצגת בקשות טובות (או רעות). ל-SLI מהסוג הזה יש את המבנה הבא:
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter": TO_BE_IDENTIFIED,
"goodServiceFilter": TO_BE_IDENTIFIED,
}
}
כדי לקבל את הערך של השדה goodServiceFilter:
בוחרים את סוג המשאב המנוטר ואת סוג המדד. חשוב לזכור שסוג המדד חייב להיות
DELTAאוCUMULATIVE. התוצאה עשויה לכלול הרבה סדרות זמן שונות.לדוגמה, בוחרים את סוג המשאב
http_lb_ruleואת סוג המדדloadbalancing.googleapis.com/https/request_count.משתמשים בשדה Filter כדי להגדיר את התווית
response_code_classלערך200. המסנן הזה מסיר כל סדרת זמן עם ערכים אחרים לתווית הזו. יכול להיות שעדיין יהיו כמה סדרות עיתיות שתואמות.בוחרים את האגרגטור
sumכדי ליצור סדרת זמן אחת. בתרשים בדף Metrics Explorer מוצגת סדרת הזמנים שמתקבלת.לוחצים על אפשרויות נוספות more_vert מעל התרשים ובוחרים באפשרות הצגה כ-JSON בתפריט.
קובץ ה-JSON שמאוחזר נראה בערך כך:
"dataSets": [ { "timeSeriesFilter": { "filter": "metric.type="loadbalancing.googleapis.com/https/request_count" resource.type="http_lb_rule" metric.label."response_code_class"="200"" "perSeriesAligner": "ALIGN_RATE", "crossSeriesReducer": "REDUCE_SUM", "secondaryCrossSeriesReducer": "REDUCE_NONE", "minAlignmentPeriod": "60s", "groupByFields": [], "unitOverride": "1" }, "targetAxis": "Y1", "plotType": "LINE" } ],
החלק שמעניין אתכם הוא הערך של השדה filter שמוטמע באובייקט dataSets:
"filter": "metric.type="loadbalancing.googleapis.com/https/request_count" resource.type="http_lb_rule" metric.label."response_code_class"="200""
כדי ליצור את מבנה ה-SLI:
מזינים את הערך הזה במבנה של ה-SLI כערך של השדה
goodServiceFilter.צריך גם להוסיף את הערך הזה למבנה של ה-SLI כערך של
totalServiceFilter, אבל אחר כך להסיר את החלק של התווית במסנן,metric.label.\"response_code_class\"=\"200\".
מדד רמת השירות שמתקבל:
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter": "metric.type="loadbalancing.googleapis.com/https/request_count" resource.type="http_lb_rule"",
"goodServiceFilter": "metric.type="loadbalancing.googleapis.com/https/request_count" resource.type="http_lb_rule" metric.label."response_code_class"="200"",
}
}
אחר כך אפשר להוסיף את מדד ה-SLI הזה ל-SLO, למשל:
{
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter": "metric.type="loadbalancing.googleapis.com/https/request_count" resource.type="http_lb_rule"",
"goodServiceFilter": "metric.type="loadbalancing.googleapis.com/https/request_count" resource.type="http_lb_rule" metric.label."response_code_class"="200"",
}
}
},
"goal": 0.98,
"calendarPeriod": "WEEK",
"displayName": "98% Successful requests in a calendar week"
}
אפשר להשתמש ב-JSON הזה כדי ליצור SLO, כמו שמתואר במאמר יצירת SLO.