Simple Log Service:Pengumpulan log kontainer Kubernetes

Fitur

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

• Dukungan log multi-sumber

  • Mendukung berbagai tipe log, termasuk standard output (stdout), standard error (stderr), dan file log teks dari kontainer.

• Pemfilteran kontainer granular

  • Sertakan atau kecualikan kontainer berdasarkan nama namespace, nama pod, nama kontainer, label kontainer, atau variabel lingkungan.

• Pemrosesan log tingkat lanjut

  • Kumpulkan log multi-baris: Gabungkan entri log yang tersebar di beberapa baris, seperti stack trace exception Java, menjadi satu event log untuk mencegah pemisahan yang salah.

  • Praproses log: Gunakan filter plugin untuk membuang data tidak valid di sumbernya. Gunakan plugin desensitisasi log atau ekstraksi field untuk menyamarkan atau menstrukturkan data sensitif dalam log mentah.

  • Uraikan field ke dalam format terstruktur: Gunakan plugin parsing berbasis ekspresi reguler, JSON, atau separator untuk menstrukturkan log mentah sebelum disimpan.

• Asosiasi metadata cerdas

  • Secara otomatis mengasosiasikan metadata dengan log kontainer, seperti nama kontainer, image, pod, namespace, dan variabel lingkungan.

• Keandalan

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

  • Menangani log saat kontainer berhenti dengan menyediakan strategi berbeda untuk berbagai runtime kontainer.

Batasan

• runtime kontainer: Hanya Docker dan Containerd yang didukung.

  Docker:

  • Memerlukan izin untuk mengakses docker.sock.

  • Untuk pengumpulan standard output, hanya driver logging json-file yang didukung.

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

  Containerd:

  • Memerlukan izin untuk mengakses containerd.sock.

• Batas log multi-baris:

  Untuk mencegah log multi-baris terpisah akibat keterlambatan output, baris terakhir yang dikumpulkan dibuffer selama periode singkat. Waktu buffer default adalah 3 detik. Anda dapat menyesuaikannya dengan parameter BeginLineTimeoutMs. Nilainya harus minimal 1.000 milidetik untuk menghindari penguraian yang salah.

• Standard output:

  Ukuran maksimum default untuk satu entri log adalah 524.288 byte (512 KB), dan batas atasnya adalah 8.388.608 byte (8 MB). Jika satu entri log melebihi 524.288 byte, Anda dapat menaikkan batas ini dengan mengatur variabel lingkungan max_read_buffer_size untuk kontainer LoongCollector.

  Penting

  Kami menyarankan agar Anda tidak mengaktifkan pengumpulan standard output dan standard error secara bersamaan karena dapat menyebabkan entri log saling tercampur secara salah.

Ikhtisar alur kerja pengumpulan

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

2. Instal kolektor LoongCollector: Gunakan LoongCollector untuk mengumpulkan dan mengirimkan log ke Simple Log Service.

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

4. Kueri dan analisis log: Kueri log yang telah dikumpulkan untuk memantau layanan Anda.

Proses utama

Persyaratan sumber log dan titik mount

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

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

  Persyaratan titik mount kustom

  Log file path:

  • Jangan gunakan tautan simbolik:

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

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

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

    1Mount point: /var/log/service
    2✅ Path pengumpulan valid: /var/log/service atau /var/log/service/subdir
    3❌ Path pengumpulan tidak valid: /var/log (Path tidak cukup spesifik)

Instalasi kolektor

Pilih mode penyebaran berdasarkan kasus penggunaan Anda:

Mode penyebaran: Simple Log Service mendukung instalasi LoongCollector menggunakan mode DaemonSet atau sidecar.

