Halaman ini menyediakan ringkasan opsi logging yang tersedia di Google Kubernetes Engine (GKE).
Ringkasan
Log GKE yang dikirim ke Cloud Logging disimpan di datastore khusus dan persisten. Meskipun GKE menyimpan log, log tersebut tidak disimpan secara permanen. Misalnya, log container GKE dihapus saat Pod host-nya dihapus, saat disk tempatnya disimpan kehabisan ruang, atau saat diganti dengan log yang lebih baru. Log sistem dihapus secara berkala untuk mengosongkan ruang bagi log baru. Peristiwa cluster dihapus setelah satu jam.
Agen logging GKE
Untuk log container dan sistem, GKE men-deploy, secara default, agen logging per node yang membaca log container, menambahkan metadata yang berguna, lalu menyimpannya di Cloud Logging. Agen logging GKE memeriksa log container di sumber berikut:
Output standar dan log error standar dari proses dalam container
log runtime kubelet dan container
Log untuk komponen sistem, seperti skrip startup VM
Untuk peristiwa, GKE menggunakan deployment di namespace sistem kube yang otomatis mengumpulkan peristiwa dan mengirimkannya ke Logging.
Log yang dikumpulkan
Secara default, GKE mengumpulkan beberapa jenis log dari cluster Anda dan menyimpannya di Cloud Logging:
Log audit mencakup log Aktivitas Admin, log Akses Data, dan log Peristiwa. Untuk mengetahui informasi mendetail tentang Log Audit untuk GKE, lihat dokumentasi Log Audit untuk GKE. Log audit untuk GKE tidak dapat dinonaktifkan.
Log sistem mencakup log dari sumber berikut:
Semua Pod yang berjalan di namespace
kube-system
,istio-system
,knative-serving
,gke-system
, danconfig-management-system
.Layanan utama yang tidak berada dalam container, termasuk runtime
docker
/containerd
,kubelet
,kubelet-monitor
,node-problem-detector
, dankube-container-runtime-monitor
.Output port serial node, jika metadata instance VM
serial-port-logging-enable
ditetapkan ke true. Mulai GKE 1.16-13-gke.400, output port serial untuk node dikumpulkan oleh agen Logging. Untuk menonaktifkan logging output port serial, tetapkan--metadata serial-port-logging-enable=false
selama pembuatan cluster. Output port serial berguna untuk memecahkan masalah error, booting gagal, masalah startup, atau masalah penonaktifan dengan node GKE. Menonaktifkan log ini dapat membuat pemecahan masalah menjadi lebih sulit.
Log aplikasi mencakup semua log yang dibuat oleh container non-sistem yang berjalan pada node pengguna.
Secara opsional, GKE dapat mengumpulkan jenis log tambahan dari komponen bidang kontrol Kubernetes tertentu dan menyimpannya di Cloud Logging:
Log server API mencakup semua log yang dihasilkan oleh server Kubernetes API (
kube-apiserver
).Log penjadwal mencakup semua log yang dibuat oleh Penjadwal Kubernetes (
kube-scheduler
).Log Controller Manager mencakup semua log yang dibuat oleh Kubernetes Controller Manager (
kube-controller-manager
).
Untuk mempelajari masing-masing komponen bidang kontrol ini lebih lanjut, lihat arsitektur cluster GKE.
Mengumpulkan log Anda
Saat Anda membuat cluster GKE baru, integrasi dengan Cloud Logging akan diaktifkan secara default.
Log sistem dan aplikasi dikirim ke Router Log di Cloud Logging.
Dari sana, log dapat diserap ke Cloud Logging, dikecualikan, atau diekspor ke BigQuery, Pub/Sub, atau Cloud Storage.
Mulai GKE versi 1.15.7, Anda dapat configure cluster Standar untuk hanya merekam log sistem dan tidak mengumpulkan log aplikasi. Untuk cluster Autopilot dan Standar, filter pengecualian dapat digunakan untuk mengurangi volume log yang dikirim ke Cloud Logging.
Throughput logging
Saat logging sistem diaktifkan, agen Cloud Logging khusus akan otomatis di-deploy dan dikelola. Cloud Logging berjalan pada semua node GKE dalam sebuah cluster untuk mengumpulkan log, menambahkan metadata bermanfaat tentang container, pod, dan cluster, lalu mengirimkan log tersebut ke Cloud Logging menggunakan agen berbasis fluentbit.
Jika node GKE memerlukan lebih dari throughput log default, dan cluster GKE Standard Anda menggunakan bidang kontrol versi 1.23.13-gke.1000 atau yang lebih baru, Anda dapat mengonfigurasi GKE untuk men-deploy konfigurasi alternatif agen Logging yang didesain untuk memaksimalkan throughput logging.
Untuk mengetahui informasi selengkapnya, lihat Menyesuaikan throughput log.
Koleksi log dengan fluentbit atau fluentbit kustom
Agen logging default GKE menyediakan solusi terkelola untuk men-deploy dan mengelola agen yang mengirim log untuk cluster Anda ke Cloud Logging. Bergantung pada versi bidang kontrol GKE Anda, fluentd atau fluentbit digunakan untuk mengumpulkan log. Mulai GKE 1.17, log dikumpulkan menggunakan agen berbasis fluentbit.
Cluster GKE yang menggunakan versi sebelum GKE
1.17 menggunakan agen berbasis yang lancar. Jika ingin mengubah perilaku default
agen fluentd
, Anda dapat menjalankan agen fluentd
yang disesuaikan
atau
agen fluentbit
yang disesuaikan.
Kasus penggunaan umum mencakup:
menghapus data sensitif dari log Anda
mengumpulkan log tambahan yang tidak ditulis ke
STDOUT
atauSTDERR
menggunakan setelan terkait performa tertentu
pemformatan log yang disesuaikan
Mengumpulkan log auditd
Linux untuk node GKE
Anda dapat mengaktifkan log audit sistem operasi panjang pada node GKE yang menjalankan Container-Optimized OS. Log sistem operasi di node Anda memberikan informasi berharga tentang status cluster dan workload Anda, seperti pesan error, upaya login, dan eksekusi biner. Anda dapat menggunakan informasi ini untuk melakukan debug masalah atau menyelidiki insiden keamanan.
Untuk mempelajari lebih lanjut, baca bagian Mengaktifkan log audit Linux di node GKE.
Log Audit GKE
Untuk mengetahui informasi mendetail tentang entri log yang berlaku untuk jenis resource Cluster Kubernetes dan Operasi Cluster GKE, buka Logging audit.
Kontrol Akses Logging
Ada dua aspek kontrol akses logging: akses aplikasi dan akses pengguna. Cloud Logging memberikan peran Identity and Access Management (IAM) yang dapat Anda gunakan untuk memberikan akses yang sesuai.
Akses Aplikasi
Aplikasi memerlukan izin untuk menulis log ke Cloud Logging, yang diberikan dengan menetapkan peran IAM roles/logging.logWriter
ke akun layanan yang dikaitkan ke kumpulan node yang mendasarinya.
Akses Lihat Pengguna
Anda harus memiliki peran roles/logging.viewer
untuk melihat log di project Anda. Jika perlu memiliki akses ke log Akses Data, Anda harus memiliki izin IAM logging.privateLogViewer
.
Untuk mengetahui informasi selengkapnya tentang izin dan peran, buka panduan Kontrol akses. Anda juga dapat meninjau Praktik terbaik untuk Cloud Audit Logs, yang juga berlaku untuk Cloud Logging secara umum.
Akses Admin Pengguna
Peran IAM roles/logging.configWriter
dan roles/logging.admin
memberikan kemampuan administratif. Peran
roles/logging.configWriter
diperlukan untuk membuat sink logging yang biasanya digunakan untuk mengarahkan log Anda ke
project tertentu atau terpusat. Misalnya, Anda mungkin ingin menggunakan sink logging bersama dengan filter logging untuk mengarahkan semua log untuk sebuah namespace ke bucket logging terpusat.
Untuk mempelajari lebih lanjut, buka panduan Kontrol Akses untuk Cloud Logging.
Praktik terbaik
- Logging terstruktur: Agen logging yang terintegrasi dengan GKE
akan membaca dokumen JSON yang diserialisasi ke string satu baris dan ditulis ke
output standar atau error standar, lalu akan mengirimkannya ke Kemampuan Observasi Google Cloud
sebagai entri log terstruktur.
- Lihat Logging terstruktur untuk detail selengkapnya tentang cara bekerja dengan agen logging terintegrasi.
- Anda dapat menggunakan Filter log lanjutan untuk memfilter log berdasarkan kolom dokumen JSON.
- Log yang dibuat dengan glog akan mengurai kolom umum, misalnya,
severity
,pid
,source_file
,source_line
. Namun, payload pesan itu sendiri tidak diurai dan muncul kata demi kata dalam pesan log yang dihasilkan di Kemampuan Observasi Google Cloud.
- Keparahan: Secara default, log yang ditulis ke output standar berada pada
level
INFO
, dan log yang ditulis ke error standar berada pada levelERROR
. Log terstruktur dapat menyertakan kolomseverity
, yang menentukan tingkat keparahan log. - Mengekspor ke BigQuery: Untuk analisis tambahan, Anda dapat mengekspor log ke layanan eksternal, seperti BigQuery atau Pub/Sub. Log yang diekspor ke BigQuery mempertahankan format dan strukturnya. Lihat Ringkasan pemilihan rute dan penyimpanan untuk informasi selengkapnya.
- Pemberitahuan: Saat Logging mencatat perilaku yang tidak terduga, Anda dapat menggunakan metrik berbasis log untuk menyiapkan kebijakan pemberitahuan. Sebagai contoh, lihat Membuat kebijakan pemberitahuan pada metrik penghitung. Untuk informasi selengkapnya tentang metrik berbasis log, lihat Ringkasan metrik berbasis log.
- Error Reporting: Untuk mengumpulkan error dari aplikasi yang berjalan di cluster, Anda dapat menggunakan Error Reporting.
Log bidang kontrol
Anda dapat mengonfigurasi cluster GKE untuk mengirim log yang dikeluarkan oleh server Kubernetes API, Scheduler, dan Controller Manager ke Cloud Logging.
Persyaratan
Pengiriman log yang dimunculkan oleh komponen bidang kontrol Kubernetes ke Cloud Logging memerlukan bidang kontrol GKE versi 1.22.0 atau yang lebih baru dan mengharuskan pengumpulan log sistem diaktifkan.
Mengonfigurasi kumpulan log bidang kontrol
Baca petunjuk untuk mengonfigurasi dukungan logging untuk cluster baru atau untuk cluster yang ada.
Harga
Log bidang kontrol GKE diekspor ke Cloud Logging. Harga Cloud Logging berlaku.
Kuota
Log bidang kontrol menggunakan kuota "Permintaan tulis per menit" dari Cloud Logging API. Sebelum mengaktifkan log bidang kontrol, periksa penggunaan puncak terbaru Anda dari kuota tersebut. Jika memiliki banyak cluster dalam project yang sama atau sudah mendekati batas kuota, Anda dapat meminta peningkatan batas kuota sebelum mengaktifkan log bidang kontrol.
Kontrol akses
Jika ingin membatasi akses ke log bidang kontrol Kubernetes dalam organisasi, Anda dapat membuat bucket log terpisah dengan kontrol akses yang lebih terbatas.
Dengan menyimpannya di bucket log terpisah dengan akses terbatas, log bidang kontrol di bucket log tidak akan otomatis dapat diakses oleh siapa saja yang memiliki akses roles/logging.viewer
ke project. Selain itu, jika Anda memutuskan untuk menghapus log bidang kontrol tertentu karena masalah privasi atau keamanan, menyimpannya dalam bucket log terpisah dengan akses terbatas akan memungkinkan penghapusan log tersebut tanpa memengaruhi log dari komponen atau layanan lainnya.