Simple Log Service:Analisis latensi pengumpulan log LoongCollector

Gejala

Di dasbor LoongCollector Pipeline Monitoring pada CloudLens for SLS, lihat laporan Pipeline Overview. Kolom terakhir, Quota error count, menunjukkan jumlah kali LoongCollector gagal menulis ke SLS dalam rentang waktu yang dikueri karena melebihi batas sisi server.

Saat LoongCollector mengalami pembatasan kecepatan, Quota error count ditandai dengan warna merah.

Penyebab

SLS mencakup konsep resource seperti Projects, LogStores, dan Shards. Untuk menjamin Quality of Service (QoS) yang andal bagi semua penyewa, setiap resource memiliki batas pembatasan kecepatan resource dan solusi (yaitu, kuota) terkait. Melebihi batas ini dapat menyebabkan kegagalan pembacaan dan penulisan data atau eksepsi permintaan.

Dalam skenario pengumpulan data LoongCollector, dua kesalahan kuota umum adalah:

• WriteQuotaExceed: Kesalahan ini menunjukkan bahwa total volume data atau jumlah permintaan penulisan ke suatu Project dalam periode waktu tertentu telah melebihi batas kuota, sehingga permintaan berikutnya gagal. Kesalahan ini tidak selalu disebabkan oleh satu konfigurasi pengumpulan, tetapi dapat berasal dari trafik gabungan dari beberapa konfigurasi pengumpulan dan LogStore.

• ShardWriteQuotaExceed: Kesalahan ini menunjukkan bahwa total volume data atau jumlah permintaan penulisan ke satu LogStore telah melebihi batas kuotanya. Kapasitas penulisan LogStore ditentukan oleh Shards-nya. Untuk informasi lebih lanjut, lihat Manage Shards.

Saat LoongCollector gagal mengirim data karena kuota terlampaui, sistem terus mencoba ulang hingga data berhasil dikirim. Namun, total volume data yang dikirim tidak dapat melebihi batas kuota. Hal ini menciptakan antrean permintaan yang terus bertambah. Akibatnya, setiap permintaan menunggu lebih lama untuk dikirim, sehingga menyebabkan latensi pengumpulan.

Di dasbor LoongCollector Pipeline Monitoring pada CloudLens for SLS, Anda dapat memeriksa Pipeline Send Status Details untuk menentukan apakah batas yang terlampaui berlaku untuk Project atau Shard LogStore.

Solusi

• Jika kuota penulisan Project terlampaui, rujuk bagian "Manage resource quotas" di Manage Shards untuk menyesuaikan parameter Project write traffic limit dan Project write QPS limit. Kemudian, ajukan permintaan peningkatan kuota.

  • Sebagai panduan umum, Anda dapat mengajukan peningkatan kuota saat ini sekitar 50% setiap kali.

• Jika kuota penulisan Shard LogStore terlampaui, rujuk bagian split shard dan auto-split shard di Manage Shards untuk menyesuaikan jumlah Shard pada LogStore tersebut.

  • Setiap Shard mendukung penulisan data hingga 5 MB/detik atau 500 permintaan per detik, serta pembacaan data hingga 10 MB/detik atau 100 permintaan per detik. Ini merupakan batas lunak (soft limits). Jika dilampaui, SLS tetap memberikan layanan tetapi tidak dapat menjamin kualitas layanan.

  • Anda dapat menjalankan pernyataan ((__topic__: loongcollector_metric and category: pipeline and source_ip:* and labels.project: * and labels.logstore: *))| select "labels.project" as project, "labels.logstore" as logstore, round(sum(flusher_in_size_bytes)/1024.0/1024.0, 2) as output_size_bytes group by project, logstore order by output_size_bytes desc limit all di LogStore log operasional Project terkait untuk menghitung volume penulisan data mentah ke berbagai LogStore tujuan. Untuk memperkirakan jumlah Shard yang dibutuhkan, ambil nilai maksimum dari hasil tersebut, bagi dengan 5, lalu tambahkan buffer 20%.

Konfigurasi peringatan

Melebihi kuota merupakan masalah kritis. Kami merekomendasikan membuat aturan peringatan.

Anda dapat memeriksa data self-monitoring setiap 10 menit untuk pesan kesalahan kuota dan segera mengambil tindakan pada Project atau LogStore yang terdampak guna mencegah gangguan pelaporan data.

• Jenis log yang dipantau: operational log

