Konstrukte in der API

Die Service Monitoring API wird verwendet, um SLO-Ziele festzulegen, die zur Überwachung der Integrität Ihrer Dienste verwendet werden können.

Service Monitoring fügt der Monitoring API die folgenden Ressourcen hinzu:

Auf dieser Seite werden die Strukturen zur Darstellung von Diensten und SLOs in der Service Monitoring API vorgestellt und den Konzepten zugeordnet, die unter Konzepte im Service Monitoring allgemein beschrieben werden.

Informationen zum Aufrufen der API finden Sie unter Arbeiten mit der API.

Dienste

Ein Dienst wird durch ein Service-Objekt dargestellt. Dieses Objekt enthält die folgenden Felder:

  • Einen Namen: ein vollständig qualifizierter Ressourcenname für diesen Dienst
  • Ein Anzeigename: Ein Label zur Verwendung in Konsolenkomponenten
  • Ein Telemetrie-Konfigurationsobjekt
  • Einen Indikator für den Diensttyp:
    • Ein App Engine-Dienst
    • Ein Cloud Endpoints-Dienst
    • Ein Istio im Google Kubernetes Engine-Dienst
    • Einen benutzerdefinierten Dienst

Der einzige Diensttyp, den Sie manuell erstellen, ist der benutzerdefinierte Dienst. Die anderen Typen werden auf der Grundlage Ihrer Umgebung automatisch erkannt.

Im Folgenden sehen Sie beispielsweise die JSON-Darstellung eines Istio-Dienstes:

    {
      "name": "projects/[PROJECT_NUMBER]/services/[PROJECT_ID]-zone-us-central1-c-csm-main-default-currencyservice",
      "displayName": "[PROJECT_ID]/us-central1-c/csm-main/default/currencyservice",
      "clusterIstio": {
        "location": "us-central1-c",
        "clusterName": "csm-main",
        "serviceNamespace": "default",
        "serviceName": "currencyservice"
      },
      "telemetry": {
        "resourceName": "//container.googleapis.com/projects/[PROJECT_ID]/zones/us-central1-c/clusters/csm-main/k8s/namespaces/default/services/currencyservice"
      }
    }
    

Dieses Beispiel zeigt die JSON-Darstellung eines benutzerdefinierten Dienstes:

    {
      "name": "projects/[PROJECT_NUMBER]/services/-I6P_NufSzKiuvX1AYHE6Q",
      "displayName": "My Test Service",
      "custom": {},
      "telemetry": {}
    }
    

Die Telemetrie befindet sich in der Entwicklung. Der einzige sinnvolle Wert ist der vollständige Name der Ressource, die den Dienst definiert. Das Format wird unter Ressourcennamen beschrieben.

Service Level Indicators

Ein Service Level Indicator (SLI) liefert ein Maß für die Leistung eines Dienstes. Ein SLI basiert auf dem vom Dienst erfassten Messwert. Die genaue Definition des SLI hängt vom Typ des Messwerts ab, der als Indikatormesswert verwendet wird. In der Regel wird er jedoch anhand eines Vergleichs zwischen akzeptablen Ergebnissen und Gesamtergebnissen ermittelt.

Ein SLI wird durch das Objekt ServiceLevelIndicator dargestellt. Dieses Objekt bietet die Möglichkeit, die drei unterstützten Arten von SLIs zusammengefasst zu referenzieren:

  • Ein grundlegender SLI, der automatisch für einen bekannten Diensttyp erstellt wird. Dieser SLI-Typ wird unter Service Level Objectives beschrieben. Er wird durch das Objekt BasicSli dargestellt und misst die Verfügbarkeit oder Latenz.

  • Ein anfragebasierter SLI, mit dem Sie Ereignisse zählen können, die einen akzeptablen Dienst darstellen. Die Verwendung dieses SLI-Typs wird unter Anfragebasierte SLOs beschrieben und er wird durch ein Objekt RequestBasedSli dargestellt.

  • Ein Zeitfenster-SLI, mit dem Sie Zeiträume zählen können, die bestimmte Gütekriterien erfüllen. Die Verwendung dieses SLI-Typs wird unter Zeitfenster-basierte SLOs beschrieben und er wird durch ein Objekt WindowsBasedSli dargestellt.

Nachstehend sehen Sie zum Beispiel einen grundlegenden Verfügbarkeits-SLI:

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

Strukturen anfragebasierter SLIs

Einem anfragebasierten SLI liegt ein Messwert zugrunde, der Diensteinheiten als Verhältnis zwischen einem bestimmten Ergebnis und dem Gesamtwert zählt. Wenn Sie beispielsweise einen Messwert verwenden, der Anfragen zählt, können Sie das Verhältnis zwischen der Anzahl der Anfragen, die erfolgreich verarbeitet werden, und der Gesamtzahl der Anfragen ermitteln.

