Simple Log Service：Panduan pengumpulan log kontainer dari kluster Kubernetes

Fitur

Simple Log Service menyediakan kemampuan inti berikut untuk pengumpulan log kontainer Kubernetes:

• Sumber log ganda

  • Tipe log: Standard output (stdout), standard error (stderr), dan file log teks kontainer.

• Filtering kontainer tingkat granular

  • Tentukan atau kecualikan kontainer dari pengumpulan berdasarkan namespace, nama pod, nama kontainer, label kontainer, atau variabel lingkungan.

• Pemrosesan log kompleks

  • Kumpulkan log multi-baris: Kenali entri log yang membentang di beberapa baris, seperti stack trace exception Java, dan proses sebagai satu event log tunggal. Hal ini mencegah log terpisah secara salah oleh line feed.

  • Pra-proses log: Gunakan plugin seperti filter plugin untuk menyaring data tidak valid pada kolektor. Gunakan plugin penyembunyian log dan ekstraksi field untuk mencegah log mentah terekspos.

  • Uraikan dan strukturkan field: Gunakan plugin parsing untuk ekspresi reguler, JSON, atau pemisah guna mengurai log mentah sebelum disimpan.

• Asosiasi metadata cerdas

  • Saat melaporkan log kontainer, LoongCollector secara otomatis mengasosiasikan metadata seperti nama kontainer, citra, pod, namespace, dan variabel lingkungan.

• Jaminan keandalan

  • Mekanisme checkpoint mencatat posisi pengumpulan saat ini untuk menjamin integritas log.

  • SLS menyediakan strategi berbeda untuk menangani log saat kontainer berhenti berdasarkan runtime kontainer.

Batasan

• Runtime kontainer: Hanya Docker dan Containerd yang didukung.

  Docker:

  • Memerlukan izin akses ke docker.sock.

  • Pengumpulan standard output hanya mendukung driver logging JSON.

  • Hanya driver penyimpanan overlay dan overlay2 yang didukung. Untuk driver penyimpanan lain, Anda harus memasang direktori log sebagai volume.

  Containerd:

  • Memerlukan izin akses ke containerd.sock.

• Batasan log multi-baris:

  Untuk mencegah entri log multi-baris terpisah karena latensi output, baris log terakhir yang dikumpulkan di-cache selama periode tertentu. Waktu cache default adalah 3 detik. Anda dapat mengubah waktu ini menggunakan parameter BeginLineTimeoutMs. Untuk mencegah pemisahan salah, nilainya harus minimal 1.000 milidetik.

• Standard output:

  Ukuran maksimum untuk satu entri log: Defaultnya 524.288 byte (512 KB), dan maksimum 8.388.608 byte (8 MB). Jika satu entri log melebihi 524.288 byte, Anda dapat mengubah batas tersebut dengan menambahkan variabel lingkungan max_read_buffer_size ke kontainer LoongCollector.

  Penting

  Jangan aktifkan standard output dan standard error secara bersamaan. Hal ini dapat menyebabkan pengumpulan log tidak berurutan.

Ikhtisar proses pengumpulan

1. Login ke kluster dan siapkan sumber log: Siapkan log standard output atau file log teks untuk dikumpulkan.

2. Instal kolektor LoongCollector: Instal LoongCollector, yang digunakan oleh SLS untuk mengumpulkan dan mengirimkan log.

3. Konfigurasikan aturan pengumpulan dan plugin parsing: Tentukan aturan untuk pengumpulan log.

4. Kueri dan analisis log: Kueri log yang telah dikumpulkan untuk menganalisis status bisnis Anda.

Deskripsi proses utama

Persyaratan sumber log dan titik pemasangan (Penting)

• Untuk log standard output, LoongCollector secara otomatis mengidentifikasi path file berdasarkan metadata kontainer.

