GSP736

Ringkasan

Cloud Logging, dan alat pendampingnya, Cloud Monitoring, adalah produk berfitur lengkap yang sangat terintegrasi dengan Google Kubernetes Engine. Lab ini mengajarkan cara kerja Cloud Logging dengan cluster dan aplikasi GKE serta beberapa praktik terbaik pengumpulan log melalui kasus penggunaan logging umum.

Tujuan

Di lab ini, Anda akan mempelajari cara:

• Menggunakan Cloud Monitoring untuk mendeteksi masalah
• Menggunakan Cloud Logging untuk memecahkan masalah aplikasi yang berjalan di GKE

Aplikasi demo yang digunakan dalam lab

Sebagai contoh konkret, Anda akan memecahkan masalah aplikasi contoh microservices demo yang di-deploy ke cluster GKE. Dalam aplikasi demo ini, terdapat banyak microservice dan dependensi di antara microservice tersebut. Anda akan membuat traffic menggunakan alat penghasil beban, lalu menggunakan Logging, Monitoring, dan GKE untuk melihat error (pemberitahuan/metriknya), mengidentifikasi akar masalah dengan Logging, lalu memperbaiki/mengonfirmasi bahwa masalah telah diperbaiki dengan Logging dan Monitoring.

Penyiapan dan persyaratan

Sebelum mengklik tombol Start Lab

Baca petunjuk ini. Lab memiliki timer dan Anda tidak dapat menjedanya. Timer yang dimulai saat Anda mengklik Start Lab akan menampilkan durasi ketersediaan resource Google Cloud untuk Anda.

Lab interaktif ini dapat Anda gunakan untuk melakukan aktivitas lab di lingkungan cloud sungguhan, bukan di lingkungan demo atau simulasi. Untuk mengakses lab ini, Anda akan diberi kredensial baru yang bersifat sementara dan dapat digunakan untuk login serta mengakses Google Cloud selama durasi lab.

Untuk menyelesaikan lab ini, Anda memerlukan:

• Akses ke browser internet standar (disarankan browser Chrome).

Catatan: Gunakan jendela Samaran (direkomendasikan) atau browser pribadi untuk menjalankan lab ini. Hal ini akan mencegah konflik antara akun pribadi Anda dan akun siswa yang dapat menyebabkan tagihan ekstra pada akun pribadi Anda.

• Waktu untuk menyelesaikan lab. Ingat, setelah dimulai, lab tidak dapat dijeda.

Catatan: Hanya gunakan akun siswa untuk lab ini. Jika Anda menggunakan akun Google Cloud yang berbeda, Anda mungkin akan dikenai tagihan ke akun tersebut.

Cara memulai lab dan login ke Google Cloud Console

1. Klik tombol Start Lab. Jika Anda perlu membayar lab, dialog akan terbuka untuk memilih metode pembayaran. Di sebelah kiri ada panel Lab Details yang berisi hal-hal berikut:

   • Tombol Open Google Cloud console
   • Waktu tersisa
   • Kredensial sementara yang harus Anda gunakan untuk lab ini
   • Informasi lain, jika diperlukan, untuk menyelesaikan lab ini

2. Klik Open Google Cloud console (atau klik kanan dan pilih Open Link in Incognito Window jika Anda menjalankan browser Chrome).

   Lab akan menjalankan resource, lalu membuka tab lain yang menampilkan halaman Sign in.

   Tips: Atur tab di jendela terpisah secara berdampingan.

   Catatan: Jika Anda melihat dialog Choose an account, klik Use Another Account.

3. Jika perlu, salin Username di bawah dan tempel ke dialog Sign in.

   {{{user_0.username | "Username"}}}

   Anda juga dapat menemukan Username di panel Lab Details.

4. Klik Next.

5. Salin Password di bawah dan tempel ke dialog Welcome.

   {{{user_0.password | "Password"}}}

   Anda juga dapat menemukan Password di panel Lab Details.

