Menggunakan metrik Cloud Load Balancing

Halaman ini meninjau jenis load balancer yang tersedia dari Cloud Load Balancing dan menjelaskan cara menggunakan metrik Cloud Monitoring yang ditampilkan olehnya sebagai SLI.

Layanan Cloud Load Balancing sering kali menyediakan titik entri pertama untuk aplikasi yang dihosting di Google Cloud. Load balancer secara otomatis diinstrumentasikan untuk memberikan informasi tentang traffic, ketersediaan, dan latensi layanan Google Cloud yang dieksposnya; oleh karena itu, load balancer sering kali bertindak sebagai sumber metrik SLI yang sangat baik tanpa memerlukan instrumentasi aplikasi.

Saat memulai, Anda dapat memilih untuk berfokus pada ketersediaan dan latensi sebagai dimensi utama keandalan, serta membuat SLI dan SLO untuk mengukur dan memberikan pemberitahuan tentang dimensi tersebut. Halaman ini memberikan contoh penerapan.

Untuk informasi tambahan, lihat referensi berikut:

• Konsep dalam pemantauan layanan
• Dokumentasi untuk Cloud Load Balancing
• Daftar jenis metrik loadbalancing.googleapis.com

Catatan: String filter dalam beberapa contoh ini telah digabungkan barisnya agar mudah dibaca.

SLI dan SLO Ketersediaan

Untuk aplikasi non-UDP, SLI ketersediaan berbasis permintaan adalah yang paling sesuai, karena interaksi layanan dipetakan dengan rapi ke permintaan.

Anda menyatakan SLI ketersediaan berbasis permintaan menggunakan struktur TimeSeriesRatio untuk menyiapkan rasio permintaan yang baik terhadap total permintaan, seperti yang ditunjukkan dalam contoh ketersediaan berikut. Untuk mendapatkan penentuan "baik" atau "valid" yang Anda inginkan, Anda memfilter metrik menggunakan label yang tersedia.

Load balancer lapisan 7 (HTTP/S) eksternal

Load balancer HTTP/S digunakan untuk mengekspos aplikasi yang diakses melalui HTTP/S dan mendistribusikan traffic ke resource yang terletak di beberapa region.

Load Balancer Aplikasi Eksternal menulis data metrik ke Monitoring menggunakan jenis resource yang dimonitor dan jenis metrik https_lb_rule dengan awalan loadbalancing.googleapis.com. Jenis metrik yang paling relevan dengan SLO ketersediaan adalah https/request_count, yang dapat Anda filter menggunakan label metrik response_code_class.

Jika Anda memilih untuk tidak menghitung permintaan yang menghasilkan kode respons error 4xx sebagai "valid" karena mungkin menunjukkan error klien, bukan error layanan atau aplikasi, Anda dapat menulis filter untuk "total" seperti ini:

"totalServiceFilter":
  "metric.type=\"loadbalancing.googleapis.com/https/request_count\"
   resource.type=\"https_lb_rule\"
   resource.label.\"url_map_name\"=\"my-app-lb\"
   metric.label.\"response_code_class\"!=\"400\"",

Anda juga perlu menentukan cara menghitung permintaan "baik". Misalnya, jika Anda memilih untuk hanya menghitung respons yang menampilkan kode respons status berhasil 200 OK, Anda dapat menulis filter untuk "baik" seperti ini:

"goodServiceFilter":
  "metric.type=\"loadbalancing.googleapis.com/https/request_count\"
   resource.type=\"https_lb_rule\"
   resource.label.\"url_map_name\"=\"my-app-lb\"
   metric.label.\"response_code_class\"=\"200\"",

Kemudian, Anda dapat menyatakan SLI berbasis permintaan seperti ini:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"loadbalancing.googleapis.com/https/request_count\"
         resource.type=\"https_lb_rule\"
         resource.label.\"url_map_name\"=\"my-app-lb\"
         metric.label.\"response_code_class\"!=\"400\"",
      "goodServiceFilter":
        "metric.type=\"loadbalancing.googleapis.com/https/request_count\"
         resource.type=\"https_lb_rule\"
         resource.label.\"url_map_name\"=\"my-app-lb\"
         metric.label.\"response_code_class\"=\"200\"",
    }
  }
},

Untuk aplikasi yang traffic-nya ditayangkan oleh beberapa backend, Anda dapat memilih untuk menentukan SLI untuk backend tertentu. Untuk membuat SLI ketersediaan untuk backend tertentu, gunakan metrik https/backend_request_count dengan label resource backend_target_name di filter Anda, seperti yang ditunjukkan dalam contoh ini:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
         resource.type=\"https_lb_rule\"
         resource.label.\"url_map_name\"=\"my-app-lb\"
         resource.label.\"backend_target_name\"=\"my-app-backend\"
         metric.label.\"response_code_class\"!=\"400\"",
      "goodServiceFilter":
        "metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
         resource.type=\"https_lb_rule\" resource.label.\"url_map_name\"=\"my-app-lb\"
         resource.label.\"backend_target_name\"=\"my-app-backend\"
         metric.label.\"response_code_class\"=\"200\"",
    }
  }
}