• Kondisi filter: Nilai bidang flusher_project_quota_error_total atau flusher_shard_write_quota_error_total lebih besar dari 0. Bidang-bidang ini masing-masing merepresentasikan jumlah kuota Project yang terlampaui dan jumlah kuota Shard LogStore yang terlampaui.

• Bidang tampilan: Tampilkan Project (labels.project), LogStore (labels.logstore), dan konfigurasi pengumpulan (labels.pipeline_name) yang mengalami kesalahan kuota dalam periode waktu tertentu.

• Interval kueri: 10 menit. Peringatan ini menggunakan data self-monitoring yang memiliki __topic__ bernilai loongcollector_metric, yang memiliki interval pelaporan 10 menit.

• Contoh kueri

__topic__: loongcollector_metric and (flusher_project_quota_error_total>0 or flusher_shard_write_quota_error_total>0) | select "labels.project" as project, "labels.logstore" as logstore, split_part("labels.pipeline_name", '$', 2) as pipeline_name, sum(flusher_project_quota_error_total) as project_quota_error_total, sum(flusher_shard_write_quota_error_total) as shard_write_quota_error_total group by project, logstore, pipeline_name having project_quota_error_total>0 or shard_write_quota_error_total>0 order by pipeline_name limit all

Gejala

Di dasbor LoongCollector Pipeline Monitoring pada CloudLens for SLS, gulir ke bawah hingga Pipeline Send Status Details. Jika Send Request Retry Rate tinggi sedangkan Project write quota exceeded count dan LogStore Shard write quota exceeded count bernilai 0, hal ini menunjukkan tidak ada kesalahan terkait kuota. Sebaliknya, tingginya laju percobaan ulang mengindikasikan bahwa kualitas jaringan buruk menghambat pelaporan data tepat waktu dan menyebabkan collection latency.

Penyebab

Secara internal, LoongCollector menggunakan pipeline untuk membaca, memproses, dan mengirim data. Setelah data dibaca dari file, data tersebut secara berurutan diteruskan ke antrian pemrosesan lalu ke antrian pengiriman. Jika kapasitas pengiriman LoongCollector terbatas karena kualitas jaringan buruk, volume data besar, atau alasan lain, data tidak dapat segera dikirim ke SLS. Hal ini tidak hanya menunda kueri data di SLS, tetapi juga menyebabkan akumulasi data di antrian pengiriman. Akumulasi ini menciptakan back pressure pada antrian pemrosesan dan thread pembacaan, sehingga semakin meningkatkan latensi pengumpulan.

Solusi

1. Periksa kualitas jaringan lokal Anda. Jika server bisnis dan Project SLS berada di wilayah berbeda (misalnya, satu di Tiongkok daratan dan satu di luar negeri), Anda tidak dapat menggunakan jaringan internal. Mengirim data melalui internet publik dapat menyebabkan latensi jaringan tinggi dan ketidakstabilan. Dalam kasus ini, Anda dapat menggunakan Transfer Acceleration untuk stabilitas dan performa jaringan yang lebih baik.

2. LoongCollector dapat mempercepat pengiriman data dengan meningkatkan konkurensi pengiriman. Untuk mengubah parameter startup, lihat Set startup parameters. Anda dapat fokus menyesuaikan konkurensi pengiriman send_request_concurrency dan trafik pengiriman maksimum max_bytes_per_sec.

Konfigurasi peringatan

Konfigurasikan peringatan untuk laju percobaan ulang permintaan pengiriman yang tinggi.

• Jenis log yang dipantau: operational log

• Kondisi filter: Filter metrik yang terkait dengan konfigurasi pengumpulan LoongCollector.

• Bidang tampilan: Tampilkan Project, LogStore, dan konfigurasi pengumpulan yang memiliki laju percobaan ulang tinggi dalam periode waktu tertentu.

• Interval kueri: 10 menit. Metrik dilaporkan setiap 10 menit. Laju percobaan ulang tinggi dalam interval 10 menit mengindikasikan bahwa LoongCollector mungkin mengalami latensi pengumpulan.

• Contoh kueri

((__topic__: loongcollector_metric and category: pipeline and source_ip:* and labels.pipeline_name:* and labels.project: *))| select "labels.project" as project, split_part("labels.pipeline_name", '$', 2) as pipeline_name,  (sum(flusher_send_done_total)-sum(flusher_success_total))*1.0/(sum(flusher_send_done_total)) as "send_retry_rate" group by project, pipeline_name having "send_retry_rate">0.1 and "send_retry_rate"<=1 order by "send_retry_rate" desc limit all 

Gejala