6. Klik Next.

   Penting: Anda harus menggunakan kredensial yang diberikan lab. Jangan menggunakan kredensial akun Google Cloud Anda. Catatan: Menggunakan akun Google Cloud sendiri untuk lab ini dapat dikenai biaya tambahan.

7. Klik halaman berikutnya:

   • Setujui persyaratan dan ketentuan.
   • Jangan tambahkan opsi pemulihan atau autentikasi 2 langkah (karena ini akun sementara).
   • Jangan mendaftar uji coba gratis.

Setelah beberapa saat, Konsol Google Cloud akan terbuka di tab ini.

Catatan: Untuk mengakses produk dan layanan Google Cloud, klik Navigation menu atau ketik nama layanan atau produk di kolom Search.

Mengaktifkan Cloud Shell

Cloud Shell adalah mesin virtual yang dilengkapi dengan berbagai alat pengembangan. Mesin virtual ini menawarkan direktori beranda persisten berkapasitas 5 GB dan berjalan di Google Cloud. Cloud Shell menyediakan akses command-line untuk resource Google Cloud Anda.

1. Klik Activate Cloud Shell di bagian atas Konsol Google Cloud.

2. Klik jendela berikut:

   • Lanjutkan melalui jendela informasi Cloud Shell.
   • Beri otorisasi ke Cloud Shell untuk menggunakan kredensial Anda guna melakukan panggilan Google Cloud API.

Setelah terhubung, Anda sudah diautentikasi, dan project ditetapkan ke Project_ID, . Output berisi baris yang mendeklarasikan Project_ID untuk sesi ini:

Project Cloud Platform Anda dalam sesi ini disetel ke {{{project_0.project_id | "PROJECT_ID"}}}

gcloud adalah alat command line untuk Google Cloud. Alat ini sudah terinstal di Cloud Shell dan mendukung pelengkapan command line.

3. (Opsional) Anda dapat menampilkan daftar nama akun yang aktif dengan perintah ini:

gcloud auth list

4. Klik Authorize.

Output:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} Untuk menetapkan akun aktif, jalankan: $ gcloud config set account `ACCOUNT`

5. (Opsional) Anda dapat menampilkan daftar ID project dengan perintah ini:

gcloud config list project

Output:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Catatan: Untuk mendapatkan dokumentasi gcloud yang lengkap di Google Cloud, baca panduan ringkasan gcloud CLI.

Menetapkan region dan zona

Resource Compute Engine tertentu berada di region dan zona. Region adalah lokasi geografis spesifik tempat Anda dapat menjalankan resource. Setiap region memiliki satu atau beberapa zona.

Jalankan perintah gcloud berikut di Konsol Cloud guna menetapkan region dan zona default untuk lab Anda:

gcloud config set compute/zone "{{{project_0.default_zone|ZONE}}}" export ZONE=$(gcloud config get compute/zone) gcloud config set compute/region "{{{project_0.default_region|REGION}}}" export REGION=$(gcloud config get compute/region)

Tugas 1. Penyiapan infrastruktur

Buat koneksi ke cluster Google Kubernetes Engine dan pastikan cluster tersebut telah dibuat dengan benar.

1. Tetapkan variabel Project ID:

export PROJECT_ID={{{project_0.startup_script.project | Project ID}}}

2. Gunakan perintah berikut untuk melihat status cluster:

gcloud container clusters list

Status cluster akan tertulis PROVISIONING.

3. Tunggu sebentar dan jalankan kembali perintah di atas hingga statusnya RUNNING. Proses ini dapat memakan waktu beberapa menit.

4. Verifikasikan bahwa cluster yang bernama central telah dibuat.

Anda juga dapat memantau progres di Konsol Cloud dengan membuka Navigation menu > Kubernetes Engine > Clusters.

5. Dapatkan kredensial cluster setelah status cluster berubah menjadi RUNNING:

gcloud container clusters get-credentials central --zone $ZONE

Output:

Fetching cluster endpoint and auth data. kubeconfig entry generated for central.

6. Pastikan node telah dibuat:

kubectl get nodes

Output Anda akan terlihat seperti ini:

NAME STATUS ROLES AGE VERSION gke-central-default-pool-5ff4130f-qz8v Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-ssd2 Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-tz63 Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-zfmn Ready 24d v1.27.2-gke.1200

Tugas 2. Men-deploy aplikasi

Selanjutnya, deploy aplikasi microservice bernama Hipster Shop ke cluster Anda untuk membuat workload yang dapat Anda pantau.

1. Jalankan perintah berikut untuk meng-clone repo:

git clone https://github.com/xiangshen-dk/microservices-demo.git

2. Ubah ke direktori microservices-demo:

cd microservices-demo

3. Instal aplikasi menggunakan kubectl:

kubectl apply -f release/kubernetes-manifests.yaml

4. Pastikan semuanya berjalan dengan benar:

kubectl get pods

Output harus terlihat seperti output di bawah:

NAME READY STATUS RESTARTS AGE adservice-55f94cfd9c-4lvml 1/1 Running 0 20m cartservice-6f4946f9b8-6wtff 1/1 Running 2 20m checkoutservice-5688779d8c-l6crl 1/1 Running 0 20m currencyservice-665d6f4569-b4sbm 1/1 Running 0 20m emailservice-684c89bcb8-h48sq 1/1 Running 0 20m frontend-67c8475b7d-vktsn 1/1 Running 0 20m loadgenerator-6d646566db-p422w 1/1 Running 0 20m paymentservice-858d89d64c-hmpkg 1/1 Running 0 20m productcatalogservice-bcd85cb5-d6xp4 1/1 Running 0 20m recommendationservice-685d7d6cd9-pxd9g 1/1 Running 0 20m redis-cart-9b864d47f-c9xc6 1/1 Running 0 20m shippingservice-5948f9fb5c-vndcp 1/1 Running 0 20m

5. Jalankan kembali perintah hingga semua pod melaporkan status Running sebelum melanjutkan ke langkah berikutnya.

Klik Periksa progres saya untuk memverifikasi tujuan. Men-deploy Aplikasi

6. Jalankan perintah berikut untuk mendapatkan IP eksternal aplikasi. Perintah ini hanya akan menampilkan alamat IP setelah service di-deploy, jadi Anda mungkin perlu mengulangi perintah hingga alamat IP eksternal ditetapkan:

export EXTERNAL_IP=$(kubectl get service frontend-external | awk 'BEGIN { cnt=0; } { cnt+=1; if (cnt > 1) print $4; }')

7. Terakhir, pastikan aplikasi telah aktif dan berjalan:

curl -o /dev/null -s -w "%{http_code}\n" http://$EXTERNAL_IP

Konfirmasi Anda akan terlihat seperti ini:

200

Setelah aplikasi di-deploy, Anda juga dapat membuka Konsol Cloud dan melihat statusnya.

Di halaman Kubernetes Engine > Workloads, Anda akan melihat bahwa semua pod dalam status OK.

8. Sekarang, pilih Gateways,Services & Ingress, lalu klik tab Services untuk memverifikasi bahwa semua service dalam status OK. Jangan pindah dari layar ini untuk menyiapkan pemantauan untuk aplikasi.

Tugas 3. Membuka aplikasi

1. Scroll ke bawah ke frontend-external dan klik IP Endpoint service tersebut.

Aplikasi akan terbuka dan Anda akan melihat halaman seperti berikut:

Tugas 4. Membuat metrik berbasis log

Sekarang Anda akan mengonfigurasi Cloud Logging untuk membuat metrik berbasis log, yang merupakan metrik kustom dalam Cloud Monitoring yang dibuat dari entri log. Metrik berbasis log cocok untuk menghitung jumlah entri log dan melacak distribusi nilai dalam log Anda. Dalam kasus ini, Anda akan menggunakan metrik berbasis log untuk menghitung jumlah error dalam service frontend Anda. Selanjutnya, Anda dapat menggunakan metrik tersebut di dasbor dan pemberitahuan.