• Untuk file log teks kontainer, LoongCollector secara default memasang direktori root host ke direktori /logtail_host miliknya sendiri, sehingga pemasangan manual tidak diperlukan. Jika Anda menggunakan titik pemasangan kustom, titik tersebut harus memenuhi persyaratan berikut:

  Persyaratan titik pemasangan kustom

  Log file path:

  • Jangan gunakan tautan simbolik:

    • Konfigurasi salah: /var/log -> /mnt/logs.

    • Konfigurasi benar: Gunakan path fisik langsung, seperti /mnt/logs.

  • Aturan pencocokan path pemasangan: Jika direktori data aplikasi kontainer dipasang menggunakan volume, path pengumpulan harus sama dengan atau merupakan subdirektori dari path titik pemasangan.

    1 Titik pemasangan: /var/log/service
    2 ✅ Path pengumpulan valid: /var/log/service atau /var/log/service/subdir
    3 ❌ Path pengumpulan tidak valid: /var/log (Path terlalu pendek)

Instal kolektor

Pilih mode penyebaran berdasarkan skenario Anda:

Mode penyebaran: SLS mendukung instalasi LoongCollector dalam mode DaemonSet atau Sidecar.

• Mode penyebaran DaemonSet: Konfigurasikan sekali untuk secara otomatis menerapkan LoongCollector pada setiap node di dalam kluster. Ini merupakan mode yang direkomendasikan untuk sebagian besar skenario.

  • Jika Anda menggunakan mode DaemonSet, pilih metode penyebaran berdasarkan hubungan antara kluster Anda dan SLS.

    • Jika Anda menggunakan kluster ACK, komponen loongcollector-ds sudah terintegrasi. Untuk menyelesaikan instalasi, aktifkan komponen tersebut di Konsol ACK. Secara default, metode ini mengikat collector ke Akun Alibaba Cloud pemilik kluster ACK dan menyimpan log di instans SLS akun tersebut. Untuk informasi selengkapnya, lihat Install LoongCollector (Kubernetes).

    • Jika Anda menggunakan kluster ACK tetapi perlu mengumpulkan log-nya ke proyek SLS yang dimiliki oleh Akun Alibaba Cloud berbeda karena alasan seperti struktur organisasi, isolasi izin, atau Pemantauan terpadu, Anda harus menginstal komponen LoongCollector secara manual. Kemudian, konfigurasikan komponen tersebut dengan ID akun tujuan atau kredensial akses (AccessKey) untuk membuat asosiasi. Untuk informasi selengkapnya, lihat Install LoongCollector (Kubernetes).

    • Jika Anda menggunakan kluster yang dikelola sendiri, Anda harus menginstal komponen LoongCollector secara manual. Kemudian, konfigurasikan komponen tersebut dengan ID akun tujuan atau kredensial akses (AccessKey) untuk membuat asosiasi. Untuk informasi selengkapnya, lihat Install LoongCollector (Kubernetes).

    Instalasi LoongCollector merupakan prasyarat untuk pengumpulan log. Untuk proses pengumpulan lengkap, termasuk instalasi LoongCollector, lihat Collect container logs from a Kubernetes cluster using a CRD (standard output/file).

• Mode penyebaran Sidecar: Kontainer Sidecar LoongCollector disuntikkan ke setiap Pod bersama kontainer aplikasi. Mode ini melibatkan penyebaran serta operasi dan maintenance (O&M) yang lebih kompleks. Gunakan mode ini untuk pengumpulan log kontainer arsitektur tanpa server, ketika volume data Pod pada node tunggal melebihi batas pengumpulan DaemonSet, atau untuk pengumpulan log dari Kubernetes dengan runtime kontainer aman. Untuk informasi selengkapnya, lihat Collect text logs from a Kubernetes pod (Sidecar mode).

Konfigurasikan aturan pengumpulan

SLS menyediakan dua cara untuk menentukan aturan konfigurasi pengumpulan:

Konsep inti

• Kubernetes: Kubernetes (K8s) adalah platform orkestrasi kontainer open-source yang mengotomatiskan deployment, penskalaan, dan manajemen aplikasi berkontainer. Kubernetes merupakan infrastruktur inti untuk pengembangan aplikasi cloud-native modern dan operasi serta maintenance (O&M).

