מבנים ב-API

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

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

השירות Service Monitoring מוסיף את המשאבים הבאים ל-Monitoring API:

מידע על הפעלת ה-API זמין במאמר עבודה עם ה-API.

שירותים

שירות מיוצג על ידי אובייקט Service. האובייקט הזה כולל את השדות הבאים:

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

כדי להגדיר שירות בסיסי, מציינים את סוג השירות ומספקים קבוצה של תוויות ספציפיות לשירות שמתארות את השירות:

{
   "serviceType": string,
   "serviceLabels": {
      string: string,
      ...
   }
}

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

סוגים בסיסיים של שירותים

בקטע הזה מופיעות דוגמאות להגדרות של שירותים שמבוססות על הסוג BasicService, שבו הערך של השדה serviceType הוא אחד מהערכים הבאים:

  • APP_ENGINE
  • CLOUD_ENDPOINTS
  • CLUSTER_ISTIO
  • ISTIO_CANONICAL_SERVICE
  • CLOUD_RUN

בכל אחד מסוגי השירותים האלה נעשה שימוש במדד רמת השירות BasicSli.

App Engine 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "APP_ENGINE",
          "serviceLabels": {
            "module_id": "MODULE_ID"
          },
      },
    }

Cloud Endpoints 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "CLOUD_ENDPOINTS",
          "serviceLabels": {
            "service": "SERVICE"
          },
      },
    }

‫Cluster Istio 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "CLUSTER_ISTIO",
          "serviceLabels": {
            "location": "LOCATION",
            "cluster_name": "CLUSTER_NAME",
            "service_namespace": "SERVICE_NAMESPACE",
            "service_name": "SERVICE_NAME"
          },
      },
    }

שירות רשמי (קנוני) של Istio 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "ISTIO_CANONICAL_SERVICE",
          "serviceLabels": {
            "mesh_uid": "MESH_UID",
            "canonical_service_namespace": "CANONICAL_SERVICE_NAMESPACE",
            "canonical_service": "CANONICAL_SERVICE"
          },
      },
    }

Cloud Run 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "CLOUD_RUN",
          "serviceLabels": {
            "service_name": "SERVICE_NAME",
            "location": "LOCATION"
          },
      },
    }

סוגים בסיסיים של שירותים ב-GKE

בקטע הזה יש דוגמאות להגדרות של שירות GKE שמבוססות על הסוג BasicService, שבהן הערך של השדה serviceType הוא אחד מהערכים הבאים:

  • GKE_NAMESPACE
  • GKE_WORKLOAD
  • GKE_SERVICE

צריך להגדיר מדדי SLI לסוגי השירותים האלה. הם לא יכולים להשתמש במדדי רמת השירות של BasicSli. מידע נוסף מופיע במאמר בנושא אינדיקטורים לרמת השירות.

מרחב שמות של GKE 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "GKE_NAMESPACE",
          "serviceLabels": {
            "project_id": "PROJECT_ID",
            "location": "LOCATION",
            "cluster_name": "CLUSTER_NAME",
            "namespace_name": "NAMESPACE_NAME"
          }
      },
    }

עומס עבודה (workload) של GKE 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "GKE_WORKLOAD",
          "serviceLabels": {
            "project_id": "PROJECT_ID",
            "location": "LOCATION",
            "cluster_name": "CLUSTER_NAME",
            "namespace_name": "NAMESPACE_NAME",
            "top_level_controller_type": "TOPLEVEL_CONTROLLER_TYPE",
            "top_level_controller_name": "TOPLEVEL_CONTROLLER_NAME",
          }
      },
    }

שירות GKE 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "GKE_SERVICE",
          "serviceLabels": {
            "project_id": "PROJECT_ID",
            "location": "LOCATION",
            "cluster_name": "CLUSTER_NAME",
            "namespace_name": "NAMESPACE_NAME",
            "service_name": "SERVICE_NAME"
          }
      },
    }

שירותים בהתאמה אישית

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

    {
      "displayName": "DISPLAY_NAME",
      "custom": {}
    }

צריך להגדיר מדדי SLI לסוגי השירותים האלה. הם לא יכולים להשתמש במדדי רמת השירות של BasicSli. מידע נוסף מופיע במאמר בנושא אינדיקטורים לרמת השירות.

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

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

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

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

  • ‫SLI מבוסס-בקשות, שאפשר להשתמש בו כדי לספור אירועים שמייצגים שירות מקובל. השימוש בסוג הזה של SLI מתואר במאמר יעדי זמינות (SLO) שמבוססים על בקשות. הוא מיוצג על ידי אובייקט RequestBasedSli.

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

לדוגמה, כך נראה SLI בסיסי של זמינות: 

{
  "basicSli": {
    "availability": {},
    "location": [
      "us-central1-c"
    ]
  }
}

מבנים של מדדי SLI מבוססי-בקשות

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