1. Kembali ke Konsol Cloud, dan dari Navigation menu, buka Logging, lalu klik Logs Explorer.

2. Aktifkan Show query dan di kotak Query builder, tambahkan kueri berikut:

resource.type="k8s_container" severity=ERROR labels."k8s-pod/app": "recommendationservice"

3. Klik Run Query.

Kueri yang digunakan memungkinkan Anda menemukan semua error dari pod frontend. Namun, saat ini Anda tidak akan melihat hasil apa pun karena memang belum ada error.

4. Untuk membuat metrik berbasis log, klik dropdown Actions dan pilih Create Metric.

5. Namai metrik Error_Rate_SLI, lalu klik Create Metric untuk menyimpan metrik berbasis log:

Anda sekarang akan melihat metrik yang tercantum di bagian User-defined Metrics pada halaman Logs-based Metrics.

Klik Periksa progres saya untuk memverifikasi tujuan. Membuat metrik berbasis log

Tugas 5. Membuat kebijakan pemberitahuan

Pemberitahuan akan memberikan informasi tentang masalah di aplikasi cloud Anda saat diperlukan agar Anda dapat menyelesaikan masalah dengan cepat. Sekarang Anda akan menggunakan Cloud Monitoring untuk memantau ketersediaan service frontend dengan membuat kebijakan pemberitahuan berdasarkan metrik berbasis log error frontend yang telah Anda buat sebelumnya. Saat kondisi kebijakan pemberitahuan terpenuhi, Cloud Monitoring akan membuat dan menampilkan insiden di Konsol Cloud.

1. Di Navigation menu, buka Monitoring, lalu klik Alerting.

2. Setelah ruang kerja dibuat, klik Create Policy di bagian atas.

Catatan: Jika diperlukan, klik Try it! untuk menggunakan alur pembuatan pemberitahuan yang telah diperbarui.

3. Klik pada dropdown Select a metric. Hapus centang Active.

4. Di kolom filter by resource and metric name, ketik Error_Rate.

5. Klik Kubernetes Container > Logs-Based Metric. Pilih logging/user/Error_Rate_SLI dan klik Apply.

Layar Anda akan terlihat seperti ini:

6. Tetapkan Rolling windows function ke Rate.

7. Klik Next.

8. Tetapkan 0.5 sebagai Threshold value Anda.

Seperti yang diharapkan, tidak ada kegagalan, dan aplikasi Anda memenuhi Tujuan Tingkat Layanan (SLO) ketersediaannya.

9. Klik Next lagi.

10. Nonaktifkan Use notification channel.

11. Berikan nama pemberitahuan, misalnya Error Rate SLI, lalu klik Next.

12. Tinjau pemberitahuan tersebut, lalu klik Create Policy.

Catatan: Anda tidak akan membuat saluran notifikasi untuk lab ini, tetapi untuk aplikasi yang berjalan di tahap produksi, sebaiknya Anda membuatnya agar Anda dapat mengirim notifikasi melalui email, aplikasi seluler, SMS, Pub/Sub, dan webhook.

Klik Periksa progres saya untuk memverifikasi tujuan. Membuat kebijakan pemberitahuan

Memicu error aplikasi

Sekarang Anda akan menggunakan penghasil beban untuk membuat traffic bagi aplikasi web Anda. Karena ada bug yang sengaja dimasukkan ke dalam versi aplikasi ini, sejumlah tertentu volume traffic akan memicu error. Anda akan mempelajari langkah-langkah untuk mengidentifikasi dan memperbaiki bug ini.

1. Dari Navigation menu, pilih Kubernetes Engine, lalu Gateways,Services & Ingress dan klik tab Services.

2. Cari service loadgenerator-external, lalu klik link endpoints.

Sebagai alternatif, Anda dapat membuka tab atau jendela browser baru, menyalin/menempel IP-nya ke kolom URL, misalnya: http://\[loadgenerator-external-ip\]