Load balancer lapisan 7 (HTTP/S) internal

Load Balancer Aplikasi Internal menulis data metrik ke Monitoring menggunakan jenis resource yang dimonitor dan jenis metrik internal_http_lb_rule dengan awalan loadbalancing.googleapis.com. Jenis metrik yang paling relevan dengan SLO ketersediaan adalah https/internal_request_count, yang dapat Anda filter menggunakan label metrik response_code_class.

Berikut adalah contoh SLI ketersediaan berbasis permintaan:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
         resource.type=\"internal_http_lb_rule\"
         resource.label.\"url_map_name\"=\"my-internal-lb\"
         metric.label.\"response_code_class\"!=\"400\"",
      "goodServiceFilter":
         "metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
          resource.type=\"internal_http_lb_rule\"
          resource.label.\"url_map_name\"=\"my-internal-lb\"
          metric.label.\"response_code_class\"=\"200\"",
    }
  }
},

Load balancer Lapis 3 (TCP)

Load balancer TCP tidak memberikan metrik permintaan karena aplikasi yang menggunakannya mungkin tidak didasarkan pada model permintaan-respons. Tidak ada metrik loadbalancing.googleapis.com yang disediakan oleh load balancer ini yang cocok untuk SLI ketersediaan yang baik.

Untuk membuat SLI ketersediaan bagi load balancer ini, Anda harus membuat metrik kustom atau berbasis log. Untuk informasi selengkapnya, lihat Menggunakan metrik kustom atau Menggunakan metrik berbasis log.

SLI dan SLO latensi

Untuk aplikasi permintaan-respons, ada dua cara untuk menulis SLO latensi:

• Sebagai SLO berbasis permintaan.
• Sebagai SLO berbasis rentang waktu.

SLO latensi berbasis permintaan

SLO berbasis permintaan menerapkan nilai minimum latensi dan menghitung fraksi permintaan yang selesai di bawah nilai minimum dalam periode kepatuhan tertentu. Contoh SLO berbasis permintaan adalah "99% permintaan selesai dalam waktu kurang dari 100 md dalam periode satu jam bergulir".

Anda menyatakan SLI latensi berbasis permintaan menggunakan struktur DistributionCut, seperti yang ditunjukkan dalam contoh latensi berikut.

Satu SLO berbasis permintaan tidak dapat menangkap performa standar dan degradasi pengalaman pengguna, dengan "ekor" atau permintaan paling lambat mengalami waktu respons yang semakin lama. SLO untuk performa standar tidak mendukung pemahaman latensi ekor. Untuk diskusi tentang latensi ekor, lihat bagian "Mengkhawatirkan Ekor Anda" di Bab 6: Memantau Sistem Terdistribusi dari Site Reliability Engineering.

Untuk mengurangi batasan ini, Anda dapat menulis SLO kedua untuk berfokus secara khusus pada latensi tail, misalnya, "99,9% permintaan selesai dalam waktu kurang dari 1.000 md selama periode 1 jam bergulir". Kombinasi dari dua SLO ini menangkap degradasi dalam pengalaman pengguna umum dan latensi ekor.

SLO latensi berbasis periode waktu

SLO berbasis jendela menentukan kriteria kualitas untuk jangka waktu pengukuran dan menghitung rasio interval "baik" terhadap jumlah total interval. Contoh SLO berbasis periode adalah "Metrik latensi persentil ke-95 kurang dari 100 md untuk setidaknya 99% periode satu menit, selama periode bergulir 28 hari":

• Periode pengukuran yang "baik" adalah rentang waktu satu menit dengan 95% permintaan memiliki latensi di bawah 100 md.
• Ukuran kepatuhan adalah pecahan periode "baik" tersebut. Layanan mematuhi kebijakan jika pecahan ini minimal 0,99, yang dihitung selama periode kepatuhan.

Anda harus menggunakan SLO berbasis periode jika metrik mentah yang tersedia untuk Anda adalah persentil latensi; yaitu, jika kedua hal berikut benar:

• Data dikelompokkan ke dalam jangka waktu (misalnya, ke dalam interval satu menit).
• Data dinyatakan dalam grup persentil (misalnya, p50, p90, p95, p99).

Untuk jenis data ini, setiap grup persentil menunjukkan waktu yang membagi grup data di atas dan di bawah persentil tersebut. Misalnya, interval satu menit dengan metrik latensi p95 sebesar 89 md memberi tahu Anda bahwa, selama menit tersebut, layanan merespons 95% permintaan dalam 89 md atau kurang.

Load Balancer Aplikasi Eksternal

Load Balancer Aplikasi Eksternal menggunakan jenis metrik utama berikut untuk menangkap latensi:

• https/total_latencies: distribusi latensi yang dihitung dari saat permintaan diterima oleh proxy hingga proxy mendapatkan ACK dari klien pada byte respons terakhir. Gunakan jika pengalaman pengguna secara keseluruhan merupakan hal yang paling penting.