• Mode penyebaran DaemonSet: Setelah dikonfigurasi sekali, agen LoongCollector secara otomatis diterapkan di setiap node dalam kluster. Mode ini cocok untuk sebagian besar skenario.

  • Dalam mode DaemonSet, metode penyebaran yang tepat bergantung pada hubungan antara kluster Anda dan Simple Log Service.

    • Untuk kluster Container Service for Kubernetes (ACK), komponen loongcollector-ds telah terintegrasi sebelumnya. Anda hanya perlu mengaktifkan komponen tersebut di Konsol ACK untuk menyelesaikan instalasi. Secara default, metode ini mengikat kolektor ke Akun Alibaba Cloud pemilik kluster ACK, dan log disimpan di Project Simple Log Service akun tersebut. Untuk informasi lebih lanjut, lihat Instalasi dan konfigurasi.

    • Jika Anda menggunakan kluster ACK tetapi perlu mengumpulkan lognya ke Project Simple Log Service di bawah Akun Alibaba Cloud yang berbeda—misalnya karena struktur organisasi, isolasi izin, atau pemantauan terpusat—Anda harus menginstal komponen LoongCollector secara manual. Konfigurasikan dengan ID akun Alibaba Cloud atau AccessKey akun tujuan untuk terhubung ke akun tersebut. Untuk informasi lebih lanjut, lihat Instalasi dan konfigurasi.

    • Jika Anda menggunakan kluster self-managed, Anda harus menginstal komponen LoongCollector secara manual dan mengonfigurasikannya dengan ID akun Alibaba Cloud atau AccessKey akun tujuan untuk terhubung ke akun tersebut. Untuk informasi lebih lanjut, lihat Instalasi dan konfigurasi.

    Menginstal LoongCollector merupakan prasyarat untuk pengumpulan log. Untuk panduan lengkap yang mencakup langkah-langkah instalasi, lihat Kumpulkan log kontainer dari kluster Kubernetes menggunakan CRD (standard output/file).

• Mode penyebaran sidecar: Kontainer sidecar LoongCollector disuntikkan ke setiap pod aplikasi. Mode ini lebih kompleks untuk diterapkan dan dipelihara. Gunakan mode ini untuk pengumpulan log kontainer serverless, untuk node di mana volume data pod jauh melebihi kapasitas pengumpulan DaemonSet, atau untuk pengumpulan log di lingkungan Kubernetes yang menggunakan runtime kontainer aman. Untuk informasi lebih lanjut, lihat Kumpulkan log teks pod Kubernetes (mode sidecar).

Aturan pengumpulan

Simple Log Service menyediakan dua metode berikut untuk menentukan aturan pengumpulan:

Konsep utama

• Kubernetes: Kubernetes (K8s) adalah platform orkestrasi kontainer open-source yang mengotomatiskan penerapan, penskalaan, dan manajemen aplikasi berbasis kontainer. Ini merupakan infrastruktur inti untuk pengembangan dan operasi aplikasi cloud-native modern.

• Standard output, standard error, dan file log teks: Standard output (stdout) adalah informasi yang dicetak selama eksekusi program normal, seperti log bisnis dan catatan operasional. Secara default, diarahkan ke terminal dan ditangkap oleh engine kontainer. Standard error (stderr) adalah informasi tentang error atau peringatan, seperti stack trace exception atau kegagalan startup. Ini juga ditangkap oleh engine kontainer dan dapat tercampur dengan stdout. File log teks ditulis ke file oleh aplikasi, seperti access.log Nginx atau file log kustom. Log ini ditulis langsung ke sistem file kontainer dan dihapus saat kontainer dihancurkan, tetapi dapat dipertahankan dengan menggunakan volume.

• Mekanisme checkpoint: Checkpoint mencatat posisi tepat dalam file tempat Simple Log Service telah mengumpulkan log. Secara default, checkpoint disimpan di /tmp/logtail_checkpoint. Ini memastikan pengumpulan log yang andal setelah gangguan, seperti restart LoongCollector atau kegagalan node.

• LoongCollector (Logtail): LoongCollector adalah kolektor log berkinerja tinggi yang dikembangkan oleh Alibaba Cloud. Mendukung mode penyebaran DaemonSet dan sidecar di Kubernetes. LoongCollector adalah penerus Logtail dan sepenuhnya kompatibel mundur.

• CRD Kubernetes: CRD (CustomResourceDefinition) adalah mekanisme Kubernetes yang memungkinkan Anda mendefinisikan resource kustom dan membuat instans untuk konfigurasi. Tipe resource kustom yang disediakan oleh Simple Log Service adalah AliyunPipelineConfig.

• Konfigurasi pengumpulan: Konfigurasi pengumpulan menentukan aturan untuk jenis log yang akan dikumpulkan, path pengumpulan, pemfilteran log, penguraian konten log, dan lokasi penyimpanan di Simple Log Service. Untuk informasi lebih lanjut, lihat Apa itu konfigurasi pengumpulan?.