• Standard output, standard error, dan file log teks: Standard output (stdout) adalah informasi yang dicetak program selama operasi normal, seperti log bisnis dan catatan operasi. Informasi ini secara default dioutput ke terminal dan ditangkap oleh engine kontainer untuk disimpan. Standard error (stderr) adalah informasi error atau peringatan dari program, seperti stack trace exception dan alasan kegagalan startup. Informasi ini juga ditangkap oleh engine kontainer dan dapat bercampur dengan stdout. File log teks adalah log yang ditulis aplikasi ke file, seperti access.log Nginx atau file log kustom. Log ini ditulis langsung ke sistem file internal kontainer dan dihapus saat kontainer dihapus. Anda dapat menggunakan volume untuk persistensi.

• Mekanisme checkpoint: Checkpoint mencatat posisi terakhir yang dikumpulkan dalam file. Secara default, checkpoint disimpan di /tmp/logtail_checkpoint. Mekanisme ini menjamin keandalan pengumpulan log jika LoongCollector restart atau terjadi kegagalan node.

• LoongCollector (Logtail): Kolektor log berkinerja tinggi yang dikembangkan oleh Alibaba Cloud. Mendukung mode penyebaran DaemonSet dan Sidecar di Kubernetes. LoongCollector adalah versi peningkatan dari Logtail dan kompatibel dengan semua fitur Logtail.

• Kubernetes CRD: CustomResourceDefinition (CRD) adalah mekanisme Kubernetes yang memungkinkan pengguna mendefinisikan resource kustom dan membuat instance untuk konfigurasi. Tipe resource kustom yang disediakan oleh SLS adalah AliyunPipelineConfig.

• Konfigurasi pengumpulan: Menentukan aturan untuk pengumpulan log, termasuk tipe log, path pengumpulan, filtering log, parsing konten, dan lokasi penyimpanan di Simple Log Service. Untuk informasi lebih lanjut, lihat Apa itu konfigurasi pengumpulan LoongCollector?.

• Plugin parsing: Digunakan dalam konfigurasi plugin prosesor dari konfigurasi pengumpulan. SLS menyediakan beberapa unit pemrosesan untuk menyusun, memisahkan, menyaring, dan menyembunyikan konten log. Unit-unit ini mendukung berbagai mode pemrosesan, seperti ekspresi reguler, pemisah, JSON, dan multi-baris.

Cara kerja pengumpulan log

1. Pengguna membuat custom resource (CR) menggunakan kubectl untuk menentukan aturan pengumpulan.

2. loongcollector-operator terus-menerus mendengarkan perubahan CR di kluster.

3. Saat perubahan CR terdeteksi, operator mengonversinya menjadi konfigurasi spesifik dan mengirimkannya ke SLS.

4. LoongCollector secara berkala mengirim heartbeat ke SLS untuk mengambil pembaruan konfigurasi. LoongCollector menarik konfigurasi pengumpulan terbaru dan melakukan hot-reload.

5. loongcollector-ds mengumpulkan log berdasarkan konfigurasi terbaru dan mengirimkannya ke SLS melalui titik akhir yang dikonfigurasi.

Cara kerja mode DaemonSet

LoongCollector ditempatkan di setiap node kluster untuk mengumpulkan log dari semua kontainer di node tersebut. Mode ini memiliki O&M sederhana, konsumsi resource rendah, dan konfigurasi fleksibel. Namun, isolasinya lemah.

Cara kerja mode DaemonSet

• Dalam mode DaemonSet, kluster Kubernetes memastikan hanya satu kontainer LoongCollector yang berjalan di setiap node. Kontainer ini mengumpulkan log dari semua kontainer lain di node yang sama.

• Saat node baru bergabung ke kluster, Kubernetes secara otomatis membuat kontainer LoongCollector di atasnya. Saat node meninggalkan kluster, Kubernetes secara otomatis menghapus kontainer LoongCollector di node tersebut. Mekanisme auto-scaling DaemonSet dan kelompok mesin berbasis identifier menghilangkan kebutuhan manajemen manual instance LoongCollector.