• https/backend_latencies: distribusi latensi yang dihitung dari saat permintaan dikirim oleh proxy ke backend hingga proxy menerima byte terakhir respons dari backend. Gunakan untuk mengukur latensi backend tertentu yang menyalurkan traffic di belakang load balancer.

Metrik ini ditulis berdasarkan jenis resource yang dimonitor https_lb_rule.

Catatan: Kedua metrik memiliki jenis nilai DISTRIBUTION, yang berarti keduanya berisi histogram yang mewakili distribusi nilai di seluruh bucket. Batas bucket untuk metrik ini dibuat menggunakan bilangan pangkat 1,4; yaitu, bucket pertama adalah 0-1,4, bucket kedua adalah 1,4-1,96, dan seterusnya. Jika Anda memiliki persyaratan pemberitahuan yang sangat akurat, Anda dapat mempertimbangkan hal ini saat menetapkan nilai minimum, tetapi sebagian besar waktu, mengandalkan interpolasi untuk nilai minimum yang berada dalam bucket sudah memadai.

Total latensi

Contoh SLO ini mengharapkan bahwa 99% permintaan memiliki total latensi antara 0 dan 100 md selama periode satu jam bergulir:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
             "metric.type=\"loadbalancing.googleapis.com/https/total_latencies\"
              resource.type=\"https_lb_rule\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Latensi backend

Contoh SLO ini memperkirakan bahwa 98% permintaan ke target backend "my-app-backend" memiliki latensi antara 0 dan 100 md selama periode satu jam bergulir:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"loadbalancing.googleapis.com/https/backend_latencies\"
           resource.type=\"https_lb_rule\"
           resource.label.\"backend_target_name\"=\"my-app-backend\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.98,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Load Balancer Aplikasi Internal

Load Balancer Aplikasi Internal menggunakan dua jenis metrik utama untuk merekam latensi:

• https/internal/total_latencies: distribusi latensi yang dihitung dari saat permintaan diterima oleh proxy hingga proxy mendapatkan ACK dari klien pada byte respons terakhir. Gunakan jika pengalaman pengguna secara keseluruhan merupakan hal yang paling penting.

• https/internal/backend_latencies: distribusi latensi yang dihitung dari saat permintaan dikirim oleh proxy ke backend hingga proxy menerima byte terakhir respons dari backend. Gunakan untuk mengukur latensi backend tertentu yang menyalurkan traffic di belakang load balancer.

Metrik ini ditulis berdasarkan jenis resource yang dimonitor internal_http_lb_rule.

Catatan: Kedua metrik memiliki jenis nilai DISTRIBUTION, yang berarti keduanya berisi histogram yang mewakili distribusi nilai di seluruh bucket. Batas bucket untuk metrik ini dibuat menggunakan bilangan pangkat 2 dengan skala 1e-06. Jika Anda memiliki persyaratan pemberitahuan yang sangat presisi, Anda dapat mempertimbangkan hal ini saat menetapkan nilai minimum, tetapi sebagian besar waktu, mengandalkan interpolasi untuk nilai minimum yang berada dalam bucket sudah memadai.

Total latensi

Contoh SLO ini mengharapkan bahwa 99% permintaan memiliki total latensi antara 0 dan 100 md selama periode satu jam bergulir:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"loadbalancing.googleapis.com/https/internal/total_latencies\"
           resource.type=\"internal_http_lb_rule\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Contoh SLO ini memperkirakan bahwa 99% permintaan memiliki total latensi antara 0 dan 100 md selama periode satu jam bergulir.

Latensi backend

Contoh SLO ini memperkirakan bahwa 98% permintaan ke target backend "my-internal-backend" memiliki latensi antara 0 dan 100 md selama periode satu jam bergulir:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"loadbalancing.googleapis.com/https/internal/backend_latencies\"
           resource.type=\"https_lb_rule\"
           resource.label.\"backend_target_name\"=\"my-internal-backend\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.98,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Load balancer lapisan 3 (TCP) eksternal

Load balancer TCP eksternal menggunakan satu jenis metrik, l3/external/rtt_latencies, yang mencatat distribusi waktu bolak-balik yang diukur melalui koneksi TCP untuk alur load balancer eksternal.

Metrik ini ditulis berdasarkan resource tcp_lb_rule.

Contoh SLO ini mengharapkan bahwa 99% permintaan memiliki total latensi antara 0 dan 100 md selama periode satu jam bergulir:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"loadbalancing.googleapis.com/l3/external/rtt_latencies\"
           resource.type=\"tcp_lb_rule\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Load balancer lapisan 3 (TCP) internal

Load balancer TCP internal menggunakan satu jenis metrik, l3/internal/rtt_latencies, yang mencatat distribusi waktu bolak-balik yang diukur melalui koneksi TCP untuk alur load balancer internal.

Metrik ini ditulis berdasarkan resource internal_tcp_lb_rule.

Contoh SLO ini mengharapkan bahwa 99% permintaan memiliki total latensi antara 0 dan 100 md selama periode satu jam bergulir:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"loadbalancing.googleapis.com/l3/internal/rtt_latencies\"
           resource.type=\"internal_tcp_lb_rule\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}