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 Cloud de Confiance by S3NS konten, lihat Peran dan tugas pengguna GKE umum.

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.	Memverifikasi 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 sepenuhnya di-buffer, sering kali karena stdout.	Menyelidiki penundaan dan buffering 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 log atau penundaan 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.

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 dengan Investigasi Gemini Cloud Assist di dokumentasi Gemini.

Memverifikasi konfigurasi dan izin logging

Setelan yang salah adalah alasan umum hilangnya log GKE. 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 Cloud de Confiance by S3NS , 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:

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:

Memverifikasi cakupan akses node pool

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

Gejala:

Log tidak ada dari node di node pool tertentu.

Penyebab:

Node di node pool 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 Cloud de Confiance by S3NS , yang mencakup izin dari logging.write.

Resolusi:

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

Memverifikasi izin akun layanan node

Node menggunakan akun layanan untuk mengautentikasi dengan layanan Cloud de Confiance by S3NS , 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 Cloud de Confiance .

Penyebab:

Masalah ini disebabkan oleh salah satu akun layanan berikut:

• Akun layanan node: akun layanan yang digunakan oleh node pool tidak memiliki izin IAM yang diperlukan untuk menulis log ke Cloud Logging. Akun layanan node harus memiliki peran yang mencakup izin logging.logEntries.create.

• Agen layanan node GKE: di GKE versi 1.33 dan yang lebih baru, agen layanan node (service-PROJECT_NUMBER@gcp-sa-gkenode.iam.s3ns-system.iam.gserviceaccount.com) GKE harus memiliki peran Kubernetes Default Node Service Agent (roles/container.defaultNodeServiceAgent). Peran ini memberikan akses GKE untuk mengelola resource dan operasi node, termasuk komponen logging.

Anda dapat mengidentifikasi akun layanan yang tidak memiliki akses yang diperlukan menggunakan rekomendasi. Untuk menggunakan rekomendasi guna memeriksa izin yang tidak ada, pilih salah satu opsi berikut:

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

Resolusi:

Untuk mengatasi masalah ini, coba langkah-langkah berikut:

1. Berikan peran roles/container.defaultNodeServiceAccount di project cluster ke akun layanan node. Peran ini mencakup izin yang diperlukan GKE untuk menulis log. Untuk mengetahui informasi selengkapnya, lihat Memberikan peran minimum yang diperlukan untuk GKE.

2. Setelah Anda menyelesaikan langkah sebelumnya, jika log masih belum ada dan cluster menggunakan versi 1.33 atau yang lebih baru, berikan peran roles/container.defaultNodeServiceAgent di project kepada agen layanan node GKE:

   1. Dapatkan nomor project Anda:

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

      Ganti PROJECT_ID dengan project ID Anda.

   2. Untuk memberikan peran roles/container.defaultNodeServiceAgent kepada agen layanan node, pilih salah satu opsi berikut:

      Konsol

      1. Di konsol Cloud de Confiance , buka halaman IAM.

         Buka IAM

      2. Centang kotak Include Google-provided role grants.

      3. Di kolom filter_list Filter, tentukan alamat email agen layanan berikut:

         service-PROJECT_NUMBER@gcp-sa-gkenode.s3ns-system.iam.gserviceaccount.com
         

         Ganti PROJECT_NUMBER dengan nomor project dari output langkah sebelumnya.

      4. Tekan Enter.

      5. Klik edit Edit principal.

      6. Klik add Tambahkan peran.

      7. Di kolom penelusuran, masukkan Kubernetes Engine Default Node Service Agent, lalu pilih peran.

      8. 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.s3ns-system.iam.gserviceaccount.com"
         

         Ganti PROJECT_NUMBER dengan nomor project dari output langkah sebelumnya.

         Pada output, cari roles/container.defaultNodeServiceAgent.

      2. Jika peran tidak ada, berikan peran tersebut:

         gcloud projects add-iam-policy-binding PROJECT_ID \
             --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.s3ns-system.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 sesekali 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 Cloud de Confiance , buka halaman Quotas.

   Buka Quotas

2. Di kolom Filter filter_list , 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 membuat log lebih cepat dari batas ini, agen mungkin akan 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:

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:

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 baris saat terhubung ke terminal, perilaku ini berubah saat output di-pipe. Jika log atau skrip startup aplikasi dalam pipeline penampung stdout 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 berhenti 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 melakukan flush 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 Cloud de Confiance , 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 filter 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.
   • 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" dan 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 dalam dokumentasi Cloud Logging.

Jika Anda masih tidak dapat menemukan log setelah menyempurnakan 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. 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 akan dihapus atau dimasukkan 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 data 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:

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 di seluruh layanan yang jarang terjadi 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 terlambat muncul.

Resolusi:

• Periksa status layanan Cloud de Confiance by S3NS dengan membuka Cloud de Confiance by S3NS 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 mengatasi masalah ini, lakukan langkah 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

• Jika Anda tidak dapat menemukan solusi untuk masalah Anda dalam dokumentasi, lihat Mendapatkan dukungan untuk mendapatkan bantuan lebih lanjut, termasuk saran tentang topik berikut:

  • Membuka kasus dukungan dengan menghubungi Cloud Customer Care.
  • Mendapatkan dukungan dari komunitas dengan mengajukan pertanyaan di StackOverflow dan menggunakan tag google-kubernetes-engine untuk menelusuri masalah serupa. Anda juga dapat bergabung ke #kubernetes-engine channel Slack untuk mendapatkan dukungan komunitas lainnya.
  • Membuka masalah atau permintaan fitur menggunakan issue tracker publik.