Memecahkan masalah log yang tidak ada di GKE

Masalah pada pipeline logging di Google Kubernetes Engine (GKE) dapat mencegah log cluster Anda muncul di Cloud Logging, sehingga menghambat upaya pemantauan dan pen-debug-an Anda.

Gunakan dokumen ini untuk mempelajari cara memverifikasi konfigurasi dan izin, menyelesaikan masalah performa dan resource, menyelidiki filter dan perilaku aplikasi, serta mengatasi masalah platform atau layanan yang memengaruhi log Anda.

Informasi ini penting bagi admin dan operator Platform yang mempertahankan kemampuan observasi cluster dan bagi siapa pun yang menggunakan Cloud Logging untuk memecahkan masalah operasi GKE. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas yang kami referensikan dalam konten, lihat Peran dan tugas pengguna GKE umum. Google Cloud

Untuk mengetahui informasi selengkapnya tentang cara menggunakan log untuk memecahkan masalah workload dan cluster, lihat Melakukan analisis historis dengan Cloud Logging.

Temukan solusi Anda berdasarkan gejala

Jika Anda telah mengidentifikasi gejala tertentu yang terkait dengan log yang hilang, gunakan tabel berikut untuk menemukan saran pemecahan masalah:

Kategori Gejala atau pengamatan Kemungkinan penyebab Langkah pemecahan masalah
Konfigurasi Tidak ada log dari cluster mana pun dalam project yang terlihat. Cloud Logging API dinonaktifkan untuk project. Verifikasi status Cloud Logging API
Log tidak ada dari cluster tertentu, atau hanya jenis log tertentu yang tidak ada. Logging tingkat cluster dinonaktifkan untuk jenis log yang diperlukan. Memverifikasi konfigurasi logging cluster
Log tidak ada dari node di node pool tertentu. Node di node pool tidak memiliki cakupan akses yang diperlukan. Memverifikasi cakupan akses node pool
Error izin (401 atau 403) muncul di log agen pencatatan. Akun layanan node tidak memiliki izin yang diperlukan. Memverifikasi izin akun layanan node
Resource dan performa Log hilang secara berkala, atau Anda melihat error RESOURCE_EXHAUSTED. Project melampaui kuota penulisan Cloud Logging API. Menyelidiki penggunaan kuota Cloud Logging API
Beberapa log dari node tertentu tidak ada, sering kali selama traffic atau beban tinggi. Node melebihi batas throughput agen logging, atau tidak memiliki resource (CPU atau memori) untuk memproses log. Menyelidiki throughput node dan penggunaan resource
Pemfilteran dan perilaku aplikasi Log tertentu yang cocok dengan pola tertentu selalu tidak ada. Filter pengecualian log di Cloud Logging secara tidak sengaja menghapus log. Menyelidiki filter pengecualian log
Log dari penampung tertunda secara signifikan atau hanya muncul setelah penampung keluar. Output aplikasi di-buffer sepenuhnya, sering kali karena stdout. Menyelidiki penampungan dan penundaan log penampung
Log yang diharapkan tidak muncul di hasil penelusuran. Filter kueri di Logs Explorer mungkin terlalu ketat. Menyelidiki kueri Logs Explorer
Tidak ada log yang terlihat dari Pod aplikasi tertentu, tetapi log cluster lainnya ada. Aplikasi di dalam container tidak menulis ke stdout atau stderr. Menyelidiki perilaku logging spesifik per aplikasi
Platform dan layanan Log yang lebih lama dari tanggal tertentu tidak muncul. Log telah melewati periode retensinya dan telah dihapus oleh Cloud Logging. Menyelidiki periode retensi log
Kehilangan atau penundaan log yang meluas di seluruh project atau cluster. Masalah layanan Cloud Logging atau penundaan penyerapan. Menyelidiki masalah dan keterlambatan layanan Cloud Logging
Masalah logging bertepatan dengan batasan versi cluster. Versi GKE tidak didukung. Menyelidiki versi cluster

Menggunakan alat diagnostik otomatis

Bagian berikut membahas alat yang dapat memeriksa cluster Anda secara otomatis untuk menemukan kesalahan konfigurasi umum dan membantu menyelidiki masalah yang kompleks.

Men-debug masalah logging GKE dengan gcpdiag

Jika Anda kehilangan atau mendapatkan log yang tidak lengkap dari cluster GKE, gunakan alat gcpdiag untuk memecahkan masalah.

gcpdiag adalah alat open source. Ini bukan produk Google Cloud yang didukung secara resmi. Anda dapat menggunakan alat gcpdiag untuk membantu mengidentifikasi dan memperbaiki masalah project Google Cloud. Untuk mengetahui informasi selengkapnya, lihat project gcpdiag di GitHub.

Jika log dari cluster GKE tidak ada atau tidak lengkap, selidiki kemungkinan penyebabnya dengan berfokus pada setelan konfigurasi inti berikut:

  • Logging tingkat project: memastikan bahwa project yang menghosting cluster GKE telah mengaktifkan Cloud Logging API. Google Cloud
  • Logging tingkat cluster: memverifikasi bahwa logging diaktifkan secara eksplisit dalam konfigurasi cluster GKE.
  • Izin node pool: mengonfirmasi bahwa node dalam node pool cluster telah mengaktifkan cakupan Cloud Logging Write, sehingga node tersebut dapat mengirim data log.
  • Izin akun layanan: memvalidasi bahwa akun layanan yang digunakan oleh node pool memiliki izin IAM yang diperlukan untuk berinteraksi dengan Cloud Logging. Secara khusus, peran roles/logging.logWriter biasanya diperlukan.
  • Kuota penulisan API Cloud Logging: memverifikasi bahwa kuota Penulisan API Cloud Logging belum terlampaui dalam jangka waktu yang ditentukan.

KonsolGoogle Cloud

  1. Lengkapi, lalu salin perintah berikut. 
    2. gcpdiag runbook gke/logs \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=LOCATION
  2. Buka Google Cloud konsol dan aktifkan Cloud Shell.
    3. Buka Konsol Cloud
  3. Tempelkan perintah yang disalin.
  4. Jalankan perintah gcpdiag, yang mendownload image Docker gcpdiag, lalu melakukan pemeriksaan diagnostik. Jika berlaku, ikuti petunjuk output untuk memperbaiki pemeriksaan yang gagal.

Docker