Cara kerja mode Sidecar

Kontainer Sidecar LoongCollector disuntikkan ke setiap pod bersama kontainer aplikasi. Direktori log kontainer aplikasi dipasang sebagai volume bersama menggunakan volume Kubernetes, seperti emptyDir, hostPath, atau persistent volume (PV). Hal ini membuat file log tersedia di path pemasangan kedua kontainer—aplikasi dan Sidecar—sehingga LoongCollector dapat membacanya langsung. Mode ini memiliki isolasi data multi-tenant dan performa yang baik. Namun, mode ini mengonsumsi lebih banyak resource dan lebih kompleks untuk dikonfigurasi serta dipelihara.

Cara kerja mode Sidecar

• Dalam mode Sidecar, satu kontainer LoongCollector berjalan di setiap pod untuk mengumpulkan log dari semua kontainer lain dalam pod tersebut. Pengumpulan log untuk pod berbeda terisolasi.

• Untuk mengumpulkan file log dari kontainer lain dalam pod yang sama, Anda dapat menggunakan volume bersama. Volume yang sama harus dipasang ke kontainer aplikasi dan kontainer LoongCollector.

• Jika volume data pod di satu node sangat besar dan melebihi batas performa pengumpulan mode DaemonSet, Anda dapat menggunakan mode Sidecar untuk mengalokasikan resource khusus ke LoongCollector. Hal ini meningkatkan performa dan stabilitas pengumpulan log.

• Kontainer serverless tidak memiliki konsep node, sehingga mode penyebaran DaemonSet tradisional tidak dapat digunakan. Dalam skenario ini, mode Sidecar dapat dikombinasikan dengan arsitektur serverless untuk memastikan proses pengumpulan log yang fleksibel dan adaptif.

Cara kerja discovery kontainer

Agar kontainer LoongCollector dapat mengumpulkan log dari kontainer lain, ia harus menemukan dan mengidentifikasi kontainer mana yang sedang berjalan. Proses ini disebut discovery kontainer.

• Selama fase discovery kontainer, kontainer LoongCollector tidak berkomunikasi dengan kube-apiserver kluster Kubernetes. Sebaliknya, ia berkomunikasi langsung dengan daemon runtime kontainer di node untuk mengambil informasi tentang semua kontainer di node tersebut. Hal ini menghindari tekanan pada kube-apiserver kluster.

• LoongCollector dapat mengambil informasi konteks kontainer dengan mengakses file sock runtime kontainer, seperti Docker Engine atau Containerd, di host. LoongCollector mendukung penentuan atau pengecualian kontainer untuk pengumpulan log berdasarkan kriteria seperti nama namespace, nama pod, label pod, dan variabel lingkungan kontainer.

Pengumpulan standard output

LoongCollector secara otomatis mengidentifikasi API atau driver logging runtime kontainer berbeda, seperti Docker dan Containerd, berdasarkan metadata kontainer. Tidak diperlukan konfigurasi manual. LoongCollector langsung membaca aliran standard output semua kontainer tanpa mengakses sistem file internal mereka.

Pengumpulan log file teks kontainer

• Kubernetes mengisolasi sistem file kontainer, sehingga kolektor tidak dapat langsung mengakses file di kontainer lain. Namun, sistem file kontainer dipasang dari sistem file host. Anda dapat memasang sistem file root host ke kontainer LoongCollector untuk mengakses file apa pun di host. Hal ini memungkinkan Anda mengumpulkan file dari sistem file kontainer aplikasi secara tidak langsung.

• Secara default, LoongCollector memasang sistem file direktori root host ke direktori /logtail_host miliknya sendiri. Pemasangan manual tidak diperlukan. Misalnya, jika path file log di dalam kontainer adalah /log/app.log, dan path yang dipetakan di host adalah /var/lib/docker/containers/<container-id>/log/app.log, maka path aktual yang dikumpulkan LoongCollector adalah /logtail_host/var/lib/docker/containers/<container-id>/log/app.log.