• Plugin parsing: Plugin parsing adalah unit pemrosesan yang digunakan dalam konfigurasi plugin pemrosesan dari konfigurasi pengumpulan. Digunakan untuk menstrukturkan, memisahkan, memfilter, atau mendesensitisasi konten log. Simple Log Service mendukung berbagai mode pemrosesan, termasuk ekspresi reguler, separator, JSON, dan multi-baris.

Cara kerja

1. Pengguna membuat Custom Resource (CR) menggunakan kubectl untuk menentukan aturan pengumpulan.

2. loongcollector-operator terus-menerus memantau perubahan pada CR di kluster.

3. Saat perubahan terdeteksi, Operator mengonversi CR menjadi konfigurasi LoongCollector dan menerapkannya ke Simple Log Service.

4. Agen LoongCollector secara berkala mengirim heartbeat ke Simple Log Service untuk mengambil pembaruan konfigurasi, menarik konfigurasi pengumpulan terbaru, dan menerapkannya secara dinamis.

5. Agen loongcollector-ds mengumpulkan log sesuai konfigurasi baru dan mengirimkannya ke SLS melalui titik akhir yang dikonfigurasi.

Mode DaemonSet

Agen LoongCollector diterapkan di setiap node dalam kluster untuk mengumpulkan log dari semua kontainer di node tersebut. Mode ini memiliki operasi sederhana, konsumsi sumber daya rendah, dan konfigurasi fleksibel, tetapi menawarkan isolasi antar penyewa yang lebih lemah.

Cara kerja mode DaemonSet

• Dalam mode DaemonSet, kluster Kubernetes memastikan hanya satu kontainer LoongCollector yang berjalan di setiap node untuk mengumpulkan log dari semua kontainer di node tersebut.

• Saat node baru bergabung ke kluster, Kubernetes secara otomatis membuat kontainer LoongCollector di atasnya. Saat node meninggalkan kluster, Kubernetes secara otomatis menghancurkan kontainer LoongCollector di node tersebut. Penskalaan otomatis ini berarti Anda tidak perlu mengelola instans LoongCollector secara manual.

Sidecar mode

Di setiap pod, kontainer sidecar LoongCollector disuntikkan bersama kontainer aplikasi. Direktori log kontainer aplikasi dipasang sebagai volume bersama menggunakan mekanisme volume Kubernetes, seperti emptyDir, hostPath, atau PVC. Hal ini membuat file log dapat diakses oleh kontainer aplikasi dan kontainer sidecar, sehingga LoongCollector dapat membacanya secara langsung. Mode ini memberikan isolasi multi-penyewa yang kuat dan kinerja tinggi tetapi mengonsumsi lebih banyak sumber daya serta lebih kompleks untuk dikonfigurasi dan dipelihara.

Cara kerja mode sidecar

• Dalam mode sidecar, setiap pod menjalankan kontainer LoongCollector khusus untuk mengumpulkan log dari semua kontainer lain dalam pod yang sama. Pengumpulan log diisolasi antar pod yang berbeda.

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

• Jika volume data satu pod di node sangat besar dan melebihi kapasitas pengumpulan agen DaemonSet, mode sidecar memungkinkan Anda mengalokasikan sumber daya khusus ke LoongCollector, meningkatkan kinerja dan stabilitas pengumpulannya.

• Lingkungan kontainer serverless tidak memiliki konsep node, sehingga mode penyebaran DaemonSet tidak dapat diterapkan. Dalam kasus ini, mode sidecar berintegrasi secara efektif dengan arsitektur serverless, memastikan proses pengumpulan log yang fleksibel dan adaptif.

Penemuan kontainer

Untuk mengumpulkan log dari kontainer lain, kontainer LoongCollector harus terlebih dahulu mengidentifikasi kontainer mana yang sedang berjalan di node. Proses ini disebut penemuan kontainer.

• Selama penemuan kontainer, kontainer LoongCollector berkomunikasi langsung dengan daemon runtime kontainer di node, bukan dengan kube-apiserver kluster Kubernetes. Hal ini memungkinkannya mendapatkan informasi tentang semua kontainer di node saat ini tanpa memberikan beban tambahan pada kube-apiserver kluster.