Anda dapat menjalankan gcpdiag menggunakan wrapper yang memulai gcpdiag dalam container Docker. Docker atau Podman harus diinstal.

  1. Salin dan jalankan perintah berikut di workstation lokal Anda. 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Jalankan perintah gcpdiag. 
    ./gcpdiag runbook gke/logs \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=LOCATION

Lihat parameter yang tersedia untuk runbook ini.

Ganti kode berikut:

  • PROJECT_ID: ID project yang berisi resource.
  • CLUSTER_NAME: nama cluster GKE.
  • LOCATION: region atau zona Compute Engine (misalnya, us-central1 atau us-central1-a) untuk cluster.

Flag yang berguna:

Untuk mengetahui daftar dan deskripsi semua flag alat gcpdiag, lihat petunjuk penggunaan gcpdiag.

Menggunakan investigasi Gemini Cloud Assist

Pertimbangkan untuk menggunakan investigasi Gemini Cloud Assist untuk mendapatkan insight tambahan tentang log Anda dan menyelesaikan masalah. Untuk mengetahui informasi selengkapnya tentang berbagai cara untuk memulai investigasi menggunakan Logs Explorer, lihat Memecahkan masalah terkait Investigasi Gemini Cloud Assist di dokumentasi Gemini.

Memverifikasi konfigurasi dan izin logging

Setelan yang salah adalah alasan umum mengapa log GKE tidak ada. Gunakan bagian berikut untuk memverifikasi konfigurasi Cloud Logging Anda.

Memverifikasi status Cloud Logging API

Agar log dikumpulkan dari cluster mana pun di project Anda, Cloud Logging API harus aktif.

Gejala:

Tidak ada log dari resource GKE di project Anda yang terlihat di Cloud Logging.

Penyebab:

Cloud Logging API dinonaktifkan untuk project Google Cloud , sehingga mencegah agen logging di node mengirim log.

Resolusi:

Untuk memverifikasi bahwa Cloud Logging API telah diaktifkan dan mengaktifkannya jika perlu, pilih salah satu opsi berikut:

Konsol

  1. Di konsol Google Cloud , buka halaman Enabled APIs & services.

    Buka Enabled APIs & services

  2. Di kolom Filter, ketik Cloud Logging API, lalu tekan Enter.

  3. Jika API diaktifkan, Anda akan melihatnya tercantum. Jika API tidak tercantum, aktifkan API tersebut:

    1. Klik Enable APIs and services.
    2. Di kolom Search, ketik Cloud Logging API, lalu tekan Enter.
    3. Klik hasil Cloud Logging API.
    4. Klik Enable.

gcloud

  1. Periksa apakah API diaktifkan:

    gcloud services list --enabled --filter="NAME=logging.googleapis.com"

    Output harus berupa yang berikut ini:

    NAME: logging.googleapis.com
TITLE: Cloud Logging API

  2. Jika API tidak tercantum dalam layanan yang diaktifkan, aktifkan API tersebut:

    gcloud services enable logging.googleapis.com \
    --project=PROJECT_ID

    Ganti PROJECT_ID dengan ID project Google Cloud Anda.

Memverifikasi konfigurasi logging cluster

GKE memungkinkan Anda mengonfigurasi jenis log yang dikumpulkan dari cluster (seperti SYSTEM atau WORKLOAD).

Gejala:

Tidak ada log yang muncul di Cloud Logging dari cluster GKE tertentu, atau hanya jenis log tertentu (seperti SYSTEM) yang tidak ada.

Penyebab:

Logging tingkat cluster dinonaktifkan untuk jenis log yang diperlukan. Jika Anda menggunakan cluster Autopilot, hal ini bukan penyebab masalah logging Anda. Setelan ini dapat dikonfigurasi untuk cluster Standard, tetapi selalu diaktifkan secara default di cluster Autopilot dan tidak dapat dinonaktifkan.

Resolusi:

Untuk memeriksa dan memperbarui konfigurasi logging cluster, pilih salah satu opsi berikut:

Konsol

  1. Di konsol Google Cloud , buka halaman Kubernetes clusters.

    Buka cluster Kubernetes

  2. Klik nama cluster yang ingin Anda selidiki.

  3. Klik tab Detail dan buka bagian Fitur.

  4. Di baris Logging, tinjau jenis log yang diaktifkan, seperti System atau Workloads.

  5. Jika jenis log yang ingin Anda kumpulkan dinonaktifkan atau salah, klik Edit Logging.

  6. Dalam daftar Components, centang kotak untuk jenis log yang ingin Anda kumpulkan, lalu klik OK. Untuk mengetahui informasi selengkapnya tentang jenis log yang tersedia, lihat Tentang log GKE.

  7. Klik Simpan Perubahan.

gcloud

  1. Untuk memeriksa konfigurasi logging, deskripsikan cluster:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(name,loggingConfig.componentConfig.enableComponents)"

    Ganti kode berikut:

    • CLUSTER_NAME: nama cluster Anda.
    • LOCATION: region atau zona Compute Engine (misalnya, us-central1 atau us-central1-a) untuk cluster.
    • PROJECT_ID: Google Cloud Project ID Anda.

    Jika logging diaktifkan, output-nya akan mirip dengan berikut ini:

    example-cluster    SYSTEM_COMPONENTS;WORKLOADS

    Jika outputnya adalah NONE, berarti logging dinonaktifkan.

  2. Jika jenis log yang Anda inginkan dinonaktifkan atau salah, perbarui konfigurasi logging:

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --logging=LOGGING_TYPE

    Ganti LOGGING_TYPE dengan SYSTEM, WORKLOAD, atau keduanya. Untuk mengumpulkan log apa pun, SYSTEM harus diaktifkan. Log WORKLOAD tidak dapat dikumpulkan sendiri. Untuk mengetahui informasi selengkapnya tentang jenis log yang tersedia, lihat Tentang log GKE.

Memverifikasi cakupan akses node pool

Node dalam cluster GKE menggunakan cakupan akses OAuth untuk mendapatkan izin guna berinteraksi dengan Google Cloud API, termasuk Cloud Logging.

Gejala:

Log tidak ada dari node di node pool tertentu.

Penyebab:

Node di kumpulan node tidak memiliki cakupan akses OAuth yang diperlukan. Salah satu cakupan berikut diperlukan bagi node untuk menulis log ke Cloud Logging:

  • https://www.googleapis.com/auth/logging.write: memberikan izin untuk menulis log. Ini adalah cakupan minimum yang diperlukan.
  • https://www.googleapis.com/auth/logging.admin: memberikan akses penuh ke Cloud Logging API, yang mencakup izin dari logging.write.
  • https://www.googleapis.com/auth/cloud-platform: memberikan akses penuh ke semua API yang diaktifkan Google Cloud , yang mencakup izin dari logging.write.