Es gibt zwei Möglichkeiten, einen anfragebasierten SLI zu erstellen:

  • Als TimeSeriesRatio, wenn das Verhältnis zwischen erfolgreichen Dienstvorgängen und deren Gesamtzahl aus zwei Zeitachsen berechnet wird, deren Werte die Messwertart DELTA oder CUMULATIVE haben.
  • Als DistributionCut, wenn die Zeitachse den Werttyp DISTRIBUTION hat und dessen Werte von der Messwertart DELTA oder CUMULATIVE sind. Der Wert der erfolgreichen Dienstvorgänge ist die Anzahl der Elemente, die in die Histogramm-Buckets eines bestimmten Bereichs fallen, und die Gesamtzahl ist die Anzahl aller Werte in der Verteilung.

Im Folgenden sehen Sie die JSON-Darstellung eines SLI, der auf einem Zeitachsenverhältnis beruht:

    {
      "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",
        }
      }
    }
    

Die Zeitachsen in diesem Verhältnis werden anhand des Paares aus überwachtem Ressourcentyp und Messwerttyp ermittelt:

  • Ressource: https_lb_rule
  • Messwerttyp: loadbalancing.googleapis.com/https/request_count

Der Wert für totalServiceFilter wird durch das Paar aus Messwert und Ressourcentyp dargestellt. Der Wert für goodServiceFilter wird durch dasselbe Paar repräsentiert, doch hat dabei ein Label einen bestimmten Wert. In diesem Fall hat das Label response_code_class den Wert 200.

Das Verhältnis zwischen den Filtern misst die Anzahl der Anfragen, die einen HTTP-Status "2xx" zurückgeben gegenüber der Gesamtzahl der Anfragen.

Nachstehend sehen Sie die JSON-Darstellung eines SLI, der auf einem Verteilungsschnitt beruht:

    {
      "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
          }
        }
      }
    }
    

Die Zeitachse wird durch den Typ der überwachten Ressource, den Messwerttyp und den Wert eines Messwertlabels identifiziert:

  • Ressource: https_lb_rule
  • Messwerttyp: loadbalancing.googleapis.com/https/backend_latencies
  • Label-Wert-Paar: response_code_class = 200

Der Bereich der als gut bewerteten Latenzen wird durch das Feld range definiert. Dieser SLI berechnet das Verhältnis der Latenzen von Antworten der 2xx-Klasse unter 500 zu den Latenzen aller Antworten der 200er-Klasse.

Strukturen Zeitfenster-basierter SLIs

Dieser SLI zählt Zeitfenster, in denen der bereitgestellte Dienst als gut eingestuft wird. Das Kriterium zur Bestimmung, wie gut der Dienst ist, ist Teil der SLI-Definition.

Alle Windows-basierten SLIs enthalten einen Zeitraum von 60 bis 86.400 Sekunden (1 Tag).

Es gibt zwei Möglichkeiten, bei Zeitfenster-basierten SLIs das Kriterium für die Dienstgüte festzulegen:

  • Erstellen Sie einen Filterstring, wie unter [Monitoring filters][monfilters] beschrieben, der eine Zeitachse mit Booleschen Werten zurückgibt. Ein Zeitfenster wird als gut erachtet, wenn der Wert für dieses Fenster true ist. Dieser Filter wird als goodBadMetricFilter bezeichnet.
  • Erstellen Sie ein Objekt [PerformanceThreshold][sli-perthreshold-apiref], das einen Grenzwert für akzeptable Leistung darstellt. Dieses Objekt wird als Wert von goodTotalRatioThreshold angegeben.

    Ein Objekt PerformanceThreshold gibt einen Grenzwert und einen Leistungs-SLI an. Wenn der Wert des Leistungs-SLI den Grenzwert erreicht oder überschreitet, wird das Zeitfenster als gut gewertet.

    Es gibt zwei Möglichkeiten zur Angabe von Leistungs-SLI:

Im Folgenden sehen Sie die JSON-Darstellung eines Zeitfenster-basierten SLI, der auf dem Leistungsgrenzwert eines grundlegenden SLI für Verfügbarkeit beruht:

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

Dieser SLI definiert eine gute Leistung als 5-Minuten-Fenster, in dem die Verfügbarkeit 90 % oder mehr erreicht. Die Struktur eines grundlegenden SLI wird unter Service Level Indicators gezeigt.

Sie können auch ein einen anfragebasierten SLI in den Zeitfenster-basierten SLI einbetten. Weitere Informationen zu eingebetteten Strukturen finden Sie unter Strukturen anfragebasierter SLIs.

Service Level Objectives

Ein Service Level Objective (SLO) wird durch ein Objekt ServiceLevelObjective dargestellt. Dieses Objekt enthält die folgenden Felder:

  • Einen Namen
  • Einen Anzeigenamen
  • Den Ziel-SLI; ein eingebettetes Objekt ServiceLevelIndicator
  • Das Leistungsziel für den SLI
  • Den Compliancezeitraum für den SLI

Im Folgenden sehen Sie die JSON-Darstellung eines SLO, das einen grundlegenden Verfügbarkeits-SLI als Wert für das Feld serviceLevelIndicator verwendet:

    {
       "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"
    }
    

Dieses SLO legt das Leistungsziel auf 98 % Verfügbarkeit über einen Zeitraum von einer Woche fest.