יש שתי דרכים ליצור SLI מבוסס-בקשות:

  • בתור TimeSeriesRatio, כשמחשבים את היחס בין שירות טוב לבין שירות כולל מתוך שתי סדרות זמן שהערכים שלהן הם מסוג מדד DELTA או CUMULATIVE.
  • כ-DistributionCut, אם לסדרת הזמן יש סוג ערך DISTRIBUTION והערכים שלה הם מסוג מדד DELTA או CUMULATIVE. הערך של שירות טוב הוא מספר הפריטים שנכללים בדליים של ההיסטוגרמה בטווח שצוין, והערך הכולל הוא מספר כל הערכים בהתפלגות.

בדוגמה הבאה מוצג ייצוג JSON של SLI שמשתמש ביחס של סדרת זמן: 

{
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter": "resource.type=https_lb_rule metric.type="loadbalancing.googleapis.com/https/request_count"",
      "goodServiceFilter": "resource.type=https_lb_rule metric.type="loadbalancing.googleapis.com/https/request_count" metric.label.response_code_class=200",
    }
  }
}

סדרת הזמנים ביחס הזה מזוהה על ידי הצמד של סוג המשאב שבמעקב וסוג המדד:

  • משאב: https_lb_rule
  • סוג המדד: loadbalancing.googleapis.com/https/request_count

הערך של totalServiceFilter מיוצג על ידי צמד של מדד וסוג משאב. הערך של goodServiceFilter מיוצג על ידי אותו צמד, אבל במקרה הזה, כשתווית מסוימת מקבלת ערך מסוים. כלומר, כשערך התווית response_code_class הוא 200.

היחס בין המסננים מודד את מספר הבקשות שמחזירות סטטוס HTTP‏ 2xx חלקי המספר הכולל של הבקשות.

הדוגמה הבאה מציגה את ייצוג ה-JSON של SLI שמשתמש ב-cut של חלוקה: 

{
  "requestBased": {
    "distribution_cut": {
      "distribution_filter": "resource.type=https_lb_rule  metric.type="loadbalancing.googleapis.com/https/backend_latencies" metric.label.response_code_class=200",
      "range": {
        "min": "-Infinity",
        "max": 500.0
      }
    }
  }
}

סדרת הזמנים מזוהה לפי סוג המשאב במעקב, סוג המדד והערך של תווית המדד:

  • משאב: https_lb_rule
  • סוג המדד: loadbalancing.googleapis.com/https/backend_latencies
  • צמד של תווית-ערך: response_code_class = 200

הטווח של זמני האחזור שנחשבים טובים מצוין בשדה range. ה-SLI הזה מחשב את היחס בין זמן האחזור של תגובות מסוג 2xx מתחת ל-500 לבין זמן האחזור של כל התגובות מסוג 200.

מבנים של SLI מבוסס Windows

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

כל ה-SLI שמבוססים על חלונות כוללים תקופת חלון של 60 עד 86,400 שניות (יום אחד).

יש שתי דרכים לציין את קריטריון השירות הטוב עבור SLI מבוסס-Windows:

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

  • צריך ליצור אובייקט PerformanceThreshold שמייצג סף לביצועים קבילים. האובייקט הזה מצוין כערך של goodTotalRatioThreshold.

    אובייקט PerformanceThreshold מציין ערך סף ו-SLI של ביצועים. אם הערך של מדד הביצועים SLI עומד בסף או עולה עליו, חלון הזמן נחשב לטוב.

    יש שתי דרכים לציין את ה-SLI של הביצועים:

    • כאובייקט BasicSli בשדה basicPerformanceSli.
    • כאובייקט RequestBasedSli בשדה performance. אם אתם משתמשים ב-SLI מבוסס-בקשה, סוג המדד של ה-SLI צריך להיות DELTA או CUMULATIVE. אי אפשר להשתמש במדדים GAUGE ב-SLI מבוססי-בקשות.

הדוגמה הבאה מציגה ייצוג JSON של SLI מבוסס-חלונות שנבנה על סמך סף ביצועים עבור SLI בסיסי של זמינות:

{
  "windowsBased": {
     "goodTotalRatioThreshold": {
       "threshold": 0.9,
       "basicSliPerformance": {
         "availability": {},
         "location": [
           "us-central1-c"
         ]
       }
     },
     "windowPeriod": "300s"
   }
}

ה-SLI הזה מגדיר ביצועים טובים כחלון של 5 דקות שבו הזמינות מגיעה ל-90% או יותר. המבנה של SLI בסיסי מוצג במאמר אינדיקטורים לרמת שירות.

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

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

יעד למדידת רמת השירות (SLO) מיוצג על ידי אובייקט ServiceLevelObjective. האובייקט הזה כולל את השדות הבאים:

הדוגמה הבאה מציגה ייצוג JSON של יעד רמת שירות (SLO) שמשתמש במדד בסיסי של זמינות (SLI) כערך של השדה serviceLevelIndicator: 

{
   "name": "projects/PROJECT_NUMBER/services/PROJECT_ID-zone-us-central1-c-csm-main-default-currencyservice/serviceLevelObjectives/3kavNVTtTMuzL7KcXAxqCQ",
   "serviceLevelIndicator": {
     "basicSli": {
       "availability": {},
       "location": [
         "us-central1-c"
       ]
     }
   },
   "goal": 0.98,
   "calendarPeriod": "WEEK",
   "displayName": "98% Availability in Calendar Week"
}

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