[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[],[],null,["# Creating a service-level indicator\n\nIf you create custom services, then you must also create service-level\nobjectives (SLOs) for them. There are no predefined SLOs for custom\nservices.\n\nYou can also create custom SLOs for automatically detected services, but\nthat is less common.\n\nSLOs are built on top of metrics that measure performance and are used as\nservice-level indicators (SLIs). For custom SLOs, you must identify the\nmetrics you want to use in your SLIs.\n\nIf you are not creating custom SLOs, you can skip this page.\n\nCharacteristics of suitable metric types\n----------------------------------------\n\nThere are two types of SLOs you can create for your services:\n\n- Request-based SLOs.\n- Windows-based SLOs.\n\nSLOs are based on the metric types you choose as SLIs. The values in metrics\ntypes are classified by how they are related to each other. This classification\nis called the *metric kind* , and it has three possible values, `GAUGE`,\n`DELTA,` and `CUMULATIVE`. For more information, see\n[`MetricKind`](/monitoring/api/ref_v3/rest/v3/projects.metricDescriptors#MetricKind).\n\nFor request-based SLOs, your SLI represents a ratio of good requests\nto total requests. The metric kind of your SLI must be\n`DELTA` or `CUMULATIVE`. You can't use `GAUGE` metrics\nin request-based SLIs.\n\nFor windows-based SLOs, your SLI represents a count of good outcomes in\na given period. The acceptable metric kinds depend on how you structure\nthe SLIs. However, if you use a request-based SLI, then the metric kind of your\nSLI must be `DELTA` or `CUMULATIVE`. You can't use `GAUGE` metrics\nin request-based SLIs.\nFor more information, see [Structures for windows-based\nSLIs](/stackdriver/docs/solutions/slo-monitoring/api/api-structures#window-sli-structs).\n\nFor more information on the types of SLOs, see [Concepts in service\nmonitoring](/stackdriver/docs/solutions/slo-monitoring).\n\nYou can use metric types provided by Cloud Monitoring, or you can\nuse custom metric types you've created. In both cases,\nthe values are suitable for the SLI you want to create.\n\n### Unsuitable metric types\n\nWhen considering a metric type for use as an SLI, avoid high-cardinality\nmetric types. Cardinality describes the number of possible time series that\ncan be associated with the metric type, and it is related to the granularity\nof the values that metric labels can take. For a discussion of cardinality,\nsee [Cardinality: time series and labels](/monitoring/api/v3/metric-model#cardinality).\n\nMetric types with labels that take values like timestamps are likely to have\nvery high cardinality and are poor choices for use as SLIs.\nHigh-cardinality metrics are often user-defined metrics that have not been\ndesigned to avoid cardinality issues. These can include user-defined [log-based\nmetrics](/logging/docs/logs-based-metrics) and [custom metrics](/monitoring/custom-metrics).\n\nFinding suitable metric types\n-----------------------------\n\nThe information about metric types, including the metric kind, can be found\nin multiple places:\n\n- The metrics selector used in tools like Metrics Explorer displays\n a hover-card for the highlighted metric type. This tool works for\n custom and built-in metrics.\n\n For example, the following screenshot shows the hover-card for the metric\n type `loadbalancing.googleapis.com/https/request_count` as seen in\n Metrics Explorer:\n\n With Metrics Explorer, you can also configure the metric to mimic\n what the SLO API does, and you can get a JSON representation of\n that configuration. This JSON is useful in creating an SLI manually.\n- The pages in the [Metrics list](/monitoring/api/metrics) contain tables for each\n service that detail the metric types associated with the services.\n These tables include all the built-in metric types, but don't show\n custom metric types.\n\n For example, the following screenshot shows the entry for the metric type\n `loadbalancing.googleapis.com/https/request_count` as seen in\n the [list of loadbalancing metrics](/monitoring/api/metrics_gcp_i_o#gcp-loadbalancing). These entries\n often provide more detail than the hover-cards in Metrics Explorer.\n\nBuilding the SLI\n----------------\n\nFor service monitoring, metric data is processed in specific ways, which\nyou can replicate in Metrics Explorer. This page assumes you are familiar\nwith using Metrics Explorer. If you need more information, see\n[Metrics Explorer](/monitoring/charts/metrics-explorer).\n\nTo build a request-based SLI based on a time-series ratio, you need two\ntime series: one that represents all requests, and one that represents good\n(or bad) requests. This type of SLI has the following structure: \n\n```\n \"requestBased\": {\n \"goodTotalRatio\": {\n \"totalServiceFilter\": TO_BE_IDENTIFIED,\n \"goodServiceFilter\": TO_BE_IDENTIFIED,\n }\n }\n```\n\n\u003cbr /\u003e\n\nTo get the value for the `goodServiceFilter` field:\n\n1. Select the monitored-resource type and metric type. Remember that\n the metric kind must be `DELTA` or `CUMULATIVE`. The result might\n include many different time series.\n\n For example, select the `http_lb_rule` resource type and the\n `loadbalancing.googleapis.com/https/request_count` metric type.\n2. Use the **Filter** field to set the label `response_code_class` to `200`.\n This filter removes any time series with other values for this label. There\n still might be multiple time series that match.\n\n3. Choose the `sum` aggregator to create a single time series. The chart\n on the **Metrics Explorer** page displays the resulting time series.\n\n4. Click **More Options *more_vert*** above the chart, and\n select **View as JSON** from the menu.\n\n The retrieved JSON looks something like the following: \n\n ```\n \"dataSets\": [\n {\n \"timeSeriesFilter\": {\n \"filter\": \"metric.type=\"loadbalancing.googleapis.com/https/request_count\" resource.type=\"http_lb_rule\" metric.label.\"response_code_class\"=\"200\"\"\n \"perSeriesAligner\": \"ALIGN_RATE\",\n \"crossSeriesReducer\": \"REDUCE_SUM\",\n \"secondaryCrossSeriesReducer\": \"REDUCE_NONE\",\n \"minAlignmentPeriod\": \"60s\",\n \"groupByFields\": [],\n \"unitOverride\": \"1\"\n },\n \"targetAxis\": \"Y1\",\n \"plotType\": \"LINE\"\n }\n ],\n ```\n\n \u003cbr /\u003e\n\nThe piece you are interested in is the value of the `filter` field embedded\nin the `dataSets` object: \n\n```\n\"filter\": \"metric.type=\"loadbalancing.googleapis.com/https/request_count\" resource.type=\"http_lb_rule\" metric.label.\"response_code_class\"=\"200\"\"\n```\n\n\u003cbr /\u003e\n\nTo build out the SLI structure:\n\n1. Insert this value into the SLI structure as the value of the\n `goodServiceFilter` field.\n\n2. Also insert this value into the SLI structure as the value of the\n `totalServiceFilter`, but then remove the label part of the filter,\n `metric.label.\\\"response_code_class\\\"=\\\"200\\\"`.\n\nThe resulting service-level indicator follows: \n\n```\n \"requestBased\": {\n \"goodTotalRatio\": {\n \"totalServiceFilter\": \"metric.type=\"loadbalancing.googleapis.com/https/request_count\" resource.type=\"http_lb_rule\"\",\n \"goodServiceFilter\": \"metric.type=\"loadbalancing.googleapis.com/https/request_count\" resource.type=\"http_lb_rule\" metric.label.\"response_code_class\"=\"200\"\",\n }\n }\n```\n\n\u003cbr /\u003e\n\nYou can then insert this SLI into an SLO, for example: \n\n```\n{\n \"serviceLevelIndicator\": {\n \"requestBased\": {\n \"goodTotalRatio\": {\n \"totalServiceFilter\": \"metric.type=\"loadbalancing.googleapis.com/https/request_count\" resource.type=\"http_lb_rule\"\",\n \"goodServiceFilter\": \"metric.type=\"loadbalancing.googleapis.com/https/request_count\" resource.type=\"http_lb_rule\" metric.label.\"response_code_class\"=\"200\"\",\n }\n }\n },\n \"goal\": 0.98,\n \"calendarPeriod\": \"WEEK\",\n \"displayName\": \"98% Successful requests in a calendar week\"\n}\n```\n\n\u003cbr /\u003e\n\nYou can use this JSON to create an SLO, as described in [Creating an\nSLO](/stackdriver/docs/solutions/slo-monitoring/api/using-api#slo-create)."]]