Resolusi:

Untuk memverifikasi izin dan memberikan peran yang diperlukan jika tidak ada, pilih salah satu opsi berikut:

Konsol

  1. Verifikasi cakupan akses node pool:

    1. Di konsol Google Cloud , buka halaman Kubernetes clusters.

      Buka cluster Kubernetes

    2. Untuk membuka halaman detail cluster, klik nama cluster yang ingin Anda selidiki.

    3. Klik tab Nodes.

    4. Di bagian Node Pools, klik nama node pool yang ingin Anda selidiki.

    5. Buka bagian Security.

    6. Tinjau cakupan yang tercantum di kolom Cakupan akses. Pastikan setidaknya salah satu cakupan yang diperlukan ada:

      • Stackdriver Logging API - Hanya Tulis
      • Stackdriver Logging API - Penuh
      • Cloud Platform - Diaktifkan

      Jika cakupan yang diperlukan tidak ada, buat ulang node pool. Anda tidak dapat mengubah cakupan akses pada node pool yang ada.

  2. Jika diperlukan, buat node pool baru dengan cakupan yang diperlukan:

    1. Kembali ke halaman detail cluster untuk cluster yang ingin diubah.
    2. Klik tab Nodes.
    3. Klik Create user-managed node pool.
    4. Isi bagian Node pool details.
    5. Di navigasi kiri, klik Keamanan.
    6. Di bagian Cakupan akses, pilih peran yang ingin Anda tambahkan:
      • Untuk menambahkan cakupan tertentu, pilih Tetapkan akses untuk setiap API.
      • Untuk mengizinkan akses penuh, pilih Izinkan akses penuh ke semua Cloud API.
    7. Konfigurasi bagian lainnya sesuai kebutuhan.
    8. Klik Buat.

  3. Migrasikan workload Anda ke node pool baru. Setelah Anda memigrasikan workload ke node pool baru, aplikasi Anda akan berjalan di node yang memiliki cakupan yang diperlukan untuk mengirim log ke Cloud Logging.

  4. Hapus node pool lama:

    1. Kembali ke halaman detail cluster dan pilih tab Nodes.
    2. Di bagian Node Pools, temukan node pool lama.
    3. Di samping node pool, klik Hapus .
    4. Saat diminta, konfirmasi penghapusan dengan mengetikkan nama kumpulan node dan klik Hapus.