• LoongCollector mengakses socket runtime kontainer (Docker atau Containerd) di host untuk mendapatkan konteks kontainer. Mendukung penyertaan atau pengecualian kontainer dari pengumpulan log berdasarkan kriteria seperti nama namespace, nama pod, label pod, dan variabel lingkungan kontainer.

Pengumpulan keluaran standar

LoongCollector secara otomatis mengidentifikasi API atau driver logging yang tepat untuk berbagai runtime kontainer, seperti Docker dan Containerd, berdasarkan metadata kontainer. Tidak diperlukan konfigurasi manual. Membaca aliran standard output dari semua kontainer secara langsung, tanpa mengakses sistem file di dalam kontainer.

Pengumpulan log file teks kontainer

• Karena sistem file kontainer Kubernetes terisolasi, kolektor tidak dapat langsung mengakses file di kontainer lain. Namun, karena sistem file kontainer berada di sistem file host, LoongCollector dapat memasang sistem file root host. Hal ini memungkinkannya mengakses file apa pun di host, sehingga secara tidak langsung mengakses file di sistem file kontainer aplikasi.

• Secara default, LoongCollector memasang sistem file root host ke direktorinya sendiri /logtail_host. Pemasangan manual biasanya 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, path pengumpulan aktual yang digunakan LoongCollector adalah /logtail_host/var/lib/docker/containers/<container-id>/log/app.log.

Parsing log multi-baris

LoongCollector menggunakan ekspresi reguler yang ditentukan pengguna untuk mencocokkan awal baris log.

• Pencocokan berhasil: Baris tersebut dianggap sebagai awal entri log baru.

• Pencocokan gagal: Baris tersebut ditambahkan ke entri log saat ini.

Saat baris lain mencocokkan ekspresi reguler awal-baris, hal ini menyelesaikan entri log saat ini dan memulai yang baru.

Pemrosesan log saat kontainer berhenti

Pengambilan metadata kontainer

LoongCollector berinteraksi langsung dengan runtime kontainer melalui API CRI (Container Runtime Interface) standar untuk mengambil metadata Kubernetes. Hal ini memungkinkan pelabelan metadata Kubernetes secara otomatis dan non-intrusif selama pengumpulan. Interaksi langsung ini memungkinkan pengambilan data secara real-time.

• Docker: LoongCollector menggunakan Docker Client untuk berkomunikasi dengan Docker Daemon guna mengambil metadata kontainer secara langsung. Hal ini memungkinkan pemantauan dan manajemen mendalam. API utama yang digunakan meliputi:

  • ContainerList: Mengambil daftar kontainer yang sedang berjalan, memberikan ikhtisar kontainer aktif di node.

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

  • Events: Mendengarkan event kontainer secara real time, memungkinkan pelacakan dinamis siklus hidup kontainer.

  Saat mengambil metadata kontainer melalui Docker Client, informasi berikut sangat penting:

  • LogPath: Path di host tempat file log standard output kontainer disimpan. Ini penting untuk pengumpulan dan analisis log.

  • GraphDriver.Data: Path rootfs kontainer di host. Path ini penting untuk memahami penyimpanan sistem file kontainer dan membantu troubleshooting serta optimasi kinerja.

• Containerd: Dengan menggunakan CRI, LoongCollector mendukung lingkungan containerd dan CRI-O. Hal ini memungkinkannya mengumpulkan metadata dari berbagai runtime dasar, seperti runc atau Kata Containers, memastikan pengumpulan data yang konsisten.

  • Metadata kontainer yang disediakan oleh CRI mencakup path file log standard output kontainer di host tetapi tidak secara langsung menyediakan path rootfs kontainer. Metode berikut digunakan untuk menemukan path ini:

    • Pencarian path file: LoongCollector mencari sistem file host untuk menemukan path rootfs kontainer menggunakan pengenal uniknya (seperti ID kontainer).

    • Interaksi langsung dengan containerd: Untuk mendapatkan informasi lebih komprehensif, LoongCollector dapat melewati CRI dan berkomunikasi langsung dengan containerd pada level yang lebih rendah. Hal ini memungkinkannya mendapatkan path rootfs kontainer dan metadata penting lainnya yang tidak tersedia melalui CRI.