Cara kerja pengenalan log multi-baris

Setiap baris log dicocokkan dengan ekspresi reguler kustom yang menentukan awal baris.

• Jika ditemukan kecocokan, baris tersebut dianggap sebagai awal entri log baru, dan entri log baru dimulai.

• Jika tidak ditemukan kecocokan, baris tersebut ditambahkan ke akhir entri log saat ini.

Saat baris lain yang cocok dengan ekspresi reguler awal-baris ditemukan, entri log saat ini dianggap selesai, dan entri baru dimulai.

Penanganan log saat kontainer berhenti

Cara pengambilan metadata kontainer

Untuk mengambil metadata kontainer, LoongCollector berinteraksi langsung dengan runtime kontainer berdasarkan API Container Runtime Interface (CRI) standar. Hal ini memungkinkan LoongCollector mengambil berbagai jenis metadata di Kubernetes dan menerapkan fitur AutoTagging metadata Kubernetes secara non-intrusif selama pengumpulan. Mekanisme interaksi langsung dengan runtime ini meningkatkan pengambilan data real-time dan kemampuan mengelola status kontainer.

• Docker: Klien Docker berkomunikasi dengan daemon Docker untuk langsung mendapatkan metadata kontainer. Hal ini memungkinkan pemantauan dan manajemen kontainer secara mendalam. Antarmuka utama yang digunakan meliputi:

  • ContainerList: Mengambil daftar kontainer yang sedang berjalan untuk mengidentifikasi kontainer di node saat ini.

  • ContainerInspect: Memberikan informasi detail untuk setiap kontainer, termasuk informasi kunci seperti konfigurasi dan status.

  • Events: Mendengarkan event perubahan kontainer secara real time untuk melacak siklus hidup kontainer dan memperbarui logika pemrosesan terkait.

  Saat mengambil metadata kontainer melalui Klien Docker, informasi berikut penting:

  • LogPath: Ini adalah path penyimpanan file log standard output kontainer di host. Memfasilitasi pengumpulan dan analisis log.

  • GraphDriver.Data: Menyediakan path rootfs kontainer di node host. Path ini penting untuk memahami metode penyimpanan sistem file kontainer dan membantu diagnosis kesalahan serta optimasi performa.

• Containerd: Melalui CRI, LoongCollector sepenuhnya mendukung berbagai skenario yang menggunakan lingkungan runtime containerd dan cri-o. LoongCollector dapat mengumpulkan dan mengambil metadata kontainer secara efisien terlepas dari apakah runtime dasarnya runc atau Kata Containers. Hal ini menjamin pengumpulan data log yang akurat dan terpadu terlepas dari lingkungan tempat kontainer berjalan, membantu Anda memantau dan menganalisis data log secara real time.

  • Metadata kontainer yang disediakan oleh CRI hanya mencakup path file log standard output kontainer di node host. Path Rootfs kontainer tidak dapat diperoleh secara langsung. Untuk mengatasi masalah ini, Anda dapat menggunakan salah satu solusi berikut:

    • Pencarian path file: Cari sistem file host untuk menemukan path Rootfs kontainer. Metode ini melibatkan traversal direktori file di host dan menggunakan identifier unik kontainer, seperti ID kontainer, untuk asosiasi dan pencarian. Hal ini memungkinkan Anda mengambil sistem file kontainer. Mekanisme pencarian dinamis ini dapat mengatasi masalah akibat informasi path yang hilang dan memberikan dukungan untuk pengumpulan dan pemantauan log selanjutnya.

    • Lewati CRI dan berinteraksi langsung dengan containerd: Berkomunikasi langsung dengan containerd untuk mengambil informasi kontainer yang lebih komprehensif dan akurat. Hal ini memungkinkan LoongCollector melewati keterbatasan CRI untuk mendapatkan path Rootfs kontainer dan metadata penting lainnya.