gcloud

  1. Verifikasi cakupan akses node pool:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(nodePools[].name,nodePools[].config.oauthScopes)"

    Ganti kode berikut:

    • CLUSTER_NAME: nama cluster Anda.
    • LOCATION: region atau zona Compute Engine (misalnya, us-central1 atau us-central1-a) untuk cluster.
    • PROJECT_ID: Google Cloud Project ID Anda.

    Tinjau output untuk setiap node pool. Pastikan setidaknya salah satu cakupan yang diperlukan (https://www.googleapis.com/auth/logging.write, https://www.googleapis.com/auth/cloud-platform, atau https://www.googleapis.com/auth/logging.admin) tercantum. Jika cakupan yang diperlukan tidak ada, buat ulang node pool. Anda tidak dapat mengubah cakupan akses pada node pool yang ada.

  2. Jika diperlukan, buat node pool baru dengan cakupan yang diperlukan:

    gcloud container node-pools create NEW_NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --scopes=https://www.googleapis.com/auth/logging.write,OTHER_SCOPES

    Ganti kode berikut:

    • NEW_NODE_POOL_NAME: nama untuk node pool baru.
    • OTHER_SCOPES: daftar yang dipisahkan koma untuk cakupan lain yang diperlukan node Anda. Jika Anda tidak memerlukan cakupan lain, hapus placeholder ini dan koma sebelumnya.

  3. Migrasikan workload Anda ke node pool baru. Setelah Anda memigrasikan workload ke node pool baru, aplikasi Anda akan berjalan di node yang memiliki cakupan yang diperlukan untuk mengirim log ke Cloud Logging.

  4. Hapus node pool lama:

    gcloud container node-pools delete OLD_NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID

Memverifikasi izin akun layanan node

Node menggunakan akun layanan untuk mengautentikasi dengan layanan Google Cloud , dan akun ini memerlukan izin IAM tertentu untuk menulis log.

Gejala:

  • Log tidak ada di node.
  • Memeriksa log agen logging (misalnya, Fluent Bit) dapat menampilkan error terkait izin, seperti kode 401 atau 403 saat mencoba menulis ke Cloud Logging.
  • Anda mungkin melihat notifikasi Grant Critical Permissions to Node Service Account untuk cluster di konsol Google Cloud .

Penyebab:

Akun layanan yang digunakan oleh node pool tidak memiliki izin IAM yang diperlukan untuk menulis log ke Cloud Logging. Node memerlukan akun layanan dengan peran logging.logWriter, yang mencakup izin logging.logEntries.create.

Selain itu, untuk GKE versi 1.33 atau yang lebih baru, Agen Layanan Node Default GKE (service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com) harus memiliki peran Agen Layanan Node Default Kubernetes (roles/container.defaultNodeServiceAgent) minimal. Peran ini memungkinkan GKE mengelola resource dan operasi node, termasuk komponen logging.

Resolusi:

Untuk memverifikasi izin dan memberikan peran yang diperlukan jika tidak ada, lakukan hal berikut:

  • Verifikasi izin akun layanan node.
  • Pastikan agen layanan GKE memiliki peran yang diperlukan.

Memverifikasi izin akun layanan node

Akun layanan node adalah akun yang digunakan node Anda untuk mengautentikasi dan mengirim log. Untuk mengidentifikasi akun layanan ini dan memverifikasi bahwa akun layanan tersebut memiliki izin roles/logging.logWriter yang diperlukan, lakukan hal berikut:

  1. Untuk mengidentifikasi akun layanan yang digunakan oleh node pool, pilih salah satu opsi berikut:

    Konsol

    1. Di konsol Google Cloud , buka halaman Kubernetes clusters.

      Buka cluster Kubernetes

    2. Di daftar cluster, klik nama cluster yang ingin Anda periksa.

    3. Bergantung pada mode operasi cluster, lakukan salah satu hal berikut:

      • Untuk cluster Standard, lakukan hal berikut:

        1. Klik tab Nodes.
        2. Di tabel Node pool, klik nama node pool. Halaman detail Node pool akan terbuka.
        3. Di bagian Security, temukan kolom Service account.

      • Untuk cluster Autopilot, lakukan hal berikut:

        1. Buka tab Detail.
        2. Di bagian Security, temukan kolom Service account.

      Jika nilai di kolom Service account adalah default, node Anda menggunakan akun layanan default Compute Engine. Jika nilai di kolom ini bukan default, node Anda menggunakan akun layanan kustom. Untuk memberikan peran yang diperlukan ke akun layanan kustom, lihat Menggunakan akun layanan IAM dengan hak istimewa terendah.

    gcloud

    Jalankan perintah berikut, bergantung pada jenis cluster yang Anda gunakan:

    Cluster standar 

    gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(config.serviceAccount)"

    Ganti kode berikut:

    • NODE_POOL_NAME: nama node pool.
    • CLUSTER_NAME: nama cluster Standard Anda.
    • LOCATION: region atau zona Compute Engine (misalnya, us-central1 atau us-central1-a) untuk cluster.
    • PROJECT_ID: ID project Google Cloud Anda.

    Jika outputnya adalah default, berarti node pool menggunakan akun layanan default Compute Engine. Jika nilainya bukan default, node Anda menggunakan akun layanan kustom. Untuk memberikan peran yang diperlukan ke akun layanan kustom, lihat Menggunakan akun layanan IAM dengan hak istimewa terendah.

    Cluster Autopilot 

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(nodePoolDefaults.nodeConfigDefaults.serviceAccount)"

    Ganti kode berikut:

    • CLUSTER_NAME: nama cluster Autopilot Anda.
    • LOCATION: region atau zona Compute Engine (misalnya, us-central1 atau us-central1-a) untuk cluster.
    • PROJECT_ID: Google Cloud Project ID Anda.

    Jika outputnya adalah default, berarti node pool menggunakan akun layanan default Compute Engine. Jika nilainya bukan default, node Anda menggunakan akun layanan kustom. Untuk memberikan peran yang diperlukan ke akun layanan kustom, lihat Menggunakan akun layanan IAM dengan hak istimewa terendah.

    Untuk skrip yang lebih mendetail guna mengidentifikasi izin yang tidak ada, lihat Mengidentifikasi semua akun layanan node yang tidak memiliki izin.

  2. GKE secara otomatis memindai izin yang tidak ada dan memberikan rekomendasi. Untuk menggunakan rekomendasi guna memeriksa izin yang tidak ada, pilih salah satu opsi berikut:

    Konsol

    1. Di halaman Kubernetes clusters, cari kolom Notifications.
    2. Periksa kolom Notifikasi untuk rekomendasi Beri izin penting. Rekomendasi ini berarti pemeriksaan NODE_SA_MISSING_PERMISSIONS telah gagal.
    3. Jika rekomendasi ada, klik rekomendasi tersebut. Panel detail akan terbuka, menjelaskan izin yang tidak ada dan memberikan langkah-langkah untuk memperbaikinya.

    gcloud

    1. Mencantumkan rekomendasi untuk izin akun layanan yang tidak ada:

      gcloud recommender recommendations list \
    --recommender=google.container.DiagnosisRecommender \
    --location LOCATION \
    --project PROJECT_ID \
    --format yaml \
    --filter="recommenderSubtype:NODE_SA_MISSING_PERMISSIONS"

    2. Analisis output perintah:

      • Jika perintah menampilkan daftar kosong, berarti recommender belum menemukan rekomendasi NODE_SA_MISSING_PERMISSIONS yang aktif. Akun layanan yang diperiksa tampaknya memiliki izin yang diperlukan.

      • Jika perintah menampilkan satu atau beberapa blok YAML, berarti recommender telah mengidentifikasi masalah izin. Tinjau output untuk kolom utama berikut:

        • description: memberikan ringkasan masalah, seperti menentukan bahwa akun layanan node Anda tidak memiliki peran roles/logging.logWriter atau bahwa agen layanan GKE tidak memiliki peran roles/container.defaultNodeServiceAgent.
        • resource: menentukan cluster yang terpengaruh.
        • content.operations: berisi resolusi yang direkomendasikan. Bagian ini memberikan perintah gcloud projects add-iam-policy-binding yang tepat yang diperlukan untuk memberikan peran tertentu yang tidak ada.

    Pemberi rekomendasi dapat memerlukan waktu hingga 24 jam untuk mencerminkan perubahan terbaru.

  3. Jika Anda ingin segera memverifikasi izin, untuk memeriksa izin dan memberikan peran, pilih salah satu opsi berikut:

    Konsol

    1. Di konsol Google Cloud , buka halaman IAM.

      Buka IAM

    2. Temukan akun layanan yang digunakan oleh node pool.

    3. Di kolom Role, periksa apakah akun layanan memiliki peran Logs Writer (roles/logging.logWriter).

    4. Jika izin tidak ada, tambahkan:

      1. Klik Edit akun utama
      2. Klik Add another role.
      3. Di kolom penelusuran, masukkan Logs Writer.
      4. Centang kotak Logs Writer, lalu klik Apply.
      5. Klik Simpan.

    gcloud

    1. Periksa peran saat ini untuk akun layanan node:

      gcloud projects get-iam-policy PROJECT_ID \
    --flatten="bindings[].members" \
    --format='table(bindings.role)' \
    --filter="bindings.members:serviceAccount:SERVICE_ACCOUNT_EMAIL"

    2. Jika tidak ada, berikan peran logging.logWriter:

      gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/logging.logWriter"

Memverifikasi izin agen layanan GKE

Jika log masih tidak ada, dan Anda menggunakan versi 1.33 atau yang lebih baru, verifikasi bahwa agen yang dikelola Google yang digunakan GKE untuk mengelola komponen node Anda memiliki izin yang diperlukan:

  1. Untuk mengidentifikasi alamat email agen layanan, dapatkan nomor project Anda:

    gcloud projects describe PROJECT_ID --format="value(projectNumber)"

    Ganti PROJECT_ID dengan project ID Anda. Perhatikan outputnya.

    Email GKE Service Agent adalah: service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com

  2. Untuk menggunakan rekomendasi guna memeriksa izin yang tidak ada, pilih salah satu opsi berikut:

    Konsol

    1. Di halaman Kubernetes clusters, temukan kolom Notifications.
    2. Periksa kolom untuk melihat rekomendasi Berikan izin penting.
    3. Jika rekomendasi ada, klik rekomendasi tersebut. Panel detail akan terbuka, menjelaskan izin yang tidak ada dan memberikan langkah-langkah untuk memperbaikinya.

    gcloud

    1. Mencantumkan rekomendasi untuk izin akun layanan yang tidak ada:

      gcloud recommender recommendations list \
    --recommender=google.container.DiagnosisRecommender \
    --location LOCATION \
    --project PROJECT_ID \
    --format yaml \
    --filter="recommenderSubtype:NODE_SA_MISSING_PERMISSIONS"

    2. Analisis output perintah. Tinjau output untuk mengetahui deskripsi yang menyatakan bahwa agen layanan GKE (gcp-sa-gkenode) tidak memiliki peran roles/container.defaultNodeServiceAgent.

  3. Untuk segera memeriksa izin dan memberikan peran, pilih salah satu opsi berikut:

    Konsol

    1. Di konsol Google Cloud , buka halaman IAM.

      Buka IAM

    2. Di kolom Filter, ketik alamat email Agen Layanan GKE, lalu tekan Enter.

    3. Dalam daftar yang difilter, periksa apakah agen layanan memiliki setidaknya peran Agen Layanan Node Default Kubernetes (roles/container.defaultNodeServiceAgent).

    4. Jika peran tidak ada, berikan peran tersebut:

      1. Klik Edit principal di samping agen layanan.
      2. Klik Tambahkan peran.
      3. Di kolom penelusuran, masukkan Kubernetes Default Node Service Agent, lalu pilih peran.
      4. Klik Simpan.

    gcloud

    1. Pastikan peran roles/container.defaultNodeServiceAgent terikat ke agen layanan:

      gcloud projects get-iam-policy PROJECT_ID \
    --flatten="bindings[].members" \
    --format='table(bindings.role)' \
    --filter="bindings.members:serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com"

      Di output, cari roles/container.defaultNodeServiceAgent.

    2. Jika peran tidak ada, berikan peran Kubernetes Default Node Service Agent:

      gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAgent"

Memecahkan masalah resource dan performa

Jika log hilang secara berkala atau dihapus dari node dengan traffic tinggi, penyebabnya mungkin bukan karena kesalahan konfigurasi, tetapi masalah performa. Gunakan bagian berikut untuk menyelidiki apakah project Anda melampaui kuota API atau apakah volume log yang tinggi membebani agen pada node tertentu.

Menyelidiki penggunaan kuota Cloud Logging API

Untuk melindungi layanan, Cloud Logging menerapkan kuota tulis di semua project, yang membatasi total volume log yang dapat diserap Cloud Logging per menit.

Gejala:

  • Log hilang secara berkala atau sepenuhnya.
  • Anda melihat error RESOURCE_EXHAUSTED terkait logging.googleapis.com di log agen logging atau node.

Penyebab:

Project melebihi kuota permintaan tulis Cloud Logging API. Masalah ini mencegah agen logging mengirim log.

Resolusi:

Untuk memeriksa penggunaan kuota dan meminta penambahan, lakukan hal berikut:

  1. Di konsol Google Cloud , buka halaman Quotas.

    Buka Quotas

  2. Di kolom Filter, ketik Cloud Logging API, lalu tekan Enter.

  3. Dalam daftar yang difilter, temukan kuota untuk Log write bytes per minute per region untuk region tempat cluster Anda berada.

  4. Tinjau nilai di kolom Persentase penggunaan saat ini. Jika penggunaan berada pada atau mendekati batas, Anda mungkin telah melampaui kuota.

  5. Untuk meminta penambahan, klik Edit kuota, lalu ikuti perintahnya. Untuk mengetahui informasi selengkapnya, lihat Melihat dan mengelola kuota.

Untuk mengurangi penggunaan, pertimbangkan untuk mengecualikan log atau mengurangi kejelasan log dari aplikasi. Anda juga dapat menyiapkan kebijakan pemberitahuan agar diberi tahu sebelum mencapai batas.

Menyelidiki throughput node dan penggunaan resource

Agen logging GKE di setiap node memiliki batas throughput sendiri, yang dapat terlampaui.

Gejala:

Log dari node tertentu terkadang hilang atau tertunda, terutama selama periode aktivitas cluster yang tinggi atau penggunaan resource node yang berat.

Penyebab:

Agen logging GKE memiliki batas throughput default (sekitar 100 KBps per node). Jika aplikasi di node menghasilkan log lebih cepat dari batas ini, agen dapat menghapus log, meskipun kuota API keseluruhan project tidak terlampaui. Anda dapat memantau throughput logging node menggunakan metrik kubernetes.io/node/logs/input_bytes di Metrics Explorer.

Log juga mungkin tidak ada jika node mengalami tekanan CPU atau memori yang berat, sehingga tidak ada cukup resource bagi agen untuk memproses log.

Resolusi:

Untuk mengurangi throughput, pilih salah satu opsi berikut:

Cluster standar

Coba solusi berikut:

  • Aktifkan logging throughput tinggi: fitur ini meningkatkan kapasitas per-node. Untuk mengetahui informasi selengkapnya, lihat Menyesuaikan throughput agen Cloud Logging.

  • Mengurangi volume log: menganalisis pola logging aplikasi. Mengurangi logging yang tidak perlu atau terlalu panjang.

  • Men-deploy agen logging kustom: Anda dapat men-deploy dan mengelola DaemonSet Fluent Bit kustom Anda sendiri, tetapi Anda bertanggung jawab atas konfigurasi dan pemeliharaannya.

  • Periksa penggunaan resource node: meskipun volume log berada dalam batas, pastikan node tidak mengalami tekanan CPU atau memori yang berat. Resource node yang tidak memadai dapat menghambat kemampuan agen logging untuk memproses dan mengirim log. Anda dapat memeriksa metrik seperti kubernetes.io/node/cpu/core_usage_time dan kubernetes.io/node/memory/used_bytes di Metrics Explorer.

Cluster Autopilot

Coba solusi berikut:

  • Kurangi volume log: analisis pola logging aplikasi Anda. Mengurangi logging yang tidak perlu atau terlalu panjang. Pastikan log disusun jika memungkinkan, karena jenis log ini dapat membantu pemrosesan yang efisien. Mengecualikan log yang tidak penting.

  • Mengoptimalkan performa aplikasi: karena resource node dikelola di cluster Autopilot, pastikan aplikasi Anda tidak mengonsumsi CPU atau memori secara berlebihan, yang secara tidak langsung dapat memengaruhi performa komponen node seperti agen logging. Meskipun Anda tidak mengelola node secara langsung, efisiensi aplikasi memengaruhi kondisi keseluruhan node.

Memecahkan masalah pemfilteran dan aplikasi

Jika aplikasi Anda berhasil membuat log, tetapi log tersebut tetap tidak muncul di Cloud Logging, masalah ini sering kali disebabkan oleh pemfilteran atau perilaku logging aplikasi. Bagian berikut membahas masalah seperti filter pengecualian log, buffering tingkat penampung, kueri penelusuran yang ketat, dan aplikasi yang tidak menulis ke stdout atau stderr.

Menyelidiki filter pengecualian log

Logs Explorer hanya menampilkan log yang cocok dengan semua filter dalam kueri Anda dan rentang waktu yang dipilih.

Gejala:

Log tertentu yang cocok dengan kriteria tertentu tidak ada di Cloud Logging, tetapi log lain dari sumber yang sama ada.

Penyebab:

Filter pengecualian log ditentukan di sink Cloud Logging Anda (biasanya sink _Default). Aturan ini secara diam-diam menghapus log yang cocok dengan kriteria tertentu, meskipun log tersebut berhasil dikirim oleh node.

Resolusi:

Untuk meninjau dan mengubah filter pengecualian, pilih salah satu opsi berikut:

Konsol

  1. Di konsol Google Cloud , buka halaman Log Router.

    Buka Router Log

  2. Identifikasi filter yang bermasalah:

    1. Untuk setiap sink (selain sink _Required, yang tidak dapat memiliki filter pengecualian), klik Tindakan lainnya, lalu pilih Lihat detail sink.
    2. Tinjau kueri di bagian Filter pengecualian. Bandingkan logika filter dengan atribut log yang hilang (misalnya, jenis resource, label, atau kata kunci).
    3. Salin kueri filter pengecualian.

    4. Buka halaman Logs Explorer.

      Buka Logs Explorer

    5. Tempelkan kueri filter pengecualian ke panel kueri, lalu klik Run query.

    6. Tinjau hasilnya. Log yang ditampilkan adalah log yang akan dikecualikan oleh filter. Jika log yang hilang muncul dalam hasil ini, kemungkinan penyebabnya adalah filter ini.

  3. Menonaktifkan atau mengedit filter:

    1. Kembali ke halaman Logs Router.
    2. Klik More actions untuk sink dengan filter yang dicurigai, lalu pilih Edit sink.
    3. Temukan bagian Choose logs to filter out of sink dan temukan filter pengecualian.
    4. Anda dapat mengklik Nonaktifkan untuk menonaktifkan filter, atau mengubah kuerinya agar lebih spesifik.
    5. Klik Perbarui sink. Perubahan berlaku untuk log baru.

gcloud

  1. Mencantumkan semua sink dalam project:

    gcloud logging sinks list --project=PROJECT_ID

  2. Melihat filter pengecualian setiap tujuan:

    gcloud logging sinks describe SINK_NAME --project=PROJECT_ID

    Pada output, tinjau bagian exclusions. Bandingkan logika filter dengan atribut log yang tidak ada (misalnya, jenis resource, label, atau kata kunci).

  3. Untuk mengubah pengecualian, perbarui konfigurasi sink:

    1. Ekspor konfigurasi sink ke file lokal (misalnya, sink-config.yaml):

      gcloud logging sinks describe SINK_NAME \
    --format=yaml > sink-config.yaml

    2. Buka file sink-config.yaml di editor teks.

    3. Temukan bagian exclusions: dan hapus atau ubah filter yang bermasalah.

    4. Perbarui sink yang diubah:

      gcloud logging sinks update SINK_NAME sink-config.yaml \
    --project=PROJECT_ID

      Untuk mengetahui informasi selengkapnya tentang perintah ini, lihat dokumentasi gcloud logging sinks update.

Menyelidiki penampungan dan penundaan log container

Aplikasi dan sistem operasi sering menggunakan buffering untuk menulis data dalam potongan, bukan baris demi baris, yang dapat meningkatkan performa.

Gejala:

  • Log dari container tertentu hanya muncul di Cloud Logging setelah container keluar, atau ada penundaan yang signifikan dalam munculnya log.
  • Terkadang, log tidak lengkap.

Penyebab:

Masalah ini sering disebabkan oleh buffering log. Meskipun output standar (stdout) biasanya di-buffer per baris saat terhubung ke terminal, perilaku ini berubah saat output di-pipe. Jika log atau skrip startup aplikasi dalam pipeline stdout penampung ke perintah lain (misalnya, my-app | grep ...), output mungkin menjadi sepenuhnya di-buffer. Akibatnya, log ditahan hingga buffer penuh atau saluran ditutup. Perilaku ini dapat menyebabkan penundaan atau kehilangan data jika penampung berakhir secara tiba-tiba. Buffering internal aplikasi juga dapat menyebabkan penundaan.

Resolusi:

Untuk mengatasi masalah ini, coba solusi berikut:

  • Hindari penggunaan stdout: jika memungkinkan, ubah titik entri penampung atau perintah aplikasi untuk menulis log langsung ke stdout atau stderr tanpa menggunakan perintah lain seperti grep atau sed dalam penampung.
  • Pastikan buffering baris:
    • Jika penggunaan pipa tidak dapat dihindari, gunakan alat yang mendukung buffering baris. Misalnya, gunakan grep --line-buffered.
    • Untuk aplikasi kustom, pastikan aplikasi tersebut sering menghapus log, idealnya setelah setiap baris, saat menulis ke stdout. Banyak library logging memiliki setelan untuk mengontrol buffering.

  • Uji perilaku buffering: deploy manifes Pod berikut dan amati efeknya dalam log menggunakan perintah kubectl logs -f buffered-pod. Lakukan eksperimen dengan memberi dan menghapus komentar pada berbagai array command dalam manifes buffered-container:

    # buffered.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: run-script
data:
run.sh: |
    #!/bin/bash
    echo "Starting..."
    for i in $(seq 3600); do
    echo "Log ${i}"
    sleep 1
    done
    echo "Exiting."
---
apiVersion: v1
kind: Pod
metadata:
name: buffered-pod
spec:
containers:
    - name: buffered-container
    image: ubuntu  # Or any other image with bash

    # Case 1: Direct execution - line buffered by default to TTY
    # Logs appear immediately.
    command: ['/bin/bash', '-c', '/mnt/run.sh']

    # Case 2: Piped to grep - fully buffered by default
    # Logs might be delayed or appear in chunks.
    # command: ['/bin/bash', '-c', '/mnt/run.sh | grep Log']

    # Case 3: Piped to grep with --line-buffered
    # Logs appear immediately.
    # command: ['/bin/bash', '-c', '/mnt/run.sh | grep --line-buffered Log']

    volumeMounts:
        - name: scripts
        mountPath: /mnt
volumes:
    - name: scripts
    configMap:
        name: run-script
        defaultMode: 0777
restartPolicy: Never

Menyelidiki kueri Logs Explorer

Jika Anda yakin bahwa log Anda dikumpulkan, tetapi Anda tidak dapat menemukannya, kueri penelusuran atau rentang waktu Anda mungkin menjadi masalahnya.

Gejala:

Log yang diharapkan tidak muncul di hasil penelusuran, meskipun Anda tahu bahwa aplikasi sedang membuatnya.

Penyebab:

Kueri Anda di Logs Explorer mungkin memiliki filter (misalnya, pada namespace, label, jenis resource, atau teks) yang secara tidak sengaja mengecualikan log yang Anda cari.

Resolusi:

  1. Di konsol Google Cloud , buka halaman Logs Explorer.

    Buka Logs Explorer

  2. Klik Pilih rentang waktu. Meskipun Anda merasa tahu kapan log terjadi, coba rentang yang jauh lebih luas untuk mengesampingkan masalah pengaturan waktu.

  3. Sederhanakan kueri:

    1. Hapus semua filter.

    2. Coba memfilter hanya menurut cluster Anda:

      resource.type="k8s_container"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"

      Ganti kode berikut:

      • CLUSTER_NAME: nama cluster Anda.
      • LOCATION: region atau zona Compute Engine (misalnya, us-central1 atau us-central1-a) untuk cluster.

    3. Klik Run query.

  4. Jika kueri luas berfungsi, perkenalkan kembali filter asli Anda satu per satu:

    • Jenis resource: pastikan Anda menggunakan jenis resource yang benar. Misalnya, apakah Anda memfilter menurut k8s_container padahal seharusnya memfilter menurut k8s_node?
    • Label: periksa kembali ejaan untuk resource.labels seperti namespace_name, container_name, atau label kustom.
    • Tingkat keparahan: pastikan tingkat keparahan (misalnya, severity=ERROR) tidak terlalu ketat.
    • Payload teks: periksa kesalahan ejaan dan string yang terlalu ketat dalam istilah penelusuran. Misalnya, gunakan : untuk "berisi", bukan = untuk pencocokan persis (jsonPayload.message:"error", bukan jsonPayload.message="error").

  5. Pastikan filter Anda memperhitungkan kepekaan huruf besar/kecil (teks biasanya tidak peka huruf besar/kecil, tetapi label mungkin tidak), pastikan nilai tidak memiliki karakter tersembunyi atau spasi tambahan, dan periksa apakah istilah dengan karakter khusus perlu diapit tanda petik.

  6. Tinjau Linimasa. Penurunan mendadak saat menambahkan filter dapat membantu Anda mengidentifikasi bagian kueri yang bermasalah.

Untuk mengetahui saran selengkapnya tentang kueri logging yang efektif, lihat artikel Menemukan entri log dengan cepat di dokumentasi Cloud Logging.

Jika Anda masih tidak dapat menemukan log setelah mempersempit kueri, masalahnya mungkin bukan kueri, tetapi masalah yang dijelaskan di bagian lain dalam dokumen ini.

Menyelidiki perilaku logging khusus aplikasi

Agen logging GKE hanya mengumpulkan log yang ditulis ke aliran stdout dan stderr.

Gejala:

Tidak ada log untuk Pod atau container tertentu yang terlihat di Cloud Logging, meskipun log lain dari cluster ada.

Penyebab:

Aplikasi tidak menulis ke stdout atau stderr. Aplikasi mungkin salah dikonfigurasi untuk menulis log ke file di dalam penampung, tempat agen logging tidak dapat mengumpulkannya.

Aplikasi juga dapat mencampur teks JSON dan non-JSON dalam outputnya. Parser agen logging mengharapkan format yang konsisten (JSON atau teks) dari satu aliran. Jika aplikasi yang dikonfigurasi untuk logging JSON menghasilkan baris teks biasa, hal ini dapat merusak parser, sehingga log tidak dicatat atau dicatat dengan tidak benar.

Resolusi:

  1. Tentukan nama Pod dan namespace aplikasi yang lognya tidak ada:

    kubectl get pods -n NAMESPACE_NAME

  2. Periksa log container:

    • Jika Pod memiliki satu container, jalankan perintah berikut:

      kubectl logs POD_NAME \
    -n NAMESPACE_NAME

      Ganti kode berikut:

      • POD_NAME: nama Pod Anda.
      • NAMESPACE_NAME: namespace Pod Anda.

    • Jika Pod memiliki beberapa container, tentukan nama container:

      kubectl logs POD_NAME \
    -c CONTAINER_NAME \
    -n NAMESPACE_NAME

      Ganti CONTAINER_NAME dengan nama container dalam Pod.

    • Untuk mengikuti log secara real-time, jalankan perintah berikut:

      kubectl logs -f POD_NAME \
    -c CONTAINER_NAME \
    -n NAMESPACE_NAME

      Ganti kode berikut:

      • POD_NAME: nama Pod Anda.
      • CONTAINER_NAME: nama container dalam Pod.
      • NAMESPACE_NAME: namespace Pod Anda.

  3. Analisis output:

    • Jika perintah kubectl logs tidak memiliki output atau jika output perintah tidak berisi log yang diharapkan, berarti masalahnya ada pada aplikasi itu sendiri. Perintah kubectl logs membaca langsung dari aliran stdout dan stderr yang diambil oleh runtime container. Jika log tidak ada di sini, agen logging GKE tidak dapat melihatnya.

      Ubah kode atau konfigurasi aplikasi Anda untuk berhenti menulis ke file dan mencatat semua pesan langsung ke stdout (untuk log reguler) dan stderr (untuk log error).

    • Jika Anda melihat campuran string JSON dan baris teks biasa, output ini menunjukkan masalah format campuran. Konfigurasi aplikasi Anda agar hanya menulis objek JSON satu baris yang valid ke stdout dan stderr.

    • Jika perintah kubectl logs menampilkan log yang diharapkan, berarti masalahnya kemungkinan terjadi lebih jauh di pipeline logging (misalnya, agen, izin, atau layanan Cloud Logging).

Memecahkan masalah platform dan layanan

Bagian berikut membantu Anda menyelidiki masalah di luar konfigurasi langsung Anda, seperti kebijakan retensi log, kondisi Cloud Logging, atau versi GKE yang tidak didukung.

Menyelidiki periode retensi log

Log disimpan dalam bucket, dan setiap bucket memiliki periode retensi yang menentukan berapa lama lognya disimpan sebelum dihapus secara otomatis.

Gejala:

Log yang lebih lama dari tanggal tertentu tidak ada.

Penyebab:

Log yang Anda cari lebih lama dari periode retensi untuk bucket log tempat log tersebut dirutekan.

Resolusi:

Untuk mengidentifikasi dan memperbarui periode retensi, pilih salah satu opsi berikut:

Konsol

  1. Identifikasi bucket tempat log GKE Anda dirutekan:

    1. Di konsol Google Cloud , buka halaman Log Router.

      Buka Router Log

    2. Tinjau kolom Tujuan, yang menunjukkan tempat log dirutekan.

      Tujuan akan terlihat mirip dengan berikut ini:

      logging.googleapis.com/projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID

      Perhatikan PROJECT_ID, LOCATION, dan BUCKET_ID.

      Log sering kali diarahkan ke bucket _Default, tetapi juga dapat diarahkan ke bucket lain jika Anda telah mengonfigurasi sink kustom.

  2. Periksa periode retensi bucket log:

    1. Di konsol Google Cloud , buka halaman Logs Storage.

      Buka Penyimpanan Log

    2. Temukan bucket yang cocok dengan BUCKET_ID, LOCATION, dan PROJECT_ID dari tujuan sink.

    3. Untuk setiap bucket yang relevan, lihat kolom Periode retensi.

    4. Jika log yang ingin Anda lihat lebih lama dari periode retensi, Cloud Logging telah menghapusnya. Jika Anda memerlukan periode retensi yang lebih lama, lakukan hal berikut:

      1. Untuk bucket yang masa retensinya ingin Anda perpanjang, klik Tindakan lainnya.
      2. Pilih Edit bucket, lalu perbarui periode retensi. Perhatikan implikasi biaya yang mungkin terjadi.

gcloud

  1. Identifikasi bucket tempat log GKE Anda dirutekan:

    gcloud logging sinks list --project=PROJECT_ID

    Tinjau output-nya. Kolom destination untuk setiap sink menunjukkan tempat log dirutekan. Format tujuan untuk bucket log adalah:

    logging.googleapis.com/projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID

    Perhatikan PROJECT_ID, LOCATION, dan BUCKET_ID.

    Log sering kali diarahkan ke bucket _Default.

  2. Periksa periode retensi bucket log:

    gcloud logging buckets describe BUCKET_ID \
    --location=LOCATION \
    --project=PROJECT_ID

    Pada output, cari kolom retentionDays. Jika log yang Anda butuhkan lebih lama dari nilai yang tercantum untuk retentionDays, maka Cloud Logging telah menghapusnya.

  3. Jika Anda memerlukan periode retensi yang lebih lama, perbarui:

    gcloud logging buckets update BUCKET_ID \
    --location=LOCATION \
    --retention-days=RETENTION_DAYS \
    --project=PROJECT_ID

    Ganti kode berikut:

    • BUCKET_ID: ID bucket log.
    • LOCATION: region atau zona Compute Engine (misalnya, us-central1 atau us-central1-a) untuk bucket.
    • RETENTION_DAYS: jumlah hari untuk mempertahankan log. Perhatikan implikasi biaya potensial untuk memperpanjang periode retensi.
    • PROJECT_ID: Google Cloud Project ID Anda.

Menyelidiki masalah layanan Cloud Logging dan keterlambatan penyerapan

Terkadang, pipeline pencatatan log itu sendiri mungkin mengalami masalah, baik dari gangguan di seluruh layanan atau penundaan penyerapan data sementara dalam skala besar.

Gejala:

  • Kehilangan log yang meluas atau terputus-putus di beberapa project atau cluster.
  • Log tertunda secara signifikan dalam muncul di Logs Explorer.

Penyebab:

  • Gangguan layanan Cloud Logging: gangguan langka di seluruh layanan dapat mencegah penyerapan log, sehingga menyebabkan penundaan yang meluas atau kehilangan log total.
  • Volume log yang tinggi: meskipun tanpa gangguan resmi, volume log yang tinggi dari project atau region Anda dapat membebani layanan penyerapan untuk sementara, sehingga menyebabkan log tertunda dalam muncul.

Resolusi:

  • Periksa status layanan Google Cloud dengan membuka Google Cloud dasbor Service Health. Cari insiden terbuka yang terkait dengan Cloud Logging atau GKE.

  • Perhitungkan kemungkinan keterlambatan penyerapan. Jika log tidak langsung terlihat, dan tidak ada insiden aktif, tunggu beberapa saat hingga log diproses, terutama jika volume log tinggi. Periksa kembali setelah beberapa menit.

Menyelidiki versi cluster

GKE secara rutin merilis versi baru yang mencakup perbaikan bug dan peningkatan performa untuk komponen, termasuk agen logging.

Gejala:

Masalah logging bertepatan dengan batasan versi cluster.

Penyebab:

Cluster mungkin menjalankan versi GKE yang lebih lama atau tidak didukung yang memiliki masalah agen logging yang diketahui atau tidak memiliki fitur logging tertentu.

Resolusi:

Untuk menyelesaikan masalah ini, lakukan tindakan berikut:

  1. Periksa versi cluster Anda:

    gcloud container clusters describe CLUSTER_NAME \
    --location LOCATION \
    --format="value(currentMasterVersion)"

    Ganti kode berikut:

    • CLUSTER_NAME: nama cluster Anda.
    • LOCATION: region atau zona Compute Engine (misalnya, us-central1 atau us-central1-a) untuk cluster.

  2. Untuk memastikan versi tersebut adalah versi yang didukung, bandingkan versi ini dengan Jadwal rilis GKE.

  3. Jika cluster menggunakan versi yang tidak didukung, upgrade cluster Anda.

Langkah berikutnya