Anda akan berada di halaman alat penghasil beban Locust:

Locust adalah penghasil beban open source, yang memungkinkan Anda melakukan uji beban atas aplikasi web. Locust dapat menyimulasikan sejumlah pengguna yang secara bersamaan mengakses endpoint aplikasi Anda dengan laju tertentu.

1. Simulasikan 300 pengguna yang mengakses aplikasi dengan laju kemunculan baru 30. Locust akan menambahkan 30 pengguna per detik hingga mencapai 300 pengguna.

2. Untuk kolom host, Anda akan menggunakan frontend-external. Salin URL dari halaman Gateways,Services & Ingress. Pastikan untuk mengecualikan port. Contoh:

3. Klik tombol Start swarming. Dalam beberapa detik, sekitar 300 pengguna akan mengakses URL yang telah ditentukan sebelumnya.

4. Klik tab Failures untuk melihat kegagalan yang mulai terjadi. Anda dapat melihat ada banyak error 500.

Sementara itu, jika Anda mengklik produk apa pun dari halaman beranda, responsnya akan lebih lambat atau Anda menerima error seperti berikut ini:

Mengonfirmasi pemberitahuan dan error aplikasi

1. Di konsol, dari Navigation menu, klik Monitoring, lalu Alerting. Sebentar lagi, Anda seharusnya akan melihat insiden terkait logging/user/Error_Rate_SLI. Jika Anda tidak langsung melihat insiden, tunggu satu atau dua menit, lalu muat ulang halaman Anda. Munculnya pemberitahuan dapat memakan waktu hingga 5 menit.

2. Klik link insiden:

Anda akan dibawa Anda ke halaman detail.

3. Di bagian Logs, klik View in Logs Explorer dan pilih ID project dari dropdown untuk melihat log pod.

4. Anda juga dapat mengklik label Error di panel penjelajah kolom Logs untuk hanya mengkueri error.

Anda juga dapat mengklik kolom Query preview untuk menampilkan builder kueri, lalu klik dropdown Severity, tambahkan Error ke kueri. Klik tombol Add, lalu klik Run Query. Menu dropdown memungkinkan penambahan beberapa nilai tingkat keparahan.

Hasilnya adalah penambahan severity=ERROR ke kueri Anda. Setelah melakukannya, Anda akan mendapatkan semua error untuk pod recommendationservice.

5. Lihat detail error dengan meluaskan peristiwa error. Contoh:

6. Luaskan textPayload.

7. Klik pesan error dan pilih Add field to summary line agar pesan error muncul sebagai kolom ringkasan:

Dari sana, Anda dapat mengonfirmasi bahwa memang ada banyak error untuk service RecommendationService. Berdasarkan pesan error, tampaknya RecommendationService tidak dapat terhubung ke beberapa layanan downstream untuk mendapatkan produk atau rekomendasi. Namun, penyebab utama error ini masih belum jelas.

Jika Anda melihat kembali diagram arsitektur, RecommendationService menyediakan daftar rekomendasi untuk service Frontend. Namun, service Frontend dan RecommendationService memanggil ProductCatalogService untuk mendapatkan daftar produk.

Untuk langkah berikutnya, Anda akan melihat metrik yang menjadi tersangka utama, ProductCatalogService, untuk mencari anomali. Terlepas dari itu, Anda dapat melihat perincian log untuk mendapatkan informasi yang bermanfaat.

Memecahkan masalah menggunakan dasbor & log Kubernetes

1. Salah satu hal pertama yang dapat Anda lihat metriknya adalah bagian Kubernetes Engine dari konsol Monitoring (Navigation menu > Monitoring> Dashboards > GKE).

2. Lihat bagian Workloads.

3. Buka Kubernetes Engine > Workloads > productcatalogservice. Anda dapat melihat bahwa pod untuk service ini terus-menerus mengalami crash dan memulai ulang.

Selanjutnya, lihat apakah ada informasi menarik di log.

Ada 2 cara untuk mengakses log container Anda dengan mudah:

1. Klik tab Logs untuk melihat log terbaru dengan cepat. Selanjutnya, klik tombol link eksternal di sudut kanan atas panel log untuk kembali ke Logs Explorer.

2. Di halaman overview, klik link Container logs di halaman Deployment Details.

Anda kembali ke halaman Logs Explorer, sekarang dengan kueri yang telah ditentukan sebelumnya dan difilter secara khusus untuk log dari container yang Anda lihat di GKE.

Dari Logs Viewer, pesan log dan histogram menunjukkan bahwa container berulang kali mengurai katalog produk dalam jangka waktu yang singkat. Sepertinya sangat tidak efisien.

Di bagian bawah hasil kueri, mungkin juga terdapat error runtime seperti yang berikut ini:

panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation

Hal ini sebenarnya dapat menyebabkan pod mengalami error.

Untuk lebih memahami alasannya, telusuri pesan log dalam kode.

1. Jalankan perintah berikut di Cloud Shell:

grep -nri 'successfully parsed product catalog json' src

Output Anda akan terlihat seperti berikut, yang memiliki nama file sumber dengan nomor baris:

src/productcatalogservice/server.go:237: log.Info("successfully parsed product catalog json")

2. Untuk melihat file sumber, klik tombol Open Editor di menu Cloud Shell, lalu Open in New Window (jika Anda melihat error "Unable to load code editor because third-party cookies are disabled", klik ikon mata di bagian atas halaman Chrome).

3. Klik file microservices-demo/src/productcatalogservice/server.go, scroll ke bawah ke baris 237, dan Anda akan melihat bahwa metode readCatalogFile mencatat pesan ini:

Dengan sedikit usaha, Anda dapat melihat bahwa jika variabel boolean reloadCatalog bernilai true, service akan memuat ulang dan mengurai katalog produk setiap kali dipanggil, yang tampaknya tidak perlu.

Jika Anda menelusuri variabel reloadCatalog dalam kode, Anda dapat melihat bahwa variabel ini dikontrol oleh variabel lingkungan ENABLE_RELOAD dan menulis pesan log untuk statusnya.

Periksa log lagi dengan menambahkan pesan ini ke kueri Anda dan tentukan apakah ada entri yang ditemukan.

1. Kembali ke tab tempat Logs Explorer terbuka dan tambahkan baris berikut ke kueri:

jsonPayload.message:"catalog reloading"

Jadi, kueri lengkap di query builder Anda adalah:

resource.type="k8s_container" resource.labels.location="{{{project_0.startup_script.zone | ZONE}}}" resource.labels.cluster_name="central" resource.labels.namespace_name="default" labels.k8s-pod/app="productcatalogservice" jsonPayload.message:"catalog reloading"

2. Klik Run Query lagi dan temukan pesan "Enable catalog reloading" di log container. Hal ini mengonfirmasi bahwa fitur pemuatan ulang katalog diaktifkan.

Pada titik ini, Anda dapat memastikan bahwa error frontend disebabkan oleh overhead untuk memuat katalog untuk setiap permintaan. Saat Anda meningkatkan beban, overhead menyebabkan service gagal dan menghasilkan error.

Tugas 6. Memperbaiki masalah dan memverifikasi hasilnya

Berdasarkan kode dan yang Anda lihat di dalam log, Anda dapat mencoba memperbaiki masalah dengan menonaktifkan pemuatan ulang katalog. Sekarang Anda akan menghapus variabel lingkungan ENABLE_RELOAD untuk service katalog produk. Setelah membuat perubahan variabel tersebut, Anda dapat men-deploy ulang aplikasi dan memverifikasi bahwa perubahan tersebut telah mengatasi masalah yang diamati.

1. Klik tombol Open Terminal untuk kembali ke terminal Cloud Shell jika sudah ditutup.

2. Jalankan perintah berikut:

grep -A1 -ni ENABLE_RELOAD release/kubernetes-manifests.yaml

Output akan menampilkan nomor baris variabel lingkungan dalam file manifes:

373: - name: ENABLE_RELOAD 374- value: "1"

3. Hapus kedua baris tersebut untuk menonaktifkan pemuatan ulang dengan menjalankan:

sed -i -e '373,374d' release/kubernetes-manifests.yaml

4. Kemudian terapkan kembali file manifes:

kubectl apply -f release/kubernetes-manifests.yaml

Anda akan melihat bahwa hanya productcatalogservice yang dikonfigurasi. Service lainnya tidak berubah.

5. Kembali ke halaman Deployment details (Navigation menu > Kubernetes Engine > Workloads > productcatalogservice), dan tunggu hingga pod berhasil berjalan. Tunggu 2-3 menit atau sampai Anda dapat memastikan bahwa aplikasi tidak lagi mengalami error.

6. Jika Anda mengklik link Container logs lagi, Anda akan melihat pesan successfully parsing the catalog json yang berulang sudah tidak ada:

7. Jika Anda kembali ke URL aplikasi web dan mengklik produk di halaman beranda, aplikasi ini juga sudah jauh lebih responsif dan seharusnya Anda tidak akan menemukan error HTTP apa pun.

8. Kembali ke penghasil beban, klik tombol Reset Stats di kanan atas. Persentase kegagalan direset dan seharusnya Anda tidak akan melihat peningkatan kegagalan lagi.

Semua pemeriksaan di atas menunjukkan bahwa masalah telah diperbaiki. Jika Anda masih melihat error 500, tunggu beberapa menit lagi dan coba klik produk lagi.

Selamat!

Anda telah menggunakan Cloud Logging dan Cloud Monitoring untuk menemukan error dalam versi aplikasi microservices demo yang sengaja diberikan kesalahan konfigurasi. Ini adalah proses pemecahan masalah yang serupa dengan yang akan Anda gunakan untuk mempersempit kemungkinan penyebab masalah pada aplikasi GKE Anda di lingkungan produksi.

Pertama, Anda men-deploy aplikasi ke GKE, lalu menyiapkan metrik dan pemberitahuan untuk error frontend. Selanjutnya, Anda membuat beban dan kemudian melihat bahwa pemberitahuan dipicu. Dari pemberitahuan, Anda mempersempit kemungkinan penyebab masalah ke service tertentu menggunakan Cloud Logging. Kemudian, Anda menggunakan Cloud Monitoring dan UI GKE untuk melihat metrik service GKE. Untuk memperbaiki masalah ini, Anda kemudian men-deploy konfigurasi yang diperbarui ke GKE dan mengonfirmasi bahwa perbaikan tersebut mengatasi error dalam log.

Langkah berikutnya/Pelajari lebih lanjut

• Lab ini didasarkan pada postingan blog ini tentang penggunaan Logging untuk aplikasi yang berjalan di GKE.
• Ada baiknya Anda juga membaca Postingan lanjutan ini tentang cara tim DevOps menggunakan Cloud Monitoring dan Logging untuk menemukan masalah dengan cepat.

Sertifikasi dan pelatihan Google Cloud

...membantu Anda mengoptimalkan teknologi Google Cloud. Kelas kami mencakup keterampilan teknis dan praktik terbaik untuk membantu Anda memahami dengan cepat dan melanjutkan proses pembelajaran. Kami menawarkan pelatihan tingkat dasar hingga lanjutan dengan opsi on demand, live, dan virtual untuk menyesuaikan dengan jadwal Anda yang sibuk. Sertifikasi membantu Anda memvalidasi dan membuktikan keterampilan serta keahlian Anda dalam teknologi Google Cloud.

Manual Terakhir Diperbarui pada 21 Februari 2025

Lab Terakhir Diuji pada 21 Februari 2025

Hak cipta 2025 Google LLC. Semua hak dilindungi undang-undang. Google dan logo Google adalah merek dagang dari Google LLC. Semua nama perusahaan dan produk lain mungkin adalah merek dagang masing-masing perusahaan yang bersangkutan.