Pertama-tama, pastikan kuota penulisan sisi server SLS tidak terlampaui dan tidak ada bottleneck pada pengiriman data LoongCollector.

• Periksa bottleneck pengumpulan

  Buka Exception Monitoring di CloudLens for SLS, lihat All Error Messages di bagian Collection Exception Monitoring, lalu filter berdasarkan jenis peringatan PROCESS_QUEUE_BUSY_ALARM. Banyaknya peringatan ini menunjukkan adanya bottleneck performa pemrosesan di LoongCollector yang menyebabkan latensi pengumpulan. Di Konsol CloudLens for SLS, pilih Report Center > Collection Monitoring, lalu klik tab Exception Monitoring. Di bagian Collection Exception Monitoring, lihat semua pesan kesalahan. Jika PROCESS_QUEUE_BUSY_ALARM muncul di kolom Alert Type, hal ini menunjukkan bahwa antrian pemrosesan log penuh (Detail peringatan: logprocess queue is full, put modify event to event queue again).

• Identifikasi konfigurasi pengumpulan dengan waktu pemrosesan tinggi

  Di dasbor LoongCollector Pipeline Monitoring pada CloudLens for SLS, Anda dapat melihat laporan Pipeline Processing Time Percentage untuk mengidentifikasi konfigurasi pengumpulan dengan waktu pemrosesan tinggi.

Penyebab

LoongCollector memberikan performa pengumpulan yang sangat baik. Untuk informasi lebih lanjut, lihat Log Collection Agent Performance Comparison—In-depth Performance Review of LoongCollector. Satu thread yang hanya menggunakan plugin native dapat memproses data lebih dari 100 MB/detik. Namun, jika konfigurasi pengumpulan menggunakan plugin extended, ekspresi reguler kompleks, atau rantai beberapa plugin, LoongCollector tetap dapat mencapai bottleneck performa saat volume datanya besar. Dalam kasus ini, pertimbangkan terlebih dahulu mengganti plugin extended dengan plugin SPL atau plugin native untuk meningkatkan performa pemrosesan. Jika performa masih belum mencukupi, Anda perlu menyesuaikan jumlah thread pemrosesan internal dan batas penggunaan CPU LoongCollector agar data dapat diproses lebih efisien.

Solusi

• Pertama, ganti semua plugin extended dengan plugin native atau gunakan Logtail SPL untuk mengurai log guna meningkatkan performa pemrosesan secara signifikan. Sebagian besar plugin extended yang umum digunakan, seperti untuk penguraian ekspresi reguler atau ekspansi JSON, memiliki plugin native yang setara. Untuk informasi lebih lanjut, lihat Processor Plugin List.

• Jika performa pemrosesan masih belum mencukupi setelah Anda mengganti sebanyak mungkin plugin extended dengan plugin native, Anda dapat mempercepat pemrosesan data di LoongCollector dengan meningkatkan batas penggunaan CPU dan jumlah thread pemrosesan. Lihat Set startup parameters untuk mengubah parameter startup LoongCollector, dan fokuslah menyesuaikan cpu_usage_limit dan process_thread_count.

Konfigurasi peringatan

Konfigurasikan peringatan untuk kesalahan PROCESS_QUEUE_BUSY_ALARM. Perhatikan bahwa sesekali munculnya kesalahan PROCESS_QUEUE_BUSY_ALARM mungkin disebabkan oleh lonjakan tiba-tiba data yang ditulis ke file log dan tidak menyebabkan latensi pengumpulan. Hanya kesalahan persisten yang mengindikasikan bahwa LoongCollector memiliki kapasitas pemrosesan tidak mencukupi.

• Jenis log yang dipantau: operational log

• Kondisi filter: alarm_type adalah PROCESS_QUEUE_BUSY_ALARM, yang menunjukkan bahwa antrian pemrosesan penuh.

• Bidang tampilan: Tampilkan Project, LogStore, dan konfigurasi pengumpulan yang mengalami kesalahan pemrosesan lambat dalam periode waktu tertentu.

• Interval kueri: 5 menit. Interval peringatan adalah 30 detik. Jika terjadi lebih dari lima kesalahan dalam lima menit, hal ini mengindikasikan bahwa LoongCollector mengalami latensi pengumpulan akibat kapasitas pemrosesan tidak mencukupi.

• Contoh kueri

__topic__: logtail_alarm and alarm_type: PROCESS_QUEUE_BUSY_ALARM  | SELECT project, logstore, split_part(config_name, '$', 2) as "collection_configuration", count(1) as cnt from log group by project, logstore, config_name  having cnt >5 order by cnt desc limit all