Menggunakan metrik Cloud Load Balancing

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

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

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

Untuk informasi tambahan, lihat referensi berikut:

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

Catatan: String filter dalam beberapa contoh ini telah diatur dalam beberapa baris agar mudah dibaca.

SLI dan SLO ketersediaan

Untuk aplikasi non-UDP, SLI ketersediaan berbasis permintaan adalah yang paling tepat, 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 eksternal lapis 7 (HTTP/S)

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

Load Balancer Aplikasi Eksternal menulis data metrik ke Monitoring menggunakan jenis resource yang dimonitor https_lb_rule dan jenis metrik 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 menghitung hanya 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 trafficnya ditayangkan oleh beberapa backend, Anda dapat memilih untuk menentukan SLI untuk backend tertentu. Untuk membuat SLI ketersediaan bagi backend tertentu, gunakan metrik https/backend_request_count dengan label resource backend_target_name dalam 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 internal lapisan 7 (HTTP/S)

Load Balancer Aplikasi Internal menulis data metrik ke Monitoring menggunakan jenis resource yang dimonitor internal_http_lb_rule dan jenis metrik 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 ini 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 menggunakan load balancer ini 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 mengetahui 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 ambang batas latensi dan menghitung fraksi permintaan yang selesai di bawah ambang batas dalam periode kepatuhan tertentu. Contoh SLO berbasis permintaan adalah "99% permintaan selesai dalam waktu kurang dari 100 md dalam periode satu jam".

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

SLO berbasis permintaan tunggal tidak dapat mencakup performa umum dan penurunan kualitas pengalaman pengguna, di mana permintaan "ekor" atau permintaan paling lambat mengalami waktu respons yang semakin lama. SLO untuk performa standar tidak mendukung pemahaman latensi ekor. Untuk pembahasan tentang latensi ekor, lihat bagian "Mengkhawatirkan Ekor Anda" di Bab 6: Memantau Sistem Terdistribusi dalam 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". Kombinasi kedua SLO mencatat penurunan kualitas dalam pengalaman pengguna umum dan latensi ekor.

SLO latensi berbasis jendela

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

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

Anda harus menggunakan SLO berbasis jendela 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 kelompok persentil (misalnya, p50, p90, p95, p99).

Untuk jenis data ini, setiap kelompok persentil menunjukkan waktu yang membagi kelompok data di atas dan di bawah persentil tersebut. Misalnya, interval satu menit dengan metrik latensi p95 sebesar 89 md memberi tahu Anda bahwa, selama satu 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 mencatat 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 saat pengalaman pengguna secara keseluruhan menjadi 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 melayani traffic di belakang load balancer.

Metrik ini ditulis terhadap jenis resource yang dipantau https_lb_rule.

Catatan: Kedua metrik memiliki jenis nilai DISTRIBUTION, yang berarti bahwa keduanya berisi histogram yang merepresentasikan distribusi nilai di seluruh bucket. Batas bucket untuk metrik ini dibuat menggunakan 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 presisi, Anda dapat mempertimbangkan hal ini saat menetapkan nilai minimum, tetapi sebagian besar waktu, mengandalkan interpolasi untuk nilai minimum yang berada dalam rentang sudah cukup.

Total latensi

Contoh SLO ini mengharapkan 99% permintaan berada di antara 0 dan 100 md dalam total latensi 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 mengharapkan 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 mencatat 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 saat pengalaman pengguna secara keseluruhan menjadi 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 melayani traffic di belakang load balancer.

Metrik ini ditulis terhadap jenis resource yang dimonitor internal_http_lb_rule.

Catatan: Kedua metrik memiliki jenis nilai DISTRIBUTION, yang berarti bahwa keduanya berisi histogram yang merepresentasikan distribusi nilai di seluruh bucket. Batas bucket untuk metrik ini dibuat menggunakan 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 rentang sudah cukup.

Total latensi

SLO contoh ini mengharapkan 99% permintaan berada di antara 0 dan 100 md dalam total latensi 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"
}

SLO contoh ini mengharapkan 99% permintaan berada di antara 0 dan 100 md dalam total latensi selama periode satu jam bergulir.

Latensi backend

Contoh SLO ini mengharapkan 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 eksternal layer 3 (TCP)

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

Metrik ini ditulis terhadap resource tcp_lb_rule.

SLO contoh ini mengharapkan 99% permintaan berada di antara 0 dan 100 md dalam total latensi 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 internal layer 3 (TCP)

Load balancer TCP internal menggunakan satu jenis metrik, l3/internal/rtt_latencies, yang mencatat distribusi waktu perjalanan pulang pergi yang diukur melalui koneksi TCP untuk aliran load balancer internal.

Metrik ini ditulis terhadap resource internal_tcp_lb_rule.

SLO contoh ini mengharapkan 99% permintaan berada di antara 0 dan 100 md dalam total latensi 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"
}